- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 3 Jun 2009 19:06:15 +0000 (UTC)
- To: "Michael A. Puls II" <shadow2531@gmail.com>, Anne van Kesteren <annevk@opera.com>
- Cc: public-html@w3.org
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? > 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? > 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? Am I right to understand that that is the more compatible thing for this Wifi AP? > 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. 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. > 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? 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? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 3 June 2009 19:06:50 UTC