Anne van Kesteren

SMIL a mess?

I have not actually read the entire SMIL 2.1 Recommendation, but I do want to make a statement about it based on what I have read and seen. Basically to be able to say: Hey, you are right, but I knew that in 2005. All people interested in accessibility can now slap themselves for not having raised serious concerns regarding the accesskey attribute. I hear you scream, John Foliot. My interests lie however in interoperability. There are 70 new testcases for six new modules. These are not small modules. For example, The SMIL 2.1 Transition Effects Module is fourty pages in print. And that is just one of the modules which introduces new attributes which might or might not interact with existing attributes and other elements. Let alone testing error handling, et cetera. To compare, :first-letter is about two pages in print. So far I created 22 testcases for :first-letter and most show different issues depending on the browser you use. (They have been submitted.)

Other funny things from SMIL are that background-color is apparently deprecated in favor of backgroundColor, but z-index remains the same. The worst part is actually that mobile profiles have a different namespace. O. My. God. The SMIL 2.1 Extended Mobile Profile defines for example the http://www.w3.org/2005/SMIL21/ExtendedMobile namespace. The informative section in Identifiers for SMIL 2.1 Profiles and Features defines the six different namespaces elements can be in. Either I am missing something or this whole recommendation violates Architecture of the World Wide Web, Volume One in various ways. Bah.

By the time desktop browsers will start with implementing SMIL I guess the whole SVG debacle will start over again. (Which has not ended.) On a positive note, I heard from Chris Lilley that application/smil will be obsoleted and application/smil+xml will be used. SMIL 2.1 already states just that.

Comments

  1. You're behind the times Anne... I already wrote about the accesskey stuff, and you've taken many times longer to catch up. :P I'm surprised really. I thought your youthful enthusiasm and raw intellect would be more than a match for my sloth and age-related-decrepitude :)

    Whether a document is 4 paragraphs or 40 pages is a poor guide to what it actually introduces or requires. It is possible that the transition effects are so clearly written that there will be dozens of interoperable implementations while the :first-letter specification is so bad that no three people in any random selection of 1000 experts understands the same thing. (Or not, of course).

    Just be glad you didn't have to try and read the last call, which was published as a collection of notes about things that were different to the SMIL 2.0 spec, itself a monster of hundreds of pages.

    You may be missing something. The profiles identified by namespaces to which you refer are not necessarily mutually exclusive - they are "convenience" functions. Surely you understand how "convenient" it is to make a pile of extra code that recognises a monstrous collection of namespaces in varius contexts... Actually, I think it specifies (in painful detail which I have only skimmed through, but am inclined to more or less believe) how to do this so that authors only have to make minimal changes to their existing processes to do various new things. Or something like that.

    PS I keep wondering: If you insist on validating input as XHTML, why don't you name the relevant elements in lower case?

    Posted by chaals at

  2. The problem is that they put elements in multiple namespaces. The root element smil for example can be in the http://www.w3.org/2005/SMIL21/ExtendedMobile namespace, but it can also be in the http://www.w3.org/2005/SMIL21/Language namespace per Conforming SMIL 2.1 Documents. Section 15.3.2 explicitly points out that those elements are supposed to be in a different namespace so it was not some huge typo in the specification.

    Now Architecture of the World Wide Web, Volume One says about elements in a different namespace that they are different. Actually, this is simply how namespaces work.

    It must be said that SMIL is not alone in this mess. XForms 1.1 tries to do it, XHTML 2.0 does it by taking elements from XForms 1.1 and XHTML 1.0 and putting these in its own namespace et cetera. SMIL is the one however who manages to do it in a single specification and the first who passes all stadia right to recommendation. That should show something is clearly wrong in my opinion. And not just that people like me have not enough time to review every single specification in time ;-)

    Posted by Anne at