[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] [patch][ox-html] Stylistic changes

From: Rick Frankel
Subject: Re: [O] [patch][ox-html] Stylistic changes
Date: Wed, 19 Mar 2014 10:00:49 -0400
User-agent: Roundcube Webmail/0.9.0

On 2014-03-18 15:46, Rasmus wrote:
Rick Frankel <address@hidden> writes:

On 2014-03-17 23:36, Rasmus wrote:
When you refer above to "utf-8 entities", do you mean the named html
entities (e.g., &lt;) or the actual utf-8 encoded characters?

The latter.  Do M-x describe-char on such an character.  Emacs will
tell you the code points.  My conjecture is therefore that one could
write a script that would translate html values to these weird hex
string or codepoints.  It would create more ugly source output, but
perhaps better for XHTML.  Personally, I don't care about XHTML as I
have little intuition as to when to use. . .

Do you close the empty tags in your html (e.g., <br />, <hr />)? Then
you're using xhtml.

I believe the named entities are encoding independent, while including
encoded characters in html output is fine -- although making sure the
page is served with the correct character encoding is another issue

Not what I meant.  I'm only addressing your concern about

As to using a more extensive set of named entities, as i said above,
the problem is that the xhtml flavors don't support them, and I don't
see any advantage in making the exporter handle character encoding
differently based on ouput doctype.

Definitely not.  Why I ask if there's a point in changing nice
entities to ugly entities for the sake of not getting them in
XHTML-encoded documents.

Yes we should. You can't properly post-process the html if it's
invalid xml. And the definition of "pretty" and "ugly" are subjective.

The question is, do we want to generate valid (x)html or not? My vote
is yes. In our case, html is an output format and not a source format.
In fact, we should probably compress out unnecessary whitespace, etc.
the way other web generators do to make the smallest/most efficent
output for webserving.

As Nicolas would point out, you can always use a filter to map all the
entities in the output.

With ox-latex.el we for instance don't include entities that are not
supported by the default package alist.  A similar concern could be at
play here.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]