- From: Michael A. Puls II <shadow2531@gmail.com>
- Date: Thu, 04 Jun 2009 00:31:15 -0400
- To: "Ian Hickson" <ian@hixie.ch>, "Anne van Kesteren" <annevk@opera.com>
- Cc: public-html@w3.org
On Wed, 03 Jun 2009 15:06:15 -0400, Ian Hickson <ian@hixie.ch> wrote: > On Mon, 6 Apr 2009, Michael A. Puls II wrote: >> >> Note1: Testing in IE8 final, Firefox latest trunk, Safari 4 with latest >> webkit nightly and the latest Opera 10 snapshot >> <http://my.opera.com/desktopteam/blog/2009/04/03/turbo-in-10> (and >> <http://labs.opera.com/news/2008/11/25/> for <video>) >> >> Note2: This is specifically about document.id to @id matching and not >> window.foo to @id/@name or document.name to @name matching. >> >> IE, Firefox, Safari and Opera seem to differ on how they match >> document.id to <element id="id">. >> >> The main differences between browsers are: >> >> 1. What elements are named elements (object, applet etc.) >> >> 2. When #1 is matched. <element id="id"> and or <element id="id" >> name=""> and or <element id="id" name="non-empty"> >> >> With that said, attached is an example that shows when and how applet, >> object, embed, iframe, img, form, canvas and video come up as matches in >> different browsers. I haven't found any other elements that are matched >> in browsers (keeping note #2 in mind), so other elements are not in the >> test. >> >> These are the results of the test: >> >> Opera: >> OBJECT with no @name >> APPLET with no @name >> EMBED with no @name >> IFRAME (as Window object) with no @name >> IMG with no @name >> OBJECT with empty @name >> APPLET with empty @name >> EMBED with empty @name >> IFRAME (as Window object) with empty @name >> IMG with empty @name >> OBJECT with non-empty @name >> APPLET with non-empty @name >> EMBED with non-empty @name >> IFRAME (as Window object) with non-empty @name >> IMG with non-empty @name >> FORM with non-empty @name >> CANVAS with no @name >> CANVAS with empty @name >> CANVAS with non-empty @name >> VIDEO with no @name >> VIDEO with empty @name >> VIDEO with non-empty @name >> >> Firefox: >> OBJECT with no @name >> APPLET with no @name >> EMBED with no @name >> IMG with no @name >> OBJECT with empty @name >> APPLET with empty @name >> EMBED with empty @name >> IMG with empty @name >> OBJECT with non-empty @name >> APPLET with non-empty @name >> EMBED with non-empty @name >> IMG with non-empty @name >> >> Safari: >> OBJECT with no @name >> APPLET with no @name >> OBJECT with empty @name >> APPLET with empty @name >> IMG with empty @name >> OBJECT with non-empty @name >> APPLET with non-empty @name >> IMG with non-empty @name >> >> IE: >> OBJECT with no @name >> APPLET with no @name >> OBJECT with empty @name >> APPLET with empty @name >> OBJECT with non-empty @name >> APPLET with non-empty @name >> EMBED with non-empty @name >> IFRAME (as Window object) with non-empty @name >> IMG with non-empty @name >> FORM with non-empty @name >> >> (I only tested fallback-free objects though) >> >> Now, HTML5 covers this at >> <http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#dom-document-nameditem>. >> >> However: >> >> 1. I don't really understand the part about there always being one >> element by definition and 'lists' and collections in this case. > > The algorithm is only called if there's at least one match. > > >> I don't really understand the first iframe case either. > > What don't you understand about it? > > >> In other words, if I had to create a JS function to show an example of >> how the spec says the matching works, I couldn't do it given the current >> text in the spec. >> >> Perhaps if it was more like "Let x be the result of" etc. like the >> parsing steps are. > > I don't really understand how what there is now is different from that? I misinterpreted what the spec was saying. <http://lists.w3.org/Archives/Public/public-html/2009Apr/0112.html> "I was thinking from a caller perspective and thought it was saying that document.<nomatch> would return at least one element instead of undefined." So, the spec text is O.K. >> 2. I'm not sure when exactly it says to match iframe in these cases. > > When the iframe has a name="" attribute with the given name. > > >> 3. I'm not sure if the named element conditions are as compatible as >> they could be. Specifically, <img> matching in the spec is compatible >> with Safari more than it is Opera, Firefox and kind of IE. >> >> 4. Opera seems to do more iframe matching than any others in these >> cases, which it looks like it should stop doing. But, is the spec >> following IE here or something different? I can't tell for sure and, >> Firefox and Safari don't match iframes at all in these cases. > > When all the browsers differ, the spec tends to take a "most sane" > approach that matches a common subset. However, if the spec is less > compatible with legacy content than it should be, I'm happy to change it; > what do you suggest should be changed? See below. >> FYI though: opera matching for <iframe id="test"> (IFRAME (as Window >> object) with no @name) seems to be a compatibility problem with at least >> some pages on at least one Wifi AP. > > The spec doesn't match that case, right? Right. > Am I right to understand that > that is the more compatible thing for this Wifi AP? What I was told from the person that has the AP. I can try and get the brand, model name and firmware version. >> 5. Opera matches <canvas> and <video> in these cases. Not sure about >> <canvas>, but matching for <video> in this case *might* make sense to be >> consistent with <object> and <embed>. Then again, there's probably no >> reason to add more chaos when Safari and Firefox don't currently do it. >> Have <video> and <canvas> been considered? What about <audio>? > > I'd rather avoid adding more things to this list. O.K. > On Mon, 6 Apr 2009, Michael A. Puls II wrote: >> >> So, the spec's saying that @id doesn't matter at all for document.foo >> matching for iframe, ever? > > Currently that is correct. O.K. >> document.foo matches <iframe id="foo" name="non-empty"> in IE and Opera >> where the @name value is anything non-empty, not necessarily the same >> value as @id. > > Is this required for compatibility? I think so, but I don't know how much. > On Tue, 7 Apr 2009, Anne van Kesteren wrote: >> On Tue, 07 Apr 2009 00:41:57 +0200, Michael A. Puls II >> <shadow2531@gmail.com> >> wrote: >> > So, the spec's saying that @id doesn't matter at all for document.foo >> > matching for iframe, ever? >> > >> > document.foo matches <iframe id="foo" name="non-empty"> in IE and >> > Opera where the @name value is anything non-empty, not necessarily the >> > same value as @id. >> >> Interesting, that's similar to the <img> case. Maybe the specification >> should simply align with IE then. > > I'd be happy to change the spec if we believe doing this will improve > interoperability or compatibility. Do we? I personally don't have enough data to say for sure. -- Michael
Received on Thursday, 4 June 2009 04:31:51 UTC