From: Ihor Radchenko <yantar92@posteo.net>
To: Rick Lupton <mail@ricklupton.name>
Cc: "Juan Manuel Macías" <maciaschain@posteo.net>,
"Y. E." <emacs-orgmode@gnu.org>
Subject: Re: Attributes on images (was:: Experimental public branch for inline special blocks)
Date: Sun, 14 Apr 2024 19:26:53 +0000 [thread overview]
Message-ID: <87seznrbia.fsf@localhost> (raw)
In-Reply-To: <f693e6b3-36d8-4e41-9e49-a0ebe8d989b3@app.fastmail.com>
"Rick Lupton" <mail@ricklupton.name> writes:
>> #+attr_html: :height 300
>> [[file:image.png]] has a height of 300, but what if we want a
>> different height in @@[:html-height 300]{[[file:another-image.png]]}?
>>
>> Note how @@{...} markup assigns attributes to objects inside - the
>> attributes should be somehow inherited.
>
> This way of assigning a height to the image seems odd to me. Mostly, the attributes specified by the inline block apply to the block, not the contents, so wouldn't this case be potentially surprising?
We already have #+attr_html: :height 300 that applies to the whole
paragraph and it is not going anywhere. So, my idea is natural given the
existing convention.
And I explicitly suggested that attributes of anonymous inline blocks
@@[...]{...} will be inherited by all other markup. This is not just for
images, but in case if we want some extra configuration for other
traditional Org markup:
@@[:weight semi-bold]{All the *bold text here* will *be* semi-bold.}
Also, one may do something like
@@[:html-height 300]{This [[file:image.png]] and that
[[file:other-image.png]]}, but not third [[file:yet-another-image.png]].
> Both of these examples mean different things in HTML, and it seems like you might want to create either -- how would you control which was produced using the "@@[:html-height 300]{[[file:another-image.png]]}" syntax?
>
> <span><img height="300"></span>
>
> <span style="height: 300"><img></span>
Anonymous inline markup will not at all be exported by itself. Its
purpose is to provide attributes or serve as back escape sequence.
So, I envision your examples as
@span{@@[:html-height 300]{<file:image.png>}}
@span[:html-style height: 300]{<file:image.png>}
> Instead, I wonder if the problem is that the way of inserting an image using a link itself. If you need more control, could there be a special "img" inline special block which can handle additional attributes?
>
> For example:
>
> Or, if using the original syntax, perhaps the attribute should be explicitly :img-attr or :img-height to resolve the ambiguity about which element is being targetted?
I do not have much of an opinion about the attribute names. If we need
to make them unique, that's totally fine and does not affect the overall
syntax design. I used image height simply as an illustration of the idea
of attribute inheritance. The above example with attributes for *bold*
is illustrating the same idea.
> @img[:height 300]{image.png} has a height of 300, and we can also have images with different heights and attributes like @img[:height 400 :alt "An image"]{another-image.png}.
This is also an option, although it allows setting attributes only for a
single image. Maybe we can modify the anonymous markup to make its
attributes be inherited by a subset of the markup inside:
@@[:parent-of link :height 300]{Only [[file:link.png]] inherits :height
attribute, but not @bold{other markup}}
This way, we can have some interesting options for ad-hoc markup like
#+inline_attr:tall: :parent-of link, latex-fragment :height 1000
@tall{All the images and latex inside will be tall: <file:1.png>
<file:2.png> \(x^2\)}
Another aspect of your example is that you implicitly suggested an
alternative link markup, which raises a more general question - should
we allow making the inline markup an alias of an existing markup?
This may require two alternative approaches:
a. Special treatment of certain inline markup names, like
@code{verbatim code}
@verbatim{...}
@bold{...}
@italic{...}
@underline{...}
@strikethrough{...}
@link[...]{path}{description}
(we need such special treatment to make sure that, for example,
@bold{...} in Org files can still be correctly exported by export
backends not aware about the new inline markup)
b. In addition to :export_template idea I proposed that would define
custom *per-backend* export rules, we will need some way to define
ad-hoc markup in terms of the more traditional Org markup:
@code{...} == ~code~
@bold{...} == *bold*
or even
@alert{...} == @bold{@italic{...}}
I personally feel that b is more powerful, but it is getting so close to
the idea of {{{macros}}} that we may confuse users.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
next prev parent reply other threads:[~2024-04-14 19:27 UTC|newest]
Thread overview: 83+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-01 20:34 Experimental public branch for inline special blocks Juan Manuel Macías
2024-03-02 8:29 ` Stefan Nobis
2024-03-02 10:57 ` Juan Manuel Macías
2024-03-03 20:29 ` Juan Manuel Macías
2024-03-10 2:08 ` `:export' attribute?: " Juan Manuel Macías
2024-03-10 13:54 ` Juan Manuel Macías
2024-03-11 10:27 ` Max Nikulin
2024-03-11 13:59 ` Juan Manuel Macías
2024-03-11 17:01 ` Max Nikulin
2024-03-11 20:19 ` Juan Manuel Macías
2024-03-12 8:32 ` Stefan Nobis
2024-03-12 13:45 ` Juan Manuel Macías
2024-03-12 16:20 ` Max Nikulin
2024-03-12 17:41 ` Juan Manuel Macías
2024-03-13 16:08 ` Max Nikulin
2024-03-13 16:48 ` Juan Manuel Macías
2024-03-13 17:16 ` Juan Manuel Macías
2024-03-15 2:19 ` Juan Manuel Macías
2024-03-15 10:52 ` Max Nikulin
2024-03-15 13:10 ` Juan Manuel Macías
2024-03-15 17:21 ` Max Nikulin
2024-03-15 14:00 ` Ihor Radchenko
2024-03-15 11:11 ` Max Nikulin
2024-03-15 14:19 ` Ihor Radchenko
2024-03-15 16:26 ` Juan Manuel Macías
2024-03-16 14:07 ` Max Nikulin
2024-03-18 19:42 ` Juan Manuel Macías
2024-03-19 14:54 ` Max Nikulin
2024-03-19 17:47 ` Juan Manuel Macías
2024-03-21 10:26 ` inline-special-block: export rules (was: `:export' attribute?: Re: Experimental public branch for inline special blocks) Juan Manuel Macías
2024-03-26 16:56 ` inline-special-block: export rules Max Nikulin
2024-03-04 17:13 ` naming: Re: Experimental public branch for inline special blocks Max Nikulin
2024-03-04 17:29 ` Ihor Radchenko
2024-03-04 17:49 ` Juan Manuel Macías
2024-03-05 10:53 ` Max Nikulin
2024-03-05 11:04 ` Ihor Radchenko
2024-03-05 15:16 ` Suhail Singh
2024-03-05 15:23 ` Suhail Singh
2024-03-05 15:16 ` Juan Manuel Macías
2024-03-06 10:42 ` Max Nikulin
2024-03-06 10:56 ` Ihor Radchenko
2024-03-07 10:34 ` Max Nikulin
2024-03-07 14:12 ` Ihor Radchenko
2024-03-08 5:26 ` Samuel Wales
2024-03-08 16:32 ` Max Nikulin
2024-03-08 16:41 ` Ihor Radchenko
2024-03-04 18:07 ` Juan Manuel Macías
2024-03-04 22:17 ` Samuel Wales
2024-03-04 22:18 ` Samuel Wales
2024-03-05 16:47 ` smallcaps: " Max Nikulin
2024-03-05 17:28 ` Juan Manuel Macías
2024-03-06 10:55 ` Max Nikulin
2024-03-06 15:21 ` Juan Manuel Macías
2024-03-06 16:53 ` To avoid zero width space: " Max Nikulin
2024-03-06 18:27 ` Juan Manuel Macías
2024-03-06 21:13 ` Juan Manuel Macías
2024-03-07 10:57 ` false positives: " Max Nikulin
2024-03-07 11:06 ` Juan Manuel Macías
2024-03-07 11:18 ` Ihor Radchenko
2024-03-07 11:19 ` Juan Manuel Macías
2024-03-07 15:53 ` Juan Manuel Macías
2024-03-07 16:09 ` Ihor Radchenko
2024-03-07 16:57 ` Juan Manuel Macías
2024-03-07 18:21 ` Juan Manuel Macías
2024-03-08 13:58 ` Max Nikulin
2024-03-08 15:44 ` Juan Manuel Macías
2024-03-08 16:04 ` Max Nikulin
2024-03-08 16:15 ` Ihor Radchenko
2024-03-08 18:44 ` Juan Manuel Macías
2024-03-08 18:57 ` Juan Manuel Macías
2024-03-09 11:10 ` Max Nikulin
2024-03-09 11:48 ` Juan Manuel Macías
2024-03-09 15:24 ` Juan Manuel Macías
2024-03-10 7:11 ` Max Nikulin
2024-04-09 8:52 ` Ihor Radchenko
2024-04-09 10:51 ` Max Nikulin
2024-04-09 14:05 ` Ihor Radchenko
2024-04-10 23:00 ` Juan Manuel Macías
2024-04-11 12:26 ` Ihor Radchenko
2024-04-11 13:47 ` Juan Manuel Macías
2024-04-14 15:59 ` Attributes on images (was:: Experimental public branch for inline special blocks) Rick Lupton
2024-04-14 19:26 ` Ihor Radchenko [this message]
2024-04-11 11:06 ` Experimental public branch for inline special blocks Max Nikulin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87seznrbia.fsf@localhost \
--to=yantar92@posteo.net \
--cc=emacs-orgmode@gnu.org \
--cc=maciaschain@posteo.net \
--cc=mail@ricklupton.name \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).