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.
