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

14 views
Skip to first unread message

David Mark

unread,
Nov 15, 2009, 11:34:15 PM11/15/09
to
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

unread,
Nov 16, 2009, 12:48:42 AM11/16/09
to
On Nov 15, 11:34 pm, David Mark <dmark.cins...@gmail.com> wrote:
> 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

unread,
Nov 16, 2009, 2:09:10 AM11/16/09
to
On Nov 16, 2:34 pm, David Mark <dmark.cins...@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.


--
Rob

David Mark

unread,
Nov 16, 2009, 2:47:58 AM11/16/09
to
On Nov 16, 2:09 am, RobG <rg...@iinet.net.au> wrote:
> On Nov 16, 2:34 pm, David Mark <dmark.cins...@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.

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

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

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

unread,
Nov 17, 2009, 5:33:06 PM11/17/09
to
On Nov 16, 2:09 am, RobG <rg...@iinet.net.au> wrote:

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

unread,
Nov 23, 2009, 5:26:19 PM11/23/09
to

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

--
kangax

David Mark

unread,
Nov 23, 2009, 7:35:34 PM11/23/09
to

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

unread,
Nov 23, 2009, 10:03:20 PM11/23/09
to

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

unread,
Nov 23, 2009, 10:22:30 PM11/23/09
to

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

unread,
Nov 23, 2009, 10:25:37 PM11/23/09
to

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

unread,
Nov 24, 2009, 9:17:39 AM11/24/09
to

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

kangax

unread,
Nov 24, 2009, 11:08:35 AM11/24/09
to
David Mark wrote:
> On Nov 23, 10:03 pm, David Mark <dmark.cins...@gmail.com> wrote:
>> On Nov 23, 7:35 pm, David Mark <dmark.cins...@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

David Mark

unread,
Nov 24, 2009, 7:13:18 PM11/24/09
to
On Nov 24, 11:08 am, kangax <kan...@gmail.com> wrote:
> David Mark wrote:
> > On Nov 23, 10:03 pm, David Mark <dmark.cins...@gmail.com> wrote:
> >> On Nov 23, 7:35 pm, David Mark <dmark.cins...@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. ;)

Garrett Smith

unread,
Nov 25, 2009, 2:37:36 AM11/25/09
to
David Mark wrote:
> On Nov 24, 11:08 am, kangax <kan...@gmail.com> wrote:
>> David Mark wrote:
>>> On Nov 23, 10:03 pm, David Mark <dmark.cins...@gmail.com> wrote:
>>>> On Nov 23, 7:35 pm, David Mark <dmark.cins...@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/

David Mark

unread,
Nov 25, 2009, 3:28:28 AM11/25/09
to
On Nov 25, 2:37 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> David Mark wrote:
> > On Nov 24, 11:08 am, kangax <kan...@gmail.com> wrote:
> >> David Mark wrote:
> >>> On Nov 23, 10:03 pm, David Mark <dmark.cins...@gmail.com> wrote:
> >>>> On Nov 23, 7:35 pm, David Mark <dmark.cins...@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.

kangax

unread,
Nov 25, 2009, 12:42:21 PM11/25/09
to

I talked about it here:
<http://yura.thinkweb2.com/named-function-expressions/#activation-object-in-blackberry-browser>

(this peculiarity was found by Garrett recently in one of the threads
here, when we were trying to figure out if any browsers implement
Activation Object as an instance of built-in `Object` constructor).

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

There are rumors of Blackberry switching to WebKit in a very near future
(given recent acquisition of Torch Mobile � makers of webkit-based Iris
browser � by RIM).

<http://www.theiphoneblog.com/2009/08/24/competition-blackberry-browser-webkit-torch-mobile/>
<http://wapreview.com/blog/?p=4935>

There's no point in developing yet another proprietary engine. If they
do adopt webkit, Blackberry browser will probably disappear in a couple
of years (given its already low share among other giants like iPhone and
Android � both webkit-based as well :))

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

Which results?

--
kangax

kangax

unread,
Nov 25, 2009, 12:43:34 PM11/25/09
to
David Mark wrote:
> On Nov 24, 11:08 am, kangax <kan...@gmail.com> wrote:
[...]

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

>
> 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. :(

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.

[...]

--
kangax

Garrett Smith

unread,
Nov 25, 2009, 2:46:49 PM11/25/09
to
kangax wrote:
> David Mark wrote:
>> On Nov 25, 2:37 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>>> David Mark wrote:
>>>> On Nov 24, 11:08 am, kangax <kan...@gmail.com> wrote:
>>>>> David Mark wrote:
>>>>>> On Nov 23, 10:03 pm, David Mark <dmark.cins...@gmail.com> wrote:
>>>>>>> On Nov 23, 7:35 pm, David Mark <dmark.cins...@gmail.com> wrote:

[snip]

>>>
>>> The Blackberry device is Java, so Opera Mini would be an option for that
>>> device.
>>
>> 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

unread,
Nov 25, 2009, 7:56:59 PM11/25/09
to
On Nov 25, 12:43 pm, kangax <kan...@gmail.com> wrote:
> David Mark wrote:
> > On Nov 24, 11:08 am, kangax <kan...@gmail.com> wrote:
> [...]
> >> 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.

>
>
>
> > 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.  :(
>
> 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

unread,
Nov 25, 2009, 8:25:04 PM11/25/09
to
On Nov 25, 12:43 pm, kangax <kan...@gmail.com> wrote:

[...]

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

unread,
Nov 25, 2009, 10:17:47 PM11/25/09
to

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

unread,
Nov 25, 2009, 10:41:38 PM11/25/09
to
On Nov 25, 10:17 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> kangax wrote:
> > David Mark wrote:
> >> On Nov 24, 11:08 am, kangax <kan...@gmail.com> wrote:
> > [...]
> >>> 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

unread,
Nov 26, 2009, 1:06:22 AM11/26/09
to
On Nov 26, 1:17 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
[...]

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


--
Rob

David Mark

unread,
Nov 26, 2009, 1:09:18 AM11/26/09
to
> <http://yura.thinkweb2.com/named-function-expressions/#activation-obje...>

>
> (this peculiarity was found by Garrett recently in one of the threads
> here, when we were trying to figure out if any browsers implement
> Activation Object as an instance of built-in `Object` constructor).
>
>
>
> >> 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.  :)
>
> There are rumors of Blackberry switching to WebKit in a very near future
> (given recent acquisition of Torch Mobile — makers of webkit-based Iris
> browser — by RIM).
>
> <http://www.theiphoneblog.com/2009/08/24/competition-blackberry-browse...>

> <http://wapreview.com/blog/?p=4935>
>
> There's no point in developing yet another proprietary engine. If they
> do adopt webkit, Blackberry browser will probably disappear in a couple
> of years (given its already low share among other giants like iPhone and
> Android — both webkit-based as well :))

>
>
>
> >> 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.
>
> Which results?

