Prev: Note 1. ECMAScript. Bound functions.
Next: Thoughts on JS library to help with event driven paradigms
From: David Mark on 14 Jun 2010 20:09
On Jun 14, 12:26 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote:
> On 6/13/2010 7:11 PM, David Mark wrote:
>
> > On Jun 13, 9:50 pm, Thomas 'PointedEars' Lahn<PointedE...(a)web.de>
> > 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?

My current audio module will return true or false for browsers that
use plug-ins. That allows for it to make an informed choice when
presented with multiple alternative formats.

The HTML5 implementations that I tested (e.g. latest Opera, Safari
Chrome, FF). failed to play most of the formats that were detected as
maybes. IIRC, Chrome was the best performer. The rest played only
OGG's, failing silently on the rest.

> It would be an eye opener and a wake
> up to them.

They are past the point of no return. If and when they fix the issue,
it won't affect the versions that I tested.

> I'm always annoyed when I get a new standard feature, RTM,
> and find out that they implemented it wrong.
>

Doesn't really bother me as HTML5 is not a standard yet and won't be
viable on the Web until years after it becomes one. Bits of it may be
usable right away. For example, if all of your audio is in OGG format
and you only "care about" a handful of the latest browsers, you can
assume the "maybes" are positive results and get away with it. But as
the general public doesn't care what developers profess to care about,
it doesn't make sense to me to switch any time soon.

I'll post the HTML5 audio add-on when I get a chance and it will
include disclaimers that indicate it is a downgrade for most
contexts. BGSOUND's for IE and plug-ins for the rest (as implemented
in my current audio API) has worked well for me for over a decade and
that strategy will likely continue to work in the future. Granted,
loading a plug-in is not the snappiest of operations (and can have
adverse effects), which is why I wanted to leverage HTML5 when
possible. The only other alternatives are Flash and Java applets,
both of which I detest.
From: Garrett Smith on 14 Jun 2010 21:20
On 6/14/2010 5:09 PM, David Mark wrote:
> On Jun 14, 12:26 am, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote:
>> On 6/13/2010 7:11 PM, David Mark wrote:
>>
>>> On Jun 13, 9:50 pm, Thomas 'PointedEars' Lahn<PointedE...(a)web.de>
>>> 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?

>
> Doesn't really bother me as HTML5 is not a standard yet and won't be
> viable on the Web until years after it becomes one. Bits of it may be
> usable right away. For example, if all of your audio is in OGG format
> and you only "care about" a handful of the latest browsers, you can
> assume the "maybes" are positive results and get away with it. But as
> the general public doesn't care what developers profess to care about,
> it doesn't make sense to me to switch any time soon.
>

HTML 5 is a draft standard. It is being implemented now. Fallbacks that
you've described using BGSOUND can be used when the feature can be
detected.

I've not used the AUDIO or VIDEO elements at all. SWFObject us awful
code and has been shown here to not work well in versions of IE.

Then there are those who prefer using the approach on Adobe for Flash
detection.

[...]

Garrett
From: David Mark on 14 Jun 2010 21:54
On Jun 14, 9:20 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote:
> On 6/14/2010 5:09 PM, David Mark wrote:
>
>
>
>
>
> > On Jun 14, 12:26 am, Garrett Smith<dhtmlkitc...(a)gmail.com>  wrote:
> >> On 6/13/2010 7:11 PM, David Mark wrote:
>
> >>> On Jun 13, 9:50 pm, Thomas 'PointedEars' Lahn<PointedE...(a)web.de>
> >>> 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.

>
>
>
> > Doesn't really bother me as HTML5 is not a standard yet and won't be
> > viable on the Web until years after it becomes one.  Bits of it may be
> > usable right away.  For example, if all of your audio is in OGG format
> > and you only "care about" a handful of the latest browsers, you can
> > assume the "maybes" are positive results and get away with it.  But as
> > the general public doesn't care what developers profess to care about,
> > it doesn't make sense to me to switch any time soon.
>
> HTML 5 is a draft standard. It is being implemented now. Fallbacks that
> you've described using BGSOUND can be used when the feature can be
> detected.

Did you read my post? You can't infer anything from the ridiculous
"maybe" or "probably" results. As the names might indicate, they are
ambiguous. So, as of right now, trying to detect the features that
matter (e.g. what formats are supported) is impossible.

>
> I've not used the AUDIO or VIDEO elements at all.

Clearly.

> SWFObject us awful
> code and has been shown here to not work well in versions of IE.

Yes, it is, and always has been, complete trash. Last I checked, it
was crawling with browser sniffs, ironically many of them for IE.

>
> Then there are those who prefer using the approach on Adobe for Flash
> detection.
>

Yes, their own rendition makes SWFObject look masterful. If you want
Flash, use My Library. AFAIK, it's the only implementation out there
that refrains from browser sniffing. Works in every browser/Flash
combination I've ever tried, in both HTML and XHTML DOM's, dating back
to the turn of the century. Was pleased to see it is still working in
IE9. And I have every reason to believe it will continue to work
indefinitely. Haven't even looked at the code in years either.

Why a giant concern like Adobe would continue to ship inept deployment
code for such a key product is beyond me. Of course, Apple builds
mobile sites with SproutCore and MS promotes jQuery. Funny old world.
From: Garrett Smith on 15 Jun 2010 00:10
On 6/14/2010 6:54 PM, David Mark wrote:
> On Jun 14, 9:20 pm, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote:
>> On 6/14/2010 5:09 PM, David Mark wrote:
>>
>>
>>
>>
>>
>>> On Jun 14, 12:26 am, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote:
>>>> On 6/13/2010 7:11 PM, David Mark wrote:
>>
>>>>> On Jun 13, 9:50 pm, Thomas 'PointedEars' Lahn<PointedE...(a)web.de>
>>>>> 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.

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

Garrett

From: David Mark on 15 Jun 2010 06:14
On Jun 15, 12:10 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote:
> On 6/14/2010 6:54 PM, David Mark wrote:
>
>
>
> > On Jun 14, 9:20 pm, Garrett Smith<dhtmlkitc...(a)gmail.com>  wrote:
> >> On 6/14/2010 5:09 PM, David Mark wrote:
>
> >>> On Jun 14, 12:26 am, Garrett Smith<dhtmlkitc...(a)gmail.com>    wrote:
> >>>> On 6/13/2010 7:11 PM, David Mark wrote:
>
> >>>>> On Jun 13, 9:50 pm, Thomas 'PointedEars' Lahn<PointedE...(a)web.de>
> >>>>> 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.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Note 1. ECMAScript. Bound functions.
Next: Thoughts on JS library to help with event driven paradigms