RE: CSS1, new draft specification

Mike Wexler <mwexler@frame.com> wrote:
>> Every other element selector (other than <HTML>) is on structural
>>elements that _occur_in_the_text_ (that is, concrete as opposed to
>>implied by OMITTAG).
>That's not completely true. The current CSS won't work very well unless
>you support implied END-tags. For example the following:
>	<P CLASS="A">Start of paragraph one.
>	<P CLASS="B">Start of paragraph two.
>You need to handle tag omission to figure out where paragraph one ends and
>paragraph two starts.

True enough; but end tag implication is different than begin tag 
implication.  Not a major difference, but still more code for me.  :^)

>I don't see why implemented $CANVAS as a special token is any easier than
>special casing BODY. Note that you really shouldn't be special casing BODY,
>but if handling OMITTAG is too difficult...

Because any browser will have the concept of a "document" already - as a 
structure, an object, whatever.  You can easily attach a default style 
declaration to that object.  In addition, the internal document structure 
representation, which maintains the structure of all the <HTML>, <BODY>, 
<UL>, <LI>, etc. tags, can have styles attached to each structure item 
(obviously).  It has not been significant, with current requirements on web 
UAs, to represent tags like <BODY> if they don't exist in the text.  Now, 
with overriding <BODY> for CSS, it is.

I didn't intend for this to turn into a major discussion.  I still like the 
abstraction of $CANVAS.  Barring that, I'd rather override <HTML>, like the 
fifth (?) draft, mostly because tossing an extra HTML into the structure 
representation wouldn't have so many side effects (like bg-color, etc.). 
 Also, <HTML> seems to me to be the "top level" of the document - I suppose 
it might be an interesting exercise for other people to think about what it 
means to set the style of <TITLE>.

Again, though, I don't want us to use too much time on this point.