Integration

Hi :)

Part 1 - Introduction - A practical example:

Many of the web designers I train want to make "Flash" sites.  The
reality is that there are many sites out there who insist on providing
this type of content.  I have been strongly encouraging these web
designers to evaluate standard and accessible technologies such as SVG
and SMIL.  I have been promoting the idea that there is not a lot of
things you can do with proprietary technology like Flash or Internet
Explorer extensions that can't be done just as well through W3C
recommendations.  But in my experience demonstrating this, there is one
area that has traditionally fallen short, and still does.  Sound.

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.

In theory I totally agree with the W3C party line that HTML is not a
multimedia oriented language, and sound is outside it's scope.  There
has also been much debate, which I don't want to get into here (sound is
just an example of a larger problem), regarding the attitude that
'proper' web pages should not even play sounds automatically, as it is
intrusive.  The fact is that there are many cases in the Real World
where sound is very appropriate, whether it be auditory feedback for an
intranet application, or a page on MTV.com.  I agree that SMIL is the
appropriate technology for this task.  There are several SMIL players
out there, one of the more prominently deployed currently being RealONE.

Part 2 - The Actual Problem - Integration

It's not just sound though.  The problem above is one of many.  The crux
of most problems I now encounter in doing web design is integration. 
The W3C has all of these working groups, each with a clearly defined
scope.  These groups all do a fine job creating technology within their
scope.  The problem is that none of these technologies exist in a
vacuum.  There are many practical problems every related working group
will tell you are outside their scope (and it's true).

Going back to my practical example above, have you ever tried to include
SMIL content in a web page?  If you want it to validate or work, you
have to tie that page (CLSID) to a particular implementation (on a
particular platform).

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)

Not all of these gaps are even new SVG, SMIL, or CSS3 type issues. 
Working groups have, within the last year or two, at least started to
increase their scope to include things like MIME types as part of the
specification, along with Namespaces and such.  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.  Yes, that is correct, there is, as far as I know, no
document or standard which defines a mime type for Javascript.  The
defacto mime type in use today (text/javascript), which works
everywhere, is, from a purist perspective, arguably incorrect - it
should probably be application/javascript - which, incidentally, doesn't
really work anywhere.  There is java script on a LOT of web pages out
there, yet no standard formally defines this application.  These gaps
are what I am talking about.

[Incidentally, some time ago I asked Waldemar Horwat from Netscape, who
is on the TC39 group which defines ECMA script, about the above issue. 
He said he would ask at next meeting if they wanted to do something
about it, but I never heard back from him]

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".

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!

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.

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?

-- 
Chris Hubick
mailto:chris@hubick.com
http://www.hubick.com/

Received on Monday, 8 July 2002 19:09:06 UTC