atom feed9 messages in org.w3.www-styleRe: css3-selectors Summary of Comment
FromSent OnAttachments
Janina SajkaMay 7, 2009 5:02 pm 
Tab Atkins Jr.May 7, 2009 5:24 pm 
Ian HicksonMay 7, 2009 6:19 pm 
Andrew FedonioukMay 7, 2009 7:52 pm 
Henri SivonenMay 14, 2009 5:48 am 
James CraigMay 14, 2009 4:02 pm 
fantasaiOct 23, 2009 11:19 am 
Michael CooperNov 18, 2009 9:34 am 
Michael CooperNov 18, 2009 9:36 am 
Subject:Re: css3-selectors Summary of Comment
From:fantasai (fant@inkedblade.net)
Date:Oct 23, 2009 11:19:34 am
List:org.w3.www-style

Janina Sajka wrote:

The Protocols and Formats Wg has the following comments regarding Selectors Level 3 last call at http://www.w3.org/TR/2009/WD-css3-selectors-20090310. PF thanks Cynthia Shelly of Microsoft for leading our review of this draft, and we apologize for our late response to this last call.

Thank you for your review of the Selectors Level 3 last call. The CSS Working Group responds as follows.

--------------------------------------------------------------------------------

Pseudoclasses: We ask that there be support for ARIA states and properties [1] as
pseudoclasses. Many of these are similar to things that are currently supported as
pseudoclasses, in that they can be set in multiple ways. For example, "checked" can be set from an HTML attribute, from aria-checked, or by user action. It is useful for a CSS author to be able to style all checked things the same, regardless of how they came to be checked. Ask whether the CSS WG thinks it's better to make
that part of the selectors spec, part of the ARIA spec, or something else. Is there an extensibility mechanism for psudoclasses.

The CSS Working Group considers this request out-of-scope for Selectors. Selectors doesn't define when an element is in the "checked" state, only that a ':checked' pseudo-class matches when the element is in a "checked" state. It is up to the document language, whether that be defined by the DocBook spec or by a combination of HTML5+DOM3+SVG+ARIA, to define when an element is in the checked state.

Hover, active, focus: All elements should be able to take those states. Any element that receives focus should be able to make use of those. With ARIA and with HTML 5, any element can be focusable. Before that, form elements and buttons are also focusable.

While Selectors recognizes that there may be document language or implementation-specific limits on which elements can be :active or acquire :focus, it does not impose any such limits. If ARIA+HTML5 defines all elements to be focusable, then the :focus pseudo-class can potentially apply to any element in the document.

::before and ::after may offer a work-around to accessibility issues with generated content not being in the DOM. PFWG thinks this is a useful feature and wants to see it supported.

The CSSWG also wants to see ::before and ::after supported. :) (There are already multiple implementations of this feature, btw.)

What was the ::selection pseudo-element, and why was it removed? From its name it seems it could be quite useful for ARIA-based applications, which manage their own selection.

The ::selection pseudo-element allowed the styling of a selection, e.g. changing the highlight and text color. It was removed because the details of its behavior were poorly defined, and would take significant effort to work out; also implementations would then have to converge on those details. The CSS Working Group felt it was more important to complete Selectors Level 3, since all other features in the draft were well-supported, and to defer ::selection to a future module such as Selectors Level 4. There is interest in pursuing this feature, but not in this draft.

Please let us know if this adequately addresses your comments.