Microsoft and attributes--will they ever figure them out?
in [JavaScript]
|
Prev: What is a software engineer?
Next: Java Front end Developer | NYC | Long term (Only GC/Citizens)
From: Garrett Smith on 26 Nov 2009 22:05 David Mark wrote: > On Nov 26, 3:45 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: >> David Mark wrote: >>> On Nov 26, 2:17 am, Garrett Smith <dhtmlkitc...(a)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. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: David Mark on 26 Nov 2009 23:02 On Nov 26, 10:05 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > David Mark wrote: > > On Nov 26, 3:45 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > >> David Mark wrote: > >>> On Nov 26, 2:17 am, Garrett Smith <dhtmlkitc...(a)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).
From: David Mark on 26 Nov 2009 23:30 On Nov 26, 11:02 pm, David Mark <dmark.cins...(a)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.
From: Garrett Smith on 27 Nov 2009 03:35 David Mark wrote: > On Nov 26, 10:05 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: >> David Mark wrote: >>> On Nov 26, 3:45 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: >>>> David Mark wrote: >>>>> On Nov 26, 2:17 am, Garrett Smith <dhtmlkitc...(a)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 ) { -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: David Mark on 27 Nov 2009 03:57
On Nov 27, 3:35 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > David Mark wrote: > > On Nov 26, 10:05 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > >> David Mark wrote: > >>> On Nov 26, 3:45 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > >>>> David Mark wrote: > >>>>> On Nov 26, 2:17 am, Garrett Smith <dhtmlkitc...(a)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. 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). |