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

[David Mark]

David Mark wrote:
David Mark wrote:
[...]
[snip]
Those grading charts must be of great comfort to the end users who are
stuck with such "ancient" browsers as Opera 9, FF3 and whatever is in
that Blackberry of yours (NetFront?)
Blackberry browser is default browser for Blackberry device. It is a
totally unique browser with its own rendering engine.
Javascript is turned off, by default. Older versions of Blackberry
shipped with CSS off by default.
It has some really weird javascript bugs in it, some very undesirable
behavior with respect to DOM recalc (it skips many), but has decent DOM
support and pretty good support of ECMA-262 r3.

That's why you have to test whether style changes affect the DOM
immediately and as expected.  If not, you skip any enhancements that
rely on that happening.

The most interesting ECMAScript bug was recently found in Blackberry.
The bug? Activation/Variable object has a [[Prototype]].

That is interesting.

I talked about it here:
<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).

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 )

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]

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

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

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

[...]

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.

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

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]

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]

[...]

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]

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.

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.

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

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]

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.


I didn't check the HTML validator.

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

http://www.whatwg.org/specs/web-apps/current-work/multipage/
Throws javascript errors in IE:
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.

 

[David Mark]

[...]

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]

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


That is correct.



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



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.

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]

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

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

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

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.

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]

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


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]

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

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]

[...]

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]

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

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

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]

[...]

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]

[...]

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]

[...]

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]

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

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.


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.

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-app...flecting-content-attributes-in-idl-attributes

 

[Eric Bednarz]

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]

[...]

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

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;
// 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]

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

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.

 

[David Mark]

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!