"David Mark" <> wrote in message
news:08f53b94-6773-40d6-a249-...
On Dec 7, 5:09 pm, "Jukka K. Korpela" <jkorp...@cs.tut.fi> wrote:
> 2011-12-07 20:48, Fokke Nauta wrote:
>
> > Well, I used the embed element on other webpages with the same doctype
> > and
> > it works perfectly.
>
> Forget the doctype and validation issues for the moment. They do not
> affect the problem at hand.
Right.
OK, this makes sense.
>
> The question is: can you expect the <embed> element to have play() and
> stop() methods?
Nope.
And this makes sense as well. So, the script I found was crap.
>
> You might consider using the HTML5 <audio> element, with its play() and
> pause() methods, but then you would need to deal with the varying
> support to this element (well, you could use <embed> as fallback
> content) and varying support to different audio media types with it.
Could use the My Library audio module (or the like if can find one) as
the fallback. The book on EMBED/OBJECT-based audio was written ten
years ago. Quick review: it stinks; plug-ins are unreliable. And if
you need to support IE, you should use BGSOUND elements, which is also
taken care of by this module.
You might also consider using an HTML5-based solution and then falling
straight back to the BGSOUND shenanigans. Could even put the latter
in conditional comments. After all, who cares if audio features are
available in old versions of Firefox, Safari, Opera, etc.? Best to
leave the EMBED/OBJECT crap out of it at this point.
OK.
Can you give me an example of how to code this?
>
> Does it really pay off, as opposite to using <embed> with its own
> visible controls? I'd expect most users to prefer those controls (which
> they have encountered on other pages) to your site- or page-specific
> special controls.
>
Pays off for control-freak designers, but stiffs the users.
OK, HTML5 then. With a fall back to the old BGSOUND element.
If you could give me an example ...
Fokke