Re: Hash

--- "L. David Baron" <dbaron@fas.harvard.edu> wrote:
> If an identifier valid in CSS cannot occur in HTML, then
> it can't occur in an HTML document.  It might be possible in some
> application of XML
No, the NAME token is an SGML construct.
> 
> > Correct would be:
> > 
> > HASH = #{name}
> > name = {namestart}{namechar}+
> > namestart = [a-zA-Z]|{escape}
> > namechar = [a-z0-9-]|{escape}
> 
<blockquote cite="http://www.w3.org/TR/REC-CSS2/syndata.html#q8">
When a user agent can't parse the selector (i.e., it is not valid CSS2),
it must ignore the {}-block as well.
</blockquote>
'can't parse' means that it doesn't comply with CSS grammar. See also
(elucidating as to the meaning of  'valid CSS2'):
<blockquote cite="http://www.w3.org/TR/REC-CSS2/conform.html#q1">
A valid CSS2 style sheet must be written according to the grammar of CSS2.
Furthermore, it must contain only at-rules, property names, and property
values defined in this specification. An illegal (invalid) at-rule,
property name, or property value is one that is not valid.
</blockquote>

On the basis of this, one should ignore a selector when it is
grammatically incorrect. Thus:
.1class {color: red} should be ignored because 1 is not a valid nmstart
character.

However, even though id is _more_ restrictive than class #1id {color: red}
should not be ignored, since it can be parsed - the name macro is nmchar+,
which includes numbers. 

It is clear that #1id is intended to be ignored, but since the sole
criterion for ignoring is if it can't be parsed, as the grammar stands it
shouldn't be.

To fix this, it is necessary to provide a separate RGB token:
"#"{color} {return RGB}
(I did write this before:
<q>
Note that this would also require a separate token (preferably two, one
for 3 digit, one for 6) for use by the hexcolor production.
</q>
)
using 
color     {h}{3,6}
(h is already defined as [0-9a-f]) (there is no need for separate rgb6 and
rgb3 macros - properties are subject to additional validation beyond mere
parsability)
and:
"#"{name} {return ID}
name {namestart}{namechar}*
namestart [a-z]|{escape}
namechar [a-z0-9-]|{escape}

{escape} is essentially superfluous since only letters, numbers and
hyphens are valid in NAME both CSS and SGML, but it is included for
completeness.
> 
> > Having proposed these changes, I also have a question - should invalid
> > (HTML) IDs result in the ruleset being ignored - can invalid IDs be
> > parsed?
> 
> HTML does not specify error-handling behavior.
I know that, but I was referring (somewhat obliquely and without any kind
of reference (sorry)) to this:

<blockquote cite="http://www.w3.org/TR/REC-CSS2/grammar.html">
The grammar below defines the syntax of CSS2. It is in some sense,
however, a superset of CSS2 as this specification imposes additional
semantic constraints not expressed in this grammar. A conforming UA must
also adhere to the forward-compatible parsing rules, the property and
value notation, and the unit notation. In addition, the document language
may impose restrictions, e.g. HTML imposes restrictions on the possible
values of the "class" attribute.
</blockquote>

I was wondering whether a parser can 'parse' (important for ignoring
purposes - see above) invalid (HTML) IDs - this belief (that maybe it
cannot) was further incited by the sentence above - 'In addition, the
document language may impose restrictions, e.g. HTML imposes restrictions
on the possible values of the "class" attribute.'

My reasoning was that since this sentence is in the grammar section rather
than the main body of the spec, it has some especial relevance to parsing
(as opposed to simply a note in Section 4 saying 'Although this is valid,
it might not be valid in the markup language') - does it imply the parsers
should also check that the tokens are valid in the markup language?
 

=====
----------------------------------------------------------
From Matthew Brealey (http://members.tripod.co.uk/lawnet (for law)or http://members.tripod.co.uk/lawnet/WEBFRAME.HTM (for CSS))
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

Received on Wednesday, 26 January 2000 04:01:46 UTC