Re: CSS3 Paged Media Draft

SUMMARY:

  1. string-set should take comma separated list.
  2. open|close-quote should be expanded in content not in string-set.
  3. hidden-policy is a good idea.
  4. @counter/@string rules need their scope defined.
  5. proposal for 'counter-step'.


On Tue, 28 Sep 1999, Robert Stevahn wrote:

> Please have a look at this new draft and provide feedback via www-
> style. Thanks in advance!
> http://www.w3.org/TR/1999/WD-css3-page-19990928

It looks great!

A few comments on Named Strings:

1. 'string-set' should take a comma separated list of [identifier
(string)] because otherwise you can't make an element create more than
one string.

This would be important in a dictionary, where each page has a
first-word and a last-word header:

   @string first { page-policy: first; }
   @string last { page-policy: last; }
   dt { string-set: first content(), last content(); }
   @page {
      @top first-word { 
         content: string(first);
         vertical-align: top;
         text-align: left;
      }
      @top last-word { 
         content: string(last);
         vertical-align: top;
         text-align: right;
      }
   }


2. What are the exact semantics of 'open-quote' and 'close-quote' in
the context of the string-set property? When is the nesting counter
reset? To what is it relative?

For example, what quotes would be on the following?:

   :root { quotes: "1" "1" "2" "2"; }
   Q:before { content: open-quote; }
   Q:after { content: close-quote; }
   Q { string-set: quote open-quote content() close-quote; }
   X { content: string(quote); }

Would an element X have the content "1quote1" or "2quote2"?

What about here?:

   :root { quotes: "1" "1" "2" "2"; }
   Q { string-set: quote open-quote content() close-quote; }
   X { content: open-quote string(quote) close-quote; }

Would X read "11quote11" or "12quote21" ?

I would suggest that the value of 'string-set' should not be
"dereferenced" until the string is used (apart from attribute values
and element content, obviously), and so the quote nesting would be
based on what is going on where the string _is used_.

This seems to make more sense than expanding the string immediately,
and thus using the quote level at that point, or -- even worse --
assuming that the quote level is always "0" at the start of the
'string-set' property.

This _must_ be specified somewhere in the spec or you can guarantee
that the first two UAs to implement this will do it differently...


3. I think 'hidden-policy' is actually a good idea. (Yes, I know this
goes back on what I said before.)

The 'string-set' property has been used to grab the value of the
<title> and <meta> tags. If this is the case, then we will no longer
be able to use display:none to hide the <head> element. This seems
silly to me. I very much like the idea of making counting of counters
and setting of strings possible on non-box-generating elements. 

In any case, "content:''" can conceivably end up creating an anonymous
empty inline element [1], and this would result in excess whitespace.
Using display:none guarantees that the layout will not be affected.
Using 'page-policy' does not make the situation worse than now: we
already have to have code checking to see if an object is generating a
box before we increment the counter. So, all this property would say
is that this check need only be made if the hidden-policy property was
"hidden" -- otherwise, 'display' is completely irrelevant (and we would
then be avoiding interactions with the 'display' property).


4. What is the scope of the @string and @counter rules? I assume that
they follow normal cascade rules and so only the last one has any
effect. This would mean that the following:

   @counter headers { list-style-type: lower-roman; }
   h1,h2,h3,h4,h5,h6 { counter-increment: headers; }
   #footer > hcount { content: counter(headers); }
   @counter headers { list-style-type: decimal; }

...would replace the "hcount" element by a decimal number, not a roman
numeral. The alternative is to use the most recent specified relevant
@rule at the point that counter/string is used. Again, this must be
specified in the spec, as otherwise it will be unclear.

From an implementation and DOM point of view, I would guess that it
would be a _lot_ easier if we used the final, cascaded value of
@counter and @string rules, and not the rule "at that point". This is
identical to the way page box at-rules work, and is because unlike the
at-rules like @import, @namespace, and @charset (which must all appear
at the top of the stylesheet), the effect of _these_ at-rules depends
very much on the document and are thus still important _after_ the
stylesheet has been parsed.


5. While we are at it, why not add a 'counter-step' property to the
@counter at-rule? This would specify by how much the counter should
increase each time. For example:

   @counter decades { counter-step: 10; }
   h2="Decades" + ol { counter-reset: decades 1890; }
   h2="Decades" + li { counter-increment: decades; }
   h2="Decades" + li:before { content: counter(decades) ": "; }
   li:before { display: marker; }

...would display this list:

   <h2>Decades</h2>
   <ol>
     <li>abc</li>
     <li>def/li>
     <li>ghi</li>
     <li>jkl</li>
   </ol>

... like this:

   Decades
   1900. abc 
   1910. def
   1920. ghi
   1930. jkl

...and so on. This would be cool, and presumably really easy to
implement.

(BTW, yes, I know the syntax I used for content matching is not the
one in the latest draft. I will be proposing some slightly more
thorough selector syntax extensions in a few days and in that proposal
the "content exact match" is specified by ="xyz", much like with
attribute selectors. You can see a very very very early draft of this
document on the web at:
   http://www.bath.ac.uk/%7Epy8ieh/internet/wwwstyle/selectors.txt
...but warning, this document is being edited daily and is absolutely
not ready yet. Comments are, of course, welcome. Especially from the
WG members working on the selector module... hint hint... :-)  )

-- 
Ian Hickson
[1] If Kipp or David are reading this, they may relax. I am not going
to suggest the virtual-anonymous-empty-generated-inline-boxes idea...
;-)

Received on Tuesday, 28 September 1999 19:13:01 UTC