Re: SVG2Reqs

Here are some other links on implementing other HTML similar controls:

Table:
http://schepers.cc/svg/accessibility/table.svg

Input text:
http://www.carto.net/papers/svg/gui/textbox/index.svg
http://jan.kollhof.net/projects/svg/examples/gui/textbox.svg

and then the general idea of just using contenteditable:
http://xn--dahlstrm-t4a.net/svg/presentations/svgdemos/spiral-editfield.svg

I'm not averse to seeing HTMLFormElement and HTMLInputElement added to 
the SVG DOM. Consider them having no-visual rendering: HTML form 
elements are not very flexible in their current rendering style.

<input type="text"> is not going to work with the spiral-editfield 
example. Not rendered by the UA.

It can easily be rendered with help from the author. The input field 
would be non-visible, and JS handles the work of mutating tspan fields.

<canvas> is being introduced into SVG2, I believe. This use of <input> 
works with Canvas:
For example: <canvas><input/></canvas>
Canvas tags are going to be restricted to the <defs> (I believe) and the 
same could be done for <input>.

Consider: <input> as a better method than 
<foreignObject><html...><body><input style="visibility: hidden;" 
/></body></html></foreignObject>

All of the events (focus, keyboard, pointer) and the DOM interfaces are 
maintained. The only thing missing is the rendering.

If a UA or an AT has an alternate rendering/editing mode, it can simply 
use that at the user's discretion. The default mode is to have the 
author handle rendering.

-Charles


On 11/8/2011 5:31 AM, Shropshire, Andrew A wrote:
>
> Would like to add that the edit box is the only non-SVG item.  It is 
> done with a foreignObject tag and uses the HTML edit box.  So it is a 
> bit of cheating, however, it could have been implemented in SVG if 
> browsers supported keyboard input events to SVG.  The edit control 
> also needs cut and paste to/from clipboard but I don't see those as 
> show stoppers.  IE9 doesn't support foreignObject, so on that browser, 
> a javascript prompt is used.
>
> Andrew
>
> *From:*Shropshire, Andrew A
> *Sent:* Tuesday, November 08, 2011 8:00 AM
> *To:* 'www-svg@w3.org'
> *Subject:* SVG2Reqs
>
> As demonstrated here: http://wafo.cpol.army.mil/issue/employment.svg, 
> most common window controls, including scrollbars, dropdown boxes, 
> list boxes, check boxes, tables, etc have been implemented 
> successfully in SVG.
>
> My suggestion is that all HTML controls in the HTML standard be 
> implemented in SVG as well as all visual effects in HTML.  HTML 
> rendering would be applied SVG.  In this way you simplify the 
> rendering in browers by replacing 2 incompatible rendering approaches 
> with one approach.
>
> One would then achieve the bandwidth economy of HTML whereby a table 
> can be specified in a few lines (vs the 50Kb in SVG) when a customized 
> table is not needed, yet still retain the precision of layout and low 
> level control afforded by SVG if cookie-cutter HTML controls are 
> insufficient.  Conceptually, HTML would be a set of common algorithms 
> and controls built in SVG that would be already on the browser (they 
> need not be downloaded each time) -- ie HTML would be an SVG standard 
> library.
>
> In a similar vein, would like to simplify the incompatible 
> architectures posed by WebGl and Canvas and create a unified 
> SVG-WebGl-Canvas-HTML conceptual model, however,  this may be far 
> off.  However, HTML seems more and more like simply a derivative of 
> SVG (and can be thought of as applied SVG because it would appear one 
> can do everything in HTML as pure SVG).
>
> Andrew
>

Received on Tuesday, 8 November 2011 23:49:43 UTC