Re: Selectors Tests

fantasai wrote:
>
> Boris Zbarsky wrote:
>>
>> fantasai wrote:
>>> Well, the Selectors spec is fixable. Daniel and I are actively
>>> editing it now. However I don't think I agree that :enabled/:disabled
>>> should not apply to type="hidden". The distinction does exist for
>>> hidden controls as well, does it not?
>>
>> Indeed.  Disabled hidden inputs do not submit.
>>
>> If that's the sort of distinction we want for :enabled/:disabled, 
>> that's also fine by me; the spec text just needs to be adjusted to 
>> handle that, then.
>
> Goals for rewording:
>   - Allow HTML5 to easily define what elements are :enabled or :disabled
>   - Make sure definition of :enabled/:disabled depends not on CSS but on
>     the semantics of the markup and object model.
>   - Make sure <input style="display: none"> matches :enabled
>   - Make sure <a href=""> does not match :enabled
>
> Here's a proposal:
> http://dev.w3.org/csswg/selectors3/#UIstates
>
> Change
>  # The :enabled pseudo-class allows authors to customize the look of
>  # user interface elements that are enabled — which the user can
>  # select or activate in some fashion (e.g. clicking on a button
>  # with a mouse)
> to
>  | The :enabled pseudo-class represents user interface elements that
>  | are in an enabled state — e.g. elements that the user can alter or
>  | activate in some fashion, but that could be disabled in a different
>  | context.
>
> Change
>  # Similar to :enabled, :disabled allows the author to specify
>  # precisely how a disabled or inactive user interface element should
>  # look.
> to
>  | The :disabled pseudo-class represents user interface elements
>  | that are in a disabled state — e.g. elements that could be enabled
>  | but cannot currently be altered or activated by the user due to
>  | its semantics.
>
> Remove
>  | An element is enabled if the user can either activate it or transfer
>  | the focus to it. An element is disabled if it could be enabled, but
>  | the user cannot presently activate it or transfer focus to it.
>
> Comments? Suggestions for improvement?
>
>
It is not clear what :enabled means exactly.

:disabled is a state of focusable element - the DOM element that has 
some active behavior (controller) assigned to it.
That element could be :disabled, otherwise it will accept focus.
For example <input type=text> is focusable element as its behavior knows 
about and will handle setFocus() request.
Passive elements like <p> and <div> are normally non-focusable. To make 
such elements focusable we  someone should
define  <p tabindex=1 > for example.

So are my questions:
1)  is :enabled is a sort of :focusable element?
2) Is any passive DOM element like <p> has :disabled state flag by 
default? Or it has neither :disabled nor :enabled?
3) Usually <p tabindex=1 > is a focusable element so presumably it 
should get :enabled (or better :focusable) state flag
    and <p tabindex="-1" > should have :disabled flag. Is this how it 
supposed to work?

I believe (and propose) that CSS should have just :focusable 
pseudo-class. Thus all passive elements will have not this flag set
and active input elements (including those that have @tabindex >= 0 
defined) will get the :focusable state. Active input elements
that are disabled by e.g. using @disabled (and so will not accept focus) 
are not :focusable.

Otherwise we need to specify clearly of what :disabled, :enabled, 
:not(:disabled) and :not(:enabled) mean.

--
Andrew Fedoniouk.

http://terrainformatica.com

Received on Thursday, 6 November 2008 01:26:10 UTC