- From: Dominique Hazaël-Massieux <dom@w3.org>
- Date: 09 Jul 2002 14:11:01 +0200
- To: Chris Hubick <chris@hubick.com>
- Cc: W3C Evangelist <public-evangelist@w3.org>
Le mar 09/07/2002 à 01:10, Chris Hubick a écrit : > Part 1 - Introduction - A practical example: > > Have you ever tried to include a looped sound clip on a standards > compliant web page? It boils down to this, you can have the page > validate, OR you can have it work. Having such a sound would really be in the scope of CSS and not HTML. I think it has been suggested to the CSS WG several times and they might get to the point of producing a specification for this (note that with CSS, you gain in much flexibility on when and how to play a sound, and you make it easier for the end user to disable this "feature" :) > Part 2 - The Actual Problem - Integration > If I write the general cross implementation/platform: > > <object type="application/smil" data="loopedsound.smil" /> > > How many browsers on computers with current SMIL players will display > that properly? (answer: not many, if any) Probably not many, indeed. But I don't think that's on the specification side that the problem is, is it? Note that since you're using XHTML in your example, there has been an XHTML+SMIL profile [1] developed to allow to include your SMIL markup in the XHTML document itself: > But for example, you > still have an HTML specification from the W3C which uses a whole chapter > to define a 'script' element, and you have ECMA with their ECMA-262 > Script (aka Javascript) which has a working group to define a popular > content for said script element, yet they don't define a mime type for > said script. Well, it's obviously not the role of W3C to register a MIME Type for an outside specification. I think that the lack of MIME Type for javascript has been raised several times, but indeed, I don't know if there has been much real action for this. Note that the Technical Architecture Group provides now some guidance so that W3C registers MIME Types along the design of its specifications. [2] > There are many problems like this. > > Threading! What if I have a script on some web page manipulating the > DOM of that page... yet have an event handler in an SVG applet try to do > the same? Multiple threads in a Java applet calling into the web page > DOM? "Threading is outside the scope of this specification". When designing standards [3], you *have* to limit the scope of your work if you want to reach a stable state at some point. I think that the current standards are already much underused, so creeping them with more details and side cases features wouldn't really help... That's only my opinion, of course :) > Part 3 - Denouement > > It's the gaps between the specifications. The "devil is in the details" > complexities of the interactions between the specifications. It's the > problems nobody thinks belong to them. These are problems where > implementors are just forced to choose something they think is logical, > and that is how we end up with five varying implementations. > > There /should/ be an integration working group! Note that W3C has many so called coordination groups whose role is to ensure that related working groups work together in the same direction, with interoperability in mind, etc. Besides, the way a specification goes through its life per the W3C Process means that its gets a lot of review from a wide range of working groups (especially when it reaches its 'last call' stage). Note that at a different level, the Technical Architecture Group (TAG), the Web Accessibility Initiative, the Internationalization activity and the Quality Assurance Activity [4] ensure transversal reviews of the specifications. > I'm sure every web designer out there, and on this list, could name at > least a few areas where they have run into undefined behavior such as > this. Indeed... But I'm not sure that's what really stopping the standards. Most proprietary technologies have much more integrations issues, undefined behavior, etc. than the open standard ones. > At the very least, we need some evangelism effort to get problems like > this solved. Somewhere people can bring questions like this and find > answers, or help getting someone to take action. That is why I am here. > > Can this group help get things like > <object type="application/smil" data="loopedsound.smil" /> > to work? Hmm... Honestly, I think the goals of this forum is more oriented toward education of content producers than to discuss technical decisions made during the design of the standards. But maybe I misunderstood? Dom 1. http://www.w3.org/TR/XHTMLplusSMIL/ 2. http://www.w3.org/2001/tag/ilist#w3cMediaType-1 3. http://www.w3.org/People/Bos/DesignGuide/ 4. http://www.w3.org/2001/tag/ http://www.w3.org/WAI/ http://www.w3.org/International/ http://www.w3.org/QA/ -- Dominique Hazaël-Massieux - http://www.w3.org/People/Dom/ W3C/INRIA mailto:dom@w3.org
Received on Tuesday, 9 July 2002 08:14:09 UTC