"Rick Lupton" 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?
>
>
>
>
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]{}}
@span[:html-style height: 300]{}
> 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:
\(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 .
Support Org development at ,
or support my work at
