comments on CDF / CSS selectors: current state

Hi all,

As an input for todays call: Below is the current state of the CDF / CSS  
selectors discussion. I added the end of the threads below, and the  
current position of the working groups. To read this fast, please search  
for "reject" or "partially".

Regards, Felix.

------------------------------------------
CSS selectors (overview of comments at  
http://www.w3.org/International/reviews/0601-css3-selectors/ )
------------------------------------------

1
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.
http://lists.w3.org/Archives/Public/public-i18n-core/2006JanMar/0082.html
Rejected: "XPath doesn't reference Selectors either."

2
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.
http://lists.w3.org/Archives/Public/public-i18n-core/2006JanMar/0083.html
Rejected: "element type is a well-established term ..."

3
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 ..."
http://lists.w3.org/Archives/Public/public-i18n-core/2006JanMar/0084.html
Rejected: WG sees no confusion, only the document location is confusing,  
but it cannot be changed.

4
"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, ...
http://lists.w3.org/Archives/Public/public-i18n-core/2006JanMar/0085.html
WG has changed E[hreflang|="en"] to E[foo|="en"] in section 2.

5
Which version of XML Namespaces (and XML) is supported by the document?
http://lists.w3.org/Archives/Public/public-i18n-core/2006JanMar/0031.html
Partially accepted: "All of them. To make this clearer we have made the  
references to
[XMLNAMES] explicitly informative and made the prose say "e.g." before
mentioning [XMLNAMES]."

6
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.
http://www.w3.org/International/reviews/0601-css3-selectors/
http://lists.w3.org/Archives/Public/public-i18n-core/2006JanMar/0088.html
Rejected: "Since it is possible to use Selectors with languages that do  
not have
namespaces at all (e.g. the language most used with CSS, namely HTML4), we
do not agree that such a prefix binding mechanism must be provided."

7
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.  
[...]
http://lists.w3.org/Archives/Public/public-i18n-core/2006JanMar/0089.html
Accepted: "We have changed the example from using a <link> element to  
using an <a>
element in section 6.3.1."

8
"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.
http://lists.w3.org/Archives/Public/public-i18n-core/2006JanMar/0091.html
Accepted: "We have made this change.
Note that this is just an informative reference, and therefore it really
makes no difference either way to the normative requirements of our draft."

9
"Similarly, the following selectors represents a DIALOGUE element"
One of the 's's in 'selectors represents' has to go.
http://lists.w3.org/Archives/Public/public-i18n-core/2006JanMar/0092.html
Accepted: "The working group discussed this, and agreed to make the  
subject and
verb agree by using the plural, i.e., "selectors represent"."

10
"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).
http://lists.w3.org/Archives/Public/public-i18n-core/2006JanMar/0093.html
Accepted: "The working group discussed this.
We used "en-scouse" instead."

11
On substring matching: it would be highly desireable to have regular  
expression facilities instead of substring matching.
http://lists.w3.org/Archives/Public/public-i18n-core/2006JanMar/0109.html
Rejected: "We will consider this for a future version of Selectors.  
However, at this time it seems too late to add new (unimplemented)  
features to this draft."

12
Your requirements for handling of default attributes corresponds to a  
non-validating XML processor, which you might make explicit. See XML  
conformance level.
http://lists.w3.org/Archives/Public/public-i18n-core/2006JanMar/0100.html
Half accepted: "[...] I have added "This corresponds to the behaviour of  
non-validating
processors as defined by the XML specification." to the note in section
6.3.4."

13
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.
http://lists.w3.org/Archives/Public/public-i18n-core/2006JanMar/0101.html
Accepted

14
"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.
http://lists.w3.org/Archives/Public/public-i18n-core/2006JanMar/0102.html
Accepted: "I have added the following paragraph to 6.6.3:
The difference between :lang(C) and the '|=' operator is that the '|='
operator only performs a comparison against a given attribute on the
element, while the :lang(C) pseudo-class uses the UA's knowledge of the
document's semantics to perform the comparison."


15
"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.
http://lists.w3.org/Archives/Public/public-i18n-core/2006JanMar/0103.html
Partially accepted:
"I have changed the definiton to read:
   Whether an element is represented by a :lang() selector is based solely
   on the element's language value being exactly equal to the identifier C,
   or beginning with the identifier C immediately followed by "-" (U+002D),
   in the same way as if performed by the '|=' operator in attribute
   selectors."
"We specifically do not wish to refer to RFC 3066 or its successors because
regardless of those specifications changing the rules, the rules for
matching of the |= and :lang() forms in Selectors will not change. If it
did change it would cause backwards compatibility issues."

16
This section should state that the matching of language values is  
case-insensitive, eg. en-gb is the same as en-GB.
No reply so far.

17
"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)."
http://lists.w3.org/Archives/Public/public-i18n-core/2006JanMar/0104.html
Accepted, change made

18
"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.
http://lists.w3.org/Archives/Public/public-i18n-core/2006JanMar/0105.html
Accepted

19
What is the intention of this section 6.6.6?
http://lists.w3.org/Archives/Public/public-i18n-core/2006JanMar/0106.html
Explained: "It is an empty section with the intention of introducing no  
normative
conformance criteria."

20
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). [...]
No reply from the Working Group, only from Daniel Glazman (bottom of
http://lists.w3.org/Archives/Public/public-i18n-core/2006JanMar/0046.html  
):
"> #20 oh, no please... That's certainly something I don't want
> us to dive into.
>      We could link to a definition, but adding one ourselvesis too  
> dangerous."

