Yeah. I'm still a little worried that if you make this optional, you
are going to wind up with the following problem:
EM { color: blue; font-style=normal }
P.splash { color: blue }
(P.splash) EM { color: red }
<p class=splash>Here is some <em>important</em> text</p>
Everything works fine if the context sensitivity is used, but a
browser which does its best but doesn't pay attention to context
renders this less intelligibly than a browser which doesn't use style
sheets at all. At least there *some* contrast will be presented.
> > (I still recommend that the syntax
> > be changed from "(H1)EM" to something like "H1::EM" or "H1/EM",
> > though.)
>
> Why?
The main reason (besides personal preference) is to disambiguate the
scoping when using commas. That is, what exactly does
(A), (B) (C) (D), (E) {...}
mean? I think that at the very least, the spec has to be explicit
about how these group. With another notation you could say what you
mean:
A, B::C::D, E {...}
(A,B)::C::D, E {...}
(A,B)::C::(D,E) {...}
etc. If you are going to retain the current syntax, I'd suyggest you
nail it down to the first reading (i.e., context *never* reaches
across a comma). This will make some specifications needlessly wordy:
(A) B, (A) C, (A) D {...}
but at least it will be clear.
> 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 --
With my language designer's hat on, this is almost always an extremely
bad idea. People tend to expect white space (with the possible
exception of relative amounts of line-initial white space, although
even that's contentious) to be completely irrelevant except to delimit
tokens.
> > > 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.
Agreed. I think that the set of values you have in the new draft
should suffice for level one. You probably want to add LI to the list
of elements for which it is likely to be used.
While on the subject, do you think that it would be reasonable to
recommend that it be permissible to specify this for other entities
such as H1 and P, and that in those cases, the browser is encouraged
(but not required) to add the appropriate number (in H1.H2.H3 format)
before the entity? Or does this need to wait for level 2?
>
> > 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.
good.
> > 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.
I won't be dogmatic on it, but it seems as though if I am doing a
presentation where I need the text to be 36pt to be readable, I don't
want to have to lose all style sheet information just because somebody
says "font-size: 12pt ! important".
> > 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.
That wasn't quite what I meant. What I was talking about was more
along the lines of what is done with font-family. That is, walk down
the list until you find a value that you can use. The same should be
true for the "color" foreground attribute, which should probably also
allow URIs in the list.
I do like the recommendation that browsers use a color first if an
image will require downloading.
> Should we allow multiple
> overlays?
>
> background: "1.gif" "2.gif" "3.gif" dark-blue
>
> With transparencies, the visual effects could be stunning.
I think that we're getting too complicated for level one here.
> 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.
bg-light-source and the "double background" notion (while neat),
strike me as *way* too complicated for level one.
bg-position seems incompletely specified: If you specify 0%, you are
talking about the upper left hand corner. If you specify 100%, you
are talking about the lower right hand corner. What about
intermediate values? Does "75% 75%" mean that that point on the image
is aligned with the corresponding point on the element, or does one or
the other of the corners get put there?
> > 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 guess that it's a difference in point of view. I see the enumerated
values as being the primary means of specifying size, allowing the
user to customize the browser to match each to an available font size
(not all platforms can scale fonts). Specifying "font-size: 12pt"
should only happen when translating from a presentation-based document
formatter, and I'd expect some browsers to say "oh, that's close to
'large'". (If the browser can scale fonts, I'd expect them to try to
meet the request, but this should probably be a user-specified option.)
As for the notion of not going "all the way", that is arguably a good
thing. I don't really want some moron saying "font-size: 500" and
causing my system to blow up or grind to a halt as my font server
tries to rasterize an enormous font. If we don't think that seven
levels are enough, we should add a couple more, but I think that the
bare numbers should be removed.
>
> > 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?
Again, not really. What I want for BIG is "contrastively larger".
I'd rather leave it up to the user to decide whether the step in size
from "small" to "normal" is the same percentage as that from "medium"
to "large".
> "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?
Here it makes even less sense than with font size. While many systems
can scale a font, they often can only select between "light",
"medium", "demi-bold", and "bold" variants. (And any typographer will
tell you that you *can't* get a decent font merely by expanding in the
horizontal direction.) Here, what I want is "choose the bolder
version of the font (if one is available)".
> > 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?
Ouch! I hadn't thought of that. With my purist hat on, it should be
changed, but it's such a *nice* value. I suppose that I can
rationalize leaving it in by saying that the only reason someone would
add an experimental "x-foo" is if they think that "foo" should be
added as a value. Since "large" is already there, nobody would add
"x-large". I suppose that we could be explicit and say "extra-large".
>
> > 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."
Fine. (Although this wording doesn't seem to be in the version of the
draft I just printed out.)
> 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 --
I actually kind of like this, although I could see either making it
optional or delaying it to level 2. This is much nicer and more
general than "alt-first-line".
> This breakes with the philosophy of addressing based on elements, not
> element content. Several issues are raised:
But "text-effect" is already talking (implicitly) about the first
character and first line. If you're going to do that, you might as
well let the author talk about the first three lines or first word.
> - 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?
My guess is that the most intuitive reading will be that everything is
relative to its enclosing environment. That is, in
P {...}
P:line[1] {...}
P:word[1] {...}
P:char[1] {...}
each is considered to be embedded in the prior one.
> Index 0 correspond to anything added before/after the content:
>
> Q[0] { color = red } -- quote-marks turn red --
Since the proposed syntax is <tag>:<type>[<range>], this should
probably just be Q:prefix and Q:suffix. I would think that Q[0] would
have a level 2 reading of "Q's with a 0 attribute".
> Implementing CSS1 will be more complex if this is added, but the model
> is clearly more general. Hmm.
I'd consider it.
----
Evan Kirshenbaum +------------------------------------
HP Laboratories |To express oneself
1501 Page Mill Road, Building 1U |In seventeen syllables
Palo Alto, CA 94304 |Is very diffic
| Tony Finch
kirshenbaum@hpl.hp.com
(415)857-7572
http://www.hpl.hp.com/
personal/Evan_Kirshenbaum/