Re: Split Issue 30?

On 2/12/2012 6:48 PM, Jonas Sicking wrote:
> On Sun, Feb 12, 2012 at 7:19 PM, Charles Pritchard<chuck@jumis.com>  wrote:
>> On 2/12/2012 3:42 PM, Jonas Sicking wrote:
>>>>>   Jonas, you have a different perspective too. That's OK, too. Multiple
>>>>>   viewpoints are a good thing. We are fleshing out real issues in this
>>>>>   process.
>>> It sounds like your only objection to allowing aria-describedby to
>>> point to @hidden elements is that it will delay publishing a finalized
>>> HTML5 spec. That is certainly an understandable argument, though given
>>> the extreme inertia for changing semantics of existing features, I'd
>>> rather spec the @hidden attribute correction from the beginning, than
>>> wait to fix it in HTML6.
>>
>> My comment was intended as: we should wait to break current behavior, until
>> HTML6. If you want to consider it like breaking a bone to reset it, that's
>> the idea.
>> The current situation of position, visibility: hidden and display: none is
>> well tested, and I am certainly being conservative in my position of
>> altering core CSS architecture.
>>
>> As I understand it, @hidden is a shortcut for display: none, in
>> implementation and markup and may be implemented through the css selector:
>> [hidden] { display: none; }.
>>
>> I'm concerned about the structural problems of altering the CSSOM behavior
>> display: none.
> No one is suggesting to change how CSSOM or display:none works. Please
> see my change proposal, it does none of these things.
>
> It sounds to me like you are worried about various changes to the
> internals of browsers. So far none of the actual browser implementors
> have expressed this concern. In fact, both Maciej and I have said that
> this seems implementable and that we have to write similar code anyway
> to support<canvas>  accessibility.
>
> I'd have a lot more understanding for you being concerned if you
> actually were implementing a browser. I much rather that we ask people
> who actually implement browsers what is implementable.

I've implemented and produced implementations of significant chunks of 
CSSOM and HTML Forms in Canvas, as well as implementing the various 
prerequisites needed for those implementations to work on a variety of 
existing graphics APIs.
webkit uses display: none for @hidden.

The Canvas accessibility mod involves only re-basing HTMLCanvasElement. 
It does not involve dynamically re-basing the inheritance chain of 
arbitrary elements. Maciej has not, as far as I can tell, worked on 
Canvas accessibility code.

My concern isn't implementation. It's the consequences that changing the 
rules would have for web authors.
For one thing, they'd be able to focus on display: none elements.

If that's not the case, then @hidden is being split from the display: 
none semantic, and that is the crux of your proposal:
@hidden is a new semantic, and not a short-cut for display: none. And if 
that is truly the case-- then I'm less alarmed, though this does 
introduce a new semantic.

>> I'm concerned that encouraging display: none for perceivable content may
>> lead to a digital divide for users of older browsers and ATs.
> This seems like an argument against adding any features to HTML5 or
> any other standard to improve accessibility. Since any time you do
> that you risk increasing the digital divide since only newer browsers
> would support said standard.

No, it's an argument against changing display: none. I've been doing 
just fine keeping my compatibility layers from HTML3 - HTML5.

> You are of course entitled to your opinion. But I strongly disagree
> with it. Especially in the context of writing new webstandards which
> is what this mailing list is about.

I was under the impression that HTML5 is under last call, and that we're 
trying to finalize an existing web standard.
... That's not to exclude discussion of HTML6.

-Charles

Received on Monday, 13 February 2012 03:16:33 UTC