21
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.
No reply.

22
Reference to character model in the bibliography, but not in the text.
http://lists.w3.org/Archives/Public/public-i18n-core/2006JanMar/0107.html
Reference in the bibliography removed.

23
Please add a link to the Syntax document, and make it a dependency.
http://lists.w3.org/Archives/Public/public-i18n-core/2006JanMar/0108.html
Rejected: "I have made no change to the spec in response to this comment.  
In the
likely event that this does not satisfy your request, please explain
exactly what it is you would like to see, with your reasoning."


------------------------------------------
CDF (overview of comments at  
http://www.w3.org/International/reviews/0601-cdf/Overview.html and  
http://www.w3.org/International/reviews/0601-cdfcore/  )
------------------------------------------

cdr-1
As for the topic of pishing: Please add a reference to utr 36 and utr 39,  
which provide possible solutions for the problems you are mentioning.
no reply.

cdr-2
You write: "For example: XML 1.1 or HTML documents tied through hypertext  
reference producing as many DOM linked to one another." What is the  
relation between versions of XML and XML namespaces in this scenario? E.g  
what happens, if an XML 1.0 document references an XML 1.1. document? It  
might be that this depends on the languages being compounded, but you  
should have general guidelines for (new) languages as well.
http://lists.w3.org/Archives/Public/public-i18n-core/2006JanMar/0120.html
"Why would anything specific happen? I do not really understand what
namespaces have to do with two documents that are only bound to each
through a reference."

cdr-3,4: no reply.

cdr-5
If you ask an SVG document about language information, and the document is  
inside an HTML document, the xml:lang attribute in the HTML applies to the  
SVG as well. It seems that the compounding specs should say: \"You should  
get the same results for both inclusion and referencel.\"
http://lists.w3.org/Archives/Public/public-i18n-core/2006JanMar/0127.html
Rejected:
"The WG has just discussed this, and we feel that for the CDR case -
which is all the current set of Last Call drafts cover - the value of
the xml:lang attribute in any containing HTML should *not* apply to
children, because it isn't authoritative (as described in the TAG's
finding on authoritative metadata[1]) as a result of requiring
multiple messages to assemble the compound document.  Consider, for
example, that the child document might be returned with an HTTP
message which includes a Content-Language header (sec 14.12 of RFC
2616) with a (authoritative) value inconsistent with that specified by
the xml:lang attribute.  More generally too, content may be retrieved
 from multiple domains over which the author of the containing document
has no control, and therefore propagating the value of attributes like
xml:lang doesn't seem appropriate."
Martin's reply:
"I have to agree with Mark here. It is very important to make clear that
xml:lang inherits inside the XML document. But it would not be appropriate
to make it apply to documents that are just referenced. This is similar
to the HTML case, where html:lang on a frame document never applied
to the individual frame contents."

cdf-core: no replies so far.

Received on Tuesday, 31 January 2006 14:14:29 UTC