- From: Charles Pritchard <chuck@jumis.com>
- Date: Thu, 07 Jul 2011 10:29:57 -0700
- To: Doug Schepers <schepers@w3.org>
- CC: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>, Richard Schwerdtfeger <schwer@us.ibm.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, "public-canvas-api@w3.org" <public-canvas-api@w3.org>
On 7/7/2011 10:18 AM, Doug Schepers wrote: > > Correct. The <canvas> element is part of HTML5, but it does not > mandate which APIs must (or can) be used with it. Neither the Canvas > 2D API nor SVG, are technically part of the HTML spec, but both can be > used with HTML in a manner defined by the HTML5 spec; we can (and plan > to) equally define how the Canvas 2D API can be used with SVG as well > as with the HTML <canvas> element. > > Rich, the Canvas 2D API is not part of HTML. Only the <canvas> > element is, and there are separate APIs that can write to it, > including (but not necessarily limited to) the Canvas 2D API and the > WebGL API. > One of the issues I've come up against with SVG is the depth of integration. Where canvas has a shadow dom which works with HTML, SVG has foreignObject, which only sort-of-works. There are a lot of extra tags necessary with SVG to get things to interoperate, and foreignObject is still a bit of a touchy area. SVG is somewhat more of an adjacency-driven format than is HTML, so ARIA semantics have been a little weird, when trying to reference HTML form elements in foreignObject from path objects in SVG.
Received on Thursday, 7 July 2011 17:30:30 UTC