bug-texinfo
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: makeinfo and CSS


From: Torsten Bronger
Subject: Re: makeinfo and CSS
Date: Sat, 26 Apr 2003 11:42:54 +0200
User-agent: Gnus/5.090015 (Oort Gnus v0.15) Emacs/21.2

Halloechen!

address@hidden (Karl Berry) writes:

>     > --css-include=FILE    include contents of FILE after the 
> built-indefinitions
>     > --css-reference=URL   put @import(URL) after the <style> tag
>     > --css-omit-defaults   do not include the built-in definitions
>     >
>     > This seems like a lot of options.  Is there a cleaner way?
>
>     I think that the first two options are necessary and well named.
>     You can make the third option implicit: If a *reference* is given
>     the defaults are omitted.  So if the user wants to use their CSS'es
>     in an @import rule, they have to provide a complete set.  I see no
>     point in override the user's @import'ed definitions, especially
>     because makeinfo's default CSS may be changed or extended.
>
> Aren't potential changes in makeinfo css exactly the reason to include
> them by default?  

The problem is that the @import must be the first thing.  If the
author sets something in the @import'ed part which is overridden by
makeinfo's defaults, the author has simply lost.

> After all, the <style> stuff we just did is not really
> "stylistic".  It's the implementation of the @small... Texinfo feature
> in the HTML output, and every user (except pathological ones) would want
> to include it, since the output isn't correct without it.

Well, I use @small... mostly to have better printed output, because
long examples look like waste of paper.  I could want to switch it
off for HTML output (making both forms equal).  I couldn't do it in
@import'ed CSS'es if makeinfo puts its defaults after me.  Well, I
thought so.

But: I pondered all this again and changed my mind.  If makeinfo's
defaults are guaranteed to be harmless (i.e. only relative font size
changes, inherited font families, no colour definitions etc) it's
probably a good idea to have them always.  And if I want to make
@smallexample bigger, I can say in my @import'ed part:

pre.smallexample { font-size: inherit ! important }

which cannot be overridden.  I tested that at least with Mozilla and
it worked.  Would be nice if somebody checks that with IE, on the
other hand the HTML files don't become useless if this breaks, and
it should occur rarely anyway.

>     You could limit it to just the first option if you scan the given
>     file to find out whether it starts with an @import rule.  (It must
>     come first according to the scpecification, so you only have to skip
>     whitespace and comments for that.)  
>
> Hmm, that seems like a reasonable way to avoid the --css-reference
> option.  Except now if the included file has both @import's and inline
> definitions, we have to insert the defaults in the middle.

Yes, but it is not only easy to find the *start* of an @import rule,
but also its end, because it must be a ";" (you must skip one string
though).  Many @import rules may be present, but nothing inbetween,
not even other @... rules.

It would be nice if eventually one CSS command line option for
makeinfo turns out to be sufficient.

Tschoe,
Torsten.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]