Microsoft and attributes--will they ever figure them out?

[David Mark]

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).

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.

The moral is to avoid these methods whenever possible (virtually
always). Calling them outside of a suitable wrapper is surefire
disaster as users can affect the behavior of these methods with a
toolbar button in IE8 (and what a silly button that is).

When might these methods be handy? CSS selector queries (if you find
them useful), parsing/serializing markup and XML elements (e.g SVG)
come to mind. Not a lot else.

But in the "real world", virtually every jQuery example uses its attr
method, which calls get/setAttribute, etc. The big problem is that
the people reading (and writing) these examples are taking it on blind
faith that the jQuery authors understand these issues (they clearly do
not). Maybe a nice picture will finally drive the point home.

 

[David Mark]

Out of curiosity about Microsoft's newfound understanding of
attributes, I put together a set of tests.  Two sets, actually:-

[...]

Added a test for the broken IE8 attribute features (a test for one
anyway, with another workaround inferred). Of course, there may be
more (it was well into the century before all of the IE6/7 quirks
surfaced).

 

[RobG]

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.

 

[David Mark]

If "compatible" means has the same number of failures, then yes, it's
compatible with my IE 6.

IIRC, 6 and 7 won't match exactly. May not have enough tests in there
to show that.

Nope, enctype still fails in IE 6. Will look into it further later.

D'oh! That one is really screwy. The attributes collection key is
actually 'encType' (though that is not the DOM property name and IIRC
that property is missing in IE6/7), but the specified flag is never
set. Apparently it doesn't show up in outerHTML either. Whatever.

I added a few more tests. Didn't budge the success tally for IE6/7/
compatibility mode. Of course, that doesn't matter unless you rely on
these methods to be consistent from one IE version (or mode) to the
next.

There are certainly lots of related tests that will pass. More than
will fail certainly, which explains a lot about how "major" libraries
could waste years working around these headaches, even as IE8 is
tested and launched with what amounts to a destruct button. You can
see in the test suites that evidence was gathered, but apparently
nobody spotted the pattern (which was mostly documented around the
turn of the century).

 

[David Mark]

If "compatible" means has the same number of failures, then yes, it's
compatible with my IE 6.




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.

 

[kangax]

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"?

 

[David Mark]

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"?

Post the results. The wrapper is just a call to get/set/
removeAttribute in quasi-standards-based browsers, so the first set
(without wrappers) should match the second (with). If not, perhaps
Opera's attribute methods are broken too (in some slightly different
way than IE).

One caveat, I did add a few lines to fix IE8 standards problems (MS
still hasn't fixed the problem completely).

And yes and no. They originated in My Library, but then I moved them
to Dojo and made a few improvements (including some new feature
testing). What is up there now is just as I left it.

 

[David Mark]

Post the results.  The wrapper is just a call to get/set/
removeAttribute in quasi-standards-based browsers, so the first set
(without wrappers) should match the second (with).  If not, perhaps
Opera's attribute methods are broken too (in some slightly different
way than IE).

One caveat, I did add a few lines to fix IE8 standards problems (MS
still hasn't fixed the problem completely).

And yes and no.  They originated in My Library, but then I moved them
to Dojo and made a few improvements (including some new feature
testing).  What is up there now is just as I left it.

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.

 

[David Mark]

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).

A bit messy and there are still a couple of inferences related to
IE8's quirks that need to be replaced with proper tests. Now I need
to transplant it back in to My Library.

One thing to keep in mind is that IE6/7 are broken beyond belief
without these wrappers. Other browsers (e.g. Opera 9.27) may be less
than 100% consistent, but still workable. It's the IE6/7 path (and
IE8 in compatibility mode) that has been ignored by the "major"
libraries (and most other scripts written in the last decade).

So, what about Opera 8.54? The results for that sound positively IE-
ish. Perhaps the net for the broken MSHTML DOM needs to be widened a
bit. Opera has been known to copy IE bugs (usually in quirks mode
though).

 

[David Mark]

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.

Thanks again!

 

[David Mark]

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).

 

[David Mark]

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.

 

[Garrett Smith]

On Nov 23, 7:35 pm, David Mark <[email protected]> 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/

 

[David Mark]

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

 

[Garrett Smith]

[snip]

Good. Maybe they will switch to that.

Well, if "they" means the end user, that is an option. Blackberry users
are allowed to use their hardware.

Contrast to the iPhone, which is locked. Fennec, which could run in
iPhone, cannot be used in iPhone because Apple monopolizes the App Store
and won't allow it. Apple SDK also prevents developing scriptable
applications, so no scriptable browser.

There are rumors of Blackberry switching to WebKit in a very near future

Yes, I have heard those rumors. Does Iris uses a proxy, like Opera Mobile?

There's no point in developing yet another proprietary engine.

There may be a point for keeping Blackberry. If Blackberry is more
efficient, the battery would last longer. With a smaller app footprint,
the browser will launch faster. There may be other reasons related to
the device hardware or OS.

The problem with browsers in touchscreen mobile I've tried is that they
have the pointing device (finger) scroll the viewport. This copies
iPhone. It breaks text selection, d'n'd, and overflow: scroll (among
other things).

 

[David Mark]

Link reference: 'http://www.cinsoft.net/images/cinsoft.gif'isnot
'images/cinsoft.gif'
Image source: 'http://www.cinsoft.net/images/cinsoft.gif'isnot
'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.

But properties are not "reliable" either in case of older Opera (URL
values are always reported as absolute, independent of whether they are
accessed as properties — `.src` — or attributes — `getAttribute('src')`,
etc.)

The DOM properties interpret the attribute values. In the case of
URI's, you get the full path (in all browsers). That's why you can't
use properties - for example - to write an innerHTML emulation.

