Re: Serious concerns about: dom-window-nameditem

I'm going to guess that the partial implementations that some browsers have
done regarding this is to obtain a level of compatibility with IE due to its
dominance in the Business user market. e.g. I believe that Firefox will
"deal" with some document.all type element references so that some major
sites/apps (that haven't kept up to web standards (because they progress
more slowly)) don't break so horribly when rendered in
Firefox/Chrome/Opera/Safari, etc.

Since IE9 (currently at platform preview 3 stage I believe) is actually
moving ahead and really focusing on standards... thus I would hope that the
Web as a whole, is trying its hardest to move away from the hacks, crutches
and legacy behaviors that have caused so much strife in the past decade.

I'll touch on the "clarity/double-speak" towards the end, but to start I
want to focus on the ID/NAME portion.


In HTML at the moment, ID and NAME attribute values have 2 different, very
distinct purposes.

1. ID
====

ID is to uniquely identify any element anywhere on a page and serves as a
"key" to lookup that element whenever needed in JavaScript or CSS.

For this reason alone, adding it to ANY global namespace is simply NOT
required.

//In JS get any element anywhere in the entire DOM by ID
document.getElementById(id);

/*In CSS style any element by ID*/
#mySpecialElement{
  border:1px solid #ccc;
  color:#ffaacc;
}


2. NAME
=======

NAME is used to provide a name form controls that are going to be submitted
via GET/POST/etc. The name DOES NOT have to be unique, in fact when a
developer wants to submit a page with an array of values they can easily do
so by creating multiple fields with the same name attribute value.

e.g

example.com?user=Steve&food=pizza&food=popcorn&food=icecream&status=likes

Or if they want to create a radio or checkbox set, the name attribute is
vital to associate the form controls together.
<input type="radio" name="status" value="likes"/>
<input type="radio" name="status" value="hates"/>
<input type="radio" name="status" value="loves"/>
<input type="radio" name="status" value="indifferent"/>

The name attribute can also be used on the form itself (as an identifier for
legacy reasons before ID was available) as well as on (i)frames which allows
the targeting of hyperlinks and form submissions to a separate frame.

Finally the name attribute can be used on anchors, to provide a name(d)
location on a page that can be directly linked to via the hash character (#)
in the url (I'm aware that most browsers today will also do the same
auto-scrolling to a position by matching on an ID (which is ok))


For the name attribute, legacy (DOM 0) access to these elements is available
through the doucment.anchors, document.forms[formKey].elements, or
window.frames[frameKey] objects.  Or via the newer
document.getElementsByName(name); (note this method is plural, as there can
be many results returned)

==========

Thus in short, there is already direct, modern DOM access to these elements
(thus there is NO NEED for them to exist as global namespace pollution).
Further still via the document.querySelector and
document.querySelectorAll(query), and getElementsByClassName(class) etc.
that access beyond this is not necessary and will only lead to confusion and
having to support both specs in the future (highly undesired)

This is all ignoring the fact that most sites/apps will throw jQuery or
similar into their sites providing an even richer API should the HTML5
JavaScript capabilities be missing anything feature wise.

==========

As for the "clarity" issue here are my main concerns.

A.) There is a waterfall fallback approach to retrieving the correct
element(s) to be returned (4 & 1/2 steps)
B.) If I read steps 1 through 3 correctly, they pretty much sum up how
HTML3.2 to 4.0 handled things with the anchors, frames, images, links
collections (thus fine, unless there is intention to add to the previous
behavior.
C.) What I object to, is the #4 item.  This is the IE bug that we most
certainly do not want or need propagated to other browsers
D.) Adding to that, the 1/2 point disclaimer at the bottom that indicates
that elements with an ID attribute will also be thrown into this collection
breaks the logic behind ID/NAME.  If I have 6 checkboxes with the name
"item" and a div elsewhere that has the id "item", these are 2 completely
mutually exclusive sets.


Finally, what is not discussed at all here, is that the current IE
implementation of this bug also does not distinguish case-sensitively
between the matches it returns, nor to query them.  Similarly, if a
developer has accidentally created more than one element with the same ID (a
bug)... current browsers differ in terms of which element is returned (I
believe all return the first found, except IE that returns the last (I'm
going off the top of my head on that stat)

I can follow up later with more details, but I have to run right now.

Thanks for your quick reply.

Steve







On Thu, Jul 8, 2010 at 12:18 PM, T.J. Crowder <tj@crowdersoftware.com>wrote:

> On 8 July 2010 16:26, Anne van Kesteren <annevk@opera.com> wrote:
>
>> On Thu, 08 Jul 2010 16:02:37 +0200, Stephen Cunliffe <
>> stephen.cunliffe@gmail.com> wrote:
>>
>>> http://dev.w3.org/html5/spec/Overview.html#dom-window-nameditem
>>>
>>> The "double-speak" of the spec makes it difficult to digest, but if I
>>> understand the intentions correctly, the idea is to now propagate this
>>> pollution of the global namespace to EVERY browser including the merging
>>> of ID/NAME attribute values into this global set.
>>>
>>
>> Most browsers have implemented this long ago for compatibility reasons and
>> therefore we have to keep it unfortunately.
>>
>
> The spec seems to go further than current browser implementation, though.
> For instance (http://jsbin.com/awato), neither Firefox nor Chrome dumps
> all named anchors on the window object; Firefox doesn't dump all named
> images on the window object (I'm surprised Chrome does, but Chrome throws
> more bones to rubbish IE-specific code than Firefox does). But I assume the
> goal in including those is to make the rules straightforward.
>
> I agree with Stephen that it's not a great idea to codify this broken IE
> behavior (I don't find the fact that some browsers half-implement it
> remotely compelling), but at the same time, I can't get too worked up about
> it. :-) You have to code around it anyway (unless you're in some nirvana
> where you don't have to support IE). So long as the spec doesn't allow IE's
> crazy-wrong behavior including these named elements in the results from
> document.getElementById (which even Microsoft has seen the light on).
>
> Could you explain how the specification is unclear? We certainly do not
>> want "double-speak" in the normative user agent requirements!
>>
>
> Agreed. FWIW, the section that Stephen linked to seemed clear to me.
> --
> T.J. Crowder
> tj@crowdersoftware.com
> Independent Software Consultant
>

Received on Thursday, 8 July 2010 18:05:35 UTC