RE: SVG2Reqs

Thanks for the links.  So we are in agreement that SVG, other than key
events, has most of what is needed to create a typical user interface.  The
SVG 1.1 spec specifically left out keyboard events 

 

See section 16.2:

"As in DOM 2 Key events
<http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/events.html#Event
s-eventgroupings-keyevents>  ([DOM2EVENTS
<http://www.w3.org/TR/SVG/refs.html#ref-DOM2EVENTS> ], section 1.6.3), the
SVG specification does not provide a key event set. An event set designed
for use with keyboard input devices will be included in a later version of
the DOM and SVG specifications."

 

which would mean the input control from carto.net is non-standard.

 

I have built input controls using the HTML key events.  So I am confident it
can be done once key events are available in SVG.

 

I see a lot of rendering technologies: WebGl, canvas, SVG, HTML, MathMl for
which the interaction, or how they fit together is not clear.  I understand
that rectangular regions of the screen can be carved out and rendered to
with one of these.  The <foreignObject> tag allows for a rectangular region
in SVG to be drawn with a different technology (ie HTML).  Likewise, the
<object> or <embed> tag in HTML allows for SVG to be drawn in HTML in a
rectangular region.  But what about overlap?  What if I want a dropdown in
SVG to draw on top of the webGL box below it when the user opens the
dropdown?  Can I surround a block of HTML XML in a foreignObject  and apply
an SVG scale transform/rotate to it?  Or put a translucent SVG rectangle
over a WebGl box to dim it?  Can I draw WebGl over top of SVG?  Can I put an
HTML edit box on a wall in my 3D scene?  Will it receive input events?  Can
I draw WebGl overtop of HTML or SVG over HTML? Etc.

 

It would seem that WebGl is at the lowest level, followed by Canvas, then
SVG, then at the highest level, HTML/MathMl).

 

WebGl -> Canvas -> SVG -> HTML/MathMl

 

Was looking for a more uniform rendering pipeline where it is clear how
these specialized rendering technologies (each addressing a special niche)
can work together clearly.  Can I write MathMl around the spiral like it the
example you gave and control the stroke properties and perhaps stick in on a
cube drawn in WebGl and have it illuminated with a green spotlight? Probably
not in a standard way.

 

 

Andrew 

 

From: Charles Pritchard [mailto:chuck@jumis.com] 
Sent: Tuesday, November 08, 2011 6:49 PM
To: Shropshire, Andrew A
Cc: 'www-svg@w3.org'
Subject: 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 Thursday, 10 November 2011 13:01:14 UTC