Re: setRequestHeader underspecified - setting Accept header as an example
On Tue, 18 Nov 2008 13:50:36 +0100, Hallvord R. M. Steen
hallv...@opera.com wrote:
I've found a site that requires that any UA default value is overridden
with the new value when using setRequestHeader('Accept', ..).
(For reference: the site is mail.163.com, it uses XHR extensively to
fetch data and sets Accept header to text/javascript to fetch JSON
content. If that value is appended to the UA's internal list instead of
replacing it the server returns XML instead of JSON, which doesn't go
down well with the JSON parsing - i.e. eval() - they put the data
through.)
The spec says about setRequestHeader():
If the header argument is in the list of request headers either use
multiple headers, combine the values or use a combination of those
(section 4.2, RFC 2616).
I think this needs to be way more specific. We probably need to verify
what existing UAs do for actual header values, and make some sensible
rules from that.
It also says that UAs should have an Accept header of */* when they supply
one. Does the server still give XML back in that scenario?
--
Anne van Kesteren
http://annevankesteren.nl/
http://www.opera.com/
Use cases for Selectors-API
As for the subject, I was wondering what are the use cases for Selectors API. Yes, author desperately need a way to get element that match some constraint inside a document (ie all tables or all p span.urgent elements). But they already have a language to implemented this: XML Path Language + DOM3 XPath. Advantages of XMLPath vs Selectors: - you can use namespaces (you can in selectors too, but not in selectors api) - you can return non-node values (ie. the element.matchesSelector equivalent), either ordered or unordered (possibly faster) node iterators - you can extend syntax by adding new functions in different namespace (this is required to support UI pseudo-classes, and actually there are no facilities to do this) - once XMLPath model is implemented, also XQuery is easily implemented and XQuery features are incredible: what about reordering a table without using HTML5 datalist or java applet? or finding a row in that table based on user input, without using ctrl+f? - XMLPath and DOM3 XPath actually are implemented: even FF2 supports document.evaluate, instead selectors api are included only in the very latest browser (Opera 10 and FF3.1 AFAIK) Disadvantages of XMLPath vs Selectors: - authors must learn a new language - authors must use XML For the first issue, I simply answer that many authors don't know the latest Selectors lev 3 features either and anyway they have to learn the Selectors-API (yes, they're not difficult, but until they're widely deployed, the only mean to learn about them are W3C specs, and authors sometimes don't even know about W3C) For the second, it would be useful if HTML5 included a way to build an XML Information Set from a text/html resource. DOM3XPath for example normatively defines bindings between Information Set elements and DOM interfaces, so that from any successfully built DOM it is possible to have an XML Infoset. I'm very curious about what your answer will look like (it seems to me that I discovered hot water) Giovanni
Re: Use cases for Selectors-API
On Fri, Dec 26, 2008 at 10:26 PM, Giovanni Campagna scampa.giova...@gmail.com wrote: As for the subject, I was wondering what are the use cases for Selectors API. Yes, author desperately need a way to get element that match some constraint inside a document (ie all tables or all p span.urgent elements). But they already have a language to implemented this: XML Path Language + DOM3 XPath. Advantages of XMLPath vs Selectors: - you can use namespaces (you can in selectors too, but not in selectors api) - you can return non-node values (ie. the element.matchesSelector equivalent), either ordered or unordered (possibly faster) node iterators - you can extend syntax by adding new functions in different namespace (this is required to support UI pseudo-classes, and actually there are no facilities to do this) - once XMLPath model is implemented, also XQuery is easily implemented and XQuery features are incredible: what about reordering a table without using HTML5 datalist or java applet? or finding a row in that table based on user input, without using ctrl+f? - XMLPath and DOM3 XPath actually are implemented: even FF2 supports document.evaluate, instead selectors api are included only in the very latest browser (Opera 10 and FF3.1 AFAIK) Disadvantages of XMLPath vs Selectors: - authors must learn a new language - authors must use XML For the first issue, I simply answer that many authors don't know the latest Selectors lev 3 features either and anyway they have to learn the Selectors-API (yes, they're not difficult, but until they're widely deployed, the only mean to learn about them are W3C specs, and authors sometimes don't even know about W3C) For the second, it would be useful if HTML5 included a way to build an XML Information Set from a text/html resource. DOM3XPath for example normatively defines bindings between Information Set elements and DOM interfaces, so that from any successfully built DOM it is possible to have an XML Infoset. A few comments: * XPath works mostly fine on HTML already, firefox supports it. The only things that weren't defined by specs were a few things related to case sensitivity. * The fact that XPath can return non-nodeset values is totally unrelated to implementing a element.matchesSelector type API. What it means is that you can return things like numbers and strings, i.e. you can return the number of p children inside the body multiplied by the value in the 'hello' attribute of the first meta element. * Related, XPath *can't* in fact be used to implement element.matchesSelector. At least not without incredible performance costs. The problem is that the full XPath language is actually too powerful. Something like myElement.matchesXPath(id(node())) would require walking the entire DOM and checking if the XPath value of the node is the same as the ID of myElement. This can get arbitrarily complicated such as myElement.matchesXPath(id(concat(., @*[3], ..))) which would essentially require evaluating the full expression with each node (including each namespace and attribute node) in the document as the context node. When XPath was developed, which happened alongside with XSLT, this exact problem was actually run into. The solution was that XSLT defines a similar, but distinct, language called 'patterns'[1] used in situations when you need to match a node against an expression. (In firefox the code for patterns is largely separate from the code for XPath) * Minor nit: It's called XPath, not XMLPath. [1] http://www.w3.org/TR/xslt#patterns / Jonas
[DOM2 Range] bug in example to handle insertions
Found an issue in DOM2 Range that doesn't seem to be addressed anywhere that I could find: Section 2.12.1 (handling insertions) says that the boundary point offset should only be adjusted if the insertion point's offset is strictly less than it. However, the first example they give doesn't do this. In the example the start boundary point and insertion point both have an offset of 10 and they adjust the offset anyway, so that inserted text stays out of the range. Opera and Firefox both do what the text says and so inserted text ends up in the range (Webkit doesn't seem to handle this very well, it doesn't update anything so the range ends up selecting inserted ). I agree with Opera/FF's behavior, so I think the example should be corrected to include the inserted text. Cheers, kats
Re: Use cases for Selectors-API
Giovanni Campagna wrote: - XMLPath and DOM3 XPath actually are implemented: even FF2 supports document.evaluate, instead selectors api are included only in the very latest browser (Opera 10 and FF3.1 AFAIK) And Safari and IE8. But yes, the point that XPath is already supported as a selection mechanism is correct (though I can't recall what the status is across all browsers). In fact, various JS toolkits use it right now. Disadvantages of XMLPath vs Selectors: - authors must learn a new language - authors must use XML You forgot: - Selectors is designed to be fast to match, while XPath had no such design criterion; as a result it's very easy to write pathologically slow XPath queries, even by accident. For non-pathological cases, Selectors are still faster, whether because of spec design choices or because browsers already heavily optimize selector matching. For example, see http://ejohn.org/blog/queryselectorall-in-firefox-31/ for some performance data. The old API section is toolkits using whatever they had on hand before querySelector came along, including XPath. At least Prototype and Dojo do in fact use XPath if possible: those would be the first and third bar on the graph. For the first issue, I simply answer that many authors don't know the latest Selectors lev 3 features either While this may be true, the initial uptake for this feature is expected to be by toolkits, not authors directly. And you don't need to learn the Selectors Level 3 stuff to use this API, of course. (yes, they're not difficult, but until they're widely deployed, the only mean to learn about them are W3C specs, and authors sometimes don't even know about W3C) I don't see how any APIs here would make a difference to this last class of authors, unless you expect them to read tutorials or whatnot And in that case, you're back to people not learning from the specs. For the second, it would be useful if HTML5 included a way to build an XML Information Set from a text/html resource. DOM3XPath for example normatively defines bindings between Information Set elements and DOM interfaces, so that from any successfully built DOM it is possible to have an XML Infoset. That seems like it would be better suited to the public-html mailing list, no? I'm very curious about what your answer will look like (it seems to me that I discovered hot water) No, more like repeated the same old arguments yet again. -Boris
