From: Eric Abrahamsen <eric@ericabrahamsen.net>
To: emacs-orgmode@gnu.org
Subject: Re: [PATCH] export to various flavors of (X)HTML
Date: Mon, 06 May 2013 00:36:13 -0700 [thread overview]
Message-ID: <874negh85u.fsf@ericabrahamsen.net> (raw)
In-Reply-To: F979FC4C-8900-4E0C-90D6-34071E47406A@gmail.com
Carsten Dominik <carsten.dominik@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 <eric@ericabrahamsen.net> wrote:
>
>> Rick Frankel <rick@rickster.com> writes:
>>
>>> On Tue, Apr 30, 2013 at 08:26:52PM -0700, Eric Abrahamsen wrote:
>>>> Rick Frankel <rick@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>
next prev parent reply other threads:[~2013-05-06 7:30 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-19 9:57 [PATCH] export to various flavors of (X)HTML Eric Abrahamsen
2013-04-19 15:37 ` Rick Frankel
2013-04-20 2:59 ` Eric Abrahamsen
2013-04-23 1:00 ` Rick Frankel
2013-04-23 4:30 ` Eric Abrahamsen
2013-04-23 4:57 ` Samuel Wales
2013-04-23 6:55 ` Carsten Dominik
2013-04-23 7:54 ` Eric Abrahamsen
2013-04-23 12:09 ` François Pinard
2013-04-24 1:17 ` Christian Wittern
2013-04-24 13:10 ` François Pinard
2013-04-25 21:20 ` Eric Abrahamsen
2013-04-26 13:49 ` Rick Frankel
2013-04-26 17:14 ` Eric Abrahamsen
2013-04-26 18:49 ` Rick Frankel
2013-04-29 6:02 ` Eric Abrahamsen
2013-04-29 7:45 ` Nicolas Goaziou
2013-04-30 14:38 ` Rick Frankel
2013-04-30 14:40 ` Rick Frankel
2013-05-01 3:26 ` Eric Abrahamsen
2013-05-01 11:55 ` Rick Frankel
2013-05-02 21:07 ` Eric Abrahamsen
2013-05-03 7:17 ` Carsten Dominik
2013-05-06 5:49 ` Carsten Dominik
2013-05-06 7:36 ` Eric Abrahamsen [this message]
2013-05-06 7:48 ` Carsten Dominik
2013-05-06 9:05 ` Eric Abrahamsen
2013-05-06 12:56 ` Rick Frankel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874negh85u.fsf@ericabrahamsen.net \
--to=eric@ericabrahamsen.net \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).