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., <) 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.
prev parent 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
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=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 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).