Re: Attributes on images (was:: Experimental public branch for inline special blocks)

[Ihor Radchenko]

"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>