> #+ATTR_HTML: :options "width=\"400px\"" > > This is heavier but will be consistent with other back-ends. Otherwise, > there is also: > > #+ATTR_HTML: :width "400px" > > But this requires to have a list of all properties supported. How about both? I.e. a short-list of common options (class, title, id for links typically) plus a generic "options" as a back up to put whatever is not in the short-list ?
/v, big fan of the ugliest solutions imaginable > If we take > that route, here is a suggested list of such properties for <a> tag: > > - rel > - target > - type > - accesskey > - class > - style > - title > > and for <img> > > - alt > - height > - width > > What do you think about it? > > > The HTML exporter should produce valid HTML regardless of the input. > > We cannot remove the ability to shoot oneself in the foot. The HTML > back-end cannot be responsible for undefined syntax. Think about: > > @@html:<foo>@@ > > > The Org manual describes ATTR_HTML as a feature that applies to the > > following image or link. It makes no mention of restrictions to > > following content in the paragraph, and neither does it say it will > > apply to all following images or links. The manual could be amended to > > say that ATTR_HTML applies to just the next image or link. To fit the > > current situation, it might say, "In cases where ATTR_HTML is applied to > > an image in a paragraph, following links will not be made invalid." But > > why would anyone be expecting invalid HTML in the first place? > > > > Incidentally, I always thought that simply using another HTML_ATTR would > > handle multiple images or links in the old exporter. In other words, > > this: > > > > #+ATTR_HTML: width="10" alt=" [Cool thing] " > > [[file:cool_thing.jpg]] > > This is a paragraph about cool things. > > #+ATTR_HTML: class="bar" > > Cool thing found here [[http://example.com/][example.com]]. > > > > Would become this: > > > > <p> > > <img src="cool_thing.jpg" width="10" alt=" [Cool thing] "/>This is a > > paragraph about cool things. Cool thing found here <a > > href="http://example.com/" class="bar">example.com (http://example.com)</a>. > > </p> > > > > I don't remember using that in the old exporter, but I thought it would > > work. > > > > It almost works in the new exporter, but it begins a new paragraph > > before the second #+ATTR_HTML. I'm not sure this is the intended > > behavior, though, because it isn't formatted like other new > > paragraphs. > > > > This is the intended behaviour. Affiliated keywords can only exist at > the beginning of the element they refer to. So, in the previous example, > you start two paragraphs. > > > Alternatively, having ATTR_HTML (or something more general) apply to the > > next thing, and having that work within paragraphs, is another > > possibility. However, this may not fit within the limitations of the > > new parser. Plus it's kind of ugly. > > > > The parser won't support it. It goes against the definition of an > affiliated keyword. Moreover, it's merely a hack (what about links in > tables?). And it's ugly, indeed. > > > Until there is a "proper" solution, however, could we please modify the > > exporter to apply ATTR_HTML to only the next image or link? I am very > > sure that was the spirit of the old exporter, and it would be nice if I > > could maintain my documents in Org without resorting to (even more) > > hacks. > > > > Done. > > > Regards, > > -- > Nicolas Goaziou