W3C home > Mailing lists > Public > www-style@w3.org > April 2014

Re: [selectors4] Request for :role() selector (matches computed role using UA internals, not attribute substring matching)

From: James Craig <jcraig@apple.com>
Date: Tue, 22 Apr 2014 11:24:02 -0700
Message-id: <0F7F0BBF-C7D6-4571-A48C-0B2D2F9069B3@apple.com>
To: www-style@w3.org
Following up on this thread from last year. 

It's come to my attention that some aspects of the :role() selector will be tricky. I don't think these negate the need for a role selector, but the CSS editors should be aware of these issues when writing this portion of the spec. In particular, role is typically not computed when an element is not rendered. This might cause some confusion if authors attempted to do things like using querySelectorAll() to find unrendered elements.

For example:

    /* This will hide all native and ARIA buttons. */
    for (el of document.querySelectorAll("*:role(button)"))
        el.hidden = true; 

    /* But this will not unhide any elements, because the computed role was invalidated once the buttons became unrendered. */
    for (el of document.querySelectorAll("*:role(button)"))
        el.hidden = false; /* No elements to unhide, b/c hidden buttons are no longer computed has having the button role. */ 

The other potential problem may end up being an implementation detail, but it's related so I feel I should mention it. Due to the role not being computed until an element is rendered, using role selectors for general layout may result in rendering engines needing to execute additional rendering passes before displaying content. It's not yet clear to me if this will cause significant performance implications. 



On Jul 3, 2013, at 1:10 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Wed, Jul 3, 2013 at 1:08 PM, James Craig <jcraig@apple.com> wrote:
>> On Jul 3, 2013, at 12:29 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 
>>> What sort of things would you use this selector for?  I don't think
> 
>>> you can generally style things according to their role;
> 
>> 
> 
>> Why not?
>> 
>> :role(checkbox):not(input) { /* style an ARIA checkbox to look like a checkbox */ }
>> :role(switch):not(input) { /* style an ARIA switch to look like a switch */ }
>> 
>> Would result in different styles for this element depending on the browser capabilities:
>> <div role="switch checkbox">
>> 
>> Another example might be a user agent style sheet that enlarged the size of buttons for a user.
>> 
>> /* Note: !important just b/c this is a USER style sheet. */
>> *:role:(button) {
>>         -vendorprefix-appearance: none !important; /* override the default styles for the element */
>>         font-size: 2rem !important;
>>         margin: 0.2rem 0.5rem !important;
>>         padding: 0.2rem 0.5rem !important;
>>         color: red !important;
>>         background-color: white !important;
>>         border: outset 0.3rem red !important;
>> }
>> 
>>> the precise element used can vary considerably and affect what styles work.
> 
>> 
> 
>> For some properties that is true, but may be alleviated somewhat with native element display overrides like "-webkit-appearance: none;"
>> 
> 
>> For many properties, this won't matter. For example, background-color works on just about everything.
> 
>> 
>> *:role(textbox):focus {
>>         background-color: yellow; /* focus highlight for text inputs */
>> }
>> 
> 
>>> Is there a use related to JS?
> 
>> 
> 
>> Sure. document.querySelector() could be used for assigning event handlers, validation, automation, etc.
> 
> 
> Okay, seems reasonable to me.
> 
> ~TJ
> 
> 
Received on Tuesday, 22 April 2014 18:24:30 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:21 UTC