Re: [whatwg] .tags()
On Thu, Oct 22, 2009 at 5:26 PM, Ian Hickson wrote: > On Mon, 19 Oct 2009, Jonas Sicking wrote: >> >> I've been meaning to send a formal email on this subject, and with the >> recent discussion going on over in the W3C webapps mailing list I >> figured now was a good time. >> >> I'd like to formally request that .tags() is removed from the >> HTMLCollection interface. Unless it can be shown that .tags() is needed >> for compatibility with the web Mozilla has no plans to implement this >> property. Back when we implemented document.all, we judged that there >> were enough sites using document.all.tags() to implement the property on >> the document.all collection, however we haven't seen any information >> indicating that this is needed elsewhere. > > I've removed it and filed bugs on WebKit and Opera. If the bugs get > WONTFIXed, though, then I'd like there to be a spec defining how this > should work. Thanks! / Jonas
Re: [whatwg] .tags()
On Mon, 19 Oct 2009, Jonas Sicking wrote: > > I've been meaning to send a formal email on this subject, and with the > recent discussion going on over in the W3C webapps mailing list I > figured now was a good time. > > I'd like to formally request that .tags() is removed from the > HTMLCollection interface. Unless it can be shown that .tags() is needed > for compatibility with the web Mozilla has no plans to implement this > property. Back when we implemented document.all, we judged that there > were enough sites using document.all.tags() to implement the property on > the document.all collection, however we haven't seen any information > indicating that this is needed elsewhere. I've removed it and filed bugs on WebKit and Opera. If the bugs get WONTFIXed, though, then I'd like there to be a spec defining how this should work. > Based on how for example the video codec issue was handled, where part > of the spec was dropped since one major browser vendor indicated that > they would not support a feature, I'd request that the same treatment > was given to .tags(), and thus remove it from the spec. There's a spec for Theora. There's no other spec for tags(). What we removed was the (quite unusual) requirement that implementors of one spec (HTML) implement another (Theora), not the actual definition of how the feature should work (the Theora spec still exists). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] .tags()
On Mon, Oct 19, 2009 at 5:01 PM, Boris Zbarsky wrote: > On 10/19/09 6:30 PM, Jonas Sicking wrote: >> >> In particular I'm wondering what made other vendors decide to >> support this. > > I'd already asked this on this list, back in July. The relevant answers > (from the "[whatwg] .tags on HTMLCollections" thread): > > On Tue, 14 Jul 2009, Maciej Stachowiak wrote: >>> >>> Support for HTMLCollection.tags() in WebKit predates the fork from >>> KHTML. So we don't know why it was originally added. > > On Tue, 14 Jul 2009, Maciej Stachowiak wrote: >>> >>> I don't know of a reason it's needed for collections other than >>> document.all. But it also doesn't seem harmful and I can't say >>> definitively whether it helps anything. I wouldn't object to >>> removing it from the spec, but we probably wouldn't remove it from >>> WebKit short of evidence that it's actually harmful. >>> >>> Perhaps Opera people can shed more light on the matter. > > On Thu, 23 Jul 2009, Anne van Kesteren wrote: >>> >>> From what I heard so far it is there because of document.all. If >>> document.all does indeed need to return a separate object as HTML5 >>> suggests we can probably remove it from HTMLCollection in due >>> course. If that's all the data we have, then I really don't see .tags() getting implemented in Firefox. / Jonas
Re: [whatwg] .tags()
On 10/19/09 6:30 PM, Jonas Sicking wrote: In particular I'm wondering what made other vendors decide to support this. I'd already asked this on this list, back in July. The relevant answers (from the "[whatwg] .tags on HTMLCollections" thread): On Tue, 14 Jul 2009, Maciej Stachowiak wrote: Support for HTMLCollection.tags() in WebKit predates the fork from KHTML. So we don't know why it was originally added. On Tue, 14 Jul 2009, Maciej Stachowiak wrote: I don't know of a reason it's needed for collections other than document.all. But it also doesn't seem harmful and I can't say definitively whether it helps anything. I wouldn't object to removing it from the spec, but we probably wouldn't remove it from WebKit short of evidence that it's actually harmful. Perhaps Opera people can shed more light on the matter. On Thu, 23 Jul 2009, Anne van Kesteren wrote: From what I heard so far it is there because of document.all. If document.all does indeed need to return a separate object as HTML5 suggests we can probably remove it from HTMLCollection in due course. -Boris
[whatwg] .tags()
Hi All, I've been meaning to send a formal email on this subject, and with the recent discussion going on over in the W3C webapps mailing list I figured now was a good time. I'd like to formally request that .tags() is removed from the HTMLCollection interface. Unless it can be shown that .tags() is needed for compatibility with the web Mozilla has no plans to implement this property. Back when we implemented document.all, we judged that there were enough sites using document.all.tags() to implement the property on the document.all collection, however we haven't seen any information indicating that this is needed elsewhere. Based on how for example the video codec issue was handled, where part of the spec was dropped since one major browser vendor indicated that they would not support a feature, I'd request that the same treatment was given to .tags(), and thus remove it from the spec. Of course, if someone has data indicating that .tags() is indeed needed to be compatible with the web, we'd reevaluate at mozilla. In particular I'm wondering what made other vendors decide to support this. Especially if these vendors strongly feel that .tags() should remain the the spec. / Jonas
Re: [whatwg] .tags on HTMLCollections
On Fri, 14 Aug 2009, Jonas Sicking wrote: > On Fri, Aug 14, 2009 at 3:35 AM, Ian Hickson 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 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 , i.e. we have some sort of data > on that it's actually a used feature. Is that not the case? 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. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] .tags on HTMLCollections
On Fri, Aug 14, 2009 at 12:02 PM, Jonas Sicking wrote:
> On Fri, Aug 14, 2009 at 3:35 AM, Ian Hickson 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 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 , 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
Re: [whatwg] .tags on HTMLCollections
On Fri, Aug 14, 2009 at 3:35 AM, Ian Hickson 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 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 , 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
Re: [whatwg] .tags on HTMLCollections
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 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. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] .tags on HTMLCollections
On Tue, Jul 28, 2009 at 2:48 PM, Ian Hickson wrote: > On Mon, 13 Jul 2009, Boris Zbarsky wrote: >> >> Ian just pointed out to me that his current draft requires >> HTMLCollections to implement a tags() method (which seems to do a filter >> by tagName on the contents of the collection). >> >> As far as I can tell, IE, Webkit, and Opera implement this; Gecko does >> not. I was wondering whether any of the Webkit or Opera folks could >> comment on _why_ they implement this? I haven't seen any uses of this >> in the wild (outside document.all.tags, but document.all doesn't behave >> like a normal HTMLCollection in all sorts of other ways either). >> >> I'd rather be specifying (and implementing) a smaller DOM API, if that's >> all that's needed for actual web compat > > On Tue, 14 Jul 2009, Maciej Stachowiak wrote: >> >> Support for HTMLCollection.tags() in WebKit predates the fork from >> KHTML. So we don't know why it was originally added. > > On Tue, 14 Jul 2009, Boris Zbarsky wrote: >> >> I guess the other question is whether you feel it's worth keeping... > > On Tue, 14 Jul 2009, Maciej Stachowiak wrote: >> >> I don't know of a reason it's needed for collections other than >> document.all. But it also doesn't seem harmful and I can't say >> definitively whether it helps anything. I wouldn't object to removing it >> from the spec, but we probably wouldn't remove it from WebKit short of >> evidence that it's actually harmful. >> >> Perhaps Opera people can shed more light on the matter. > > On Thu, 23 Jul 2009, Anne van Kesteren wrote: >> >> From what I heard so far it is there because of document.all. If >> document.all does indeed need to return a separate object as HTML5 >> suggests we can probably remove it from HTMLCollection in due course. > > 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. / Jonas
Re: [whatwg] .tags on HTMLCollections
On Mon, 13 Jul 2009, Boris Zbarsky wrote: > > Ian just pointed out to me that his current draft requires > HTMLCollections to implement a tags() method (which seems to do a filter > by tagName on the contents of the collection). > > As far as I can tell, IE, Webkit, and Opera implement this; Gecko does > not. I was wondering whether any of the Webkit or Opera folks could > comment on _why_ they implement this? I haven't seen any uses of this > in the wild (outside document.all.tags, but document.all doesn't behave > like a normal HTMLCollection in all sorts of other ways either). > > I'd rather be specifying (and implementing) a smaller DOM API, if that's > all that's needed for actual web compat On Tue, 14 Jul 2009, Maciej Stachowiak wrote: > > Support for HTMLCollection.tags() in WebKit predates the fork from > KHTML. So we don't know why it was originally added. On Tue, 14 Jul 2009, Boris Zbarsky wrote: > > I guess the other question is whether you feel it's worth keeping... On Tue, 14 Jul 2009, Maciej Stachowiak wrote: > > I don't know of a reason it's needed for collections other than > document.all. But it also doesn't seem harmful and I can't say > definitively whether it helps anything. I wouldn't object to removing it > from the spec, but we probably wouldn't remove it from WebKit short of > evidence that it's actually harmful. > > Perhaps Opera people can shed more light on the matter. On Thu, 23 Jul 2009, Anne van Kesteren wrote: > > From what I heard so far it is there because of document.all. If > document.all does indeed need to return a separate object as HTML5 > suggests we can probably remove it from HTMLCollection in due course. 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. On Thu, 23 Jul 2009, Boris Zbarsky wrote: > > Given that the namedItem behavior of document.all is different from the > namedItem behavior of HTMLCollection, I don't see how document.all could > possibly be a general HTMLCollection On Fri, 24 Jul 2009, Anne van Kesteren wrote: > > They are indeed distinct, but do share the same interface name in Opera > the moment, as far as I can tell... In any case, my point was that we'd > be ok with removing the tags member from HTMLCollection in due course. On Fri, 24 Jul 2009, Boris Zbarsky wrote: > > Oh, the _name_ is shared in Gecko too. Just not anything else. ;) Right now the HTML5 spec calls the document.all HTMLCollection "HTMLAllCollection", since I have no way to override the name, and I can't have two names the same. I'm not sure what the prototype of document.all is if it's not the same as document.images... in fact this whole area is quite confusing to me. So I haven't done any the confusingness and just made them distinct. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] .tags on HTMLCollections
Anne van Kesteren wrote: They are indeed distinct, but do share the same interface name in Opera the moment, as far as I can tell... Oh, the _name_ is shared in Gecko too. Just not anything else. ;) In any case, my point was that we'd be ok with removing the tags member from HTMLCollection in due course. Indeed, and thank you for the response! -Boris
Re: [whatwg] .tags on HTMLCollections
On Fri, 24 Jul 2009 04:56:15 +0200, Boris Zbarsky wrote: > Anne van Kesteren wrote: >> From what I heard so far it is there because of document.all. If >> document.all does indeed need to return a separate object as HTML5 >> suggests we can probably remove it from HTMLCollection in due course. > > Given that the namedItem behavior of document.all is different from the > namedItem behavior of HTMLCollection, I don't see how document.all could > possibly be a general HTMLCollection They are indeed distinct, but do share the same interface name in Opera the moment, as far as I can tell... In any case, my point was that we'd be ok with removing the tags member from HTMLCollection in due course. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] .tags on HTMLCollections
Anne van Kesteren wrote: From what I heard so far it is there because of document.all. If document.all does indeed need to return a separate object as HTML5 suggests we can probably remove it from HTMLCollection in due course. Given that the namedItem behavior of document.all is different from the namedItem behavior of HTMLCollection, I don't see how document.all could possibly be a general HTMLCollection -Boris
Re: [whatwg] .tags on HTMLCollections
On Tue, 14 Jul 2009 11:58:30 +0200, Maciej Stachowiak wrote: > I don't know of a reason it's needed for collections other than > document.all. But it also doesn't seem harmful and I can't say > definitively whether it helps anything. I wouldn't object to removing it > from the spec, but we probably wouldn't remove it from WebKit short of > evidence that it's actually harmful. > > Perhaps Opera people can shed more light on the matter. >From what I heard so far it is there because of document.all. If document.all >does indeed need to return a separate object as HTML5 suggests we can probably >remove it from HTMLCollection in due course. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] .tags on HTMLCollections
On Jul 14, 2009, at 2:50 AM, Boris Zbarsky wrote: Maciej Stachowiak wrote: Support for HTMLCollection.tags() in WebKit predates the fork from KHTML. So we don't know why it was originally added. I guess the other question is whether you feel it's worth keeping... I don't know of a reason it's needed for collections other than document.all. But it also doesn't seem harmful and I can't say definitively whether it helps anything. I wouldn't object to removing it from the spec, but we probably wouldn't remove it from WebKit short of evidence that it's actually harmful. Perhaps Opera people can shed more light on the matter. Regards, Maciej
Re: [whatwg] .tags on HTMLCollections
Maciej Stachowiak wrote: Support for HTMLCollection.tags() in WebKit predates the fork from KHTML. So we don't know why it was originally added. I guess the other question is whether you feel it's worth keeping... -Boris
Re: [whatwg] .tags on HTMLCollections
On Jul 13, 2009, at 11:55 PM, Boris Zbarsky wrote: Ian just pointed out to me that his current draft requires HTMLCollections to implement a tags() method (which seems to do a filter by tagName on the contents of the collection). As far as I can tell, IE, Webkit, and Opera implement this; Gecko does not. I was wondering whether any of the Webkit or Opera folks could comment on _why_ they implement this? I haven't seen any uses of this in the wild (outside document.all.tags, but document.all doesn't behave like a normal HTMLCollection in all sorts of other ways either). I'd rather be specifying (and implementing) a smaller DOM API, if that's all that's needed for actual web compat Support for HTMLCollection.tags() in WebKit predates the fork from KHTML. So we don't know why it was originally added. Regards, Maciej
[whatwg] .tags on HTMLCollections
Ian just pointed out to me that his current draft requires HTMLCollections to implement a tags() method (which seems to do a filter by tagName on the contents of the collection). As far as I can tell, IE, Webkit, and Opera implement this; Gecko does not. I was wondering whether any of the Webkit or Opera folks could comment on _why_ they implement this? I haven't seen any uses of this in the wild (outside document.all.tags, but document.all doesn't behave like a normal HTMLCollection in all sorts of other ways either). I'd rather be specifying (and implementing) a smaller DOM API, if that's all that's needed for actual web compat -Boris
