W3C home > Mailing lists > Public > public-html@w3.org > April 2010

Re: ISSUE-96 Change Proposal

From: Maciej Stachowiak <mjs@apple.com>
Date: Thu, 01 Apr 2010 09:57:31 -0700
Cc: Steven Faulkner <faulkner.steve@gmail.com>, Jonas Sicking <jonas@sicking.cc>, HTMLWG WG <public-html@w3.org>
Message-id: <8216F11E-0415-4088-81EB-2633A090B81F@apple.com>
To: Shelley Powers <shelley.just@gmail.com>

On Apr 1, 2010, at 9:22 AM, Shelley Powers wrote:

> On Thu, Apr 1, 2010 at 9:39 AM, Maciej Stachowiak <mjs@apple.com>  
> wrote:
>> On Apr 1, 2010, at 8:00 AM, Steven Faulkner wrote:
>>> Hi all,
>>> i agree that it is better for  accessibility to have native controls
>>> as the properties of these controls can be hooked up to  
>>> accessibility
>>> APIs by the browser.
>> This point is worth noting. Appropriate semantic markup for  
>> application
>> controls does not mean extra work has to be done by a screen reader  
>> or other
>> assistive technology, as Shelley suggested. Rather, the browser  
>> engine
>> directly exposes such controls to the appropriate accessibility  
>> API, and the
>> screen reader at the other end doesn't even have to know if it's a  
>> real
>> control or ARIA.
> That's all well and good, but it's still a bad design choice.
> How many declarative elements will we have in the future. Dozens?
> Hundreds? How many versions of HTML we'll we have to have, because we
> have to roll out new versions for a bunch of widgets that could be
> created with JavaScript and CSS?

If we wanted to have declarative elements for every reasonable control  
that a Web App? Well, Interface Builder for Mac OS X offers about 35  
distinct controls. I would say that is more than enough for any  
reasonable application, at least at the current state of the art.  I  
think this is a useful point of comparison because Cocoa is widely  
believed to be a usable and comprehensive UI toolkit. Note: that's  
combining ones that would be the same semantic element in  HTML, but  
with different styles, and omitting controls that are solely there to  
control layout. Of these, I see about 4 that are not adequately  
covered by an HTML5 element or <input> type, yet general-purpose  
enough that they could possibly make sense to add. The most notable  
omission is table / outline. This would have been handled by  
<datagrid>, but <datagrid> didn't make the cut for HTML5.

(Later if I get a chance, I'll compare to the set of controls offered  
by Cocoa Touch).

Received on Thursday, 1 April 2010 16:58:05 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:00 UTC