Whatever was "document.written" at the time you ran it. You reported
20-something errors, but didn't say if that total was for both sets of
tests (I assume it was). I'm curious about which tests failed as
well. So far I've been able to smooth out the kinks in every tested
browser (other than file URI's of course).

I downloaded a simulator recently, but didn't see immediately how to
do anything useful with it (it did hog my resources quite a bit to
show a picture of a phone though). I'll have to give that another go
some time.

Garrett Smith

unread,
Nov 26, 2009, 2:17:54 AM11/26/09
to
>>> 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.
>

Relative in IE, absolute in 4 others:
link.href
img.longDesc
script.src

Absolute in all:
a.href
img.src

Untested:
area.href
base.href
blockquote.cite
embed.src
head.profile
img.useMap
input.src
input.usemap
object.classid
object.codeBase
object.data
object.useMap
q.cite

form.action resolved in Firefox, not resolved in 4 others.

There should be a tests features all of the above using relative URIs
for attributes and see if the values of the corresponsing DOM properties
are absolute URIs.

DOM 2 HTML[1] says absolute URI for:
a.href
document.URL
document.cookie, when domain is not set

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

LINK href is also a full URI, and in Chrome and Safari.

> The wrapper fixes that in some proprietary MS way.
>

The realAttr? I don't think it does that. That function parses outerHTML
for IE. It seems like overkill.

The regexes expect no whitespace around the "=" in the attribute:

<b id = 'x'>b</b>

IE's outerHTML for that:
<B id=x>b</B>

Example code:
javascript: var div =document.createElement("div"); void(div.innerHTML =
"<b id = 'x'>b</b>"); alert(div.firstChild.outerHTML);

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

Precisely.

As you see, the HTML 4 specification states that Relative URIs are
resolved to full URIs:


>> 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 4 says an absolute URI is resolved. When? During parse time? When
the attribute is requested (as when the browser makes an HTTP request to
load a stylesheet from the src of a LINK tag)? HTML4 does not say when.
From the perspective of HTML, it doesn't matter when.


A relative URI and an absolute URI are different. Programs should be
able to have an expectation of the URI being resolved.

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

A pity that is.

As stated, a LINK's href is resolved to a full URI in a majority of
browsers. In contrast to what browsers do, HTML 5 specifies that that a
LINK's href reflects.
[1]http://www.w3.org/TR/DOM-Level-2-HTML/html.html

David Mark

unread,
Nov 26, 2009, 2:42:49 AM11/26/09
to
On Nov 26, 2:17 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:

[...]

>
> The realAttr? I don't think it does that. That function parses outerHTML
> for IE. It seems like overkill.

No, it only uses outerHTML for a couple of problematic properties
(neither related to URI's). IIRC, the file paths in the broken MSHTML
fork are dealt with through that silly iFlags argument. Regardless,
they are indeed dealt with and you do get the literal URI's in all
versions and modes AFAIK.

And of course it is overkill, except in the rare context when you need
to read attributes as they appear in the markup.

It also illustrates the futility of relying on these methods when you
don't have to (i.e. look at all of the hoops just to keep IE8's
various modes in sync).

>
> The regexes expect no whitespace around the "=" in the attribute:
>
> <b id = 'x'>b</b>
>
> IE's outerHTML for that:
> <B id=x>b</B>

I'll look at it. That was a last minute addition. I think enctype
and value have no other way to determine if they are present. If, for
instance, you were writing a function to serialize a DOM structure,
you would need to know the difference between value="" and no value
attribute at all (DOM property will be "" in either case).

>
> Example code:
> javascript: var div =document.createElement("div"); void(div.innerHTML =
> "<b id = 'x'>b</b>"); alert(div.firstChild.outerHTML);

So it shows that the white space is irrelevant in MSHTML? Regardless,
I agree that the RegExp should allow for such white space in
outerHTML. You never know when they might change it.

>
> >> The HTML 4 spec does not state *when* a relative URL is resolved.
>
> > When?
>
> Precisely.
>
> As you see, the HTML 4 specification states that Relative URIs are
> resolved to full URIs:>> 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]

I don't see the temporal connection.

>
> HTML 4 says an absolute URI is resolved. When? During parse time? When
> the attribute is requested (as when the browser makes an HTTP request to
> load a stylesheet from the src of a LINK tag)? HTML4 does not say when.
>  From the perspective of HTML, it doesn't matter when.

I know that. A property get will normally resolve it, regardless of
when. A getAttribute call, in contrast, should return whatever is in
the markup verbatim (and normally does in most of the latest major
browsers).

>
> A relative URI and an absolute URI are different. Programs should be
> able to have an expectation of the URI being resolved.

Yes. That's another use case for these wrappers (to correct such
problems when possible and degrade gracefully otherwise).

>
> >> HTML 5 doesn't say when a URL attribute is resolved either:
>
> A pity that is.

I still don't understand the time question.

>
> As stated, a LINK's href is resolved to a full URI in a majority of
> browsers.

The DOM property? Yes. Virtually all of them.

> In contrast to what browsers do, HTML 5 specifies that that a
> LINK's href reflects.
> [1]http://www.w3.org/TR/DOM-Level-2-HTML/html.html

As in, it matches the attribute value? I think that would be a stupid
change in direction. It's useful to be able to get the resolved
path. But what the HTML5 group thinks is irrelevant right now anyway.

Garrett Smith

unread,
Nov 26, 2009, 3:06:08 AM11/26/09
to
RobG wrote:
> On Nov 26, 1:17 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> [...]
>> 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/ >
>
No, I meant:
http://www.whatwg.org/specs/web-apps/current-work/

Throws javascript errors in IE.


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

I didn't check the HTML validator.

http://www.whatwg.org/specs/web-apps/current-work/multipage/
Throws javascript errors in IE:

The init() method called in onload:

http://www.whatwg.org/specs/web-apps/current-work/multipage/toc.js
function filterToc(toc, callback) {
var li = toc.firstChild;
var allmatched = true;
while (li) {
if (li.nodeType == Node.ELEMENT_NODE) {

Looks like DOM traversal.

What is |Node| on line 5? Looks like a ReferenceError in IE.

ALthough I don't advocate writing of code that spitefully throws angry
errors in IE, other contemptful authors do (Jorge might do something
like that).

However, it is hard to find any sort of justification for wanting the
one-page document to freeze any browser it loads in.

Whatever it is doing, it could probably do it more efficiently; perhaps
using event bubbling or something.

[snip]

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

The spec on whatwg page freezes IE. The spec on w3.org does not.

The problem is not the size alone.

> [...]
>> 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.
>

Oh, really? So the w3c site throws errors?

Huh, I am seeing:
fixBrokenLink(); fixBrokenLink()

- which is redundant, but no errors thrown. Maybe it was updated just
now and the file did not load. Try a force-reload and let me know what
happens.

Garrett Smith

unread,
Nov 26, 2009, 3:45:01 AM11/26/09
to
David Mark wrote:
> On Nov 26, 2:17 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>
> [...]
>
>> The realAttr? I don't think it does that. That function parses outerHTML
>> for IE. It seems like overkill.
>

Method realAttr address attribute issue; not properties.

link.href (as in HTMLLinkElement) is a property. The value is a relative
URI in IE.

[snip]

>
> It also illustrates the futility of relying on these methods when you
> don't have to (i.e. look at all of the hoops just to keep IE8's
> various modes in sync).
>

Is there a good page that details those in more depth?

[snip]


> So it shows that the white space is irrelevant in MSHTML? Regardless,
> I agree that the RegExp should allow for such white space in
> outerHTML. You never know when they might change it.
>

Whitespace is allowed there in HTML. I would not rely on nonstandard
quirks. I remember differences in Opera outerHTML.

[snip]

>> HTML 4 says an absolute URI is resolved. When? During parse time? When
>> the attribute is requested (as when the browser makes an HTTP request to
>> load a stylesheet from the src of a LINK tag)? HTML4 does not say when.
>> From the perspective of HTML, it doesn't matter when.
>
> I know that. A property get will normally resolve it,

No, a property get does not normally resolve it. DOM 2 guarantees a full
URI for document.URL, a.href, and the domain of a cookie.

In Four browsers, the property form.action is relative URI.

Further testing of properties is warranted.

regardless of
> when. A getAttribute call, in contrast, should return whatever is in
> the markup verbatim (and normally does in most of the latest major
> browsers).
>

That is correct.

>> A relative URI and an absolute URI are different. Programs should be
>> able to have an expectation of the URI being resolved.
>
> Yes. That's another use case for these wrappers (to correct such
> problems when possible and degrade gracefully otherwise).
>

That wrapper does not guarantee a full URI from a property.

>>>> HTML 5 doesn't say when a URL attribute is resolved either:
>> A pity that is.
>
> I still don't understand the time question.
>

The browser has a few options. Take form action:
1) when the form action attribute is used internally
2) when the form action dom property is accessed

When the property form.action is accessed through script, the browser
has a choice to return a value that was parsed or to return an absolute
URI.

Is it lazily, upon reading the property> or is it only when


