- From: Maciej Stachowiak <mjs@apple.com>
- Date: Sat, 1 Dec 2007 06:48:25 -0800
- To: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
- Cc: public-html@w3.org
On Dec 1, 2007, at 5:54 AM, Dr. Olaf Hoffmann wrote: > 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. Our Design Principles require compatibiity with existing content, so we can't remove existing functionality. At best we could add additional ways of doing the same thing. > 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. It's easy to say something "should be not much work" for someone else (such as the multiple vendors who have already implemented and shipped <canvas>). I don't see a strong benefit to renaming the <canvas> element. Adding functionality is reasonable if the functionality is of practical use. Inventing a new scripting language is, of course, a huge amount of specification and implementation work, and the practical benefit is not clear. Is that really intended as a serious suggestion? > 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, Elements that are overloaded with a lot of different functionality in different cases tend to end up with buggy and non-interoperable implementations. To understand why, see <http://en.wikipedia.org/wiki/Cyclomatic_complexity > and consider that past a certain point of complexity (as measured by independent linear paths through the code) a software component is effectively untestable. > 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): I'd prefer if we stick to elements that only have a valid use case, and not ones based on hypothetical needs. > style > script > > object > embed (more a command as a propper element name?) > iframe > img > video (+source) > audio (+source) > canvas These seem useful and needed. > From the point of semantical completeness the list should be > completed, for example with 'text', 'animation', maybe some > more. I don't think 'text' is needed since text is not by any means foreign to HTML. With 'animation' it's less clear; what exactly is an "animation" and how does it differ from an animated image ('img'), a video ('video'), or arbitrary possibly-interactive content ('object' or 'iframe')? SVG draws the line between 'image' and 'animation' at bitmap formats vs. vector formats. But that's not a semantic distinction, nor does it match the names of the respective elements. It appears to leave no place for a PDF (static vector image) or an animated GIF (animated bitmap image). HTML doesn't try to draw distinctions between image formats. (Arguably animated image formats could also be held in a 'video' element which would then provide time control through the API). > 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 'object' is the generic embedding element for content types that are not handled in a more specific way. I don't think you are seriously suggesting that there should be a 'smell' element. I'm not sure any of your remaining suggestions could be seriously intended, so I'll stop here. - Maciej > (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:48:43 UTC