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 14:03:37 UTC