>> As stated, a LINK's href is resolved to a full URI in a majority of
>> browsers.
>
> The DOM property? Yes. Virtually all of them.
>

Unfortunately no, many URI attributes' corresponding dom *properties*
don't get resolved to a full URI as in IE.

does not resolve to an absolute URI in IE:
script.src
form.action
img.longDesc

form.action resolves to a full URI in Firefox, but not IE, Chrome,
Safari, Opera.

All of the other URI attributes could be tested and specified.


>> In contrast to what browsers do, HTML 5 specifies that that a
>> LINK's href reflects.
>> [1]http://www.w3.org/TR/DOM-Level-2-HTML/html.html
>
> As in, it matches the attribute value?

Yes, HTML 5 says link.href returns the content attribute value.
That's not what four browsers do.

I think that would be a stupid

Yeah they should fix that.

RobG

unread,
Nov 26, 2009, 4:31:36 AM11/26/09
to
On Nov 26, 6:06 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> RobG wrote:
> > On Nov 26, 1:17 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> > [...]
> >> 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/>
>
> No, I meant:http://www.whatwg.org/specs/web-apps/current-work/

OK, we're looking at different documents then.

>
> Throws javascript errors in IE.

Yes.

> > it is valid according to the W3C validator and does not throw any
> > errors in my IE 6.
>
> I didn't check the HTML validator.

The whatwg document has a couple of minor errors that shouldn't affect
the script.

Yes.

>
> The init() method called in onload:
>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/toc.js
> function filterToc(toc, callback) {
>    var li = toc.firstChild;
>    var allmatched = true;
>    while (li) {
>      if (li.nodeType == Node.ELEMENT_NODE) {
>
> Looks like DOM traversal.

Yes.


> What is |Node| on line 5? Looks like a ReferenceError in IE.
>
> ALthough I don't advocate writing of code that spitefully throws angry
> errors in IE, other contemptful authors do (Jorge might do something
> like that).
>
> However, it is hard to find any sort of justification for wanting the
> one-page document to freeze any browser it loads in.

Presuming it was malicious rather than clueless.


--
Rob

David Mark

unread,
Nov 26, 2009, 8:12:38 PM11/26/09
to
On Nov 26, 3:45 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> David Mark wrote:
> > On Nov 26, 2:17 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>
> > [...]
>
> >> The realAttr? I don't think it does that. That function parses outerHTML
> >> for IE. It seems like overkill.
>
> Method realAttr address attribute issue; not properties.

Of course. There is a companion (unfortunately) called "attr" that
addresses properties. ;)

>
> link.href (as in HTMLLinkElement) is a property.

Yes.

> The value is a relative
> URI in IE.

That's a bug and irrelevant to realAttr as it deals with attributes.
Apparently, using realAttr (or bits of it) will be more consistent
than DOM properties in some cases.

>
> [snip]
>
>
>
> > It also illustrates the futility of relying on these methods when you
> > don't have to (i.e. look at all of the hoops just to keep IE8's
> > various modes in sync).
>
> Is there a good page that details those in more depth?

Not really. But we've been over it here. In a nutshell, IE < 8 (plus
IE8 compatibility mode) doesn't understand the difference between
attributes and properties. They also foul up the attributes that
correspond to boolean DOM properties (e.g. disabled, readonly). The
details are in the comments in the wrappers.

>
> [snip]> So it shows that the white space is irrelevant in MSHTML?  Regardless,
> > I agree that the RegExp should allow for such white space in
> > outerHTML.  You never know when they might change it.
>
> Whitespace is allowed there in HTML. I would not rely on nonstandard
> quirks. I remember differences in Opera outerHTML.

I agree and will definitely update that RegExp when I get a chance.

>
> [snip]
>
> >> HTML 4 says an absolute URI is resolved. When? During parse time? When
> >> the attribute is requested (as when the browser makes an HTTP request to
> >> load a stylesheet from the src of a LINK tag)? HTML4 does not say when.
> >>  From the perspective of HTML, it doesn't matter when.
>
> > I know that.  A property get will normally resolve it,
>
> No, a property get does not normally resolve it. DOM 2 guarantees a full
> URI for document.URL, a.href, and the domain of a cookie.

That's what I said. The get will resolve a relative URI (to a full
URI). Getting the attribute should _not_ do that (and doesn't in most
browsers).

>
> In Four browsers, the property form.action is relative URI.

Those are four bugs. Using the wrappers, it is down to two as IE is
taken care of. But certainly I wouldn't count on being able to get a
URI attribute value as it appears in the markup (or conversely rely on
property gets to resolve them to full paths).

>
> Further testing of properties is warranted.

Yes. I have a companion piece that does just that. Compares Dojo,
jQuery and GoogClosure versions of "attr" to a wrapper based on my
code and the raw results from the browser. It's quite illuminating
(and very scary if you built on those libraries) but needs a little
more work before I publish it.

>
> regardless of
>
> > when.  A getAttribute call, in contrast, should return whatever is in
> > the markup verbatim (and normally does in most of the latest major
> > browsers).
>
> That is correct.
>
> >> A relative URI and an absolute URI are different. Programs should be
> >> able to have an expectation of the URI being resolved.
>
> > Yes.  That's another use case for these wrappers (to correct such
> > problems when possible and degrade gracefully otherwise).
>
> That wrapper does not guarantee a full URI from a property.
>
> >>>> HTML 5 doesn't say when a URL attribute is resolved either:
> >> A pity that is.
>
> > I still don't understand the time question.
>
> The browser has a few options. Take form action:
> 1) when the form action attribute is used internally
> 2) when the form action dom property is accessed
>
> When the property form.action is accessed through script, the browser
> has a choice to return a value that was parsed or to return an absolute
> URI.

Yes and the latter is the correct choice.

>
> Is it lazily, upon reading the property> or is it only when

Oh, who knows? That's behind-the-scenes and up to the implementation.

>
> >> As stated, a LINK's href is resolved to a full URI in a majority of
> >> browsers.
>
> > The DOM property?  Yes.  Virtually all of them.
>
> Unfortunately no, many URI attributes' corresponding dom *properties*
> don't get resolved to a full URI as in IE.

Those are bugs.

>
> does not resolve to an absolute URI in IE:
>    script.src
>    form.action
>    img.longDesc

IE has lots of bugs. Apparently using realAttr is more consistent
than using DOM properties in IE.

>
> form.action resolves to a full URI in Firefox, but not IE, Chrome,
> Safari, Opera.

FF is the only one that got that one right then.

>
> All of the other URI attributes could be tested and specified.>> In contrast to what browsers do, HTML 5 specifies that that a
> >> LINK's href reflects.
> >> [1]http://www.w3.org/TR/DOM-Level-2-HTML/html.html
>
> > As in, it matches the attribute value?  
>
> Yes, HTML 5 says link.href returns the content attribute value.
> That's not what four browsers do.

Actually, that's what you said the four (bad) browsers did (returned
the attribute value verbatim). That's wrong and if HTML5 copies that,
they have eliminated the possibility of ever getting the fully
resolved URI from the href property. (!)

>
> I think that would be a stupid
>
> Yeah they should fix that.

Definitely. What the hell are they doing? Watching browsers and
taking notes? Do they understand the behavior observed and the
ramifications to present and future scripts? It sure doesn't sound
like it. :(

Garrett Smith

unread,
Nov 26, 2009, 10:05:50 PM11/26/09
to
David Mark wrote:
> On Nov 26, 3:45 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>> David Mark wrote:
>>> On Nov 26, 2:17 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>>> [...]
>>>> The realAttr? I don't think it does that. That function parses outerHTML
>>>> for IE. It seems like overkill.
>> Method realAttr address attribute issue; not properties.
>
> Of course. There is a companion (unfortunately) called "attr" that
> addresses properties. ;)
>
>> link.href (as in HTMLLinkElement) is a property.
>
> Yes.
>
>> The value is a relative
>> URI in IE.
>
> That's a bug

Why do you say so?

