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: David Mark on 26 Nov 2009 02:42 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. 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.
From: Garrett Smith on 26 Nov 2009 03:06 RobG wrote: > 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/ > > 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 comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Garrett Smith on 26 Nov 2009 03:45 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. 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. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: RobG on 26 Nov 2009 04:31 On Nov 26, 6:06 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > RobG wrote: > > 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/> > > 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. > 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. -- Rob
From: David Mark on 26 Nov 2009 20:12
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 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. :( |