Prev: Note 1. ECMAScript. Bound functions.
Next: Thoughts on JS library to help with event driven paradigms
From: Thomas 'PointedEars' Lahn on 15 Jun 2010 10:21
Garrett Smith wrote:

> David Mark wrote:
>> 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.

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


PointedEars
--
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
-- Richard Cornford, cljs, <cife6q$253$1$8300dec7(a)news.demon.co.uk> (2004)
From: Garrett Smith on 15 Jun 2010 13:56
On 6/15/2010 3:14 AM, David Mark wrote:
> 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.

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
From: Garrett Smith on 15 Jun 2010 13:58
On 6/15/2010 7:21 AM, Thomas 'PointedEars' Lahn wrote:
> Garrett Smith wrote:
>
>> David Mark wrote:
>>> 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.
>
> 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
From: David Mark on 15 Jun 2010 14:51
On Jun 15, 1:56 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote:
> On 6/15/2010 3:14 AM, David Mark wrote:
>
>
>
> > 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.
>
> 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.
From: Thomas 'PointedEars' Lahn on 15 Jun 2010 16:17
Garrett Smith wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Garrett Smith wrote:
>>> David Mark wrote:
>>>> 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.
>>
>> 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.

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


PointedEars
--
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
-- Richard Cornford, cljs, <cife6q$253$1$8300dec7(a)news.demon.co.uk> (2004)
First  |  Prev  | 
Pages: 1 2 3 4 5
Prev: Note 1. ECMAScript. Bound functions.
Next: Thoughts on JS library to help with event driven paradigms