MS recommends "feature detection"

[Thomas 'PointedEars' Lahn]

HTML 5 is a draft standard.

When will you ever learn? It is a Working Draft, nothing more. Do I need
to quote to you *again* what that means?


PointedEars

 

[Garrett Smith]

On 6/14/2010 5:09 PM, David Mark wrote:

On 6/13/2010 7:11 PM, David Mark wrote:

On Jun 13, 9:50 pm, Thomas 'PointedEars' Lahn<[email protected]>
wrote:
David Mark wrote:
Garrett Smith wrote:
David Mark wrote:

[...]

And as I have recently written an HTML5 audio add-on to supplant my
old plug-in based audio functions, I can say for sure that the stuff
is not ready. Virtually all of the file formats report that they can
"maybe" work. Virtually none but OGG's work in today's browsers.
It's a shame the browser developers rushed into implementing that
stuff. Their race to be first has resulted in features that are
impossible to test. When and if the features are fixed, we'll still
be left with a slew of iffy browsers.

I think it would be helpful to the implementors to briefly elaborate on
that and provide a few test cases.

Well, first off, the answer "maybe" is useless. What the hell is the
calling app supposed to do with that?

Maybe? What do you mean?

RTFM. I would link to it if their miserable draft documents didn't
lock up my browser every time I try to read them.

The one-page freezes the browser. It's a good example of why not to
traverse the DOM on page load. Instead, either link to the correct page
of the multipage or link to the one on w3.org.

Even after disabling JS it was an unbelievable dog.

I'm not that motivated to do research on audio now.

You shouldn't need any links to find out how the HTML5 AUDIO DOM
bindings are supposed to work. And it shouldn't take thirty seconds
with a few of the latest browsers to find out that they don't work in
any useful way at this time. Just Google based on the information I
gave you. Until then, I guess you'll have to take my word for it that
it is useless.

No, a specification to any feature is necessary.

Programs (and programmers) should not assumptions of how a feature is
designed by seeing what a couple of browsers do. Especially not for a
new feature, as AUDIO is. Especially given that implementations are
known to ship buggy new features, such as seen into my recent findings
of how JSON.parse and Date.prototype.toISOString were shipped broken in
Firefox 3.6.3.

The specification (draft) is necessary here.

I see HTMLAudioElement extends HTMLMediaElement, which defines that
`canPlayType` returns a string that can be "maybe", "probably", or "".

I haven't looked into strategies for determining playability, but I'll
probably have to at some point, seeing as nobody else has.

Garrett

 

[Garrett Smith]

When will you ever learn? It is a Working Draft, nothing more. Do I need
to quote to you *again* what that means?

Look for bold letters, right at the top of the page --you can't miss it!

http://www.whatwg.org/specs/web-apps/current-work/multipage/index.html#contents

| HTML5 (including next generation additions still in development)
| Draft Standard — 12 June 2010

Don't shoot the messenger.

Garrett

 

[David Mark]

On 6/14/2010 6:54 PM, David Mark wrote:
On 6/14/2010 5:09 PM, David Mark wrote:
On 6/13/2010 7:11 PM, David Mark wrote:
On Jun 13, 9:50 pm, Thomas 'PointedEars' Lahn<[email protected]>
wrote:
David Mark wrote:
Garrett Smith wrote:
David Mark wrote:
[...]
And as I have recently written an HTML5 audio add-on to supplant my
old plug-in based audio functions, I can say for sure that the stuff
is not ready.  Virtually all of the file formats report that they can
"maybe" work.  Virtually none but OGG's work in today's browsers.
It's a shame the browser developers rushed into implementing that
stuff.  Their race to be first has resulted in features that are
impossible to test.  When and if the features are fixed, we'll still
be left with a slew of iffy browsers.
I think it would be helpful to the implementors to briefly elaborate on
that and provide a few test cases.
Well, first off, the answer "maybe" is useless.  What the hell isthe
calling app supposed to do with that?
Maybe? What do you mean?
RTFM.  I would link to it if their miserable draft documents didn't
lock up my browser every time I try to read them.
The one-page freezes the browser. It's a good example of why not to
traverse the DOM on page load. Instead, either link to the correct page
of the multipage or link to the one on w3.org.

Even after disabling JS it was an unbelievable dog.

You shouldn't need any links to find out how the HTML5 AUDIO DOM
bindings are supposed to work.  And it shouldn't take thirty seconds
with a few of the latest browsers to find out that they don't work in
any useful way at this time.  Just Google based on the information I
gave you.  Until then, I guess you'll have to take my word for it that
it is useless.

No, a specification to any feature is necessary.

Programs (and programmers) should not assumptions of how a feature is
designed by seeing what a couple of browsers do. Especially not for a
new feature, as AUDIO is. Especially given that implementations are
known to ship buggy new features, such as seen into my recent findings
of how JSON.parse and Date.prototype.toISOString were shipped broken in
Firefox 3.6.3.

The specification (draft) is necessary here.

I see HTMLAudioElement extends HTMLMediaElement, which defines that
`canPlayType` returns a string that can be "maybe", "probably", or "".

I haven't looked into strategies for determining playability, but I'll
probably have to at some point, seeing as nobody else has.

Pardon? I looked into it. Again, it's a wash as of the latest
browsers.

 

[Thomas 'PointedEars' Lahn]

Look for bold letters, right at the top of the page --you can't miss it!

http://www.whatwg.org/specs/web-apps/current- work/multipage/index.html#contents

| HTML5 (including next generation additions still in development)
| Draft Standard — 12 June 2010

Don't shoot the messenger.

To use that image, the messenger is (still) reading the wrong scroll.


PointedEars