"Rick Lupton" <m...@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>