I18n comments on CSS selectors

It would be useful to have a non-normative reference to XPath, since there is a lot of overlap in functionality between CSS and XPath, even if the application scenarios (dynamic versus static environment) are different.

Your notion of "type": It would be good if you note that there are different notions of types, e.g. the element name as a type (as in the case of CSS) as the XML Schema notion of types.

This document, from the title appears to be about CSS specifically, not a generic styling language, so the text in 6.1.1 for example seems strange: "he mechanism for declaring a namespace prefix is left up to the language implementing Selectors. In CSS, such a mechanism ..."

"E[hreflang|="en"] an E element whose "hreflang" attribute has a hyphen-separated list of values beginning (from the left) with "en""

I think this should be made more generic, ie. replace hreflang with foo in the pattern to match the surrounding text. Otherwise it appears that this only works with hreflang. You could mention hreflang as an example of the type of attribute you have in mind (but see also point 1b), but my understanding is that this attribute can be used not only for xml:lang or lang attributes too, but also in principle for other attributes defined in schemas that use a similar mechanism for values.

If this is not the case, and particularly if xml:lang and lang are not to be used with this selector, that should be made much clearer. 6.3.1 says "For lang (or xml:lang) language subcode matching, please see the :lang pseudo-class." This is not clear enough to say that those attributes are not relevant to this selector, and if my understanding is correct, would probably benefit from the addition of 'also' before 'see' to clarify the sense.

Which version of XML Namespaces (and XML) is supported by the document?

In 6.1.1, it should be made clear that the styling language (e.g. CSS) must provide a prefix binding mechanism. It is also unclear what effect, if any, namespace declarations in the document being styled have on prefixes used in the stylesheet.

hreflang is used in a examples with the HTML link element. I'm always wary of the hreflang attribute's usefulness, and the meaning of that attribute in XHTML2 will change, and I'm also struggling to see an application for using it to style the link element content in current implementations. On the other hand, there is a fairly common practice of using the hreflang attribute specifically for styling link text on a elements to show what the expected language of the link target is. I'd therefore suggest changing hreflang examples referring to the link element to refer to the a element in examples.

For more information about this see How to indicate the language of a link destination.

"as described in RFC 3066 ([RFC3066])"

Recommend 'as described in RFC 3066 ([RFC3066]) or its successor'.

Note that its successor is currently only awaiting the IETF editor to assign an RFC number, but has been approved by the IETF to succeed RFC3066. Note also that it will allow for additional subcode values, such as script identifiers.

"Similarly, the following selectors represents a DIALOGUE element"

One of the 's's in 'selectors represents' has to go.

"including "en", "en-US", and "en-cockney""

Since en-cockney is not currently an allowable value according to RFC3066, I suggest you use something different, such as en-GB (UK English).

On substring matching: it would be highly desireable to have regular expression facilities instead of substring matching.

Your requirements for handling of default attributes corresponds to a non-validating XML processor, which you might make explicit. See XML conformance level.

You use the name "period" for the character U+002E, which is the Unicode 1.0 name for "full stop". You might change the naming or make the reference to the Unicode version for this naming explicit.

"in the same way as if performed by the '|=' operator in attribute selectors"

I think it is important to clarify that the behaviour of :lang and |= is significantly *different* with regards to inherited language values. This is not explained as far as I can see, but my understanding is that it is intended.

We explain this difference at http://www.w3.org/International/questions/qa-css-lang#inheritance, and to ensure interoperable implementations of :lang we feel that this needs to be clarified in the specification.

"based solely on the identifier C being either equal to, or a hyphen-separated substring of,"

Actually it has to match the hyphen separated values starting from the beginning. ie. 'AU' cannot match 'en-AU'. Perhaps this can be expressed in a similar way to E[foo^="bar"], ie. 'based solely on the identifier C being either equal to, or exactly beginning the element's language value'.

Or you could perhaps define it in a similar way to XPath, which says "s the same as or is a sublanguage of the language as defined by RFC 3066 or its successor". This may be safer, as the matching rules may change slightly with the successor to RFC 3066.

"the language is determined by a combination of the lang attribute, the meta element, and possibly by information from the protocol (such as HTTP headers)."

I suggest at least make this "the language is determined by use of the lang attribute, and possibly by information from the meta element and the protocol (such as HTTP headers)."

In practice, as far as we can tell, major (or possibly any) browsers do not use the meta element information to apply language information to text processing. And where they use the HTTP header, the application is inconsistent.

(Note that the i18n GEO WG recommends that the text-processing language be declared using attributes, and that the meta and HTTP approaches be used simply for referring to the language of the intended reader. Partly this is because the latter two approaches allow for multiple language values. Note that the effect of declaring more than one language value is not described in this specification.)

"represent an HTML document that is in Belgian, French, or German"

Need to remove the comma after Belgian. To be absolutely clear here, you could say "French as spoken in Belgium, or German".

There are two occurences of this error in this paragraph.

Another possibility would be to uppercase the BE, to help show that this is a country rather than a language code.

What is the intention of this section?

There should be a definition of what constitutes a 'letter'. We propose that this should be the first *grapheme cluster* (after any punctuation such as you list).

We believe that the specification must, as a minimum, require a letter to be defined as a 'default grapheme cluster', as defined by Unicode http://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries.

This would mean, for example, that 0065: e LATIN SMALL LETTER E + 0301: ́ COMBINING ACUTE ACCENT would be handled appropriately.

The specification should then also state that implementors should implement additional rules based on the language of the text where necesssary.

This may be particularly important for scripts such as those of south asia, where an initial character appears as part of a syllabic group and may be preceded on the display by a later character, or where the initial character is a ligature.

The i18n WG will make some attempts to investigate further the applicability of ::first-letter styling to other scripts and report back.

It may be useful to provide an example to clarify the bidirectional ordering point. We could probably do that for you, if needed.

Presumably, in ordinary right to left text, the user agent would be expected to apply the styling to the character on the right of the line.

Note that this (presumably) applies really to Hebrew but not Arabic, since the latter script is cursive.

There is an entry for the Character Model in the bibliography, but no reference in the text.

Please add a link to the Syntax document, and make it a dependency.