Re: Selectors Tests

Fantasai:

It is extremely picky, but the sentences should be in agreement about  
the number of elements and states. (See below.)

On Nov 5, 2008, at 4:20 PM, 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.
>

Either: "The :enabled pseudo-class represents A user interface  
element that IS in an enabled state" OR "The :enabled pseudo-class  
represents user interface elementS which are in enabled states"

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

Similarly here. Either "an element ... is in a disabled state" or  
"elements ... are in disabled states"

> 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?
>
> ~fantasai
>


It seems wrong to have multiple elements in the same state. (I know  
it can be thought of as if they all were in the same state "box" but  
it doesn't 'feel' right to state it that way.) Also, the  
inconsistency between the singular (state) and the multiple  
(elements) will, on some level, make readers have to work harder to  
understand the spec.

</James>

Received on Thursday, 6 November 2008 16:24:16 UTC