RE: SVG2Reqs

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
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
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'm being flamboyant here (as is my wont), so please don't take it too
seriously.

Cheers
David

-----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
other people could use my widget transparently with the other HTML controls.
<form> elements would recognize my custom control and send it's inputs just
like other HTML controls when a submit button is pressed, etc.  My SVG
widget would participate in the tabbing order too and gain focus when the
user tabbed to it. Etc.


Andrew 


-----Original Message-----
From: Gavin Kistner [mailto:phrogz@me.com] 
Sent: Thursday, November 10, 2011 9:01 AM
To: Shropshire, Andrew A
Cc: 'Charles Pritchard'; 'www-svg@w3.org'
Subject: Re: SVG2Reqs

On Nov 10, 2011, at 6:00 AM, Shropshire, Andrew A wrote:
> 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 drop down?

Yes, you can do this. (Though I would use an HTML <select> instead of an SVG
'dropdown'.)

> Can I surround a block of HTML XML in a foreignObject  and apply an SVG
scale transform/rotate to it?

Yes. For example: http://phrogz.net/svg/html_location_in_svg_2.svg (See the
#d box that is a rotated and skewed HTML mini-page.)

> Or put a translucent SVG rectangle over a WebGl box to dim it?

Sure.

> Can I draw WebGl over top of SVG?

Yes.

> Can I put an HTML edit box on a wall in my 3D scene?

Depends on what you're using for the 3D scene.
WebGL does not 'embed' other technologies in the same way SVG does, AFAIK.
3D CSS transforms, however, allow you to make a 3D scene with HTML elements.
For example:
http://24ways.org/2010/intro-to-css-3d-transforms


> Will it receive input events?  Can I draw WebGl overtop of HTML or SVG
over HTML? Etc.

Yes, all these technologies hosted in HTML can be z-indexed.

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

One clarification: WebGL *is* Canvas. WebGL is the 3D view of Canvas; with
primitive 3D drawing facilities. The 2D Context is (I suppose) what you are
calling "Canvas", with primitive 2D drawing facilities.

Both of the Canvas technologies provide non-retained drawing modes. Unlike
HTML or SVG, drawing an 'circle' on a 2D canvas does not give you an object
that can be later moved or tracked for pointer events. It's more of a
convenient way to set a lot of pixels values at once.


Andrew, I don't see any sense in your proposal to implement all of HTML as
SVG. As noted in Doug Schepers link (below) on implementing a table in SVG,
"A less obvious flaw is that creating a tabular appearance does not confer
the semantic qualities of a real table, which is disadvantageous to
accessibility and is not conducive to rich interactivity and navigation."

The semantic web is more important now than ever, and not just for
accessibility. Two simple examples: Google uses <dt>/<dd> to find and
summarize definitions, and iOS recognizes phone numbers as text and
hyperlinks them for calling. If you make something in SVG that just *looks*
like a definition list or was the outlines of a phone number, but that
lacked the descriptive markup, you would lose these two particular benefits.

Now, you didn't explicitly suggest dropping the HTML markup. You wrote:
> 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.

I see no advantages to this, and many pragmatic disadvantages.


> 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 20:04:20 UTC