[whatwg] Attitude and Direction of the WHATWG
Ian Hickson
ian at hixie.ch
Sat Nov 27 02:50:35 PST 2010
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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg
mailing list