[whatwg] .tags on HTMLCollections

[Ian Hickson]

On Fri, 14 Aug 2009, Jonas Sicking 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?

<keygen> is rarely used on the public Web. It's probably used less than 
.tags(), in fact, though I have no hard data to back this up.


> 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. 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).

I've (mostly arbitrarly) decided to leave features from the Element 
interface to Web DOM Core. HTMLCollection has "HTML" in the name, though, 
so it's harder to argue that it's out of scope! :-) But again, the choice 
there was mostly arbitrary. I needed HTMLCollection for a number of HTML 
features, and there was no spec that defined it.


> 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.

Yes, it probably is. Feel free to raise issues for any that I've missed.


> Put it another way, what is the downside of removing it from the spec?

The majority of browsers believe that it needs to be supported. Not 
defining it means that their implementations will not be tested as well, 
will be not quite the same, and so forth. The same disadvantages as not 
including pretty much _any_ feature.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'