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

[Rick Frankel <rick@rickster.com>]

On 2014-03-18 15:46, Rasmus wrote:
> Rick Frankel <rick@rickster.com> 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
> entirely.
> 
> Not what I meant.  I'm only addressing your concern about
> &HUMAN-READABLE-NAME; vs %HEX-VALUE;.
> 
> 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.

Agreed.