Carsten Dominik <carsten.domi...@gmail.com> writes: > Hi Eric, > > thanks for the reply. OK, I am going with the patch for now, let's > push more thinking about HTML5 further down the line. > > Thanks for working this out!
My pleasure, I hope I haven't stifled debate... > On 6.5.2013, at 09:36, Eric Abrahamsen <e...@ericabrahamsen.net> wrote: > >> 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> >> >>