Input Elements, was: Re: SVG2Reqs

On SVG2Requirements:

SVG2 will include the Canvas 2d context -- a tag which relies on 
scripting and a tag which supports <input> elements.
<input> should be introduced with it.

Do not specify visual rendering of input fields in SVG2. Authors can 
still use foreignObject if they want the UA to render.
Do reference FormData, ARIA, DOM4 and Web Events for the benefit of the 
scripting environment.

Those components are enough for me to build semantically strong, 
accessible controls with a minimum of dependencies.
Authors will continue to develop their own input controls, especially as 
they explore the development of SVG and Canvas rich internet applications.
With sufficient semantics, scripted widgets may achieve the same 
expressive quality as widgets hard-coded into the user agent.

As an aside, on Canvas and form processing:

For heavy binary processing: postMessage, Web Workers, WebSockets, 
XmlHttpRequest 2.0 and ArrayBuffer comprise a strong system
for effective inter-process and internet communication. They're 
available in many ECMAScript environments.


More in thread..

On 11/10/2011 12:03 PM, David Dailey wrote:
> There once was an "xforms" working group. I'm not entirely sure, but my
> thought was that they would provide a set of wonderful control and input
> widgets that would work everywhere -- MathML, HTML, SVG etc.: color pickers,
> zoom and pan interface, keystroke management, textareas, menubars, etc.  It

Most of these widgets are included in HTML5, many are not implemented by 
vendors.

HTML5 goes too far in extending <input> vocabulary; type is losing its 
meaning.
With HTML4, you know that the <input type> vocabulary is going to be 
supported by the UA. That's not true with HTML5 programming.

HTML5 does reference MathML and SVG in their entirety, delegating authority.


> seems that in the days that the WHATWG resented the W3C, the work of the
> XFORMS group was systematically ignored, with a dose of flair and derision,
> at least that's how it seemed to an outsider. On the other hand, I saw in
> recent discussion that the HTML charter
> http://www.w3.org/2007/03/HTML-WG-charter#dependencies shows dependencies on
> Forms but not even a casual acquaintance with SVG. I don't know if the

I suspect parts of XFORMS were integrated into HTML5 forms and other 
sections were intended to be solved within XBL 2.0. This is now being 
discussed within the Component model.



> roadblocks are conspiratorial, or silly or that the problems are just too
> darn deep for humans to be able to solve. In the meantime we have every app
> developer rolling her own, leaving the visitors to our sites a bit confused
> on just how a given site is to be operated.

I've gone to the mat with a few vendors about rolling my own input 
controls in <canvas>.
There is less push-back for implementing controls in <svg>.

UA controls and script-presented controls are not mutually exclusive.

I don't think it's a bad thing that authors are able to roll their own 
controls.
People can't be web app authors and only be granted the tools of word 
processing.

When vendor developers discourage authors from programming, the spec 
process takes longer, authors lack needed vocabulary and users suffer a 
lack of accessibility and performance.

More follows Andrew's post:

> -----Original Message-----
> From: Shropshire, Andrew A [mailto:shropshire@att.com]
> Sent: Thursday, November 10, 2011 1:36 PM
> To: 'Gavin Kistner'
> Cc: 'Charles Pritchard'; 'www-svg@w3.org'
> Subject: RE: SVG2Reqs
>
> WEB-ARIA can give semantic meaning for custom controls.  Existing widgets in
> HTML would retain their semantic meaning.
>
> Combining SVG and HTML into one would make a much larger and more complex
> spec.  However, you could keep them separate, but bring them closer
> together.  They both use javascript, css, and a DOM already.  It would be
> nice to be able to create a new Widget in SVG and say have a custom tag for
> it in HTML so that I could use it just like HTMLs existing widgets.  Then
>

WebApps WG and The WHATWG are working on custom tags / the Component Model.
WebKit has an experimental shadow dom, Mozilla has anonymous box selectors.
It's a difficult problem, XBL, XBL 2.0 and XFORMS moved things forward.
Progress is being made in the area of widget re-use.

I do think we can find a minimum of WebApps APIs needed to implement 
custom controls.
I've done a lot of work in this area, I've implemented several custom 
controls using a minimum
of HTML+CSS+DOM+WebApps APIs outside of the web browser and atop several 
graphics libraries.

It can be done!

-Charles

Received on Friday, 11 November 2011 21:20:31 UTC