Re: document[id] and document.id to <element id="id"> matching

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