Thanks again for your extensive comments. As you may have seen, the
latest draft of CSS [1] has been influenced by your remarks. Also, it
has turned into a working draft of W3C describing CSS1 only. The plan
is to have stable CSS1 by the end of the year and move on to CSS2
after that.
> > Changes that we are considering in level 1:
> >
> > - dropping context sensitivity: this will lower the threshold for
> > implementors as well as keeping the syntax open.
>
> I don't think that this is a good idea. The implementation overhead
> isn't *that* great, and people are going to want to distinguish things
> like EM within H1 from EM within P.
Yes, it's clearly a useful feature. However, it requires the UA to keep a
stack of elements, and not all browsers do this. The more general
question is how to define conformance to the CSS and its levels. This
is my suggested wording:
"A conforming UA:
- attempts to fetch all referenced style sheets and parse them
according to the specification.
- orders the declarations according to the cascading rules
- indicates to the reader when style sheets are in effect, and allows
the reader to turn style sheets on and off.
- makes efforts to format the document based on the the style sheets
and the constraints of the presentation medium."
THis wording is quite soft on browsers, they woud be required to parse
context-sensitive selectors, but not honor them. Is that fair?
> (I still recommend that the syntax
> be changed from "(H1)EM" to something like "H1::EM" or "H1/EM",
> though.)
Why? Another suggestion I've received privately is to just use white
space as the delimiter:
UL UL UL LI { .. }
P[ ID = "foo" ] B { .. } -- two selectors --
P [ID="foo"] B { .. } -- three selectors --
> > Lists can be
> > discribed using a new-non-inherited property, list-style, that
> > applies only to the children of the element:
> >
> > OL { list-style: upper-alpha }
> > UL { list-style: "red-bullet.gif" }
>
> I think that something like this is needed. I still lean toward the
> template notation I suggested before ["%a. ", "%1)", "(%A)"], as it
> allows specification of the punctuation to go around the numbering as
> well.
I think this should wait for CSS2.
> o I like the notion of allowing specification by class independent
> of tag, but you run into two problems by using the same notation
It's been taken out. People got confused and complained about
ambiguity.
> o I don't like the fact that the document's "important" assertion
> is to be given more weight than my "legal" one.
I see your point, but will it be a real problem? You can turn off
style sheet if you want. Having only two diffenent weight simplifies
the cascading rules.
> o I still think that color needs to take a precedence list, and
> I'd say the same for background. There will be clients which
> can change color but not import a background, and it should be
> possible to say
>
> background: "bg.gif" dark-blue
This is now ok. "dark-blue" will be used as a background, and the
gif will be overlay when (if) it gets in. Should we allow multiple
overlays?
background: "1.gif" "2.gif" "3.gif" dark-blue
With transparencies, the visual effects could be stunning. We've also
added two more properties to describe how to lay out background
images. See the latest draft for more on bg-style and bg-position.
> o I like the collapsing of font-size-index into font-size. Is
> there any reason to retain "<number>" as one of the possible
> values? Since you're not even keeping the Netscape range of
> 0..7, with 3 being "medium", it would seem that the enumerated
> tokens would be sufficient.
They dont't take you all the way. Sometimes you want to be REALLY GIANT,
and defining "xxxxxxx-large" as a token is not the way to go.
> I'd certainly recommend adding
> "[<number>] larger | [<number>] smaller" to the set of possible
> values, though.
A percentage value will reference the font size of the parent
element, does this fill your needs?
> o font-family needs a generic value of "fixed" or "typewriter" to
> handle PRE and TT. Alternatively, perhaps font-spacing with
> values "fixed" and "variable".
"monospace" added, thanks.
> o For font-weight, I am again not sure what value the number is
> playing, and I would suggest "[<number>] lighter" and
> "[<number>] bolder".
Again, a percentage will refer to the parent. Doesn't that make more
sense than dealing with arbitrary units?
> o For bg-style, I like the idea, but I am uncomfortable with a
> value that begins with "x-", as that space is generally reserved
> for experimental extensions. Perhaps "repeat-x" and "repeat-y"?
Changed. How about "x-large", would you change that too?
> o text-decoration should probably be multi-valued, as, e.g.,
> "blink" and "line-through" seem as though they could peacefully
> coexist. I'm also not sure why the color of the decoration is
> based on the color of the text. (aside: what do you mean by
> "based on"? the same? contrasting?)
Description changed to: "The color of the decoration is the same as
the color of the text. If more than one color is required to render
the decoration (e.g. for 3d boxes) the other colors are based on the
text color."
> I see that the common case
> may well be to have text and decoration the same, but consider
>
> P {color: black}
> EM {color: red}
> [class=3D"so"] {text-decoration: line-through}
>
> <span class=3Dso>Here is some <em>struck out</em> text</span>
>
> I don't think that it makes sense for the line to change color
> for the emphasized words. On the other hand, I can see wanting
> to say that "this style has words struck out with a red line".
> Perhaps, at least it should be specified that when the
> text-decoration is inherited, its color is inherited as well.
This makes sense, especially for the more complex decorations such as
boxes. Now, what if the author really want to have red underlining? In
order to support this, while keeping the above suggested rule, we would
need a new property. Until someone argues convincingly for the need,
it will not be added.
> o text-effect would seem that it could reasonably be multi-valued,
> as "drop-cap" and "alt-firstline" work well together, and indeed
> are often seen together in print. Of course, this opens up the
> problem that they both reference the same properties (alt-font,
> etc.) Perhaps these should be changed to "cap-font", etc. and
> "first-line-font", etc. The same question arises for the font
> used for the numbers referenced by "list-style" and will be for
> "insert-before", "insert-after" (and their needed cousins
> "before-line" and "after-line"). Perhaps some more general
> mechanism should be designed at this stage.
You raise an important point. We could extend the generality by
improving addressing while simplifying properties. E.g., if we can
address characters and lines on the left side, we could drop the
alternate set of properties:
P:char[1] { text-effect: drop-cap }
P:line[1:2] { font-size: 120% } -- the first and second line --
This breakes with the philosophy of addressing based on elements, not
element content. Several issues are raised:
- What does the percentage in the last example refer to? The
font-size of the "normal" P content, or its parent?
- children elements "inside" content addressed by the new notation,
what set of values do they inherit?
The extra functionality can be used to better describe wanted
behaviour:
P:char[2] { text-effect: dropcap; font-size: 200% }
<P>"Cool"</P>
Here, only the 'C' would be using the large font, not the preceding
quote-mark.
Index 0 correspond to anything added before/after the content:
Q[0] { color = red } -- quote-marks turn red --
Implementing CSS1 will be more complex if this is added, but the model
is clearly more general. Hmm.
[1] http://www.w3.org/pub/Style/css/draft
Regards,
-h&kon
Hakon W Lie, W3C/INRIA, Sophia-Antipolis, France
http://www.w3.org/People/howcome [email protected]