Carsten Dominik <carsten.domi...@gmail.com> 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 <e...@ericabrahamsen.net> wrote: > >> Rick Frankel <r...@rickster.com> writes: >> >>> On Tue, Apr 30, 2013 at 08:26:52PM -0700, Eric Abrahamsen wrote: >>>> Rick Frankel <r...@rickster.com> 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>