Re: [O] [PATCH] export to various flavors of (X)HTML

[Eric Abrahamsen]

Carsten Dominik <address@hidden> writes:

> Hi Eric, Rick, Francois and others,
>
> Nicolas commented to me about this patch that he was wondering if it
> would not be better to have a separate backend for html5, i.e.
> ox-html5.el that could be derived from ox-html.el and make it easier
> in the future to build it out to take full advantage of html5 features.
> I think he has a point, and I would like to hear your comments.

My initial reaction is: yes, eventually, but perhaps not now. A few
reasons:

1. This patch is already done, and it works, modulo bugfixes (not a
great reason, I know).

2. The patch ended up with two predicate functions (org-html-xhtml-p and
org-html-html5-p) because we really are dealing with four distinct
states: X or not, and 5 or not. Splitting off ox-html5 only isolates one
of those predicates: the "X or not" question would still have to be
asked and answered in both ox-html and ox-html5. You could just as well
split it the other way (ox-xhtml and ox-html), and have the X variants
actually build a DOM tree and write xml (I'm not actually advocating
that, but I just read this[1]).

3. The change to org-html-special-block takes care of the large majority
of new html5 features. The change to inline-images is fairly small.
Otherwise, there are many new inline elements that could be used, but in
many cases browser support for these is limited or nonexistent, and even
basic syntax is up in the air. They can wait (or be handled with custom
link types).

More importantly, the html5 version of, for example, the formatting of
timestamps would look very like the (x)html(4) version, except that the
final tag would be a bit different (<time> instead of <span>, with
different attributes). Most of the surrounding logic would be the same.
So ox-html5 would only override a few of ox-html's formatting functions,
and even those few would largely be copy-n-paste from ox-html. I'm not
sure that's worth it. (Unless derived backends could call back to their
parent backends' implementations, a la OO inheritance? But that way lies
madness.)

To be clear, I think *something* more drastic should be done. But my
feeling is: go with this patch for now. Then stop there. The next time
someone feels the need to expand org's html5 capabilities, think about
new backends.

I'm happy to continue with the discussion, and the coding. I think part
of the problem is HTML itself: as Rick's polyglot concerns show, the
formats can be multiple things at once. Another part of the problem is
that org has a certain take on HTML that I guess comes out of the early
days of Unix documentation, when it really was the HyperText Markup
Language: linked sets of static pages, with up/prev/next links, and
headers and footers on each page. `org-html-divs' is a good example of
this, and a perfect example of where html5 would handle things
differently. I would argue that that should no longer be the default
point of view on HTML. If we're going to rethink things, let's rethink
this too.

Eric

[1] http://glyph.twistedmatrix.com/2008/06/data-in-garbage-out.html


> On 2.5.2013, at 23:07, Eric Abrahamsen <address@hidden> wrote:
>
>> Rick Frankel <address@hidden> writes:
>> 
>>> On Tue, Apr 30, 2013 at 08:26:52PM -0700, Eric Abrahamsen wrote:
>>>> Rick Frankel <address@hidden> writes:
>>>> 
>>>>> Whoops. Wrong key. Patch actually attached to this email...
>>>>> rick
>>>> 
>>>> Great, I'll consolidate all these -- would it be better to mush them
>>>> into one big patch, or to keep them separate (I suppose for ease of
>>>> rollback, if something goes wrong)?
>>> 
>>> Probably squashing them into one patch would be the best. But Carsten
>>> or Bastien might disagree :).
>>> 
>>> rick
>> 
>> Okay, there it is: one big patch (including your xml declaration fix).
>> 
>> I didn't add any more refined handling of the html5-fancy option. As a
>> second-order option it didn't seem worthy of an #+OPTIONS entry, and I
>> didn't bother checking for an empty string, either. It can always be
>> #+BINDed if necessary, and if it ever annoys anyone I can fix it
>> further.
>> 
>> E
>> 
>> <0001-ox-html.el-Export-to-different-X-HTML-flavors-includ.patch>