- From: Allan Sandfeld Jensen <kde@carewolf.com>
- Date: Wed, 14 Jun 2006 23:07:45 +0200
- To: www-style@w3.org
On Tuesday 13 June 2006 17:55, Bert Bos wrote: > The CSS WG published a new WD, titled > > CSS3 module: Generated Content for Paged Media > http://www.w3.org/TR/2006/WD-css3-gcpm-20060612 > > It describes features typically only used when printing: running headers > and footers, footnotes, references to page numbers, floats to the top > and bottom of a page, etc. > > Indeed, we may define explicitly that these features *don't* work in > interactive media. (Although I already heard people ask for footnotes > to work interactively as well, possibly as a light-weight form of > hyperlink, opening a pop-up.) > > It's the first draft of these features and in a very early stage. > Feedback welcome. (Please prefix subject lines with [css3-gcpm].) > It really like the ad hoc counter styles, but I think could use some more flexibility, but I don't see how they are specially related to paged media though. For instance they should allow urls beside strings. It is not more than a few weeks someone asked on the list how to count with "1.gif", "2.gif", etc. This would be simple with @counter-style graphic url("1.gif") url("2.gif") url("3.gif") Another thing is that we might as well use it to replace the absurd number of new alphabets and number systems in the CSS3 list module. This only requires being able to set a type counter. The types could be: enumerate(default), numeric and alphabetic. This way I can define a danish alphabetic counter using: @counter-style danish alphabetic "a" "b" "c" "d" "e" "f" "g" "h" "i" "j" "k" "l" "m" "n" "o" "p" "q" "r" "s" "t" "u" "v" "x" "y" "z" "æ" "ø" "å" And there would be no reason to include it as a standard list-style or trying to get a political agreement if it's a danish or a norwegian alphabet ;-) One thing though we should consider if there should be some special requirements to custom names. This counts for both list-styles but also string sets. This is a avoid clashes with future extensions. One solution could be to require them to start with '-'. Regards `Allan
Received on Wednesday, 14 June 2006 21:07:56 UTC