Re: Bug: New HTML exporter incorrect attributes

[Nicolas Goaziou <n.goaziou@gmail.com>]

tftorrey@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