On 24/05/11 00:09, Lionel Orry wrote:
Hi Stuart,
Le dimanche 22 mai 2011 22:26:54 UTC+2, srackham a écrit :
- A separate `<theme>-manpage.css` file should not be mandatory. Most of
the time a separate `<theme>-manpage.css` is unnecessary and (in the
currently shipped themes they are just place holders to suppress
warnings). This could be achived by implementing an include2::[]
macro: identical to include1::[] but no warnings if the file does
not exist.
Why not including the small css bits in -manpage.css into the main css page with
a class selector on body, for example
body.manpage h1 { /* specific manpage formatting */ }
Excellent idea! It ties in with the way both xhtml11 and html5 are handled by
the same CSS file.
, adding 'class="manpage"' to the <body> tag and getting rid of
<theme>-manpage.css totally ? No need for include2[] then, and less files
around...
- Future changes to existing markup, id and class attributes emitted
by xhtml11 and html5 outputs would need to be minimized to avoid
backward theme incompatibilities.
The suggestion above breaks that rule, but if you think the approach is
interesting, let's integrate it and then freeze the theme format, and
communicate to existing theme authors for the new format.
For the time being I don't want to get to fancy, but there are a
couple of additions that I think bear merit:
- An optional `<theme>.js` file for theme based scripting.
+1. I bet lots of people would like to animate scrolling, showing/hiding
sections etc using e.g. jQuery, and that should be placed in a theme,
definitely, nowhere else.
- A themes directory structure: the theme files would reside in a
configuration directory named `themes/<theme>/`. When generating
outputs with embedded CSS AsciiDoc would load `<theme>.css` and
(optionally) `<theme>.js` from that location; if a directory named
`themes/<theme>/icons` exists and the 'data-uri' was defined then
set the 'iconsdir' attribute to that directory.
- The above directory-per-theme arrangement would lend itself to zip
based theme plugins managed by a '--theme' command-line option (cf
filters plugins and the '--filter' command-line option). This would
make the distribution of new themes easy and take the onus of theme
management out of the core AsciiDoc distribution.
I like this approach. It's clean, and makes the themes/filter stuff more
homogeneous.
Comments and suggestions welcomed.
Cheers, Stuart
Cheers
Lionel
--
You received this message because you are subscribed to the Google Groups
"asciidoc" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/asciidoc?hl=en.
--
You received this message because you are subscribed to the Google Groups
"asciidoc" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/asciidoc?hl=en.
