Re: [selectors-api] RfC: LCWD of Selectors API Level 1; deadline July 19
Arthur Barstow art.bars...@nokia.com wrote: This is a Request for Comments for the June 28 Last Call Working Draft of Selectors API Level 1: http://www.w3.org/TR/2012/WD-selectors-api-20120628/ The comment deadline is July 19 and all comments should be sent to the public-webapps@w3.org list with a Subject: prefix of [selectors-api]. Section 1 contains a unwanted duplication: With these methods methods, There is something odd about the way matching is defined: Section 6 defines matching Element node directly in terms of the [SELECT] reference, then section 6.4 defines what it means to evaluate a selector but this is never referenced. I think section 6 needs to define matching Element node as something like: An Element node is a matching Element node if the result of invoking the *evaluate a selector* algorithm with the selector and the Element bnode is true. And then have the matching rules in a separate explanatory sentence in 6.4: Selectors are evaluated against the given element according to the rules for matching elements defined in Selectors [SELECT]. This would seem to be the original intention - the algorithm was added, but then section 6 wasn't updated (it's the same as in the previous CR) Did an edit go missing somewhere? -- Stewart Brodie Team Leader - ANT Galio Browser ANT Software Limited
Re: Use cases for Range::createContextualFragment and script nodes
Henri Sivonen hsivo...@iki.fi wrote: When WebKit or Firefox trunk create an HTML script element node via Range::createContextualFragment, the script has its 'already started' flag set, so the script won't run when inserted into a document. In Opera 10.63 and in Firefox 3.6.x, the script doesn't have the 'already started' flag set, so the script behaves like a script created with document.createElement(script) when inserted into a document. I'd be interested in use cases around createContextualFragment in order to get a better idea of which behavior should be the correct behavior going forward. Does the specification for createContextualFragment say anything about this? -- Stewart Brodie Team Leader - ANT Galio Browser ANT Software Limited
Re: Status of Selectors API Level 1 Candidate
Lachlan Hunt lachlan.h...@lachy.id.au wrote: I believe the test suite is nearly ready [1]. As I mentioned last year, Minefield currently passes 100% of the test suite. However, this has not yet shipped in a release build. I assume it will make it into the next major release after the current 3.6.x branch. The browser used in the BlackBerry 9700 also reportedly passes 100% of the test suite. Opera passes 100% of the baseline test suite. We have failures in the additional tests, which are related to bugs in our Selector implementation. This level of support has shipped in the recent 10.5x builds. WebKit (Safari and Chrome) is still failing 16 of the baseline tests. [1] http://dev.w3.org/2006/webapi/selectors-api-testsuite/ The test suite contains a test that asserts that an exception should be thrown when no arguments are passed to querySelector or querySelectorAll. Why is passing no parameter to querySelector/querySelectorAll expected to throw an exception, whereas passing an undefined value does not? The Selectors API specification mentions explicit undefineds being passed (and says, via Web IDL, that they stringify to undefined) - that's fine, but I cannot find the rules that govern omitted attributes. Presumably Web IDL must say something somewhere that's overridding the default ECMAScript rules on this sort of thing - but where precisely? Taking the null, explicit undefined and implicit undefined test cases together, I don't think I've got any two browsers here that behave the same way. :-/ -- Stewart Brodie Team Leader - ANT Galio Browser ANT Software Limited
Re: Publishing XMLHttpRequest
Anne van Kesteren ann...@opera.com wrote: On Wed, 12 Aug 2009 17:17:09 +0200, Stewart Brodie stewart.bro...@antplc.com wrote: Please could you add an appendix in the latter that summarises what's new in the new version? Is there anything the Abstract does not cover you would like to see mentioned? The Abstract is good for an abstract, but I don't think it's got enough detail in it for a list of differences. I'll review the new documents in closer detail when I get a chance and see if I can suggest some words. I'd like to adopt some of the new features into my implementation too, as time permits, probably starting with things like overrideMimeType that are already widely implemented elsewhere. I believe it is true to say that a conforming user agent as defined by XMLHttpRequest-2 cannot also a conforming user agent as defined by XMLHttpRequest (not least because the introduction of CORS overrides the requirement to throw SECURITY_ERR at various points). Yeah. I thought of changing the original XMLHttpRequest to match this new reality, but was not sure whether it is worth it. Probably not. It's kind of weird to be able to modify both versions of the specification at once! What is the recommended way for code to discover to which version of the specification an implementation conforms? I rather not recommend a particular strategy as I'm sure users of the API are much more skilled in dealing with issues such as this one. OK, thanks. -- Stewart Brodie Software Engineer ANT Software Limited
Re: [selectors-api] Liveness versus NodeList
Lachlan Hunt [EMAIL PROTECTED] wrote: Gavin Kistner wrote: DOM Level 2 Core and DOM Level 3 Core both say: The NodeList interface provides the abstraction of an ordered collection of nodes, without defining or constraining how this collection is implemented. NodeList objects in the DOM are live. [1] [2] NodeList and NamedNodeMap objects in the DOM are live; that is, changes to the underlying document structure are reflected in all relevant NodeList and NamedNodeMap objects. For example, if a DOM user gets a NodeList object containing the children of an Element, then subsequently adds more children to that element (or removes children, or modifies them), those changes are automatically reflected in the NodeList, without further action on the user's part. Likewise, changes to a Node in the tree are reflected in all references to that Node in NodeListand NamedNodeMap objects. [3] [4] This is considered to be a bug in the DOM Core specs, which will hopefully be fixed by Web DOM Core, which is a proposal Simon Pieters is working on. You will still need a new type, as I don't see how you can possibly change the existing behaviour so dramatically under the feet of existing content. I would not like to lose the liveness property of node lists, as it would make NodeList objects incredibly memory inefficient if we had to construct the entire node list at NodeList construction time, too. -- Stewart Brodie Software Engineer ANT Software Limited
Re: Call for Consensus - Selectors Last Call
Lachlan Hunt [EMAIL PROTECTED] wrote: Stewart Brodie wrote: [a few issues snipped] [see http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0216.html ] Thank you. I'd be pleased to see this document progress to LC. -- Stewart Brodie Software Engineer ANT Software Limited
Re: Call for Consensus - Selectors Last Call
Kartikaya Gupta [EMAIL PROTECTED] wrote:
On Fri, 31 Oct 2008 16:06:23 +0100, Charles McCathieNevile
[EMAIL PROTECTED] wrote:
So this is a call for Consensus to publish the Editor's Draft [1] of the
Selectors API spec as a Last Call. Please respond before Monday November
10. As always, silence is taken as assent but an explicit response is
preferred.
Opera supports publication of this draft as a Last Call.
[1] http://dev.w3.org/2006/webapi/selectors-api/
[2]
http://dev.w3.org/2006/webapi/selectors-api/disposition-of-comments.html
Is it just me or is the scope element somewhat under-defined in the
spec? The only mentions of it are in this sentence:
If the context node is a Document node, then the scope element is the
documentElement of the given document. If the context node is an Element
node, then the scope element is the same as the context node.
However, it doesn't say what the scope element does or why it's relevant,
nor does it have a reference to any other spec that explains this. I did a
quick search through the list archives (I haven't been following it too
closely) and it looks like the :scope pseudo-class will be defined in
another spec. I think that should be clarified, because otherwise it just
looks like a completely random sentence that would be better taken out
altogether.
I concur.
I've just read the spec through the start to finish for the first time in
many months, prompted by these announcements, and came up with a number of
questions. Then I've read through all the articles in the disposition of
comments, and found that the same issues have already been raised and
discussed at length, but it seems that in some cases, no changes or
clarifications have been made to the document in response. Perhaps the
meaning of the spec is obvious to those who have been actively working on
the document who know what assumptions to make, but they aren't clear to me.
I really think that the spec needs to nail down the answers to these
questions - just a simple sentence (or non-normative example) will do.
The specific questions I had (which I think I found the definitive answers
for in the mail archives):
1) What is the scope element for - it's only mentioned in one sentence?
2) Is an empty string actually a valid selector? If not, then the whole
null/undefined is an empty string discussion is irrelevant - it's simply a
syntax error.
3) Does the matching algorithm work on based on the entire tree that
contains the context node or just the sub-tree rooted at the context node? I
think this is easiest fixed by adding an example like the one in the
previous e-mail that I'm quoting and stating the expected result:
Also, since the scope element stuff was deferred to another spec, this
spec remains somewhat ambiguous (at least to me) about exactly what gets
selected in the following case:
html
body
div class=bar
div id=foo
div class=baz/div
/div
/div
/body
/html
document.getElementById('foo').querySelector('.bar .baz')
I believe the above querySelector call should return the baz div as
opposed to NULL, but it took me a few close readings of the spec to decide
on that. A clarifying example in the spec would be quite helpful on this
one.
After trawling through the comments, I also think that the answer is that it
works on the entire tree, and consequently the baz div should be the one and
only result.
--
Stewart Brodie
Software Engineer
ANT Software Limited
Re: Proposal: High resolution (and otherwise improved) timer API
Maciej Stachowiak [EMAIL PROTECTED] wrote: On Oct 3, 2008, at 2:11 PM, Robert Sayre wrote: On Thu, Oct 2, 2008 at 11:43 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: A number of WebKit developers (including from the Chrome team and the Safari team) have been discussing ideas for a new and improved timer API. We would like to serve the following use cases which we feel are not well served by the de facto standard (and now HTML5 standard) interfaces of setTimeout and setInterval: I don't see anything in the HTML5 document that requires the 10-15.6ms delay. Is HTML5 going to add that as a conformance requirement? I don't know. I would recommend to the HTML5 editor to require some reasonable minimum because it seems to be de facto required for Web compatibility. I cannot state with certainty that nothing lower than 10ms is safe. Chrome shipped with a 1ms delay and that was found to create problems on a number of sites, including nytimes. They are planning to try 4ms next. We would consider using a lower limit in the official webkit.org version of WebKit, not not as low as 1ms. Isn't the problem more that it'll depend on the code being run on the timer and whether the UA's hardware can cope with running everything fast enough? We've had trouble with some sites on slow boxes because their interval timers are constantly wanting to fire before the page has finished reacting to the previous timer fire. Our solution has also been to enforce a minimum frequency for interval timers just to give a fighting chance for the site to work at all (and to not allow the timer to fire again whilst the previous instance is still executing) -- Stewart Brodie Software Engineer ANT Software Limited
Re: Support for compression in XHR?
Jonas Sicking [EMAIL PROTECTED] wrote: This at the cost of the overhead of always making an OPTIONS request before attempting compression. Only if you haven't seen the server before - and in the vast majority of cases, you will have. I wouldn't suggest sending it every time, because that would be clearly daft. Typically, HTTP clients need to maintain notes on servers if they want to work optimally with them anyway. Whether the server supports compression via gzip and/or deflate would just be another bit of information that the client could collect. -- Stewart Brodie
Re: Support for compression in XHR?
Dominique Hazael-Massieux [EMAIL PROTECTED] wrote: Le mardi 09 septembre 2008 à 09:02 -0400, Boris Zbarsky a écrit : HTTP has Content-Encoding and Transfer-Encoding, no? No special effort on the part of XMLHttpRequest is needed to make use of those, as long as the underlying HTTP implementation supports them. Well, at least when an outgoing XmlHttpRequest goes with a body, the spec could require that upon setting the Content-Encoding header to gzip or deflate, that the body be adequately transformed. Or is there another e.g. to POST a gzip request with Content-Encoding? I disagree with any proposal that allows the application layer to forcibly interfere with the transports layer's internal workings. Use of encodings, persistent connections, on-the-fly compression are entirely internal to the transport mechanism. If you want to allow hints that the UA can ignore, that's fine - but require is silly - it might make the data larger, for all you know. Leave it as a QoI issue for the user agent to sort this out for itself. -- Stewart Brodie
