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

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