tftor...@tftorrey.com (T.F. Torrey) writes: >> It would be ATTR_HTML: :class "XXX". I try to unify syntax for >> attributes with syntax for Babel and AFAICT, `html' is the last back-end >> to have key="value" syntax. > > I see that this does not presently work, and the author listed on > ox-html.el is not currently active on this list. I hope you are not the > only one working on this. It would be our great misfortune for you to > become burned out.
It's not much work once we agree about the real syntax. For example, for links, there are two ways to replace: #+ATTR_HTML: width="400px" The easiest one, is simply to ask for `:options' before: #+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. 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</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