I thought those charts are representative of QA testing. Yes, we can
develop apps that degrade gracefully, but you still need to test things
and testing takes time.

Whatever they represent, the explanations for the results are often
wrong. That indicates they are observations without understanding.
That's fine for a QA tester, but no way for a programmer to approach
browser scripting.

So, not completely useless, but I'd rather test for myself.

 

[David Mark]

[...]

But properties are not "reliable" either in case of older Opera (URL
values are always reported as absolute, independent of whether they are
accessed as properties — `.src` — or attributes — `getAttribute('src')`,
etc.)

If by reliability you mean cross-browser consistency, then yes they
are perfectly reliable (and all you should need for most apps). The
point of all of this is that jQuery and other garbage dumps call get/
set/removeAttribute (e.g. the attr method). In some cases, there is
no attempt to normalize the results at all, creating a very wobbly
foundation for basic DOM scripting. More often, there are attempts to
work around broken implementations, but the logic is either wrong or
incomplete. These workarounds change from one version to the next as
additional observations are made, which leads to more upgrades and
incompatibilities with existing apps.

In short, it's a God-awful mess that could have easily been avoided
with a little understanding. And the first thing to understand is
that you don't often need these methods in an HTML DOM.

 

[Garrett Smith]

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.

But properties are not "reliable" either in case of older Opera (URL
values are always reported as absolute, independent of whether they are
accessed as properties — `.src` — or attributes — `getAttribute('src')`,
etc.)

Did you mean to say that older Opera does *not* return a full URL for an
href property value?

The href property must be resolved to a full URL; DOM 2 requirs that.
http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-88517319

| href of type DOMString
| The absolute URI [IETF RFC 2396] of the linked resource. See the
| href attribute definition in HTML 4.01.

Other URL properties are much less consistent in what is returned.

For example, img.longDesc does not return a full URL in IE, but does in
Firefox and Opera. DOM 2 HTML refers to HTML 4.

The HTML 4 spec does not state *when* a relative URL is resolved.

Links to HTML 4:
http://www.w3.org/TR/1999/REC-html401-19991224/types.html#type-uri
| Relative URIs are resolved to full URIs using a base URI. [RFC1808]

HTML 5 doesn't say when a URL attribute is resolved either:

http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-link-element
| The IDL attributes href, rel, media, hreflang, and type, and sizes
| each must reflect the respective content attributes of the same name.

The link property reflects in IE. Other browsers resolve a LINK
element's href property to a full URL. I'm not sure why HTML 5 specifies
it this way. A common "Location" object, like window.location, would be
nice to have on other elements such as LINK and A.

The HTML 5 specification throws javascript Errors in IE. That should not
happen.

The one-page version of HTML 5 causes Firefox 3.5 to lock up for about
20 sec (on windows vista). This is caused by the onload function which
adds extra scripts that do a lot of DOM traversal.

DOM traversal onload is known to be slow, especially for larger
documents. It is recommended against for that very reason.

The errors that will occur in IE are pretty easy to spot (e.g. Node,
textContent) and may be deliberate, out of anger. I cannot justify the
DOM traversal that causes a freeze in Firefox 3.5.

If they cannot get a simple page right, they should not be authoring web
standards.

 

[David Mark]

Link reference: 'http://www.cinsoft.net/images/cinsoft.gif'isnot
'images/cinsoft.gif'
Image source: 'http://www.cinsoft.net/images/cinsoft.gif'isnot
'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.

But properties are not "reliable" either in case of older Opera (URL
values are always reported as absolute, independent of whether they are
accessed as properties — `.src` — or attributes — `getAttribute('src')`,
etc.)

Did you mean to say that older Opera does *not* return a full URL for an
href property value?

Regardless, it isn't the case.

The href property must be resolved to a full URL; DOM 2 requirs that.http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-88517319

Right. It's consistent cross-browser in that regard.

| href of type DOMString
|    The absolute URI [IETF RFC 2396] of the linked resource. See the
| href attribute definition in HTML 4.01.

Other URL properties are much less consistent in what is returned.

Some, but not many.

For example, img.longDesc does not return a full URL in IE, but does in
Firefox and Opera. DOM 2 HTML refers to HTML 4.

The wrapper fixes that in some proprietary MS way.

The HTML 4 spec does not state *when* a relative URL is resolved.
When?


Links to HTML 4:http://www.w3.org/TR/1999/REC-html401-19991224/types.html#type-uri
| Relative URIs are resolved to full URIs using a base URI. [RFC1808]

HTML 5 doesn't say when a URL attribute is resolved either:

The attribute value is literally the string from the markup, whatever
it may be (e.g. full, relative, etc.) That's why Opera's 9.27 is
flagged with a violation (and 8.54 has 4) for the action attribute.

[...]

The HTML 5 specification throws javascript Errors in IE. That should not
happen.

Yes, they have been sucking for some time.

 

[RobG]

The HTML 5 specification throws javascript Errors in IE. That should not
happen.

If you mean the one at:

<URL: http://www.w3.org/TR/html5/ >

it is valid according to the W3C validator and does not throw any
errors in my IE 6.

The one-page version of HTML 5 causes Firefox 3.5 to lock up for about
20 sec (on windows vista). This is caused by the onload function which
adds extra scripts that do a lot of DOM traversal.

I doubt it - the script file that contains the declaration of the
onload function isn't loaded so the onload function causes an error.
The function runs OK in both Firefox and IE in the multi-page version
(link above), it doesn't do any DOM traversal that I can see. It looks
at the URL and if there's a hash, replaces it with a different value
and resets window.location.

I think the reason it takes a while to load is that the document is
about 4.4MB.

[...]

The errors that will occur in IE are pretty easy to spot (e.g. Node,
textContent)

IE throws the same error that Firefox does: the onload function isn't
defined.