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 25 Nov 2009 22:17 kangax wrote: > David Mark wrote: >> On Nov 24, 11:08 am, kangax <kan...(a)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.) > 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. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: David Mark on 25 Nov 2009 22:41 On Nov 25, 10:17 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > kangax wrote: > > David Mark wrote: > >> On Nov 24, 11:08 am, kangax <kan...(a)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. :)
From: RobG on 26 Nov 2009 01:06 On Nov 26, 1:17 pm, Garrett Smith <dhtmlkitc...(a)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
From: David Mark on 26 Nov 2009 01:09 On Nov 25, 12:42 pm, kangax <kan...(a)gmail.com> wrote: > David Mark wrote: > > On Nov 25, 2:37 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > >> David Mark wrote: > >>> On Nov 24, 11:08 am, kangax <kan...(a)gmail.com> wrote: > >>>> David Mark wrote: > >>>>> On Nov 23, 10:03 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > >>>>>> On Nov 23, 7:35 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > >>>> [...] > >> [snip] > >>> Those grading charts must be of great comfort to the end users who are > >>> stuck with such "ancient" browsers as Opera 9, FF3 and whatever is in > >>> that Blackberry of yours (NetFront?) > >> Blackberry browser is default browser for Blackberry device. It is a > >> totally unique browser with its own rendering engine. > > >> Javascript is turned off, by default. Older versions of Blackberry > >> shipped with CSS off by default. > > >> It has some really weird javascript bugs in it, some very undesirable > >> behavior with respect to DOM recalc (it skips many), but has decent DOM > >> support and pretty good support of ECMA-262 r3. > > > That's why you have to test whether style changes affect the DOM > > immediately and as expected. If not, you skip any enhancements that > > rely on that happening. > > >> The most interesting ECMAScript bug was recently found in Blackberry. > >> The bug? Activation/Variable object has a [[Prototype]]. > > > That is interesting. > > I 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). > > > > >> 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.
From: Garrett Smith on 26 Nov 2009 02:17
David Mark wrote: > On Nov 25, 10:17 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: >> kangax wrote: >>> David Mark wrote: >>>> On Nov 24, 11:08 am, kangax <kan...(a)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. > 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 -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/ |