Re: Audio (Re: CSS2.1 'content', 404 Not Found, and audio files)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

csant writes:

> The :before example is actually available for all media types,
> the 'cue-before' example, on the other hand, can only apply to
> 'aural' (or 'speech'). Synchronizing sounds with the visual
> display is not matter of CSS, and yet it becomes an issue when
> you deal with audio files: how is a UA to treat more than one
> audio file per document?
> 
> h1:before { content: opening_fanfare1.wav; }
> h1:after { content: closing_fanfare1.wav; }
> h2:before { content: opening_fanfare2.wav; }
> 

The meaning for this isn't clear for visual media, and would best
be reserved for the state when the document is loaded rather than 
the ad hoc binding to when the element's presentation is visible.
My recommendation would be to introduce a new pseudo class called 
:visible that holds true while the visual presentation of the 
selected element is currently visible. We then could have:

   h1:visible:before { content: url(opening-fanfare.wav); }
   h1:visible { content: url(mood-music.wav); }  /* repeats*/
   h1:visible:after { content: url(closing-fanfare.wav); }

The meaning of 'content' for :visible would need to be well defined,
and perhaps a different property name might be appropriate, e.g.
sound-content.

This approach scales nicely to other interaction states such as when
an element has the input focus (:focus), when the pointer is over
the element (:hover) and to any new states that may be defined in
future, e.g. for substates needed for aural confirmations of
uncertain input in speech media. 

A further benefit is the ability to define additional properties,
for instance, to specify the duration of :before and :after as well
as any transition effects.

A regular and nested notion of states is important for placing CSS
on a sound theoretical basis. I have been studying how CSS relates
to Harel Statecharts, a state transition formalism that is widely
used for modeling behaviors (and part of UML).

See, e.g. http://www.flashsim.com/pubDown/chaps/2667-ch07.pdf

...

Bert writes:

> My idea is that an element's background sound is played as soon as the
> element becomes visible in the window and stops when the element is no
> longer visible. Sounds can be specified to play once or loop. You can
> set their volume and you can also specify what happens to sounds of
> other elements: interrupt while this element plays or play at a
> certain percentage of their volume. Maybe:
> 
>     foo {
>       sound-appear: url(...);    /* Play when element appears in window */
>       sound-visible: url(...);   /* Loops while elt is visible */
>       sound-disappear: url(...); /* Play when element disappears */
>       sound-hover-in: url(...);  /* Play when mouse enters element */
>       sound-hover-out: url(...); /* Play when mouse leaves element */
>       sound-focus-in: url(...);  /* Play when elt gets focus */
>       sound-focus-out: url(...)  /* Play when elt loses focus */
>     }
>     foo:hover, foo:hover {
>       sound-visible: url(...)    /* Different sound that loops */
>     }

This looks ad hoc as it conflates sound, the concepts of entering
and leaving states, and the states themselves. My preference would
be for something more regular that separates these ideas and which
scales better.

- -- 
 Dave Raggett <dsr@w3.org>  W3C lead for voice and multimodal.
 http://www.w3.org/People/Raggett +44 1225 866240 (or 867351)
 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBE0APb3AdEmxAsUsRAv6bAKCUZIjALSZIbjUEblCupImHly+7AQCggi7T
rMgJMPrldKiXcyrtF3wJ0rs=
=dGFk
-----END PGP SIGNATURE-----

Received on Friday, 6 August 2004 04:22:57 UTC