- From: Maciej Stachowiak <mjs@apple.com>
- Date: Fri, 30 Nov 2007 12:45:58 -0800
- To: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
- Cc: public-html@w3.org
On Nov 30, 2007, at 7:02 AM, Dr. Olaf Hoffmann wrote: > > Anne van Kesteren wrote: > >> On Fri, 30 Nov 2007 15:15:11 +0100, James Graham <jg307@cam.ac.uk> >> wrote: >>> Richard Schwerdtfeger wrote: >>>> One alternative does not fit all even though a fallback may be an >>>> improvement for some. >>>> I am concerned that we would advocate using canvas over SVG >>>> where we >>>> would have an opportunity to apply semantics to the base drawing, >>> >>> I don't think we would advocate <canvas> where a more appropriate >>> technology exists, only where it makes sense. > >> This is in fact what the _second_ paragraph of the <canvas> section >> says: >> "Authors SHOULD NOT use the canvas element in a document when a more >> suitable element is available." > > I think, this part of the working draft would be more convincing, if > there was > an element like animation (as in SMIL, SVG Tiny 1.2 or vector or > however one > might call it) to reference vector graphics too (optionally with > server-sided > generation to avoid user-sided scripting) - either as an external file > similar to audio or video or to embed it in a mixed document XHTML+SVG > as a clear separation... There are already multiple appropriate ways to embed SVG in HTML or XHTML: 1) For an SVG document that is an image or animated image, without interaction, embedding in <img> is suitable (this is supported in experimental builds of Opera and Safari). 2) For an SVG document that is a purely presentational decuration, referencing as a CSS background image is suitable (this is supported in experimental builds of Opera and Safari). 3) For an SVG document that supports rich interaction (and has more application-like properties) or that requires scripting interaction between the containing HTML document and the SVG, either <object> or <iframe> is suitable. This works today in the latest shipping versions of Safari, Opera and Firefox. <object> even works in IE with a suitable plugin installed. 4) In XHTML, the <svg> element in the SVG namespace is a suitable way to embed any kind of inline SVG dicrectly in the same document. Many are working on a design to let this work in HTML as well. 5) In both Classic and XML serializations of HTML, SVG content can be dynamically generated by script and inserted into the DOM at runtime, with an svg:svg element as root. This is perhaps closest to the way <canvas> operates. This is supported by Safari, Opera and Firefox and is used by popular JavaScript libraries, such as the Dojo charting toolkit. So, I think most of the needed technological capabilities are there, and some new ones are under development. I'm not sure that adding yet another way to embed SVG which does not yet work in any browser and doesn't provide any new capabilities over the current options is necessary or helpful. > Alternatively the 'functionality' of canvas could be integrated into > the img > element - seems to be a raster image format too, therefore this fits > somehow > together and does not require yet another element for the same type of > graphics. Else, without scripting support or without activated > scripting, > canvas seems to be empty or presumably decorative or can be replaced > with other arbitrary elements like div maybe or span. This has been considered. However, the fallback behavior of a new element that can contain content (like <canvas>) is better than the fallback for a new API on an existing element that has rich markup fallback. Also, <canvas> is already widely implemented and deployed, so the new approach would have to be much better to work effectively. Regards, Maciej
Received on Friday, 30 November 2007 20:53:12 UTC