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
Re: [whatwg]
On Mon, Oct 19, 2009 at 1:10 PM, Markus Ernst wrote: > Aryeh Gregor schrieb: >> But it breaks progressive rendering, which could be extremely >> annoying. The user might give up after a second or two of no >> response, as the (possibly quite long) page is fetched and parsed. > > This is true. So using this as a feature to exclude pages from being > "onlyreplaced" should be discouraged, authors should set onlyreplace to > false (resp. not set the onlyreplace attribute) on the links to those pages. The problem I see here (as an author) is that the attribute *will* accidentally get placed where it shouldn't. From the user's point of view, this dramatically slows down clicking the link (making them annoyed at my site), but in a way that's very difficult for me to notice. It's an X% chance that clicking a given link will be inexplicably slow, at random, if I use this feature. The value of X will vary based on all sorts of things, some possibly beyond my control. It's a risk that would definitely count against the feature if I were deciding whether to use it. In short, accidental misuse should be harmless if possible. For something to be just harmless enough that authors won't notice it, but harmful enough to significantly annoy users, is bad. In some ways even worse than catastrophic failure on misuse, although in most ways better.
[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]
Aryeh Gregor schrieb: On Mon, Oct 19, 2009 at 4:49 AM, Markus Ernst wrote: - If none of the indicated IDs are found, *replace the whole page*. This makes it possible to prevent e.g. a wiki or forum from being @onlyreplaced by just using different IDs. But it breaks progressive rendering, which could be extremely annoying. The user might give up after a second or two of no response, as the (possibly quite long) page is fetched and parsed. This is true. So using this as a feature to exclude pages from being "onlyreplaced" should be discouraged, authors should set onlyreplace to false (resp. not set the onlyreplace attribute) on the links to those pages.
Re: [whatwg]
Tab Atkins Jr. schrieb: On Mon, Oct 19, 2009 at 3:49 AM, Markus Ernst wrote: What do you think about: 1. Defining which ids are to be replaced: - The list of IDs to replace is in tag, as described earlier in this thread. and elements can have a boolean @onlyreplace attribute that specifically enables or disables the functionality for the element. - If at least one of the IDs is found in the linked document, replace the IDs that are found. Ignore IDs that are not present in the linked document, or in the document that contains the link (important for dynamic applications, so the section is not forced to know the state of the ). - If none of the indicated IDs are found, *replace the whole page*. This makes it possible to prevent e.g. a wiki or forum from being @onlyreplaced by just using different IDs. I'm definitely for the last one. As well, if you recieve any response that indicates the resource you've gotten isn't what you asked for (like a 404 status code), also replace the whole page. I am sorry I expressed myself in a misunderstandable way... I did not mean this as alternatives, but as a description of "how it works" from the author/user point of view - what happens if not all IDs mentioned in the onlyreplace list are found either in the page that contains the link, or in the page linked to: - if one or more IDs are found, replace those elements only - if none are found, replace the whole page
Re: [whatwg]
On Mon, Oct 19, 2009 at 4:49 AM, Markus Ernst wrote: > - If none of the indicated IDs are found, *replace the whole page*. This > makes it possible to prevent e.g. a wiki or forum from being @onlyreplaced > by just using different IDs. But it breaks progressive rendering, which could be extremely annoying. The user might give up after a second or two of no response, as the (possibly quite long) page is fetched and parsed.
Re: [whatwg]
On Mon, Oct 19, 2009 at 3:49 AM, Markus Ernst wrote: > What do you think about: > > 1. Defining which ids are to be replaced: > - The list of IDs to replace is in tag, as described earlier in this > thread. and elements can have a boolean @onlyreplace attribute > that specifically enables or disables the functionality for the element. > - If at least one of the IDs is found in the linked document, replace the > IDs that are found. Ignore IDs that are not present in the linked document, > or in the document that contains the link (important for dynamic > applications, so the section is not forced to know the state of the > ). > - If none of the indicated IDs are found, *replace the whole page*. This > makes it possible to prevent e.g. a wiki or forum from being @onlyreplaced > by just using different IDs. I'm definitely for the last one. As well, if you recieve any response that indicates the resource you've gotten isn't what you asked for (like a 404 status code), also replace the whole page. Simple things like a 302 status code that then produces a 200 on the redirected request should obviously be fine. > 2. Possible further additions to the base tag: > - Explicitly exclude parts of a site from @onlyreplace, e.g.: > This doesn't seem necessary if @onlyreplace on links is required to indicate that they carry the onlyreplace semantics. > - Explicitly specify the links that carry the onlyreplace feature: > Similarly this isn't necessary, but it *might* be helpful. I'd be inclined to just keep things simple for now, though. > When we add more attributes to than just href and target, the > sentence "There must be no more than one base element per document." in > 4.2.3 of the spec should maybe be removed, as for every possible attribute > in there will be a note anyway saying "If there are multiple base > elements with [attributename] attributes, all but the first are ignored." Nah, the former sentence is an author conformance requirement. The latter is for UAs. Both are required.
Re: [whatwg]
Tab Atkins Jr. schrieb: On Sun, Oct 18, 2009 at 12:25 PM, Aryeh Gregor wrote: Some attention needs to be given to error handling. What happens if one or more of the requested id's aren't found? Do they silently fail? If so, this could result in the link doing absolutely nothing in hard-to-control situations -- like an error page that occurs sporadically, say a 500. Do they trigger a normal page load? If so, they have to wait until the entire page has loaded, which would be bad user experience but hard to track down -- a long, inexplicable delay followed by everything working normally. This could be mitigated by having an HTTP header to say "that id doesn't exist, load the whole page instead", but it would fail in the default case (standard HTTP server unaware of new feature). Also, what happens if some of the given id's are present, but not others? I'll think a bit about these issues today. I'm not sure, off the top of my head, what the best response is. What do you think about: 1. Defining which ids are to be replaced: - The list of IDs to replace is in tag, as described earlier in this thread. and elements can have a boolean @onlyreplace attribute that specifically enables or disables the functionality for the element. - If at least one of the IDs is found in the linked document, replace the IDs that are found. Ignore IDs that are not present in the linked document, or in the document that contains the link (important for dynamic applications, so the section is not forced to know the state of the ). - If none of the indicated IDs are found, *replace the whole page*. This makes it possible to prevent e.g. a wiki or forum from being @onlyreplaced by just using different IDs. 2. Possible further additions to the base tag: - Explicitly exclude parts of a site from @onlyreplace, e.g.: - Explicitly specify the links that carry the onlyreplace feature: When we add more attributes to than just href and target, the sentence "There must be no more than one base element per document." in 4.2.3 of the spec should maybe be removed, as for every possible attribute in there will be a note anyway saying "If there are multiple base elements with [attributename] attributes, all but the first are ignored."