>>
>>
>>> It also illustrates the futility of relying on these methods when you
>>> don't have to (i.e. look at all of the hoops just to keep IE8's
>>> various modes in sync).
>> Is there a good page that details those in more depth?
>
> Not really. But we've been over it here. In a nutshell, IE < 8 (plus
> IE8 compatibility mode)


| The X-UA-COMPATIBLE header has greater precedence than Compatibility
| View. If a Web site is on the Compatibility View List and a page on
| that site includes an X-UA-COMPATIBLE header telling Internet Explorer
| 8 to display a page in IE8 mode, the page is displayed in Internet
| Explorer 8 Standards mode. This allows Web developers to support
| Internet Explorer 8 Standards mode on an incremental basis. For more
| information, see Defining Document Compatibility.

>
>> [snip]> So it shows that the white space is irrelevant in MSHTML? Regardless,
>>> I agree that the RegExp should allow for such white space in
>>> outerHTML. You never know when they might change it.
>> Whitespace is allowed there in HTML. I would not rely on nonstandard
>> quirks. I remember differences in Opera outerHTML.
>
> I agree and will definitely update that RegExp when I get a chance.
>
>> [snip]
>>
>>>> HTML 4 says an absolute URI is resolved. When? During parse time? When
>>>> the attribute is requested (as when the browser makes an HTTP request to
>>>> load a stylesheet from the src of a LINK tag)? HTML4 does not say when.
>>>> From the perspective of HTML, it doesn't matter when.
>>> I know that. A property get will normally resolve it,
>> No, a property get does not normally resolve it. DOM 2 guarantees a full
>> URI for document.URL, a.href, and the domain of a cookie.
>
> That's what I said.

No, you wrote: "A property get will normally resolve it".

If "it" means a property with a URL value, then that would be a false
statement. A property get of URL attribute's corresponding DOM property
does *not* normally resolve a relative URL to an absolute URL. DOM 2
HTML says absolute URI for three properties (cookie, a.href,
document.url) What browsers return for other properties that correspond
to URI attributes varies.

URIs in stylesheets is yet another matter.

The get will resolve a relative URI (to a full
> URI). Getting the attribute should _not_ do that (and doesn't in most
> browsers).
>
>> In Four browsers, the property form.action is relative URI.
>

(that does not express my intent well; I meant that form.action reflects
the corresponding content attribute).

> Those are four bugs.

Why do you say so?

Using the wrappers, it is down to two as IE is
> taken care of. But certainly I wouldn't count on being able to get a
> URI attribute value as it appears in the markup (or conversely rely on
> property gets to resolve them to full paths).
>

Programs can't rely on properties or attributes.

>> Further testing of properties is warranted.
>
> Yes. I have a companion piece that does just that. Compares Dojo,
> jQuery and GoogClosure versions of "attr" to a wrapper based on my
> code and the raw results from the browser. It's quite illuminating
> (and very scary if you built on those libraries) but needs a little
> more work before I publish it.
>

I am interested in seeing a test page for reading properties from objects.

DOM URI Properties are Resolved to Absolute URI?
| property | IE7 | FF3 | | Standard |
+-------------+-----+-----+ [...] -+----------+
| link.href | N | Y | | N |
| a.href | Y | Y | | Y |
| form.action | N | Y

Just adding in all the browsers. Its work to be done, but would be
worthwhile to have published, for reference.

>> regardless of
>>
>>> when. A getAttribute call, in contrast, should return whatever is in
>>> the markup verbatim (and normally does in most of the latest major
>>> browsers).
>> That is correct.
>>
>>>> A relative URI and an absolute URI are different. Programs should be
>>>> able to have an expectation of the URI being resolved.
>>> Yes. That's another use case for these wrappers (to correct such
>>> problems when possible and degrade gracefully otherwise).
>> That wrapper does not guarantee a full URI from a property.
>>
>>>>>> HTML 5 doesn't say when a URL attribute is resolved either:
>>>> A pity that is.
>>> I still don't understand the time question.
>> The browser has a few options. Take form action:
>> 1) when the form action attribute is used internally
>> 2) when the form action dom property is accessed
>>
>> When the property form.action is accessed through script, the browser
>> has a choice to return a value that was parsed or to return an absolute
>> URI.
>
> Yes and the latter is the correct choice.
>

AFAIK, there isn't any standard that confirms that to be true.

In fact, the DOM explicitly states *absolute URI* for a.href, but does
not state so for link.href. This leads me to believe that the value of
the DOM property is not guaranteed to be an absolute URI.

[snip]

>>>> As stated, a LINK's href is resolved to a full URI in a majority of
>>>> browsers.
>>> The DOM property? Yes. Virtually all of them.
>> Unfortunately no, many URI attributes' corresponding dom *properties*
>> don't get resolved to a full URI as in IE.
>
> Those are bugs.
>

That hasn't been shown to be the case.

[...]

>
>> All of the other URI attributes could be tested and specified.>> In contrast to what browsers do, HTML 5 specifies that that a
>>>> LINK's href reflects.
>>>> [1]http://www.w3.org/TR/DOM-Level-2-HTML/html.html
>>> As in, it matches the attribute value?
>> Yes, HTML 5 says link.href returns the content attribute value.
>> That's not what four browsers do.
>
> Actually, that's what you said the four (bad) browsers did (returned
> the attribute value verbatim).

I did not write that. I wrote the opposite:


| HTML 5 says link.href returns the content attribute value. That's

| *not* what four browsers do.

Four browsers return an absolute URI for link.href.

We need a test page. I outlined earlier the object properties that have
URI-valued attributes. Each attribute needs to be tested and the resulst
published in a table.


That's wrong and if HTML5 copies that,
> they have eliminated the possibility of ever getting the fully
> resolved URI from the href property. (!)
>
>> I think that would be a stupid
>>
>> Yeah they should fix that.
>
> Definitely. What the hell are they doing? Watching browsers and
> taking notes?

Probably not in this case.

When standardizing legacy features, Ian and Anne seem look at what
browsers do. Unfortunately this often includes things that are useless,
inconsistent, and buggy, such as form.elementName, HTMLCollection.tags,
and quirks mode.

The standardizing of legacy garbage is a forest for the trees issue.
Also a chicken and egg issue. What scripts do is largely the result of
the bad DOMs and so looking at the bad DOMs and looking at the scripts
and standardizing what happens encourages browser consistency but misses
the big picture: The API should exist to solve problems. Rather than
standardizing garbage because it works in three browsers, it might make
sense to look at how it is being used and present a superior alternative.

The new HTML 5 and WebIDL features are even more bizarre, including
Element.prototype, [[Class]], special delete operator behavior. What a
disaster that is. AIUI, Brendan will be going in an cleaning up their
mess. Poor guy. Allen, great guy but they don't hang.

David Mark

unread,
Nov 26, 2009, 11:02:53 PM11/26/09
to
On Nov 26, 10:05 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> David Mark wrote:
> > On Nov 26, 3:45 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> >> David Mark wrote:
> >>> On Nov 26, 2:17 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> >>> [...]
> >>>> The realAttr? I don't think it does that. That function parses outerHTML
> >>>> for IE. It seems like overkill.
> >> Method realAttr address attribute issue; not properties.
>
> > Of course.  There is a companion (unfortunately) called "attr" that
> > addresses properties.  ;)
>
> >> link.href (as in HTMLLinkElement) is a property.
>
> > Yes.
>
> >> The value is a relative
> >> URI in IE.
>
> > That's a bug
>
> Why do you say so?

Because it should be absolute, just like a.href, img.src, etc.

I added link.href to the tests. All consistent save for Opera 8.27,
which now has five inconsistencies (all URI related). Opera 9.27 has
the one (form.action).

I'll add usemap to the tests when I get a chance.

And, other than if you need to differentiate between absolute and
relative URI's, you can rely on DOM properties. It's the opposite
with attributes, unless you use wrappers (i.e. it is complete chaos).
That's what makes the reliance on get/set/removeAttribute so shaky and
therefore the use of these methods usually indicates a bad script.

