MS recommends "feature detection"

Discussion in 'Javascript' started by David Mark, Jun 13, 2010.

  1. David Mark

    David Mark Guest

    MS has finally started to recommend feature detection.

    http://blogs.msdn.com/b/ie/archive/2010/04/14/same-markup-writing-cross-browser-code.aspx

    It's too bad they are completely clueless about how to go about it.
    Their example (slightly modified from jQuery code) is laughable.

    If you want to teach feature detection, don't use examples from
    jQuery. :)

    And from the comments, this is why the average Web developer will
    never understand why browser detection is unnecessary:-

    "On IE there exists "navigator.plugins" but it is always empty."

    They answered their own objection, didn't they?

    Another one:-

    http://blogs.msdn.com/b/ie/archive/...sion-quot-and-styling-new-html5-elements.aspx

    More jQuery-style object inferences. Lots of valid objections in the
    comments, but diluted by typically clueless "answers" like this one:-

    "In the case of a recipe like the one Tony posted, it's been found to
    work on enough browsers to be quite practical, and it's pretty
    simple. "Actually correct programming methods" involve a little
    compromise when you just don't know what environment will be running
    your code."

    Found to work on enough browsers? Empirical evidence does not trump
    logic. And the line about compromise is another variation on the
    "pragmatism" theme. In other words, if you don't understand the
    logic, why not "compromise" and use a mystical incantation.

    Oh well, it beats this blog from a Dojo fan:-

    http://blog.balfes.net/?p=1312

    "Even though Dojo does a great job in making cross browser and
    platform JavaScript development very easy there are times when you may
    want to do something that is specific for a browser. Instead of re-
    inventing the wheel you can use the many functions in the Dojo library
    to help with this."

    Mentions of "re-inventing the wheel" are a virtually infallible
    indicator of a neophyte trying to come off as an expert. Of course,
    advocating Dojo is a dead giveaway as well.

    I've seen Dojo's browser detection code (which they use internally for
    virtually everything, including CSS hacks). It's all UA-based, so if
    you really want to use browser sniffing, you could do much better than
    Dojo's rendition.
    David Mark, Jun 13, 2010
    #1
    1. Advertising

  2. On 6/13/2010 2:20 PM, David Mark wrote:
    > MS has finally started to recommend feature detection.


    [...]

    > Another one:-
    >
    > http://blogs.msdn.com/b/ie/archive/...sion-quot-and-styling-new-html5-elements.aspx
    >
    > More jQuery-style object inferences. Lots of valid objections in the
    > comments, but diluted by typically clueless "answers" like this one:-
    >


    [-snip-]

    Can you explain what problem is with that feature test? It looks fine to me.

    Garrett
    Garrett Smith, Jun 13, 2010
    #2
    1. Advertising

  3. David Mark

    David Mark Guest

    On Jun 13, 6:19 pm, Garrett Smith <> wrote:
    > On 6/13/2010 2:20 PM, David Mark wrote:
    >
    > > MS has finally started to recommend feature detection.

    >
    > [...]
    >
    > > Another one:-

    >
    > >http://blogs.msdn.com/b/ie/archive/2010/06/10/same-markup-explaining-...

    >
    > > More jQuery-style object inferences.  Lots of valid objections in the
    > > comments, but diluted by typically clueless "answers" like this one:-

    >
    > [-snip-]
    >
    > Can you explain what problem is with that feature test? It looks fine to me.


    Feature tests are supposed to be as simple and direct as possible.
    This one fails on both counts.

    var elm = document.createElement("div");
    elm.innerHTML = "<foo>test</foo>";


    Tangled up with the innerHTML property a la jQuery. That's an
    automatic failing grade.


    if(elm.childNodes.length !== 1) {


    This is an object inference that has nothing to do with what they are
    trying to test.


    // Enable styling of new HTML5 elements


    At this point, they have assumed that any browser that displays the
    above quirk can style HTML5 elements.


    var elms = [
    "abbr","article","aside","audio","canvas","command",
    "datalist","details","figcaption","figure","footer",
    "header","hgroup","mark","meter","nav","output",
    "progress","section","summary","time","video"
    ];
    for(var i = 0; i < elms.length; i++) {


    And it's beside the point, but that's just lame. :(


    document.createElement(elms);
    }
    }

    There are plenty of additional indictments (and clueless answers from
    the blogger) at the bottom of the cited post.

    And the whole idea is ridiculous anyway. You obviously shouldn't use
    HTML5 yet. The above magic spell will only help with IE. Who knows
    what the other thousand-odd agents out there will do with these
    elements?
    David Mark, Jun 13, 2010
    #3
  4. On 6/13/2010 3:36 PM, David Mark wrote:
    > On Jun 13, 6:19 pm, Garrett Smith<> wrote:
    >> On 6/13/2010 2:20 PM, David Mark wrote:
    >>
    >>> MS has finally started to recommend feature detection.

    >>
    >> [...]
    >>
    >>> Another one:-

    >>
    >>> http://blogs.msdn.com/b/ie/archive/2010/06/10/same-markup-explaining-...

    >>
    >>> More jQuery-style object inferences. Lots of valid objections in the
    >>> comments, but diluted by typically clueless "answers" like this one:-

    >>
    >> [-snip-]
    >>
    >> Can you explain what problem is with that feature test? It looks fine to me.

    >
    > Feature tests are supposed to be as simple and direct as possible.
    > This one fails on both counts.
    >
    > var elm = document.createElement("div");
    > elm.innerHTML = "<foo>test</foo>";
    >
    >
    > Tangled up with the innerHTML property a la jQuery. That's an
    > automatic failing grade.
    >
    >


    That would be a different feature test. The given test tests to see what
    happens when setting innerHTML.

    See the whatwg blog post that JDD linked to describes different in IE
    when createElement is used:

    http://blog.whatwg.org/supporting-new-elements-in-ie

    > And the whole idea is ridiculous anyway. You obviously shouldn't use
    > HTML5 yet. The above magic spell will only help with IE. Who knows
    > what the other thousand-odd agents out there will do with these
    > elements?


    If support can be detected and a fallback alternative can be provided,
    why not?
    Garrett Smith, Jun 14, 2010
    #4
  5. David Mark

    David Mark Guest

    On Jun 13, 9:25 pm, Garrett Smith <> wrote:
    > On 6/13/2010 3:36 PM, David Mark wrote:
    >
    >
    >
    >
    >
    > > On Jun 13, 6:19 pm, Garrett Smith<>  wrote:
    > >> On 6/13/2010 2:20 PM, David Mark wrote:

    >
    > >>> MS has finally started to recommend feature detection.

    >
    > >> [...]

    >
    > >>> Another one:-

    >
    > >>>http://blogs.msdn.com/b/ie/archive/2010/06/10/same-markup-explaining-....

    >
    > >>> More jQuery-style object inferences.  Lots of valid objections in the
    > >>> comments, but diluted by typically clueless "answers" like this one:-

    >
    > >> [-snip-]

    >
    > >> Can you explain what problem is with that feature test? It looks fine to me.

    >
    > > Feature tests are supposed to be as simple and direct as possible.
    > > This one fails on both counts.

    >
    > > var elm = document.createElement("div");
    > > elm.innerHTML = "<foo>test</foo>";

    >
    > > Tangled up with the innerHTML property a la jQuery.  That's an
    > > automatic failing grade.

    >
    > That would be a different feature test.


    That would be a simple and direct feature test that would give a
    useful result.

    > The given test tests to see what
    > happens when setting innerHTML.


    Which is inappropriate given the stated goals of the test.

    >
    > See the whatwg blog post that JDD linked to describes different in IE
    > when createElement is used:
    >
    > http://blog.whatwg.org/supporting-new-elements-in-ie


    Rather see my comments at the end of the cited blog. The MS
    suggestion is nothing more than an IE-centric object inference.

    >
    > > And the whole idea is ridiculous anyway.  You obviously shouldn't use
    > > HTML5 yet.  The above magic spell will only help with IE.  Who knows
    > > what the other thousand-odd agents out there will do with these
    > > elements?

    >
    > If support can be detected and a fallback alternative can be provided,
    > why not?


    Because you can't do that to any reasonable degree of certainty
    (certainly not by following the MS advice).
    David Mark, Jun 14, 2010
    #5
  6. David Mark wrote:

    > Garrett Smith wrote:
    >> David Mark wrote:
    >> > And the whole idea is ridiculous anyway. You obviously shouldn't use
    >> > HTML5 yet. The above magic spell will only help with IE. Who knows
    >> > what the other thousand-odd agents out there will do with these
    >> > elements?

    >>
    >> If support can be detected and a fallback alternative can be provided,
    >> why not?

    >
    > Because you can't do that to any reasonable degree of certainty
    > (certainly not by following the MS advice).


    First of all, I have not read the article. But if, say,
    document.createElement("video") returns a reference to an object that has a
    play() method, is that not enough indication for you that this element is
    supported as suggested by the HTML 5 draft?


    PointedEars
    --
    Use any version of Microsoft Frontpage to create your site.
    (This won't prevent people from viewing your source, but no one
    will want to steal it.)
    -- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
    Thomas 'PointedEars' Lahn, Jun 14, 2010
    #6
  7. On 6/13/2010 6:38 PM, David Mark wrote:
    > On Jun 13, 9:25 pm, Garrett Smith<> wrote:
    >> On 6/13/2010 3:36 PM, David Mark wrote:
    >>
    >>
    >>
    >>
    >>
    >>> On Jun 13, 6:19 pm, Garrett Smith<> wrote:
    >>>> On 6/13/2010 2:20 PM, David Mark wrote:

    >>
    >>>>> MS has finally started to recommend feature detection.


    [...]

    >>> var elm = document.createElement("div");
    >>> elm.innerHTML = "<foo>test</foo>";

    >>
    >>> Tangled up with the innerHTML property a la jQuery. That's an
    >>> automatic failing grade.

    >>
    >> That would be a different feature test.

    >
    > That would be a simple and direct feature test that would give a
    > useful result.
    >
    >> The given test tests to see what
    >> happens when setting innerHTML.

    >
    > Which is inappropriate given the stated goals of the test.
    >


    Goal #2:
    | The second is that earlier versions of IE collapse all unknown
    | elements at parse time.

    >>
    >> See the whatwg blog post that JDD linked to describes different in IE
    >> when createElement is used:
    >>
    >> http://blog.whatwg.org/supporting-new-elements-in-ie

    >
    > Rather see my comments at the end of the cited blog. The MS
    > suggestion is nothing more than an IE-centric object inference.
    >


    They want to know:

    | The second is that earlier versions of IE collapse all unknown
    | elements at parse time.

    - and the test of setting innerHTML should invoke the parser. Inspecting
    the result of that shows how the code was parsed.

    >>
    >>> And the whole idea is ridiculous anyway. You obviously shouldn't use
    >>> HTML5 yet. The above magic spell will only help with IE. Who knows
    >>> what the other thousand-odd agents out there will do with these
    >>> elements?

    >>
    >> If support can be detected and a fallback alternative can be provided,
    >> why not?

    >
    > Because you can't do that to any reasonable degree of certainty
    > (certainly not by following the MS advice).


    I Disagree. If the goal is to see what an element can do, that can be
    inspected in a test. A test for what a BUTTON's value is, for example
    can be to create a button and check its `value` property. Why can't HTML
    5 elements be tested using the same approach?

    Garrett
    Garrett Smith, Jun 14, 2010
    #7
  8. On 6/13/2010 6:50 PM, Thomas 'PointedEars' Lahn wrote:
    > David Mark wrote:
    >
    >> Garrett Smith wrote:
    >>> David Mark wrote:
    >>>> And the whole idea is ridiculous anyway. You obviously shouldn't use
    >>>> HTML5 yet. The above magic spell will only help with IE. Who knows
    >>>> what the other thousand-odd agents out there will do with these
    >>>> elements?
    >>>
    >>> If support can be detected and a fallback alternative can be provided,
    >>> why not?

    >>
    >> Because you can't do that to any reasonable degree of certainty
    >> (certainly not by following the MS advice).

    >
    > First of all, I have not read the article. But if, say,
    > document.createElement("video") returns a reference to an object that has a
    > play() method, is that not enough indication for you that this element is
    > supported as suggested by the HTML 5 draft?
    >


    The generalization could be mnde that where the test does that, that
    creating a VIDEO element would result in an object with a play method.
    It wouldn't detect which file types would be playable, though.

    Garrett
    Garrett Smith, Jun 14, 2010
    #8
  9. David Mark

    David Mark Guest

    On Jun 13, 9:50 pm, Thomas 'PointedEars' Lahn <>
    wrote:
    > David Mark wrote:
    > > Garrett Smith wrote:
    > >> David Mark wrote:
    > >> > And the whole idea is ridiculous anyway.  You obviously shouldn't use
    > >> > HTML5 yet.  The above magic spell will only help with IE.  Who knows
    > >> > what the other thousand-odd agents out there will do with these
    > >> > elements?

    >
    > >> If support can be detected and a fallback alternative can be provided,
    > >> why not?

    >
    > > Because you can't do that to any reasonable degree of certainty
    > > (certainly not by following the MS advice).

    >
    > First of all, I have not read the article.  But if, say,
    > document.createElement("video") returns a reference to an object that hasa
    > play() method, is that not enough indication for you that this element is
    > supported as suggested by the HTML 5 draft?
    >


    Of course, the operative word is "draft".

    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.
    David Mark, Jun 14, 2010
    #9
  10. David Mark

    David Mark Guest

    On Jun 13, 9:59 pm, Garrett Smith <> wrote:
    > On 6/13/2010 6:38 PM, David Mark wrote:
    >
    > > On Jun 13, 9:25 pm, Garrett Smith<>  wrote:
    > >> On 6/13/2010 3:36 PM, David Mark wrote:

    >
    > >>> On Jun 13, 6:19 pm, Garrett Smith<>    wrote:
    > >>>> On 6/13/2010 2:20 PM, David Mark wrote:

    >
    > >>>>> MS has finally started to recommend feature detection.

    >
    > [...]
    >
    >
    >
    >
    >
    > >>> var elm = document.createElement("div");
    > >>> elm.innerHTML = "<foo>test</foo>";

    >
    > >>> Tangled up with the innerHTML property a la jQuery.  That's an
    > >>> automatic failing grade.

    >
    > >> That would be a different feature test.

    >
    > > That would be a simple and direct feature test that would give a
    > > useful result.

    >
    > >> The given test tests to see what
    > >> happens when setting innerHTML.

    >
    > > Which is inappropriate given the stated goals of the test.

    >
    > Goal #2:
    > | The second is that earlier versions of IE collapse all unknown
    > | elements at parse time.


    That's not a goal, but a description of an unrelated quirk that they
    used for their object inference. The only goal is to determine if the
    HTML5 elements can be styled.

    >
    >
    >
    > >> See the whatwg blog post that JDD linked to describes different in IE
    > >> when createElement is used:

    >
    > >>http://blog.whatwg.org/supporting-new-elements-in-ie

    >
    > > Rather see my comments at the end of the cited blog.  The MS
    > > suggestion is nothing more than an IE-centric object inference.

    >
    > They want to know:
    >
    > | The second is that earlier versions of IE collapse all unknown
    > | elements at parse time.


    For Christ's sake. Again? See above.

    >
    > - and the test of setting innerHTML should invoke the parser. Inspecting
    > the result of that shows how the code was parsed.


    They went down the wrong road.

    >
    >
    >
    > >>> And the whole idea is ridiculous anyway.  You obviously shouldn't use
    > >>> HTML5 yet.  The above magic spell will only help with IE.  Who knows
    > >>> what the other thousand-odd agents out there will do with these
    > >>> elements?

    >
    > >> If support can be detected and a fallback alternative can be provided,
    > >> why not?

    >
    > > Because you can't do that to any reasonable degree of certainty
    > > (certainly not by following the MS advice).

    >
    > I Disagree. If the goal is to see what an element can do, that can be
    > inspected in a test. A test for what a BUTTON's value is, for example
    > can be to create a button and check its `value` property. Why can't HTML
    > 5 elements be tested using the same approach?
    >


    For one, HTML5 isn't even finished yet. For two, see my response to
    PE regarding such detection. It's a complete waste of time at the
    moment (and likely will be for years to come).
    David Mark, Jun 14, 2010
    #10
  11. David Mark

    David Mark Guest

    On Jun 13, 10:04 pm, Garrett Smith <> wrote:
    > On 6/13/2010 6:50 PM, Thomas 'PointedEars' Lahn wrote:
    >
    >
    >
    >
    >
    > > David Mark wrote:

    >
    > >> Garrett Smith wrote:
    > >>> David Mark wrote:
    > >>>> And the whole idea is ridiculous anyway.  You obviously shouldn't use
    > >>>> HTML5 yet.  The above magic spell will only help with IE.  Who knows
    > >>>> what the other thousand-odd agents out there will do with these
    > >>>> elements?

    >
    > >>> If support can be detected and a fallback alternative can be provided,
    > >>> why not?

    >
    > >> Because you can't do that to any reasonable degree of certainty
    > >> (certainly not by following the MS advice).

    >
    > > First of all, I have not read the article.  But if, say,
    > > document.createElement("video") returns a reference to an object that has a
    > > play() method, is that not enough indication for you that this element is
    > > supported as suggested by the HTML 5 draft?

    >
    > The generalization could be mnde that where the test does that, that
    > creating a VIDEO element would result in an object with a play method.
    > It wouldn't detect which file types would be playable, though.
    >


    Neither does the AUDIO element, which is detectable but thoroughly
    worthless at the moment. Less than worthless really as it is flying
    false flags in many cases.
    David Mark, Jun 14, 2010
    #11
  12. On 6/13/2010 7:17 PM, David Mark wrote:
    > On Jun 13, 9:59 pm, Garrett Smith<> wrote:
    >> On 6/13/2010 6:38 PM, David Mark wrote:
    >>
    >>> On Jun 13, 9:25 pm, Garrett Smith<> wrote:
    >>>> On 6/13/2010 3:36 PM, David Mark wrote:

    >>
    >>>>> On Jun 13, 6:19 pm, Garrett Smith<> wrote:
    >>>>>> On 6/13/2010 2:20 PM, David Mark wrote:

    >>
    >>>>>>> MS has finally started to recommend feature detection.


    [...]

    >
    > For one, HTML5 isn't even finished yet. For two, see my response to
    > PE regarding such detection. It's a complete waste of time at the
    > moment (and likely will be for years to come).


    Well CSS2.1 is not finished either.

    HTML 5 is different in a few ways. Some HTML 5 features codify existing
    browser behavior. They take things that work and put them into the spec.

    Codified features start with the doctype and include things like
    navigator.userAgent and the input.width property, both discussed
    recently, plus others, such as javascript: pseudo-protocol.

    Some codified features, such as document.all and a FORM's "past names
    map", are inconsistent, badly designed, and have never worked right.
    Specifying them won't make them any more advisable or well-designed. If
    and when these features reach TR status, they may have the potential to
    teach them to a developer who is unaware of their history and
    programming "by the book". Such developer relying on the standard
    feature may not immediately notice the problems. It seems as if these
    features were specified to cater to implementors, not to the developer
    who reads specifications.

    Ian Hickson:
    "I think it is woefully optimistic to expect any significant number of
    authors to read the specification."
    http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0512.html

    The sad thing about that is that it is probably right. So few actually
    the specifications these days. When I was learning this stuff, things
    like jQuery and Prototype would not have been possible. Even if the APIs
    ahd been in place at that time, the performance in the browsers could
    never have handled such inefficient style of coding and the file sizes
    would not have been practical. The closest thing to those was Dan
    Steinmann's Dynamic Duo. And in those days, standards and specifications
    were something to be hoped for. Then came the DOM core and DOM 2 HTML
    specs. Not without their problems, but in contrast to what was
    available, miles ahead.

    Dynamic Duo worked in IE4 and Netscape 4. Back then, you *couldn't*
    write same code paths and expect it to run in both browsers. Not even
    for image swaps because in NS4, if the image was inside of a positioned
    thing, that thing became a layer and so the image was not a property of
    the document, but a property of the containing layer's document
    property. To swap an image required a depth-first traversal. That is
    something that the previous FAQ notes explained. Still there, but not
    linked any more. Interesting history lesson, and the relevance it bears
    is that today, the libraries are larger than DynLayer API, yet they have
    much fewer browser differences to contend with (no depth first traversal
    needed for chaging an image swap). So, it is a pity that today, it is
    almost a given that developers won't read the specs.

    Going back to HTML 5 specifying input's width, it is not actually a new
    feature but it is a new standard. The design of HTML 4 specified an
    INPUT's *size* attribute as "the width of the element in pixels" for
    input type="image", otherwise, for text or password inputs, the number
    of characters. The feature is overloaded to do two different things and
    it never worked right for character width; browsers always seemed o vary
    on how wide the element would be and size="4" would not necessarily
    correspond to CSS width: 4em. It turns out browsers recognize `width`
    and `height` and treat it as such for certain input elemnets, so now
    HTML 5 specifies a `width` attribute on INPUT type="button" and
    type="image". It works as specified, though not exactly so in IE, as
    shown in the recent "jquery quiz".

    Another difference with HTML 5 is that it is modular. There are parts of
    the specification that are further along than others. There exists the
    possibility that some of it will be scaled back.

    New HTML 5 features are a different story. Any new feature must be
    carefully evaluated and tested and fallback handling and degradation
    strategies should be considered in the initial program design.

    Garrett
    Garrett Smith, Jun 14, 2010
    #12
  13. On 6/13/2010 7:11 PM, David Mark wrote:
    > On Jun 13, 9:50 pm, Thomas 'PointedEars' Lahn<>
    > 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. It would be an eye opener and a wake
    up to them. I'm always annoyed when I get a new standard feature, RTM,
    and find out that they implemented it wrong.

    Garrett
    Garrett Smith, Jun 14, 2010
    #13
  14. > I've seen Dojo's browser detection code (which they use internally for
    > virtually everything, including CSS hacks).  It's all UA-based, so if
    > you really want to use browser sniffing, you could do much better than
    > Dojo's rendition.


    That's unfortunate, especially when their own article on the subject
    promotes the opposite right off the bat.

    http://dojotoolkit.org/reference-guide/quickstart/browser-sniffing.html

    "You should try to use capability detection (http://dev.opera.com/
    articles/view/using-capability-detection/) when possible. When that is
    not an option, Dojo provides a number of is variables for browser
    detection, defined at runtime based on the users current browser."
    Justin Johnson, Jun 14, 2010
    #14
  15. David Mark

    David Mark Guest

    On Jun 14, 5:28 am, Justin Johnson <> wrote:
    > > I've seen Dojo's browser detection code (which they use internally for
    > > virtually everything, including CSS hacks).  It's all UA-based, so if
    > > you really want to use browser sniffing, you could do much better than
    > > Dojo's rendition.

    >
    > That's unfortunate, especially when their own article on the subject
    > promotes the opposite right off the bat.
    >
    > http://dojotoolkit.org/reference-guide/quickstart/browser-sniffing.html
    >
    > "You should try to use capability detection (http://dev.opera.com/
    > articles/view/using-capability-detection/) when possible. When that is
    > not an option, Dojo provides a number of is variables for browser
    > detection, defined at runtime based on the users current browser."


    Yeah, lip service. They put that up fairly recently I think. For the
    longest time, their authors advocated sniffing the UA string as more
    "pragmatic" and "faster" than feature detection.

    They have so much of it that there is very little hope of every
    cleaning it up. The typical widget is crawling with isIE checks (and
    still doesn't support Opera!) And when IE8 came out, they added lots
    of isIE8 checks (to go with the existing isIE6 and isIE7 checks). No
    wonder they are so anxious to wish IE6/7 out of existence. :)

    And, of course, the previous version of Dojo (1.3) didn't work with
    IE8. They told their users that 1.3 never claimed to work with IE8.
    (!) I'm sure they'll say the same thing about 1.4 and IE9 (assuming
    they have any users left at that point).
    David Mark, Jun 14, 2010
    #15
  16. David Mark

    David Mark Guest

    On Jun 14, 12:26 am, Garrett Smith <> wrote:
    > On 6/13/2010 7:11 PM, David Mark wrote:
    >
    > > On Jun 13, 9:50 pm, Thomas 'PointedEars' Lahn<>
    > > 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.
    David Mark, Jun 15, 2010
    #16
  17. On 6/14/2010 5:09 PM, David Mark wrote:
    > On Jun 14, 12:26 am, Garrett Smith<> wrote:
    >> On 6/13/2010 7:11 PM, David Mark wrote:
    >>
    >>> On Jun 13, 9:50 pm, Thomas 'PointedEars' Lahn<>
    >>> 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
    Garrett Smith, Jun 15, 2010
    #17
  18. David Mark

    David Mark Guest

    On Jun 14, 9:20 pm, Garrett Smith <> wrote:
    > On 6/14/2010 5:09 PM, David Mark wrote:
    >
    >
    >
    >
    >
    > > On Jun 14, 12:26 am, Garrett Smith<>  wrote:
    > >> On 6/13/2010 7:11 PM, David Mark wrote:

    >
    > >>> On Jun 13, 9:50 pm, Thomas 'PointedEars' Lahn<>
    > >>> 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.
    David Mark, Jun 15, 2010
    #18
  19. On 6/14/2010 6:54 PM, David Mark wrote:
    > On Jun 14, 9:20 pm, Garrett Smith<> wrote:
    >> On 6/14/2010 5:09 PM, David Mark wrote:
    >>
    >>
    >>
    >>
    >>
    >>> On Jun 14, 12:26 am, Garrett Smith<> wrote:
    >>>> On 6/13/2010 7:11 PM, David Mark wrote:

    >>
    >>>>> On Jun 13, 9:50 pm, Thomas 'PointedEars' Lahn<>
    >>>>> 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
    Garrett Smith, Jun 15, 2010
    #19
  20. David Mark

    David Mark Guest

    On Jun 15, 12:10 am, Garrett Smith <> wrote:
    > On 6/14/2010 6:54 PM, David Mark wrote:
    >
    >
    >
    > > On Jun 14, 9:20 pm, Garrett Smith<>  wrote:
    > >> On 6/14/2010 5:09 PM, David Mark wrote:

    >
    > >>> On Jun 14, 12:26 am, Garrett Smith<>    wrote:
    > >>>> On 6/13/2010 7:11 PM, David Mark wrote:

    >
    > >>>>> On Jun 13, 9:50 pm, Thomas 'PointedEars' Lahn<>
    > >>>>> 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 theycan
    > >>>>> "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 elaborateon
    > >>>> 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.
    David Mark, Jun 15, 2010
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. dotnetforfood
    Replies:
    3
    Views:
    339
    dotnetforfood
    Jul 4, 2004
  2. Eric Bednarz
    Replies:
    3
    Views:
    964
    Mike S
    Nov 5, 2010
  3. Lewis
    Replies:
    1
    Views:
    406
    Jukka K. Korpela
    Nov 9, 2010
  4. dotnetforfood

    Homeland Security Agency recommends abandoning IE

    dotnetforfood, Jul 2, 2004, in forum: ASP General
    Replies:
    3
    Views:
    123
    dotnetforfood
    Jul 4, 2004
  5. Joe Van Dyk

    Paul Graham recommends Ruby

    Joe Van Dyk, Mar 19, 2005, in forum: Ruby
    Replies:
    72
    Views:
    695
    Steven Shaw
    Mar 28, 2005
Loading...

Share This Page