W3C home > Mailing lists > Public > www-svg@w3.org > November 2011

Re: SVG2Reqs

From: Charles Pritchard <chuck@jumis.com>
Date: Thu, 10 Nov 2011 11:46:24 -0800
Message-ID: <4EBC2A10.50508@jumis.com>
To: Gavin Kistner <phrogz@me.com>, "Shropshire, Andrew A" <shropshire@att.com>
CC: "'www-svg@w3.org'" <www-svg@w3.org>
On 11/10/2011 6:01 AM, Gavin Kistner wrote:
> On Nov 10, 2011, at 6:00 AM, Shropshire, Andrew A wrote:
>> 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.)

In addition: the CSS transform spec and CSSMatrix objects have 
reasonably wide support.

>> Can I draw WebGl over top of SVG?
> Yes.

You may draw an SVG <img> [static] into a WebGL texture as well.

>> 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

That's correct. I recommend using additional heuristics (events) on such 
scenes so the
text entry is still practical.

>> 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.

All the magic of a few CSS concepts.

>> 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.

WebGL is a 3d proposal for Canvas. The 2d context remains the only w3c 
spec with full vendor support. That's my understanding, anyway.
Historically: 2d rendering is much more difficult than 3d rendering for 
GPUs. This is changing as software drivers and programmable shaders 
become more advanced.

Historically, 2d rendering is done on a CPU, 3d is done on GPU. They can 
both be implemented atop each other, but it's a lot of work, and 
typically slow.

The Typed Arrays specification is something of a shared "low level"; 
Canvas 2d has CanvasPixelArray; WebGL has a whole host of other 
ArrayBuffer types .
Serializing Typed Arrays into XML seems to be doable with the InkML spec.

SVG is not particularly appropriate for complex scenes: it may require a 
very bloated DOM.

Doug brought up a new "unified" API concept at SVG F2F in Seattle. I am 
certainly interested in pursuing the idea. Is the www-svg list an 
appropriate place to do so?

My understanding of the levels:  Typed Arrays [raw binary data] -> 
InkML+MathML [serialization]  -> Canvas/WebGL/CSS [rasterization] -> 
ARIA [semantics] -> SVG/HTML [UA-extensions/widgets].

> 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."

Doug's implementation of a table in SVG was incomplete and is a little 
dated. ARIA has sufficient semantics to confer the qualities of an HTML 

I've found it difficult to confer the full semantics of a spreadsheet, 
having had to abuse ARIA a bit to express some of the common semantics 
of spreadsheet editing.

> 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.

Good semantics are very important. I've found more compatibility and 
stability through using ARIA in addition to HTML.
ARIA has a larger semantic vocabulary than HTML. It's extensible, 
well-isolated and reasonably well supported.

Big fan of HTML over here, but I consider ARIA to be the low-level 
semantic API. I can create more in ARIA than HTML.

> 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.

Pushing SVG implementers into also-implementing HTML is a bit too much, 
in my opinion. SVG itself is a huge spec, and is, in my experience, more 
difficult to implement than HTML.
As for forms: I would like to see <input> as an accepted tag, but 
without any visual rendering; I'm only requesting the DOM and keyboard 
and pointer events to be exposed.

CSS is borrowing a lot of good lessons from SVG. They're being inherited 
by HTML through it's close relationship to CSS implementation.
CSS transforms are just the start of it. SVG Filters are being included. 
SVG paths are being included. I'd imagine that paint servers will be 
The concept of <use> is being included.

Consider ARIA+CSS -> HTML.

There's more to it: HTML defines the standard DOM interfaces for 
handling events and setters on various tags,
ARIA is far more basic, including only setAttribute/getAttribute.

This response has been a bit lengthy.... In closing: Web Components will 
make it easy to package SVG+HTML controls and use them in a simple manner.
The actual packaging of controls is necessarily complex. Authors (I've 
consistently made this mistake) forget to add the strong semantics 
needed for good, accessible UI controls.

Received on Thursday, 10 November 2011 19:46:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:33 UTC