Comment on Selectors LCWD

[Krzysztof Maczyński]

Dear WG,

I think the disticntion (detailed in chapter 11) between how selectors of the form prefix\:NCName are interpreted by down-level clients (should rather be called user agents anyway) and agents compliant with this spec is unnecessary. Since there can be no colon in a prefix or local name, the element type selectors (and attribute selectors, by the same way) containing a colon (impossible in direct syntax, but achievable e.g. with the backslash escape) can work independently of the provisions form namespaces described therein. This wouldn't break existing content. If broken, it would be so completely, as this functionality is the only one available in CSS currently. I see no reason for this, so please don't introduce this gratuituous incompatibility which doesn't give or enable anything new, only takes a feature away.

[fantasai]

Krzysztof Maczyński wrote:

> Dear WG,
>
> I think the disticntion (detailed in chapter 11) between how
> selectors of the form prefix\:NCName are interpreted by
> down-level clients (should rather be called user agents anyway)
> and agents compliant with this spec is unnecessary. Since there
> can be no colon in a prefix or local name, the element type
> selectors (and attribute selectors, by the same way) containing
> a colon (impossible in direct syntax, but achievable e.g. with
> the backslash escape) can work independently of the provisions
> form namespaces described therein. This wouldn't break existing
> content. If broken, it would be so completely, as this
> functionality is the only one available in CSS currently. I see
> no reason for this, so please don't introduce this gratuituous
> incompatibility which doesn't give or enable anything new, only
> takes a feature away.

The intention of this section is to explain the behavior of
selectors in a mixed legacy+updated client environment. It
is not intended to define any features or recommend any
particular authoring practices.

I've marked this section informative, as it should have been.
Please let me know if this adequately addresses your comment.

~fantasai

[Anne van Kesteren-2]

On Wed, 21 Oct 2009 02:10:31 +0200, fantasai  
<fantasai.lists@...> wrote:
> The intention of this section is to explain the behavior of
> selectors in a mixed legacy+updated client environment. It
> is not intended to define any features or recommend any
> particular authoring practices.
>
> I've marked this section informative, as it should have been.
> Please let me know if this adequately addresses your comment.

Maybe we should just remove that section. No other CSS specification  
documents what boils down to CSS hacks for UAs that do not support a  
particular feature.


--
Anne van Kesteren
http://annevankesteren.nl/

[fantasai]

Anne van Kesteren wrote:

> On Wed, 21 Oct 2009 02:10:31 +0200, fantasai
> <fantasai.lists@...> wrote:
>> The intention of this section is to explain the behavior of
>> selectors in a mixed legacy+updated client environment. It
>> is not intended to define any features or recommend any
>> particular authoring practices.
>>
>> I've marked this section informative, as it should have been.
>> Please let me know if this adequately addresses your comment.
>
> Maybe we should just remove that section. No other CSS specification
> documents what boils down to CSS hacks for UAs that do not support a
> particular feature.

The CSSWG discussed this and decided to remove the section.
Should be fixed in the latest editor's draft.

~fantasai

[Krzysztof Maczyński]

> The intention of this section is to explain the behavior of
> selectors in a mixed legacy+updated client environment. It
> is not intended to define any features or recommend any
> particular authoring practices.
>
> I've marked this section informative, as it should have been.
> Please let me know if this adequately addresses your comment.
Yes, it does. Originally I wanted something affecting conformance along the following lines: make prefix\:NCName match _both_ elements of type prefix:NCName in all namespaces or in the default namespace when one is defined (parsing XML by a namespace-aware parser never results in this, so it's mainly for non-aware ones, but things like createElement("a:b") come to mind) _and_ elements of type NCName in the namespace to which prefix is bound. But given that bindings of prefixes are in CSS separate from those in the styled content, this wouldn't necessarily work without requiring that the style resolver be provided with the content's bindings (was this a problem raised by implementors or perceived as an architectural inconsistency?). Another option might be to include in CSS the content's prefixes of the LinkStyle node (if any) which referenced the stylesheet. This would solve typical cases, like XHTML's style element under html on which all namespaces used in the document are declared, but not embedded fragments in body with their own distinct declarations or xml-stylesheet PIs. So, if the WG believes these issues have been given enough consideration and the current WD is the best conceived resolution of them, I concur.

Anne van Kesteren wrote:
> Maybe we should just remove that section. No other CSS specification  
> documents what boils down to CSS hacks for UAs that do not support a  
> particular feature.
It was already in the CSS Namespaces WD before moving to Selectors. It's a useful piece of information, if not very much for implementors, then certainly for authors. Please keep it (marked as informative guidance) in one of these specs.

Best regards,

Krzysztof Maczyński
Invited Expert, HTML WG