Oh? Well, there are a few comments I've been meaning to make, so if
the list will indulge me, I'll take this opportunity.
> - add support for user-selectable multiple style sheets through the
> TITLE attribute of the LINK element. Turning on/off various style
> sheets should be under the interactive control of the user.
My main interest in multiple style sheets is that in the potential
eventuality of multiple co-existing style sheet notations (which we now
have, sort of, with the two existing versions of the CSS draft), page
authors might write the same style information in multiple notations
for maximum coverage. It might be useful in that event to have a way
to tell the rendering agent that "These three <LINK REL=STYLE>'s all
contain the same information; once you've successfully parsed one of
them, you can ignore the others." It might also be useful to be able
to identify the style sheet's notation in the <LINK> so that the
rendering agent could easily skip style sheets in notations it couldn't
parse.
This also suggests the possibility of multiple <STYLE> blocks. The main
problem I see there (and this is drifting somewhat off charter) is that
the value of the <STYLE NOTATION> attribute is apparently restricted to
the values listed in the DTD. This seems counter-intuitive to me;
instead of trying to parse the style sheet at the SGML level, it seems
that the right thing to do would be to give the NOTATION parameter the
type CDATA and treat the contents of <STYLE>...</STYLE> as raw #PCDATA,
and let the rendering agent figure it out.
> - remove the support for addressing based on element attributes
> from level 1. Support for CLASS remains and one can address "new"
> and "old" anchors using pseudo-clases, e.g.:
>
> A.link: text-color = red
> A.vlink: text-color = pink -- visited link
> A.alink: text-color = blue -- active link
>
> The pseudo-classes only applies to A with an HREF.
Hmm. Might me not want to specify, for instance, the column spacing
for a <UL COMPACT>? I suppose you could get the same effect with a
class, though.
> Comments?
There are a few worries about the grammar in the CSS draft that I
noticed while trying to put together an equivalent yacc grammar.
Particularly worrying is the rule that covers addressing patterns:
context:
predecessor [ ancestor ancestor* context ]?;
which seems to require not only that one cannot have two adjacent
sequential search patterns (for instance, `/H1/ /P/ P' to catch the
second paragraph after an <H1>), but that the first and last search
patterns must be sequential. Why not the more straightforward:
context:
[ predecessor | ancestor ]*
?
-sbigham