- From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
- Date: Sat, 1 Dec 2007 14:54:39 +0100
- To: public-html@w3.org
Maciej Stachowiak wrote in 'Re: SURVEY: Accept requirement for immediate mode graphics a la canvas element?' > > 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 Well what currently works for HTML 4 or XHTML is maybe no argument against a better structure of elements names in a new version like HTML 5. Currently it seems that even the discussion did not finish to publish the current draft as an official working draft or not to get more audience to discuss this. This looks like a starting point for implementation, not the end point - and it should be not much work either to move the functionality from the current canvas to another element or to add more functionality to the canvas element to establish this for example as a generic element for any graphical content, either referenced from an external document, embedded directly or generated dynamically with a specific graphical script language developed for this purpose. There were opinions about avoiding too much 'domain specific' element names too and therefore this could be a good chance to clean up and reduce elements with very similar functionality to one or two elements, alternatively it could be another approach too to complete the set of 'domain specific' element names for more semantical relevance. Currently there is the following set of elements to embed somehow 'alien' content into HTML 5 (sorry if I forgot some): style script object embed (more a command as a propper element name?) iframe img video (+source) audio (+source) canvas From the point of semantical completeness the list should be completed, for example with 'text', 'animation', maybe some more. Several of them will have almost the same functionality (as in SMIL for example), but the author can choose a name fitting well to the intended purpose. A general problem in 10 or 20 years might be, that there are formats too for other senses as vision and hearing, maybe smelling, feeling, degustation and this list has to be updated anyway to cover the specific requirements of such formats (offtopic: video - I see; audio - I hear, currently video includes optionally audio too, maybe audio should not exclude video? And both should not exclude other senses to avoid such future problems and to improve the accessibility potential for multimedia applications?) From the point of redundance, the list could be reduced to the essentials too, for example having only 'style' (including script and maybe canvas) and 'object' (the others and maybe canvas) and forgetting everything else, because the functionality can be covered with this two elements completely. This is easier to explain to authors, what the difference between the elements is and what the basic purpose or functionality. Having an arbitrary selection is not explainable at all and authors have no chance to understand why they have a choice between different names for the same functionality in one domain and no element with a specific name for another domain at all. This is similar to the problem for list elements - there are a lot of different element names for the same functionality, but the list is incomplete to cover several other interesting functionalities. There are some more inconsistencies, as having or defining elements specific for the domain 'prose' in HTML5 but none for 'poetry' as already discussed and added to the wiki. With a closer look maybe there will be some more of those unbalanced domain specific selections. Such inconsistencies in the design of the language HTML5 need to be solved, else readers of the draft will have the impression, that it is jammed together to a funny collection of may useful existing tools or just the draft authors subjective choice, what is available or not. Well, maybe the impression is correct or intended, but then maybe the name of the game should be changed (maybe HFC1, HyperFunCollection 1, just joking ;o) or related to the prose problem HPML1 - HyperProseMarkupLanguage 1, no joke at all after a closer look into the current draft.
Received on Saturday, 1 December 2007 14:04:46 UTC