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

[Ihor Radchenko <yantar92@posteo.net>]

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