Re: Selectors Tests

Lachlan Hunt wrote:
> 
> Brad Kemper wrote:
>> On Nov 11, 2008, at 4:50 PM, Lachlan Hunt wrote:
>>> You haven't explained why this is a real problem.  Links already have 
>>> two other pseudo classes that can be used to match them: :link and 
>>> :visited, which more accurately reflect the states that a link can be 
>>> in.  The :enabled and :disabled pseudo classes clearly weren't 
>>> designed to address the link use cases and we have no reason for them 
>>> to.
>>
>> I don't see any reason to not have links that can be enabled and 
>> disabled. They are often used in the same sort of roles as buttons and 
>> submit inputs.
> 
> Allowing links to be disabled would be something for the HTMLWG to 
> consider, but it would require clear use cases, and there haven't been 
> any presented.  If this was something that authors really wanted, then 
> it's very likely that they would have found workarounds, which isn't too 
> hard to do.

Consider this:

<fieldset disabled>
   <legend>...</legend>
   <a href=...>...</a>
   <input type=text />
</fieldset>

In all UI systems I know disabling container means disabling all its 
child elements.

Consider lightweight modal dialog implementations in HTML/CSS when
you need to show one enabled container with container layer disabled
as a whole - all inputs, scrollbars, links, etc. has to be disabled -
shall not be clickable nor TAB traversible.

I've seen a lot various attempts in AJAX toolkits to do this - all of 
them are at least ugly without native support.

The task is quite widespread in AJAX world.

(AJAX is a wrong name for JSUI but seems everybody understand what
this means)

> 
> e.g. Attaching an event listener that cancels the default action when 
> clicked, and adding a class name like class="disabled" which can be used 
> for styling.  (If authors are doing this, or something else that gives 
> equivalent results, then please raise the issue on public-html and 
> present the examples.)
> 
> The reason to not have them without such use cases is that defining and 
> implementing the feature has a cost and that cost needs to be justified. 
>  If there aren't any real use cases, then authors aren't going to use it 
> and then implementing it would be a waste of time and resources.
> 

The same recommendation can be given to people who want to see disabled
input elements to define class .disabled or just to use [disabled].
Why do you need such strange :disabled then? And especially that
peculiar :enabled that in fact means :input, :submittable, :interactive, 
everything else but not :not(:disabled)

-- 
Andrew Fedoniouk.

http://terrainformatica.com

Received on Wednesday, 12 November 2008 07:04:01 UTC