Microsoft and attributes--will they ever figure them out?
in [JavaScript]
|
Prev: What is a software engineer?
Next: Java Front end Developer | NYC | Long term (Only GC/Citizens)
From: David Mark on 24 Nov 2009 09:17 On Nov 23, 10:25 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > On Nov 23, 5:26 pm, kangax <kan...(a)gmail.com> wrote: > > > > > On Nov 17, 5:33 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > > > > On Nov 16, 2:09 am, RobG <rg...(a)iinet.net.au> wrote: > > > > > On Nov 16, 2:34 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > > > > > > Out of curiosity about Microsoft's newfound understanding of > > > > > attributes, I put together a set of tests. Two sets, actually:- > > > > > >http://www.cinsoft.net/attributes.html > > > > > > One calls get/removeAttribute methods assuming they work consistently > > > > > across all browsers (a common strategy). Results are almost exactly > > > > > as expected. All green in modern standards-based browsers tested > > > > > (e.g. Chrome, FF3.5.) Mostly green in IE8 standards mode (yes, > > > > > they've _still_ got some mistakes in there). Put IE8 in > > > > > "compatibility view" and all hell breaks loose (all but three tests > > > > > fail). > > > > > If "compatible" means has the same number of failures, then yes, it's > > > > compatible with my IE 6. > > > > > > Out of further curiosity, I added a second set of the same tests using > > > > > wrapper functions and a feature test proposed here two years ago. All > > > > > is exactly the same, except that now IE8 compatibility mode passes all > > > > > but one test (enctype). I believe IE6/7 will pass all of them as > > > > > there is a workaround in there for that attribute. > > > > > Nope, enctype still fails in IE 6. Will look into it further later. > > > > Turns out only for the default enctype. The MSHTML parser ignores it > > > as superfluous. So that one is just a harmless irritation. Several > > > other mistakes in IE8 standards mode are not. > > > Those wrappers still fail in Opera 9.27 and 8.54 on Mac (7 and 29 > > failures respectively). Latest Blackberry (9500) has 23 failures. Are > > those wrappers from "My Library"? > > As for Blackberry. I imagine its DOM implementation is broken too. > Again, I assume the left and right results are the same. The former > uses no wrappers at all, calling the DOM methods directly. I'd be > very interested to see these results. > Tried Opera 8.54 on Windows. It is down to four failures (all file paths) after the tests were added to make 9.27 consistent. The file paths are irritating. Looks like Opera 8.54 always gives the full path, regardless of the specified attribute value. Those are easy enough to test, but not worth trying to fix IMO. These unit tests is they are good feature tests as well. If you know which attributes your design must manipulate and how it must manipulate them, you know exactly what to test. That's the best strategy (not a general purpose wrapper).
From: kangax on 24 Nov 2009 11:08 David Mark wrote: > On Nov 23, 10:03 pm, David Mark <dmark.cins...(a)gmail.com> wrote: >> On Nov 23, 7:35 pm, David Mark <dmark.cins...(a)gmail.com> wrote: [...] >> Yes. Opera 9.27 has some broken attribute features (e.g. getAttribute >> method). As expected, the two sets of tests have identical results. >> I am sure these new quirks can be feature tested. The demo is getting >> to be a bit of a mess with a couple of inferences (related to IE8 >> quirks) that need feature tests. > > It was almost a hole in one on 9.27. > > There were two quirks in Opera's getAttribute. One was being feature > tested (cellSpanAttributesBad), but not caught as the feature test was > too narrow. > > The other one was related to booleans (e.g. disabled) and was not a > bug (just an inconsistency), but the tests were too strict to let it > pass. I fixed that so that the results are consistent (new flag > added). Checked 9.27 again. Only one failure � "Form action: 'http://www.cinsoft.net/images/cinsoft.gif' is not 'images/cinsoft.gif'" 8.54 now has 4 failures. The action one (as in 9.27) and 3 more similar MSHTML-isms where relative urls are reported as absolute: Link reference: 'http://www.cinsoft.net/images/cinsoft.gif' is not 'images/cinsoft.gif' Image source: 'http://www.cinsoft.net/images/cinsoft.gif' is not 'images/cinsoft.gif' Image long description: 'http://www.cinsoft.net/images/cinsoft.gif' is not 'images/cinsoft.gif' Image long description: 'http://www.cinsoft.net/images/cinsoft.gif' is not 'images/cinsoft.gif' Passing "2" flag to getAttribute doesn't seem to help. `getAttributeNode(...).value` and `attributes[...].value` report absolute values as well. [...] -- kangax
From: David Mark on 24 Nov 2009 19:13 On Nov 24, 11:08 am, kangax <kan...(a)gmail.com> wrote: > David Mark wrote: > > On Nov 23, 10:03 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > >> On Nov 23, 7:35 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > [...] > >> Yes. Opera 9.27 has some broken attribute features (e.g. getAttribute > >> method). As expected, the two sets of tests have identical results. > >> I am sure these new quirks can be feature tested. The demo is getting > >> to be a bit of a mess with a couple of inferences (related to IE8 > >> quirks) that need feature tests. > > > It was almost a hole in one on 9.27. > > > There were two quirks in Opera's getAttribute. One was being feature > > tested (cellSpanAttributesBad), but not caught as the feature test was > > too narrow. > > > The other one was related to booleans (e.g. disabled) and was not a > > bug (just an inconsistency), but the tests were too strict to let it > > pass. I fixed that so that the results are consistent (new flag > > added). > > Checked 9.27 again. Only one failure "Form action: > 'http://www.cinsoft.net/images/cinsoft.gif'is not 'images/cinsoft.gif'" > > 8.54 now has 4 failures. The action one (as in 9.27) and 3 more similar > MSHTML-isms where relative urls are reported as absolute: Yes, that's what I show here. Opera fixed most of their URI bugs between 8.54 and 9.27. > > Link reference: 'http://www.cinsoft.net/images/cinsoft.gif'is not > 'images/cinsoft.gif' > Image source: 'http://www.cinsoft.net/images/cinsoft.gif'is not > 'images/cinsoft.gif' > Image long description: 'http://www.cinsoft.net/images/cinsoft.gif'is > not 'images/cinsoft.gif' > Image long description: 'http://www.cinsoft.net/images/cinsoft.gif'is > not 'images/cinsoft.gif' > > Passing "2" flag to getAttribute doesn't seem to help. > `getAttributeNode(...).value` and `attributes[...].value` report > absolute values as well. Yes, those are things that you might try. So, if you need all attributes to be 100% consistent across all browsers, you've got to have a lot of feature tests. Thankfully this is a (very) rare design requirement. In an HTML DOM, the typical app has no need to query, set or remove attributes "manually". That's what the DOM properties are for. An example would be a CSS selector query engine. That's one reason why those are ever-shifting bad ideas. With the "major" libraries, virtually every time a new browser comes out, their unit tests break (assuming they have anywhere near enough tests and know how to interpret them). In the minds of the authors, this invalidates the old browsers rather than their backwards design decision to hang everything on attributes. So they just "degrade" the old browser on paper (browser grading), rather than in the code. :( Those grading charts must be of great comfort to the end users who are stuck with such "ancient" browsers as Opera 9, FF3 and whatever is in that Blackberry of yours (NetFront?) When a site breaks due to an upgraded library and the user bothers to inform the developers (a rarity), are they given a link to the chart as proof that it is _their_ fault for not upgrading their browser in time for this new library script? You might ask what to do if one or more of the feature tests for your attribute-dependent application breaks. The answer is that you do not define the wrappers at all in that case. Your app's gateway would look something like this:- if (API.realAttr && API.removeAttr) { ... } ....then as you figure out how to deal with odd browsers inside the wrappers, the app keeps up without modification (and is oblivious to the encapsulated quirks). So, as usual, GP is a bad way to go. Your app may only need to deal with certain attributes (e.g. it may not care about URI form) and those are the only ones it should test. Or you can go the "major library" route and break browsers you never tested (or heard of) for no reason. ;)
From: Garrett Smith on 25 Nov 2009 02:37 David Mark wrote: > On Nov 24, 11:08 am, kangax <kan...(a)gmail.com> wrote: >> David Mark wrote: >>> On Nov 23, 10:03 pm, David Mark <dmark.cins...(a)gmail.com> wrote: >>>> On Nov 23, 7:35 pm, David Mark <dmark.cins...(a)gmail.com> wrote: >> [...] [snip] > Those grading charts must be of great comfort to the end users who are > stuck with such "ancient" browsers as Opera 9, FF3 and whatever is in > that Blackberry of yours (NetFront?) Blackberry browser is default browser for Blackberry device. It is a totally unique browser with its own rendering engine. Javascript is turned off, by default. Older versions of Blackberry shipped with CSS off by default. It has some really weird javascript bugs in it, some very undesirable behavior with respect to DOM recalc (it skips many), but has decent DOM support and pretty good support of ECMA-262 r3. The most interesting ECMAScript bug was recently found in Blackberry. The bug? Activation/Variable object has a [[Prototype]]. I added a link in the FAQ some time back to Blackberry Browser JavaScript Reference: http://jibbering.com/faq/#browserResources The Blackberry device is Java, so Opera Mini would be an option for that device. To run Blackberry Simulator, you need Email and MDS and then one or more Simulators. https://www.blackberry.com/Downloads/ -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: David Mark on 25 Nov 2009 03:28
On Nov 25, 2:37 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > David Mark wrote: > > On Nov 24, 11:08 am, kangax <kan...(a)gmail.com> wrote: > >> David Mark wrote: > >>> On Nov 23, 10:03 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > >>>> On Nov 23, 7:35 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > >> [...] > [snip] > > Those grading charts must be of great comfort to the end users who are > > stuck with such "ancient" browsers as Opera 9, FF3 and whatever is in > > that Blackberry of yours (NetFront?) > > Blackberry browser is default browser for Blackberry device. It is a > totally unique browser with its own rendering engine. > > Javascript is turned off, by default. Older versions of Blackberry > shipped with CSS off by default. > > It has some really weird javascript bugs in it, some very undesirable > behavior with respect to DOM recalc (it skips many), but has decent DOM > support and pretty good support of ECMA-262 r3. That's why you have to test whether style changes affect the DOM immediately and as expected. If not, you skip any enhancements that rely on that happening. > > The most interesting ECMAScript bug was recently found in Blackberry. > The bug? Activation/Variable object has a [[Prototype]]. That is interesting. > > I added a link in the FAQ some time back to Blackberry Browser > JavaScript Reference:http://jibbering.com/faq/#browserResources > > The Blackberry device is Java, so Opera Mini would be an option for that > device. Good. Maybe they will switch to that. :) > > To run Blackberry Simulator, you need Email and MDS and then one or more > Simulators. > > https://www.blackberry.com/Downloads/ Page not found. :( I would like to see the results posted for this device. |