Just take this structure:-

<input type="checkbox">

It is guaranteed that the checked property is false. The quasi-
standards-based browsers will return null for the checked attribute
(as is correct as it isn't there). Broken MSHTML implementations
return false. IE8 (in standards mode) returns ''.

Then take this:-

<input type="checkbox" checked>

The DOM property is true, always. Many non-IE browsers will return ''
for the attribute. Uh oh. :(

All you have to do is search the jQuery groups for attr to see that
such issues have been biting them for years. Even where that method
works, it is often by coincidence. As predicted (and relayed to the
jQuery developers and other interested parties 2 years ago), IE8
brought these issues to a head. jQuery responded with... nothing.
The newly released rendition in GoogClosure is a hundred times worse.
Other than for their (ill-advised) CSS selector query engines (Goog
uses an old Dojo version), they didn't need these methods at all.
Strange they ended up at the forefront of DOM manipulation in both
(and others).

David Mark

unread,
Nov 26, 2009, 11:30:02 PM11/26/09
to
On Nov 26, 11:02 pm, David Mark <dmark.cins...@gmail.com> wrote:

[...]

>


> I'll add usemap to the tests when I get a chance.
>

Added. As usual, bad news for browsers (e.g. IE8), but great news if
you use realAttr. :)

Or more accurately, if you reproduce the feature tests (from the code
and/or the test page) needed for your app.

I'd say the most strenuous test of such a GP wrapper would be
serializing a DOM a la innerHTML. That's one of the few things that
it is used for in My Library (though that version is not quite as good
as the one in the test page).

So where could such an app (that needs to get all attributes
accurately) fail? Looks like (some) relative file URI's in older
Opera browsers and default enctype in IE < 8 (and IE8 compatibility
mode). That latter has no real downside. The former would convert
some URI attributes to absolute. If you really need the relative
paths, you should feature test this issue before defining whatever
wrapper will retrieve the paths.

Then there's Blackberry. Haven't seen the results for that one yet.
I heard that environment failed about as many unit tests as Opera 8.54
did. Only took one feature test to smooth that one out and I'm
hopeful it put a dent in the Blackberry quirks as well.

Garrett Smith

unread,
Nov 27, 2009, 3:35:01 AM11/27/09
to
David Mark wrote:
> On Nov 26, 10:05 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>> David Mark wrote:
>>> On Nov 26, 3:45 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>>>> David Mark wrote:
>>>>> On Nov 26, 2:17 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>>>>> [...]
>>>>>> The realAttr? I don't think it does that. That function parses outerHTML
>>>>>> for IE. It seems like overkill.
>>>> Method realAttr address attribute issue; not properties.
>>> Of course. There is a companion (unfortunately) called "attr" that
>>> addresses properties. ;)
>>>> link.href (as in HTMLLinkElement) is a property.
>>> Yes.
>>>> The value is a relative
>>>> URI in IE.
>>> That's a bug
>> Why do you say so?
>
> Because it should be absolute, just like a.href, img.src, etc.
>

Alas, the DOM 2 HTML specification does not standardize it that way. Not
even for img.src.

[snip]

Understanding what browsers do offers the most benefit developers and
HTML 5 spec authors. That goal is best realized in a comprehensive table
showing browser+version in column with property names in rows.

Trying to create a comprehensive realAttr or resolvedURI(prop) method is
just going to add a lot extra cruft and slow the code down.

The jQuery attr function, as a core method, is broken by design. The
attr function seems to be an attempt to provide a cross browser function
to read *something* about an object. That something was either content
attributes or dom properties, and the discrimination between the two was
apparently grossly overlooked in the initial design.

