- From: Evan Kirshenbaum <evan@poirot.hpl.hp.com>
- Date: Wed, 27 Dec 1995 11:38:55 -0800
- To: Hakon Lie <Hakon.Lie@sophia.inria.fr>, www-style@w3.org
> A new version of the Cascading Style Sheets specification has been > released. There have been a number of changes based on comments from > implementors and participants on this list. Thanks! Some of the > changes are: > As always, comments are welcome. By now, you're probably hoping I won't. :-) Anyway, it's looking good. Here's what I noted: - For lists, you say that "the label should use the font and color properties of the list element to which it belongs." Wouldn't it make more sense to specify a "label" pseudo-class for this. This would allow you to say: OL LI:label { font-weight: bold } - For font-weight and font-size, I appreciate that you've moved from absolute numbers to relative ones. I'm a little concerned, though, that it may not be intuitive that a bare positive number means an increase. I would suggest either requiring "1 larger/smaller" ("1 bolder/lighter") or requiring that positive increments be prefixed by a plus sign ("font-weight: +2"). - For font-style, would it be worth adding as a value something like "contrasting"? By this I mean the "italics if you're in roman; roman if you're in italics" that LaTeX uses for "\em". This is probably how I'd want to define <EM>. - For color, I'd still like to be able to specify a list of options (or hear an argument why this isn't a good idea). Especially if you're allowing the possibility of multiple color models I can see people wanting to say .company { color: pantone(4231) indian-red dark-red black } - for background, what are the intended semantics if multile URIs are specified? I presume that the first acceptable one found is used, but the spec should say. - for bg-position, you explain what "0% 0%" and "100% 100%" mean, but I still don't know what, e.g., "14% 84%" means. My best guess is that the point 14% across and 84% down the image is to be placed at the point 14% across and 84% down the element. If this is so, the spec should be clearer. If it is not, then the spec should *certainly* be clearer. - for text-transform, could we note that the actual transformation in each case is language (and UA) dependent. For example, whether "é" uppercases to "É" or "E" depends on the language (or even the particular dialect: "fr-CA" vs. "fr-FR"). Also a browser will probably want to have more complex rules for what "capitalize" means. (e.g., in "en-US", I probably would have a list of words ("the", "a", "of", etc.) which would not be capitalized except at the beginning of the element, or following a colon or open quote.) - for text-align, we should note that the actual justification algorithm used is UA (and language) dependent. A UA may justify by increasing word spacing, by letterspacing (reasonable in some languages), by stretching characters (common for Hebrew), and may even hyphenate. - is text-indent necessary anymore? Can't we just say X:first-line { margin-left: 3em } - for padding, you say "the color of the padding area is controlled with the 'background' property". Wouldn't it be reasonable to add a "padding" pseudo-class. - for margin, what does "auto" mean? - the width property takes a percentage, but the height property does not. Is there a reason for this? - for the specification of colors, we now allow "rgb 1.0 0.0 0.0" with the note that "to have room for other color models in the future, the 'rgb' keyword is required in the latter notation." This implies that other color models may be added prefixed by a similar keyword. Unfortunately, there is no way for a UA to know how many parameters a particular model takes, so it cannot skip over unknown values. I would suggest that the rgb specification be changed to one of (in decreasing order of preference): rgb(1.0, 0.0, 0.0) rgb[1.0, 0.0, 0.0] rgb(1.0 0.0 0.0) rgb[1.0 0.0 0.0] rgb:1.0-0.0-0.0 with the specification that a keyword will be followed by a value contained in a balanced set of parentheses/brackets, not counting those in double-quoted strings (for the first four possibilities) or will be followed by a colon and delimited by whitespace (for the last). ---- Evan Kirshenbaum +------------------------------------ HP Laboratories |Now every hacker knows 1501 Page Mill Road, Building 1U | That the secret to survivin' Palo Alto, CA 94304 |Is knowin' when the time is free | And what's the load and queue kirshenbaum@hpl.hp.com |'Cause everyone's a cruncher (415)857-7572 | And everyone's a user |And the best that you can hope for | Is a crash when you're through http://www.hpl.hp.com/personal/Evan_Kirshenbaum/
Received on Wednesday, 27 December 1995 14:39:07 UTC