From: Matt Lundin <email@example.com>
To: Bastien <firstname.lastname@example.org>
Cc: "Sébastien Vauban" <email@example.com>, firstname.lastname@example.org
Subject: Re: [Patch] HTML export -- Allow to change the name of the global DIV
Date: Mon, 14 Mar 2011 09:11:06 -0400 [thread overview]
Message-ID: <email@example.com> (raw)
Bastien <firstname.lastname@example.org> writes:
> Are there other hardcoded HTML classes/ids that the user might want to
> customize? If so, can we think about a simple way to define all of them
> at once?
The id/class values are hardcoded in several different places and
generated in different ways in org-html.el, so I think the only
practical solution, for now, would be to create variables for each one
(or perhaps an alist that encompasses all of them).
[Slightly OT dreaming]
Over the long-term, it would be nice to give the user a simple way to
control not only classes and ids, but also the placement of structural
divs and other tags. Perhaps we could develop some sort of templating
system, allowing the user to create an custom html skeleton which is
then fleshed out with data from the org file. The user might then
customize which tags, if any, should enclose, say, a level one outline
tree. Properties and tags in an org file might be used to specify the
use of alternate templates within particular sections of the document.
This would have several benefits:
1. It would allow users to export html to an arbitrary tag structure.
One might, for instance, create static pages that conform to the
structure/styling of an existing web site. Or one might have
different types of pages within a single, org-generated website.
2. It would allow simple, clean html when exporting small snippets.
Currently, when calling C-u M-x org-export-region-as-html, the output
contains a number of hard-coded divs, classes, and ids. This makes it
difficult to integrate such snippets into another html file.
<div id="outline-container-1" class="outline-2">
<h2 id="sec-1">A section </h2>
<div class="outline-text-2" id="text-1">
3. It would allow users to try out the new html5 tags (<section>,
<article>, <nav>, etc.).
4. It would offer more consistent customization. At the moment, certain
tags can be customized (e.g., table tags) but other elements (e.g.,
lists) cannot be.
5. It would make it easier to create html that works with existing
scripts (such as the s5 presentation system ).
My guess is that such configuration would depend on your rewrite of the
exporting parser. It would indeed be wonderful if at some point the
export engine returned a generic data structure that could then be
plugged into a modular templating system.
That said, an org file is a *complex* thing, and the exporter already
produces very nice html. :)
next prev parent reply other threads:[~2011-03-14 13:11 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-10 13:07 [Patch] HTML export -- Allow to change the name of the global DIV Sébastien Vauban
2011-03-11 8:37 ` Bastien
2011-03-11 9:09 ` Sébastien Vauban
2011-03-14 13:11 ` Matt Lundin [this message]
2011-03-14 15:22 ` Jambunathan K
2011-03-14 15:25 ` Jambunathan K
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:
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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
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).