[whatwg] .tags on HTMLCollections

[Garrett Smith]

On Fri, Aug 14, 2009 at 12:02 PM, Jonas Sicking<jonas at sicking.cc> wrote:
> On Fri, Aug 14, 2009 at 3:35 AM, Ian Hickson<ian at hixie.ch> wrote:
>> On Fri, 7 Aug 2009, Jonas Sicking wrote:
>>> >
>>> > I haven't removed HTMLCollection.tags yet, since it appears to be
>>> > implemented by most browsers. If we can get Opera and WebKit to remove
>>> > support, then I'll remove it from the spec.
>>>
>>> Given that we have some data indicating that .tags() is not needed for
>>> web compatibility (Firefox doesn't support it and has received no
>>> requests for it, or bugs indicating sites needing it), and so far only
>>> weak data indicating it is needed (UAs support it, but not clear why),
>>> why not leave it out of the spec for now?
>>>
>>> UAs are always free to continue supporting it if they so please.
>>>
>>> I have very little desire to add support for anything to gecko "just in
>>> case", without any data indicating anyone would use it, much less needs
>>> it.
>>
>> HTMLCollection.tags is specified for the same reason <keygen> is -- a
>> majority of browsers support it. I'd like to remove it, though. I
>> encourage you to convince other browser vendors to drop support for this
>> feature.
>
> The difference is two-fold. First of all I thought we had indication
> that sites actually relied on <keygen>, i.e. we have some sort of data
> on that it's actually a used feature. Is that not the case?
>
> Second, .tags() arguably better belongs in a DOM-Core spec. So we
> could remove it for the same reason that HTML doesn't specify CSS
> quirks-mode behavior, that it's something better left to other specs.

The DOM core has getElementsByTagName. Kind of a long name, but the
behavior is standard and though buggy in IE <= 8, is more consistent.

What exactly does .tags return? NodeList, StaticNodeList, TagsArray?
What about .tags("*")?

> Why doesn't HTML for example define Element.children? That is also
> supported by a majority of other browsers (the exact same set of
> browsers even).

Implementing "children" would be a mistake. This was discussed on
comp.lang.javascript. Recently, in fact:
http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/18beac3cd1e06c29

To save the trouble of reading that thread, MSIE's "children" returns
a list of "DHTML Objects". Those objects include comment nodes. The
test case in the linked thread shows that.

Juriy followed up to post about Divergent behavior in Safari 2 and
Richard mentioned divergent behavior in IceBrowser, and the example I
posted demonstrates (with explanation) the problem with children and
getElementsByTagName in IE <= IE8.  Any code that wanted to use
".children" would need to do more feature testing than it would be
worth.

If a feature is to be created to get child Elements, it should have a
new name. AISB, "childElements", in Jan 2008,

|  REally, all I want is
| nextSiblingElement/previousSiblingElement/childElements properties so I
| don't have to have library code or write a for() loop every time i want
| to just find the next sibling element.

I disagree with the decision to not include those properties.

>
> In general, I suspect if the only criteria to having something in the
> spec was "supported by a majority of browsers and not currently
> defined by any other spec", then I strongly suspect the spec is
> missing a lot of features.
>

Can you explain the "Global Scope Polluter"? :-D

http://groups.google.com/group/comp.lang.javascript/msg/c46682d862939173

AYCS from that thread, we didn't quite figure out how the Global Scope
Polluter works. Would be helpful to have the author or sr for that
code, or anyone who understands it and has the time jump in on that
and explain a little more.

This "Global Scope Polluter" is an MSIE "lets make it easy" feature,
sort of like callable collections. In retrospect, it seems to have
caused more harm than good.

Garrett