W3C home > Mailing lists > Public > www-style@w3.org > October 2003

Re: CSS2.1 :lang

From: Tex Texin <tex@i18nguy.com>
Date: Thu, 16 Oct 2003 22:39:34 -0400
Message-ID: <3F8F5666.DFB8DE6E@i18nguy.com>
To: Chris Lilley <chris@w3.org>
Cc: Bert Bos <bert@w3.org>, www-style@w3.org, W3c I18n Group <w3c-i18n-ig@w3.org>



Chris Lilley wrote:
> >> 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..

But all you need say is that you are matching to a hyphen separated token list.
Referencing more irrelevant information is an opportunity for confusion and
inconsistency with respect to how matching is performed by different UA. It
also makes for problems (either confusion or extra work to clarify the specs)
if the RFC is updated in ways that are irrelevant to matching, but leaves the
css spec  behind. (ie css points to 1766 and software using it points to 3066
or future rfcs.) It is compounded where css supports more than one ML, and you
have html with one rfc, xml with another.... All of this is avoided with
defining the matching rule independently and straightforwardly.
(Unless something is done to language codes that requires a change to the
matching rules.)

It is true that other portions of the spec that require and depend on the exact
nature of language codes will still need updating, but it seems beneficial to
me to simplify where possible.


 
> >> 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.

That is one possible intepretation. But as the spec doesn't say, it is unclear
what the right behavior is.
Someone else might validate the language code, determine it is invalid and
therefore determine that the selector is invalid. CSS 4.1.7 says that if a
selector is invalid, then all of the selectors and the declaration block are to
be ignored. This would then have a larger impact than just not matching, since
it also affects rules for other selectors.

h1, p:lang(k9) {color : blue;}

h1 would then also not be blue.



> 
> 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?

Hope that example clarifies.
tex
Received on Thursday, 16 October 2003 22:41:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:24 GMT