From jQuery attr:
| // If applicable, access the attribute via the DOM 0 way
| if ( name in elem && notxml && !special ) {

David Mark

unread,
Nov 27, 2009, 3:57:31 AM11/27/09
to

I know that. Neither is necessary for _most_ applications. The best
policy is avoidance.

>
> The jQuery attr function, as a core method, is broken by design.

I know and they are not alone. And I don't think it was designed as
much as oozed out as a result of observations.

> The
> attr function seems to be an attempt to provide a cross browser function
> to read *something* about an object.

It's definitely something. Unfortunately nobody has ever been able to
describe what that something is (including John Resig).

> That something was either content
> attributes or dom properties, and the discrimination between the two was
> apparently grossly overlooked in the initial design.

Yes. Somehow they missed the broken MSHTML pattern, which has been
well documented for ten years.

>
>  From jQuery attr:
> | // If applicable, access the attribute via the DOM 0 way
> | if ( name in elem && notxml && !special ) {

Yes, I know. As documented here numerous times, it is a ridiculous
function (and used in every jQuery tutorial, plug-in example, etc.)
It's a critical, low-level function and somehow they've had it botched
all this time. So much for the browser Ninjas and their "test
swarms". They are clearly unfamiliar with IE in all sorts of critical
ways. IE8 only made things worse and they _still_ haven't fixed the
attribute issue.

Too late perhaps as there are likely a million workarounds floating
around out there. I suppose at least a small percentage of them will
break if they breathe on attr. But then, as written, it can't even be
pinned down in IE8 (results vary with the mode) and attr changes a
little bit with each jQuery release (as new "phenomena" are observed).

This can't inspire confidence for apps, widgets, etc. written on top
of any version of jQuery. They can clearly break in all sorts of
maddening ways with the click of a button, which is handily located
next to Refresh in IE8. Imagine somebody testing a jQuery app today
in IE8 standards mode, FF3, Opera 10, Chrome, Safari and nothing
else. They could easily be fooled into thinking the app works when it
actually falls apart in IE6/7 (or at the click of toolbar button).

David Mark

unread,
Nov 27, 2009, 4:22:58 AM11/27/09
to
On Nov 27, 3:35 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:

[...]

>


> Alas, the DOM 2 HTML specification does not standardize it that way. Not
> even for img.src.
>

I know, but there definitely should be. The browser developers are
mostly in agreement at this time (e.g. Opera 9.5+, Chrome, Safari 4,
IE6-8, and most if not all FF versions).

How else would you (easily) get the resolved path? That's why I
couldn't believe HTML5 would consider going in the other direction
(URI properties and attributes _both_ return unresolved paths).

Garrett Smith

unread,
Nov 27, 2009, 2:45:35 PM11/27/09
to
David Mark wrote:
> On Nov 27, 3:35 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>
> [...]
>
>> Alas, the DOM 2 HTML specification does not standardize it that way. Not
>> even for img.src.
>>
>
> I know, but there definitely should be.

It is not standard. Browsers vary for many properties.

The browser developers are
> mostly in agreement at this time (e.g. Opera 9.5+, Chrome, Safari 4,
> IE6-8, and most if not all FF versions).
>

For img.src Netscape 4 provides a full URI. Other browsers copied that.
For other URI attributes, browsers vary.

David Mark

unread,
Nov 27, 2009, 3:02:54 PM11/27/09
to
On Nov 27, 2:45 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> David Mark wrote:
> > On Nov 27, 3:35 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>
> > [...]
>
> >> Alas, the DOM 2 HTML specification does not standardize it that way. Not
> >> even for img.src.
>
> > I know, but there definitely should be.  
>
> It is not standard. Browsers vary for many properties.
>
> The browser developers are
>
> > mostly in agreement at this time (e.g. Opera 9.5+, Chrome, Safari 4,
> > IE6-8, and most if not all FF versions).

I meant mostly in agreement with URI attributes. The URI properties
are all over the place.

>
> For img.src Netscape 4 provides a full URI. Other browsers copied that.

Generally a.href as well. The idea that they would split the
remaining URI properties up into resolve and "no resolve" piles is
ridiculous. ISTM that properties should always resolve as else there
would be no way to get the resolved URI.

> For other URI attributes, browsers vary.

Not with attributes of late. Else that test page would have red spots
on the right.

Garrett Smith

unread,
Nov 27, 2009, 4:39:28 PM11/27/09
to
David Mark wrote:
> On Nov 27, 2:45 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>> David Mark wrote:
>>> On Nov 27, 3:35 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>>> [...]
>>>> Alas, the DOM 2 HTML specification does not standardize it that way. Not
>>>> even for img.src.
>>> I know, but there definitely should be.
>> It is not standard. Browsers vary for many properties.
>>
Rereading HTML 5 on "reflects"[1] requires a URI-valued content
attribute's corresponding property to have absolute URI.

| If a reflecting IDL attribute is a DOMString attribute whose content
| attribute is defined to contain a URL, then on getting, the IDL
| attribute must resolve the value of the content attribute relative to
| the element and return the resulting absolute URL if that was
| successful, or the empty string otherwise; and on setting, must set
| the content attribute to the specified literal value. If the content
| attribute is absent, the IDL attribute must return the default value,
| if the content attribute has one, or else the empty

That means that all URI valued properties, form.action, link.href,
script.src, etc would return an absolute URL (or "" if that fails).

>> The browser developers are
>>
>>> mostly in agreement at this time (e.g. Opera 9.5+, Chrome, Safari 4,
>>> IE6-8, and most if not all FF versions).
>
> I meant mostly in agreement with URI attributes.

Attribute value is whatever is in the source code, unless the property
"reflects". In that case, changing the property changes the attribute
value and vice versa.

For example, setting the title property actually creates the title
attribute value:
var node = document.createElement("div");
node.getAttribute("title"); // null
node.title="t";
node.getAttribute("title"); // "t"

The style property has a more involved serialization.

The URI properties
> are all over the place.
>
>> For img.src Netscape 4 provides a full URI. Other browsers copied that.
>
> Generally a.href as well.

a.href is required to return absolute URI per DOM 2 HTML. The same spec
says img.src is a URI but does not say if that should be relative or
absolute:
http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-87762984
| src of type DOMString
| URI [IETF RFC 2396] designating the source of this image. See the
| src attribute definition in HTML 4.01.

The idea that they would split the
> remaining URI properties up into resolve and "no resolve" piles is
> ridiculous. ISTM that properties should always resolve as else there
> would be no way to get the resolved URI.
>
>> For other URI attributes, browsers vary.
>

disambiguation:
For other URI-valued attributes, values of corresponding DOM properties
vary between browsers.

HTML 5 defines "reflect" specially for URI-valued attributes/properties,
as stated (and explained in the reflink below).

[1]http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#reflecting-content-attributes-in-idl-attributes

Eric Bednarz

unread,
Nov 27, 2009, 5:35:32 PM11/27/09
to
Garrett Smith <dhtmlk...@gmail.com> writes:

> Attribute value is whatever is in the source code,

Since there are numerous people posting to this group who appear to
think that SGML validation is a relevant tool for HTML QA, I am
delighted to say that you are wrong about that. :-)

In the source code – of HTML documents, at least – are attribute value
*literals*.

David Mark

unread,
Nov 27, 2009, 10:53:53 PM11/27/09
to
On Nov 27, 3:35 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:

[...]

>


> The jQuery attr function, as a core method, is broken by design. The
> attr function seems to be an attempt to provide a cross browser function
> to read *something* about an object. That something was either content
> attributes or dom properties, and the discrimination between the two was
> apparently grossly overlooked in the initial design.
>
>  From jQuery attr:
> | // If applicable, access the attribute via the DOM 0 way
> | if ( name in elem && notxml && !special ) {
> --
> Garrett
> comp.lang.javascript FAQ:http://jibbering.com/faq/

Then there's GoogClosure (but why?)

Here's the documentation for createDOM:-

Returns a dom node with a set of attributes. This function accepts
varargs for subsequent nodes to be added. Subsequent nodes will be
added to the first node as childNodes. So: createDom('div', null,
createDom('p'), createDom('p')); would return a div with two child
paragraphs

Yeah, that's it. No idea what it means. Could be important.

goog.dom.createDom_ = function(doc, args) {
var tagName = args[0];
var attributes = args[1];


Confusing start (and it doesn't get any better).


// Internet Explorer is dumb: http://msdn.microsoft.com/workshop/author/
// dhtml/reference/properties/name_2.asp


As mentioned, PKB.


// Also does not allow setting of 'type' attribute on 'input' or
'button'.


Oh but it does. They'd know if they only tested (instead of
misinterpreting a Microsoft missive).


if (goog.userAgent.IE && attributes && (attributes.name ||
attributes.type)) {


So, if the UA string says IE (!) and the attributes argument passed
has "name" or "type" properties...


var tagNameArr = ['<', tagName];
if (attributes.name) {
tagNameArr.push(' name="', goog.string.htmlEscape
(attributes.name),
'"');
}
if (attributes.type) {
tagNameArr.push(' type="', goog.string.htmlEscape
(attributes.type),
'"');
// Create copy of attribute map to remove 'type' without
mutating argument
attributes = goog.cloneObject(attributes);
delete attributes.type;

It's interesting. They didn't delete attributes.name.


}
tagNameArr.push('>');
tagName = tagNameArr.join('');
}


This whole mess is a completely unneeded workaround that will fail
miserably (likely throwing an exception) in any non-IE browser.
Unnecessary and programming for disaster as many UA strings look like
IE's.

In short, type can be set once. Set it immediately after creating the
element (before some other property set causes it to sprout a document
fragment). You can set name any time, but set it after appending if
you want the element to show up in DOM collections (e.g. form elements
collection).

I haven't read the MSDN article they cited (at least not recently).
Perhaps it is wildly inaccurate (wouldn't be the first time).
Regardless, these things are easy to test and the behavior has been
the same for IE4-8 AFAIK.


var element = doc.createElement(tagName);

if (attributes) {
if (goog.isString(attributes)) {


typeof attributes == 'string'

I am pleasantly surprised they checked for the string first. :)


element.className = attributes;


Seems an odd design.


} else {
goog.dom.setProperties(element, attributes);


That looks critical.


}
}

if (args.length > 2) {
var childHandler = function(child) {
// TODO: More coercion, ala MochiKit?
if (child) {
element.appendChild(goog.isString(child) ?
doc.createTextNode(child) : child);
}
};

for (var i = 2; i < args.length; i++) {
var arg = args[i];
// TODO: Fix isArrayLike to return false for a text node.
if (goog.isArrayLike(arg) && !goog.dom.isNodeLike(arg)) {


"Overloading" strategy is designed for failure.


// If the argument is a node list, not a real array, use a
clone,
// because forEach can't be used to mutate a NodeList.
goog.array.forEach(goog.dom.isNodeList(arg) ?
goog.array.clone(arg) : arg,
childHandler);
} else {
childHandler(arg);
}
}
}


Right, we'll skip that mess. Here's the salient bit:-


goog.dom.setProperties = function(element, properties) {
goog.object.forEach(properties, function(val, key) {
if (key == 'style') {
element.style.cssText = val;

No feature detection.


} else if (key == 'class') {


As there is no real documentation, this is the first clue as to what
is expected for attribute (property?) names. That's an attribute
name.


element.className = val;
} else if (key == 'for') {


As is that.


element.htmlFor = val;
} else if (key in goog.dom.DIRECT_ATTRIBUTE_MAP_) {


No filter. And that object is a partial mapping of attribute names to
DOM property names (see below).


element.setAttribute(goog.dom.DIRECT_ATTRIBUTE_MAP_[key], val);


Cue the Twilight Zone music. This passes a DOM property name to
setAttribute.


} else {


This sets a DOM property with an attribute name.


element[key] = val;


element.readonly = ???; // Don't know what to pass for values
element.colspan = ???;

Those result in useless host object augmentations and you can't pass
the property names (e.g. readOnly, colSpan) either (see mapping
below).


}
});
};


In a nutshell, this is completely unusable. It literally makes no
sense. Should be immediately apparent to almost anyone who has ever
scripted an MSHTML DOM. Look closer and notice it is broken (by
design) for everything else as well. I can see why their "technical
writers" punted on writing this one up.


As advertised:-

goog.dom.DIRECT_ATTRIBUTE_MAP_ = {
'cellpadding': 'cellPadding',
'cellspacing': 'cellSpacing',
'colspan': 'colSpan',
'rowspan': 'rowSpan',
'valign': 'vAlign',
'height': 'height',
'width': 'width',
'usemap': 'useMap',
'frameborder': 'frameBorder',
'type': 'type'
};

The height and width "mappings" are intriguing. Will force the use of
setAttribute for height/width. Same for type, which makes no sense
either. So eliminate those three.

goog.dom.DIRECT_ATTRIBUTE_MAP_ = {
'cellpadding': 'cellPadding',
'cellspacing': 'cellSpacing',
'colspan': 'colSpan',
'rowspan': 'rowSpan',
'valign': 'vAlign',
'usemap': 'useMap',
'frameborder': 'frameBorder'
};

Nobody really cares about the old cellpadding (padding style) or
cellspacing (border-collapse style) or valign (vertical-align style)
attributes/properties. So this is left:-

goog.dom.DIRECT_ATTRIBUTE_MAP_ = {
'colspan': 'colSpan',
'rowspan': 'rowSpan',
'usemap': 'useMap',
'frameborder': 'frameBorder'
};

...accesskey, codebase, framespacing, maxlength, readonly, longdesc,
tabindex, ismap... Overlooked? I suppose it doesn't really matter
when you consider how this is used above. ;)

Google couldn't have budgeted more than a case of Ripple for this
(back in 2005). They got what they paid for. It was broken then and
it is even more so now, even in an IE8-only environment. (!) Hard to
believe they've been using this code for anything, but their
developers have probably been stepping on mines for years, creating
maps, passing along folklore, etc. Did nobody have time to look at
(or test) the code that creates DOM nodes in five years? I see a note
to go back and raid more fantasy code from MochiKit, which is a
further indication of staleness (not to mention apathy).

David Mark

unread,
Nov 28, 2009, 12:02:38 AM11/28/09
to

It's not that much cruft, though any is too much IMO. Why put in
workarounds for things you don't use?

But the slowdown isn't an issue, even with the all the extra baggage
of a GP wrapper. I added times at the end of each set. In IE, as
expected (and regardless of mode), the wrappers are definitely several
milliseconds slower. Results vary from one load to the next, but the
direct method calls always win. It's about even in FF with the direct
method calls usually a bit faster and, oddly enough, reversed in Chome
where the wrappers are twice as fast as the direct method calls. YMMV
of course. And I think I'd be more confident in the comparison if it
looped through the 50 tests 100 times.

kangax

unread,
Nov 28, 2009, 9:03:18 PM11/28/09
to
David Mark wrote:
> On Nov 25, 12:42 pm, kangax <kan...@gmail.com> wrote:
>> David Mark wrote:
>>> On Nov 25, 2:37 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
[...]

>>>> 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.
>> Which results?
>
> Whatever was "document.written" at the time you ran it. You reported
> 20-something errors, but didn't say if that total was for both sets of
> tests (I assume it was). I'm curious about which tests failed as
> well. So far I've been able to smooth out the kinks in every tested
> browser (other than file URI's of course).

I get 2 errors now (on 9530).

Removed column span: '2' is not null
Input checked property set: false is not true

>
> I downloaded a simulator recently, but didn't see immediately how to
> do anything useful with it (it did hog my resources quite a bit to
> show a picture of a phone though). I'll have to give that another go
> some time.

I know. That simulator is a PITA to set up. Good luck ;)

--
kangax

kangax

unread,
Nov 28, 2009, 9:15:38 PM11/28/09
to
Garrett Smith wrote:
> kangax wrote:
[...]

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

No idea.

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

That could be a reason, sure. But look at how poor its standards support
is: <http://www.quirksmode.org/m/table.html#link23>

It gets 14 on Acid 3, comparing to Iris' 100.

[...]

--
kangax

David Mark

unread,
Nov 28, 2009, 9:31:57 PM11/28/09
to
On Nov 28, 9:03 pm, kangax <kan...@gmail.com> wrote:
> David Mark wrote:
> > On Nov 25, 12:42 pm, kangax <kan...@gmail.com> wrote:
> >> David Mark wrote:
> >>> On Nov 25, 2:37 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> [...]
> >>>> 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.
> >> Which results?
>
> > Whatever was "document.written" at the time you ran it.  You reported
> > 20-something errors, but didn't say if that total was for both sets of
> > tests (I assume it was).  I'm curious about which tests failed as
> > well.  So far I've been able to smooth out the kinks in every tested
> > browser (other than file URI's of course).
>
> I get 2 errors now (on 9530).

That means either some of the same quirks found in the old Opera
versions were also present in Blackberry or (less likely) the beefed
up test for broken MSHTML DOM's put it on the right path. Either way,
I'm quite pleased with the progress on the bizarre and ancient browser
front. :)


>
> Removed column span: '2' is not null
> Input checked property set: false is not true

The former likely means the Blackberry DOM can't remove that attribute
(and probably others).

Looking at the latter, I can see how that slipped through the net
(never feature tested that the boolean properties were consistent in
their reflections).

>

2 on the right (wrapped) and 30-something on the left (raw), right?

Thanks for your help!

kangax

unread,
Nov 28, 2009, 10:05:49 PM11/28/09
to
David Mark wrote:
> On Nov 28, 9:03 pm, kangax <kan...@gmail.com> wrote:
>> David Mark wrote:
>>> On Nov 25, 12:42 pm, kangax <kan...@gmail.com> wrote:
>>>> David Mark wrote:
>>>>> On Nov 25, 2:37 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>> [...]
>>>>>> 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.
>>>> Which results?
>>> Whatever was "document.written" at the time you ran it. You reported
>>> 20-something errors, but didn't say if that total was for both sets of
>>> tests (I assume it was). I'm curious about which tests failed as
>>> well. So far I've been able to smooth out the kinks in every tested
>>> browser (other than file URI's of course).
>> I get 2 errors now (on 9530).
>
> That means either some of the same quirks found in the old Opera
> versions were also present in Blackberry or (less likely) the beefed

Yet another proof of proper feature testing taking care of "bug
copying". There's an ubiquitous Opera/IE similarities; I found some of
the IE -like innerHTML bugs in Konqueror recently; and now Blackberry.

If only more people would understand this.

> up test for broken MSHTML DOM's put it on the right path. Either way,
> I'm quite pleased with the progress on the bizarre and ancient browser
> front. :)
>> Removed column span: '2' is not null
>> Input checked property set: false is not true
>
> The former likely means the Blackberry DOM can't remove that attribute
> (and probably others).
>
> Looking at the latter, I can see how that slipped through the net
> (never feature tested that the boolean properties were consistent in
> their reflections).
>
>
> 2 on the right (wrapped) and 30-something on the left (raw), right?

Yep. 23 on the left. 2 on the right.

>
> Thanks for your help!

No problem.

--
kangax

David Mark

unread,
Nov 28, 2009, 10:30:20 PM11/28/09
to
On Nov 28, 9:03 pm, kangax <kan...@gmail.com> wrote:
> David Mark wrote:
> > On Nov 25, 12:42 pm, kangax <kan...@gmail.com> wrote:
> >> David Mark wrote:
> >>> On Nov 25, 2:37 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> [...]
> >>>> 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.
> >> Which results?
>
> > Whatever was "document.written" at the time you ran it.  You reported
> > 20-something errors, but didn't say if that total was for both sets of
> > tests (I assume it was).  I'm curious about which tests failed as
> > well.  So far I've been able to smooth out the kinks in every tested
> > browser (other than file URI's of course).
>
> I get 2 errors now (on 9530).
>
> Removed column span: '2' is not null
> Input checked property set: false is not true

I see that the feature test I added for IE8-ish boolean woes was
checked in the getter, but not the setter in one fork. Oops. I
strongly suspect Blackberry was taking that fork and that should
account for the second one. Odd that only the checked property had a
problem as there are a few other tests with similar attribute sets and
boolean property checks. Should work now.

I also suspect that like the relative/absolute file URI issues (1 in
Opera 9.27, 6 in Opera 9.27), the first one is broken beyond repair on
Blackberry. Those two issues seem worthy of flagging externally (apps
may need them or not).

I need to add some better reporting (i.e. the state of the internal
flags) so I don't have to guess about the results as much. But it's
worked pretty well so far. ;)

ISTM that a CSS selector query engine needs to start with a foundation
like this. Likewise apps with exacting parsing requirements. Editors
and apps that need a consistent innerHTML interface would need such
wrappers for any semblance of cross-browser compatibility.

But virtually everyone else can do without them, perhaps using
individual tests (like those on the test page) on the rare occasion
that direct attribute manipulation is needed (DOM properties usually
suffice).

>
>
>
> > I downloaded a simulator recently, but didn't see immediately how to
> > do anything useful with it (it did hog my resources quite a bit to
> > show a picture of a phone though).  I'll have to give that another go
> > some time.
>
> I know. That simulator is a PITA to set up. Good luck ;)
>

I got it set up, but it didn't do anything impressive. :(

David Mark

unread,
Nov 28, 2009, 11:35:17 PM11/28/09
to
On Nov 28, 10:05 pm, kangax <kan...@gmail.com> wrote:
> David Mark wrote:
> > On Nov 28, 9:03 pm, kangax <kan...@gmail.com> wrote:
> >> David Mark wrote:
> >>> On Nov 25, 12:42 pm, kangax <kan...@gmail.com> wrote:
> >>>> David Mark wrote:
> >>>>> On Nov 25, 2:37 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> >> [...]
> >>>>>> 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.
> >>>> Which results?
> >>> Whatever was "document.written" at the time you ran it.  You reported
> >>> 20-something errors, but didn't say if that total was for both sets of
> >>> tests (I assume it was).  I'm curious about which tests failed as
> >>> well.  So far I've been able to smooth out the kinks in every tested
> >>> browser (other than file URI's of course).
> >> I get 2 errors now (on 9530).
>
> > That means either some of the same quirks found in the old Opera
> > versions were also present in Blackberry or (less likely) the beefed
>
> Yet another proof of proper feature testing taking care of "bug
> copying".

Yes, and and testing features directly and with a plan (e.g. having
some idea what to expect, which allows the results of the tests to be
correctly analyzed).

> There's an ubiquitous Opera/IE similarities; I found some of
> the IE -like innerHTML bugs in Konqueror recently; and now Blackberry.

I bet. :)

>
> If only more people would understand this.

It's coming. The days of testing for !navigator.userAgent.indexOf
('Opera') are clearly over. That strategy was always aimed at trying
to keep up with the (seemingly impossible) present, never mind the
future. For cross-browser (or even multi-browser) scripting 2000-2005
was hell on earth compared to the last five years, so it is easy to
see how the browser sniffing craze gained so much momentum at the
start and is slowly petering out at the end of the decade. If only
more people had read the FAQ notes. ;)

