[whatwg] Attitude and Direction of the WHATWG

[Charles Pritchard]

On 11/27/2010 2:50 AM, Ian Hickson wrote:
> 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.
> 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.

The HTML language has become even more semantic, less presentational, as 
CSS+SVG profiles are enhanced.

These three sections of the HTML5 specs seem out of scope:
"Loading Webpages", "Web application APIs" and "Communication"

I think something along those lines was brought up by Microsoft in 
relation to the Canvas 2D Context.
> 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.
There is a more complex philosophy relating to accessibility on this group.
Security and privacy are paramount goals, and overshadow accessibility uses.

The proper delegation of OS and UA responsibility is a strong consideration.

At this point, those considerations are not being discussed between 
vendors on the WHATWG, and we have three separate chrome (UA extension) 
namespaces.

>> 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.)
Recently, I brought to attention that there are multiple APIs 
responsible for returning CSS pixel metrics.

Outside of ARIA, this is not being discussed. The finer details of Web 
Widgets are not being discussed.
http://www.w3.org/2008/webapps/track/

Many of these are present in the HTML5 specs, though as I've stated, 
they seem out-of-scope for the HTML5 document itself.


>> 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.)
On the Application extreme, HTML may not even be involved.
HTML is at one extreme, with a very narrow scope, and Applications 
involve just about anything, a very broad scope.

An application may be driven purely by Canvas, purely by SVG, it may be 
XML+CSS. It may not have a UI at all, and run as a background 
application or service app.

As the WHATWG is centric to two software code bases, it's hyperbole to 
say "everything in between.".

My work with InkML and Canvas has had no place here in the whatwg. Web 
Widgets, apart from applicationCache, are not
defined by the WHATWG: when an issue comes up which may need to be put 
in a Widget namespace, for security/privacy reasons,
the item is stopped cold on this mailing list. Doesn't this mean that 
such discussion is out of scope?


>> 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.
I'd like to see work done on these elements. I haven't yet seen that. 
contenteditable looks the same as it did before, with most behaviors 
being the responsibility of the UA.
DOM Ranges don't seem to be mentioned.

I'd like to improve those features, but there is a strong consensus that 
contenteditable/textarea are entirely the realm of the system IME.

Should that be the case: what is there to improve, in the specs document?
> 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.
Unfortunately, contenteditable is less accessible to users than it 
should be. I'd like to see that addressed.

If these input methods are intended to be UA-driven, and the scripting 
environment is to be locked out, then this is simply a matter of filing 
bug reports with Webkit/Mozilla.

CKEditor has done a lot of work accessibility, and I think demonstrates 
a reasonable use case for continuing work on contenteditable.
http://ckeditor.com/

Still, it is a very complex application, and as has been mentioned on 
this list before: it's not likely that other web authors will use APIs 
as effectively.