[whatwg] Attitude and Direction of the WHATWG

On Fri, 26 Nov 2010, Charles Pritchard wrote:
> 
> I want to suggestion a reason for this impasse: the WHATWG intends to 
> produce a scene-graph specification. Other activities are out of scope.

Insofar as there is a WHATWG philosophy, it is that the spec written here 
will match implementations, and that within that restriction, it will be 
based on concrete use cases. Different contributors (including myself and 
any implementors) may have different further intentions, but I wouldn't 
describe them as goals of the WHATWG.

I'm not sure what you really mean by "scene-graph specification", so it's 
hard to comment on that specifically. Historically, and still today, the 
HTML language and its associated APIs are generally intended to primarily 
convey semantics (meaning, as opposed to presentation) so that they can be 
rendered in a media-independent way on any device.

If there is a philosophy regarding accessibility specifically, it's that 
the goal is to concretely improve the experience of users with unusual 
needs or interaction modalities, not just to improve the theoretically 
possible maximum accessibility. In particular, this means that we should 
prefer solutions that most authors will use in a mostly accessible way 
over solutions that a few authors will use in a perfectly accessible way 
but that most authors will use in an inaccessible way.


> Is the WHATWG the proper forum for discussion about WebApps, or is such 
> discussion better left to the W3C WebApps group and associated groups?

The WHATWG list is an appropriate forum for discussing Web platform 
technologies, especially those being specified in WHATWG specs or not 
being specified anywhere at all. (So something like JS or HTTP, while also 
Web platform technologies, are probably more productively discussed in the 
TR39 and HTTP working groups respectively; we probably won't do much to 
change them by discussing it here.)


> These applications have radically different constraints and use cases 
> than the standard and accessible presentation of markup -- of hypertext 
> documents.

"Document" and "Application" are merely two extremes of one continuous 
spectrum, in practice. HTML and the other technologies specified in the 
WHATWG cater to both and everything in between. ("WHAT" stands for "Web 
Hypertext Application Technology", which is a pretty good description of 
the scope of the work here.)


> With the group focused on developing a standard scene-graph, I understand
> completely why text-editing should be left to HTML Next Form elements

Text editing is handled by two HTML elements, a content attribute, and an 
IDL attribute: <input>, <textarea>, contenteditable="", and .designMode 
respectively. Work certainly needs to happen to improve these features and 
APIs, but it is not something that is being left to the future, we're 
specifying it right now and these features are widely implemented.

Using features such as contentEditable, that convey the underlying intent 
of the author (that is, the semantics) is the primary way we achieve an 
accessible design. This is especially true when viewed in the context of 
the aforementioned philosophy of aiming for concrete accessibility gains 
over theoretical ones. We know from experience that authors rarely provide 
dedicated secondary content, with the fraction of authors doing so being 
reduced as more effort is necessary to provide alternative content. For 
example, alt="" has probably the most success as alternative content 
solutions go, while only slightly more complicated features like HTML4's
summary="" have significantly less usage, and features only as complicated 
as longdesc="" see virtually no practical use. Providing an alternative 
for <canvas> text editing is in contrast orders of magnitude more 
complicated. One can therefore assume with some confidence that it would 
not be a good way to achieve practical accessibility in the real world.
 
Several alternatives exist, as noted earlier: contenteditable="", for 
instance, is more or less automatically accessible and thus a 
significantly better choice for this solution space.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Saturday, 27 November 2010 02:50:35 UTC