>
> > up test for broken MSHTML DOM's put it on the right path.  Either way,
> > I'm quite pleased with the progress on the bizarre and ancient browser
> > front.  :)
> >> Removed column span: '2' is not null
> >> Input checked property set: false is not true
>
> > The former likely means the Blackberry DOM can't remove that attribute
> > (and probably others).
>
> > Looking at the latter, I can see how that slipped through the net
> > (never feature tested that the boolean properties were consistent in
> > their reflections).
>
> > 2 on the right (wrapped) and 30-something on the left (raw), right?
>
> Yep. 23 on the left. 2 on the right.
>

I think it should be down to the one now. ISTM that maybe Blackberry
won't allow the removal of a colspan attribute at all. That would be
an extreme use case anyway, so I'll just flag it (in case an app must
rely on colspan removal). Have to figure rowspan has the same problem
too. It would be more apparent if I made the test table visible. :)

And I added a notes section after the first set of tests to make it
easier to interpret results.

Thanks again!

Garrett Smith

unread,
Nov 29, 2009, 1:24:43 AM11/29/09
to
Eric Bednarz wrote:
> Garrett Smith <dhtmlk...@gmail.com> writes:
>
>> Attribute value is whatever is in the source code,
>
> Since there are numerous people posting to this group who appear to
> think that SGML validation is a relevant tool for HTML QA, I am
> delighted to say that you are wrong about that. :-)
>

