all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Rick Frankel <rick@rickster.com>
To: Rasmus <rasmus@gmx.us>
Cc: emacs-orgmode@gnu.org
Subject: Re: [patch][ox-html] Stylistic changes
Date: Wed, 19 Mar 2014 10:00:49 -0400	[thread overview]
Message-ID: <488c8d8754d4539f920ce81d9698a7fb@mail.rickster.com> (raw)
In-Reply-To: <8761nbs31n.fsf@gmx.us>

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.

      reply	other threads:[~2014-03-19 14:00 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-16  0:33 [patch][ox-html] Stylistic changes Rasmus
2014-03-16  9:59 ` Nicolas Goaziou
2014-03-16 13:06   ` Rasmus
2014-03-17  2:17   ` Bastien
2014-03-17 17:01     ` Rick Frankel
2014-03-17 22:19       ` Rasmus
2014-03-18  0:35         ` Rick Frankel
     [not found]           ` <874n2w2n62.fsf@gmx.us>
2014-03-18 13:49             ` Rick Frankel
2014-03-18 19:46               ` Rasmus
2014-03-19 14:00                 ` Rick Frankel [this message]

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=488c8d8754d4539f920ce81d9698a7fb@mail.rickster.com \
    --to=rick@rickster.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=rasmus@gmx.us \
    /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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.