Re: Split Issue 30?

hi Charles,

>From testing this is what I have found [1]:

*Chrome, Opera, Firefox & Safari: *Content within elements that have a
hidden attribute are not displayed or navigable.

*
*

*Note:* In all supporting browsers CSS display:none is applied to elements
with the hidden attribute.


The fact that as currently implemented CSS display:none hides content from
all users is well understood and relied upon by authors.


[1] http://html5accessibility.com/


regards

Stevef

On 13 February 2012 03:16, Charles Pritchard <chuck@jumis.com> wrote:

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