Ok, this is odd…  I knew I'd sent this, but I don't see it in my PF mail.


Do you need additional changes?


From: Cynthia Shelly
Sent: Wednesday, April 08, 2009 3:35 PM
To: Cynthia Shelly; Protocols and Formats Working Group WG
Subject: RE: CSS selectors review for PFWG



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.


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.


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


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


Namespace:  don’t report this.


[1]ARIA States and Properties http://www.w3.org/TR/2009/WD-wai-aria-20090224/#global_states


From: Cynthia Shelly
Sent: Wednesday, April 08, 2009 9:23 AM
To: 'Protocols and Formats Working Group WG'
Subject: CSS selectors review for PFWG


I took an action item to review CSS Selectors Level 3 for PFWG, with a particular eye to how it could be used to style HTML+ARIA markup.  I’m wondering about how ARIA and psudoclasses might play together, as ARIA states and properties are dynamic in much the same way as other things for which there are psudoclasses. 

Overall, it seems fine.  It allows for namespaces and has good support for Attribute selectors. 


The one area where I’d like to see more specific support is in psudoclasses, in Section 6.6.  There is a concept of dynamic psudoclasses that deal with information that may come from outside the element.  :active :focus :hover are examples, as is the :lang psudoclass.  P:lang=fr can be true because the whole page has a French language set, because a parent of this <p> does, or because the <p> itself does.  ARIA states like “checked” should be treated the same way.  There is a :checked psudoclass, and it’s not clear to me whether aria-checked affects it. 


It also seems potentially useful to have psudoclasses for all of the ARIA states and properties, since these are dynamic in nature like checked and active.  However, there are only a few psudoclasses defined in this spec.  I don’t know if there is a mechanism for adding more from other specs, or if this WG would want to absorb all of the ARIA states and properties. 


Other thoughts

·         Do :hover :active :focus apply to all elements, or just links?

·         ::before and ::after give access to generated content.  Can anyone think of accessibility applications for this?

·         What was the ::selection pseudo-element and why is it gone?  Section 7.3

·         Namespace selectors will be ignored in downlevel clients that don’t understand namespaces.  That seems reasonable.  Can anyone think of cases where the missing CSS might be a problem?  What about for generated content?