On Thursday, October 16, 2003, 3:09:41 PM, Bert wrote:
BB> Tex Texin writes:
>> Does ':lang()' match elements that have language set to the empty tag?
>>
>> It might be thought to match all languages, since in the absence of simple
>> selectors, * is presumed, so it is conceivable that absence of a tag might be
>> equivalent to all. It might also be deemed to be an error to have no tag inside
>> the parens.
>> So the spec should address the issue.
It would match those that have no language set.
BB> But making it match elements with no language seems the most useful,
BB> especially since it parallels RFC 3066.
I agree, and that is also the definition of xml:lang="".
>> For the purposes of matching, I wonder if it makes sense to
>> reference the RFCs at all.
Yes, it does, because matching is to a hyphen separated token list..
>> Isn't it really string matching based on strings formatted with hyphen
>> separators? Does any software verify that the language tag contains
>> appropriately registered codes or uses ISO codes? Should it be an error, or
>> perhaps the rule ignored, if a CSS document specifies :lang(k9) since k9 is
>> not an offical language code or a properly formatted private code.
No, it just means that it probably does not match anything since
nothing has that lang code.
BB> I like that suggestion: it removes a dependency.
I don't see the value of removing that dependency.
BB> The definition of the "|=" operator is already generic.
Yes.
BB> It only
BB> requires a UA to split a string value at every "-" and doesn't require
BB> the string to be a valid language. The ':lang()' refers to that
BB> definition and could be made generic as well,
It could. But how would that help?
BB> e.g.:
BB> Current text in 5.11.4:
BB> The pseudo-class ':lang(C)' matches if the element is in language
BB> C. Here C is a language code as specified in HTML 4.0 [HTML40] and
BB> RFC 1766 [RFC1766]. It is matched the same way as for the '|='
BB> operator.
BB> Proposed:
BB> The pseudo-class ':lang(C)' matches if the element is in language
BB> C. CSS doesn't define what are valid language names and the string
BB> C doesn't have to be a valid language name in the source document.
BB> It is matched the same way as for the '|=' operator.
BB> And in 5.8.1, in the informative reference to RFC 1766, "1766" is
BB> replaced by "3066."
I agree that CSS should not be required to know whether language tags
have been registered or not.
--
Chris mailto:chris@w3.org