Good point. In fact, I distinctly remember an angry situation with URLs
containing literal ^ (unencoded %5E), somebody's unwillingness to fix
the URLs' generator, and HTML 4.01 Appendix B.2.

As it turns out, many browsers do not follow HTML 4.01 Appendix B.2
completely, and will not encode ^. Safari 4 for windows does (or did).

> In the source code – of HTML documents, at least – are attribute value
> *literals*.

Thank you for bringing this point up.

The implication of this is outerHTML cannot be used directly for reading
attribute values. It could be used intermediately, to first get the
value, then set textContent of an element to that value, then get the
innerText of the element read. Hackery.

Entities in outerHTML may be resolved or they may be unresolved.
Seems IE chooses a mix of the two, plus entitification of various other
characters:

IE6-IE8:
+--------------+------------+
| Source Code | outerHTML |
+--------------+------------+
| &amp; | &amp; |
| tab literal | &#9; |
| CRLF literal | &#13;&#10; |
| &#39; | ' |
| &raquo; | » |
+--------------+------------+

The results in the table show that some entities are resolved while
others are not, and that some literal characters result in creation of
entities where none occurred.

Persuing a comprehensive way to read attribute values (like realAttr)
seems not worth the effort. Testing various encodings, all entities,
etc, sounds like a tremendous effort.

IE8 still does not support &apos;

My next table is going to be a list of clientHeight clientWidth for
documentElement and body in quirks mode and standards mode. I will test
tall, wide documents and short, narrow documents.

This will require the creation of many documents and a considerable
amount of time.

David Mark

unread,
Nov 29, 2009, 1:57:41 AM11/29/09
to
On Nov 29, 1:24 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> Eric Bednarz wrote:

Don't forget borders on the body. ;) But I think you are wasting
your time.

>
> This will require the creation of many documents and a considerable
> amount of time.

So why bother? There's already a test for it. Why not try the test
page from the FAQ 9.3 thread in something other than the browsers
already tested? I really think it is close to perfect on the
measurement at this point and am going to update with scroll position
reporting (and setting) shortly.

David Mark

unread,
Nov 29, 2009, 4:10:49 AM11/29/09
to
On Nov 29, 1:24 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> Eric Bednarz wrote:
> > Garrett Smith <dhtmlkitc...@gmail.com> writes:
>
> >> Attribute value is whatever is in the source code,
>
> > Since there are numerous people posting to this group who appear to
> > think that SGML validation is a relevant tool for HTML QA, I am
> > delighted to say that you are wrong about that. :-)
>
> Good point. In fact, I distinctly remember an angry situation with URLs
> containing literal ^ (unencoded %5E), somebody's unwillingness to fix
> the URLs' generator, and HTML 4.01 Appendix B.2.
>
> As it turns out, many browsers do not follow HTML 4.01 Appendix B.2
> completely, and will not encode ^. Safari 4 for windows does (or did).
>
> > In the source code – of HTML documents, at least – are attribute value
> > *literals*.
>
> Thank you for bringing this point up.
>
> The implication of this is outerHTML cannot be used directly for reading
> attribute values. It could be used intermediately, to first get the
> value, then set textContent of an element to that value, then get the
> innerText of the element read. Hackery.
>

Oh, I missed this part. The outerHTML property is used (when
possible) in broken MSHTML implementations (and those that would mimic
them) to determine if attributes _exist_. That property is not used
to read attributes at all. So your worries are of no consequence to
the example at hand. I think you'll find the viewport example to be
the same case. ;)

kangax

unread,
Nov 29, 2009, 11:01:17 PM11/29/09