[whatwg] Attitude and Direction of the WHATWG
Charles Pritchard
chuck at jumis.com
Fri Nov 26 11:53:06 PST 2010
All,
You may have seen me posting to the list, posting defects related to the
accessibility of the Canvas element. If you've followed those threads,
you've seen others on the list rebuke my use cases, as inappropriate
uses of existing APIs. This has happened twice, recently. In both cases,
I've brought to light simple defects in the current WHATWG specs, and
proposed that attributes be exposed to the scripting environment, to
address the defects. My first proposal was that 'baseline' be added to
measureText. My second proposal was that the CSS pixel ratio be exposed
to the scripting environment, through window and/or window.screen.
In response to this, I've been told: one, Canvas should not be used for
rich text editing and two, Canvas bitmap resolution should not be
managed by the author.
These responses are grounded in a reasonable philosophy, and my purpose,
in this thread, is to bring that philosophy to discussion, so it might
be explicitly stated, and I might better understand the scope of this
mailing list.
Canvas is a low level API. There are very few of them in the WebApps /
HTML specs. I'd say that Typed Arrays [ArrayBuffer] is another low-level
API. They're certainly revolutionary, in what they offer programmers, in
terms of control and expressiveness. These APIs allow WebApp authors the
same flexibility and control as classical desktop application developers.
Many on this list have commented that low level management will lead to
poor use and misunderstanding by unknowing developers: essentially, that
we should not give developers another tool to shoot themselves in the
foot. I've spent some time discussing the merits of that particular
concern. Though I have stood my ground, I've not convinced others on
this list that my use cases are valid.
I want to suggestion a reason for this impasse: the WHATWG intends to
produce a scene-graph specification. Other activities are out of scope.
At some point, and this does reoccur, there was a separate WebApps spec.
This was merged into the hypertext spec, leading to the current work
product. There were good reasons: many WebApps APIs are named and based
upon corresponding hypertext attributes. Scripting is as ubiquitous as
scene rendering implementations. Merging these two specs meant a
broadening of scope, in the single work-product.
Fantastic work is being done in relation to CSS, DOM and HTML elements.
I couldn't be more pleased. That said, the editor of the WHATWG and some
implementers are of the mind that they are working on a hypertext
standard (seems fair, considering the group name), one that will be
implemented, universally, by browser vendors. That's great, but it
neglects the history of the WebApps specifications and use cases.
Is the WHATWG the proper forum for discussion about WebApps, or is such
discussion better left to the W3C WebApps group and associated groups?
These applications have radically different constraints and use cases
than the standard and accessible presentation of markup -- of hypertext
documents.
With the group focused on developing a standard scene-graph, I
understand completely why text-editing should be left to HTML Next Form
elements, and I understand why bitmap resolutions should be declared
within the CSS/HTML scene graph. If the group also intends to support
WebApps, which do not operate exclusively under a scene-graph, and are
instead operating under a WebIDL-based scripting environment, then these
scope restrictions are wholly inappropriate.
There is a lot of room for growth in WebApps. They straddle the browser
extension / scripting environment sandbox divide. Some implementers may
see that divide as something separate from the WHATWG. Let me know your
opinion on the matter. I think it'd be reasonable to limit the scope of
WHATWG, and develop WebApps under a separate list and group. At the same
time, I would prefer, and hope, that WebApps can be discussed within the
WHATWG.
Thank you all, for engaging in discussion, here, in the open.
-Charles
More information about the whatwg
mailing list