Balancing level1 and 2 is an important and difficult issue. There is
an obvious tradeoff between ease of implementation and the "wow!"
stuff. Then there are some not-so-obvious factors like how "mature" a
property is, how "intuitive" it is and how "useful" it is.
The current approach is to put in the obvious features (font, color,
space) along with some "wow!" stuff to give people some new
toys. Also, conformance requirements should not be strict to allow all
browsers, including text-based ones, to feel welcome.
In the last spec, the wow stuff includes
- big initials and alternate first lines
- background on a per-element basis
- tagless small-caps
- magnification
- bg-light-source
The latter two are new, and recent messages have killed
'bg-light-source'. (But, should we keep simple gradients a la:
BODY { background: red/blue; /* fade from red (top) -> blue (bottom) */
which looks "really cool", but can be emulated with a gif)
The magnification property will ease the relationship between authors
and readers. Few authors would object to a the reader using glasses or
a lens (which is what the magnification property is), but may not like
that the font-size is increased without scaling images
correspondingly. Also, this is a genuinely useful feature that anyone
having demonstrated the web for >5 people around one monitor would
want. The only objection I can see is that scaling images is expensive
computing-wise (but not that expensive) and that the resulting images
may not look as sharp or require some more colors. Any other concerns?
Some more specific comments:
> (1) Abbreviate section "Containment in HTML" to "See draft-ietf-
> html-style-00.txt". In particular, don't include an example which
> is "sure to be obsolete".
Yes,
> (4) Comments section - change "two dashes" to "two hyphens (ASCII 0x2D)"
Good point. We'll probably change them to C-style comments, though,
based on Evan's concerns.
> (6) The Cascade - move "@import" to level 2
The current WD-style [1] does not allow for cascading in the LINK or
STYLE elements, so in order to live up to the name, we need
@import. I agree that it should be kept out of CSS1 if possible.
> (7) Important and Legal - move to level 2
This is also a requirement for cascading to work.
> (8) Multi-column layout - move to level 2
Given that you stack boxes based on their margins, you will need some
sort of policy when the boxes don't end up on top of each other. Then,
the multi-column layout comes for free. The average formatter is
likely able to hadle it due to the align attribute on IMG that has
been in use on the web for some time.
> (9) CSS1 properties - "an ASCII-based UA ini a monochrome environment
> is not able to honor color values" ?? What does ASCII have to do
> with color?
thanks..
> (10) Fonts - "there exists no well-defined and widely accepted taxonomy
> for classifying fonts". I guess you haven't seen the PANOSE system
> nor have noticed that both Microsoft and IBM employ it in their font
> mapping equipment.
We have tried to start a dialog with the PANOSE people, but a 2-way
communication has not yet been established. If anyone has information
or opinions on the conditions we could add PANOSE to a public spec,
let us know.
> (11) Under font-size, what does a "VR scene" have to do with HTML? Are
> you confusing HTML with VRML perhaps?
No, some HTML browsers offer a VR user interface ("pad" comes to my
mind). In those, a document will be scaled according to your
"distance" from it, and the author's choice of font sizes may not be
honored.
> (12) bg-light-source - move to level 2 (please don't propose new and
> exciting but unimplemented properties for level 1!)
Point taken. I probably got carried away trying to emulate
PowerPoint.
> (13) text-spacing - change to text-set-width or break out into separate
> properties for specifying opt/min/max word space and opt/min/max letter
> space.
The latter would certainly give your software a competitive advantage
:-)
> (14) text-decoration - move box, shadowbox, box3d, and cartouche to level 2.
>
> (15) text-position - change to baseline-offset.
Yes, probably a better name. We've also planned to add "text-top",
"top", "text-bottom" and "bottom" as well as a percentage to the list
of values.
> (16) text-transform - change to glyph-substitution; add small-caps
Now say "glyph-substitution" 100 times fast. As long as we're in the
context of a style sheet, I don't see anyting wrong with "transform".
> (19) Frames - change to "Borders", consider moving to level 2
These are important for tables, and if they're allowed in table
elements, why not in all elements? That's how they got in.
> (21) aliases - remove; there is no need for alternative spellings of
> keywords; it just makes people confused
Agreed.
> (22) Formal grammar needs revision to eliminate level 2 productions
> and extensions
They don't do much damage, do they? Consider it future-proofing. Or
maybe you're right. Do one thing at a time. Hmm.
[1] http://www.w3.org/pub/WWW/TR/WD-style