[whatwg] Attitude and Direction of the WHATWG

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

Received on Friday, 26 November 2010 11:53:06 UTC