[whatwg] .tags on HTMLCollections

[Jonas Sicking]

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

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.

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

/ Jonas