Re: Selectors Tests

On Wed, Nov 12, 2008 at 12:47 AM, Brad Kemper <brkemper.comcast@gmail.com>wrote:

> On Nov 11, 2008, at 8:30 PM, 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.
>>
>> 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.
>>
>
> Its a bit of a circular argument isn't it? You're saying that you need use
> cases in the wild in order to consider it, but any such use cases that exist
> go to show that it isn't needed because there are workarounds, since their
> existence would require workarounds. In my own case, I prefer to use
> A[nchor] tags instead of buttons or submit inputs, because I can style them
> much more reliably.
>
> I do, however, understand and accept your argument that it is an HTML issue
> first, before it is ever a CSS issue, if the CSSWG is absolved from
> determining on its own what is considered disable-able or not.


No, he's saying that we *want* to provide easy ways for authors to do things
that they want to do.  Employing workarounds indicates that there is a lack
in the language that we can fix.  If there *are* no workarounds in popular
use, that indicates that the feature probably isn't useful enough to authors
to bother speccing and implementing.

~TJ