W3C home > Mailing lists > Public > public-html@w3.org > February 2012

Re: Split Issue 30?

From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 13 Feb 2012 12:46:28 -0800
Cc: Jonas Sicking <jonas@sicking.cc>, Laura Carlson <laura.lee.carlson@gmail.com>, Sam Ruby <rubys@intertwingly.net>, public-html@w3.org
Message-id: <F3A95E6A-05EE-488A-A4F0-0E279B11117B@apple.com>
To: Charles Pritchard <chuck@jumis.com>

On Feb 12, 2012, at 7:16 PM, Charles Pritchard wrote:

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

I have worked on WebKit's accessibility code (though not Canvas-related aspects). I have made some tricky changes, including support for "continuations" in our render tree, which is what happens when a block is nested inside an inline. I am quite confident that to properly support accessibility of the canvas descendant DOM, we will have to do at least one of the following:

(1) Construct a render tree for content that is otherwise not rendered to the screen, to be able to expose its full semantics; OR
(2) Teach our accessibility code to expose full semantics, information and behavior to AT for elements that have no render tree.

This would be required because our accessibility code uses the render tree as well as the DOM. 

And this is essentially the same as the work that would be required to allow @hidden content to expose full semantics to AT.

> 
> 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 think this is what Jonas is proposing - behavior for @hidden elements that would not apply to content which is set to display: none in other ways. I don't think be advocates changing behavior for display: none content in any way.

(Note, I do not necessarily support or oppose Jonas's proposal, I merely wanted to clarify the implementation issues.)

Regards,
Maciej
Received on Monday, 13 February 2012 20:46:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:44 GMT