[Bug 14214] missing definition of Transferable
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14214 Glenn Adams gl...@skynav.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | --- Comment #3 from Glenn Adams gl...@skynav.com 2011-10-21 06:51:16 UTC --- I would like to see an either a link from the use of Transferable to the definition in HTML5 or an explicit mention of Transferable as a dependent type defined in HTML5. In particular, under 2.1 Dependencies, there is the text: HTML Many fundamental concepts from HTML are used by this specification. [HTML] I wish to make certain that every normatively fundamental concept (including types) that are defined in HTML5 and used by this specification are either explicitly linked or are enumerated under 2.1 Dependencies. I would suggest that linking would be preferable to enumerating. G. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: QSA, the problem with :scope, and naming
On Thu, Oct 20, 2011 at 2:33 PM, Lachlan Hunt lachlan.h...@lachy.id.au
wrote:
Not necessarily. It depends what exactly it means for a selector to
contain
:scope for determining whether or not to enable the implied :scope
behaviour. Consider:
foo.find(:not(:scope));
Ooh, this is an interesting case too. So here's the full list of cases which
we need defined behavior for (again looking at Alex and Yehuda here).
In the following DOM
body id=3
div id=0/div
div id=context foo=bar
div id=1/div
div class=class id=2/div
div class=withChildren id=3div class=child id=4/div/div
/div
div id=5/div
div id=6/div
/body
What would each of the following .findAll calls return. I've included my
guessed based on the discussions so far:
var e = document.getElementById('context');
e.findAll(div) // returns ids 1,2,3,4
e.findAll() // returns an empty list
e.findAll(#3) // returns id 3, but not the body node
e.findAll( div) // returns ids 1,2,3
e.findAll([foo=bar]) // returns nothing
e.findAll([id=1]) // returns id 1
e.findAll(:first-child) // returns id 1
e.findAll(+ div) // returns id 5
e.findAll(~ div) // returns id 5, 6
e.findAll(:scope)
e.findAll(div:scope)
e.findAll([foo=bar]:scope)
e.findAll(:scope div)
e.findAll(div:scope div)
e.findAll(div:scope #3)
e.findAll(body :scope div)
e.findAll(div, :scope)
e.findAll(body :scope div, :scope)
e.findAll(:not(:scope))
/ Jonas
[selectors-api] Requirements and Use Cases for Scoped Methods
Hi, Based on the ongoing discussion, I've put together the following list of requirements and sumarised use cases that should be met by the design of new features in selectors API. *Use Cases* 1. Select elements that are descendants of specific Element node, where all elements matched by the chain of selectors are all descendants of that element. section h1A/h1 div id=foo h1B/h1 section h1C/h1 /section /div section h1D/h1 /section /section e.g. JQuery $(#foo).find(section h1) This should find heading C only. 2. Select elements that is a child of a specific Element node. e.g. $(#foo).find(h1) 3. Select elements that are siblings (adjacent + or general ~) of a specific Element node. e.g. $(#foo).find(+section h1) $(#foo).find(~section h1) 4. Select elements relative to a specific Element node, conditionally based on it's own state. e.g. (Pseudo code) if Element foo has class name X, Select descendant elements matching input[type=radio] Otherwise, if Element foo has class name Y Select descendant elements matching input[type=checkbox] Alternatively, foo = document.getElementById(foo); inputs = foo.querySelectorAll(.X:scope input[type=radio], .Y:scope input[type=checkbox]); 5. Select elements relative to a specific Element node, conditionally based on the state of an ancestor or previous sibling element. e.g. (Pseudo code) if ancestor Element section has class name X, Select descendant elements matching input[type=radio] Otherwise, if ancestor Element section has class name Y Select descendant elements matching input[type=checkbox] foo = document.getElementById(foo); inputs = foo.querySelectorAll(section.X :scope input[type=radio], section.Y :scope input[type=checkbox]); *General* * Method names should be short, memorable and easy to type. - querySelectorAll is considered too long by authors. * Methods should prioritise optimisations for the common cases over full flexibility. Less common and more complex cases can be handled by existing methods. - Use cases 4 and 5 may be left to existing methods, depending on complexity they introduce and the impact upon potential optimisations. i.e. The cost vs. benefit of supporting them in new methods. * Optimisations should consider both authors and implementations *Implicit Scoping* * In the common case, when called on an element, selectors should be scoped relative to the context element * In the common case when called on the document, it either: - Search the whole document, or - Be scoped relative to a collection of reference elements * Support matching descendants, next siblings and their descendants * Should avoid matching ancestors or previous siblings - (See reference combinator issue below) *Syntax* * Should not require authors to explicitly use :scope, at least when it occurs at the beginning. * Selectors should be able to begin with combinators, :scope should be implied at the beginning. *Return Value* * Methods should return either a single Element node and/or an collection of elements * A collection of Elements should be - Mutable - Static, not live - Support all, or at least some, methods from Array. Need to determine which functionality is most important. - JS Libraries use Array.slice hack to convert a NodeList to an Array. This is a sub-optimal solution. *Implementation Optimisations* * It should be possible to, at least in the common cases, to limit the set of potential matches to a subset of the document. - This reduces the number of comparisons that need to be done and thus time to compute the result. * Ideally, it should be possible to determine heuristically from the Selector whether the impelemntation needs to check: - Only context element's descendants (descendant or child combinators) - Only context element's siblings (sibling combinators) - Both Issue: What should happen with the new reference combinator? label.find(/for/ input); div.find(label /for/ input) div.find(label /for/ input + span) * What would authors expect the result to be? * Should these search: - The whole document (or whole tree, if disconnected from document)? - Only descendants? - Only descendants and siblings? - Other subset of the document? * How does each option affect performance? * Are there any possible optimisations for these cases? e.g. label for=fooLabel/label input type=text name=a id=foo input type=text name=b id=foo label /for/ input matches both inputs, just like #foo Note: If you have anything to add, please do so. I'll be on holiday and mostly offline for the next 3 weeks. I'll review any additional discussion and attempt to draft up a possible solution in the spec after I get back from holidays. -- Lachlan Hunt - Opera Software http://lachy.id.au/
[Bug 14530] New: Hi, In Server-Sent Events Section Processing model, it should be clearly stated how to avoid the pipelining of HTTP requests on the connection used for an event source. HTTP pipel
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14530 Summary: Hi, In Server-Sent Events Section Processing model, it should be clearly stated how to avoid the pipelining of HTTP requests on the connection used for an event source. HTTP pipelining - decribed in RFC 2616 / section 8.1.2.2 - is the possibility for a Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#top OS/Version: other Status: NEW Severity: normal Priority: P3 Component: Server-Sent Events (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Specification: http://www.w3.org/TR/eventsource/ Multipage: http://www.whatwg.org/C#top Complete: http://www.whatwg.org/c#top Comment: Hi, In Server-Sent Events Section Processing model, it should be clearly stated how to avoid the pipelining of HTTP requests on the connection used for an event source. HTTP pipelining - decribed in RFC 2616 / section 8.1.2.2 - is the possibility for a user agent to send a new HTTP request on a connection before the HTTP response of the previous request on the same connection is received. On a connection used for server-sent events, pipelining new HTTP requests cause them to hang forever, since the event stream is potentially infinite. I had this issue recently and some images in my web app were never loaded. I see 2 possible solutions for this type of issue (not necessarily exclusive, of course): 1- it should be clearly stated that a user agent shall not use a connection with a pending text/eventstream typed request for pipelining 2- The server should set a Connection: close HTTP header in the event-stream response to prevent any reuse of the same connection by the user agent. This second option solved the issue in my case, but, as I didn't find any guideline on this subject in the current Server-Sent Events draft, I decided to send you this feedback. Hope this can help. Jean-Luc (jean-...@comimos.com) Posted from: 90.32.162.46 User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_2) AppleWebKit/534.51.22 (KHTML, like Gecko) Version/5.1.1 Safari/534.51.22 -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: QSA, the problem with :scope, and naming
On Oct 20, 2011, at 4:34 PM, Tab Atkins Jr. wrote: On Thu, Oct 20, 2011 at 12:09 PM, Jonas Sicking jo...@sicking.cc wrote: Let's do the general discussion about how live and non-live NodeLists should behave in a separate thread. Yes, let's. ^_^ The immediate question here is how should the returned object from .findAll behave? Should it be mutable? Should you be able to insert non-Nodes into it? Should it have all of the functions of Array.prototype or just some subset? Should it have any additional functions? Since .findAll is a new function we have absolutely no constraints as far as how NodeLists behave, we can simply return something that isn't a NodeList. It should absolutely have all the Array functions. I know that I want to be able to slice, append, forEach, map, and reduce the list returned by .find. IMHO, the most useful thing would be to just return an Array of nodes so no further adjustment of the return value is required in selector engines. ~TJ
Re: Proposal for a new Matrix API
On Thu, 20 Oct 2011 16:39:56 +0200, Igor Oliveira
igor.olive...@openbossa.org wrote:
Hello,
Currently CSSMatrix and SVGMatrix has an immutable API. None of the
method calls change the Matrix, instead, it creates a new Matrix with
the changed value. It can be a problem specially when CSSMatrix is
used together with WebGL. [1]
I would suggest that the matrix should not be a host object. Instead is
should be a pure ecmascript object so it can run closer to the metal (be
jitted easily).
I did suggest previously extending array a bit, like
{length: 6, height: 2, width:3, 0. ..., 1: ..., 2: ..., 3: ..., 4: ..., 5:
..., }
which represents a 2x3 matrix. The matrix would not have any kind of side
effects or limitations, possibly being of any arbitrary size, hence usable
not only by graphical APIs, but by any algebra you throw at it.
The methods you suggest, would then be on the prototype, or in the Math
object.
Re: Proposal for a new Matrix API
On 10/21/11 11:28 AM, João Eiras wrote: On Thu, 20 Oct 2011 16:39:56 +0200, Igor Oliveira igor.olive...@openbossa.org wrote: Hello, Currently CSSMatrix and SVGMatrix has an immutable API. None of the method calls change the Matrix, instead, it creates a new Matrix with the changed value. It can be a problem specially when CSSMatrix is used together with WebGL. [1] I would suggest that the matrix should not be a host object. Instead is should be a pure ecmascript object so it can run closer to the metal (be jitted easily). It may still want to be immutable. This has certain benefits when you want to do really high-performance computation; c.f. River Trail. -Boris
Re: Proposal for a new Matrix API
On Fri, Oct 21, 2011 at 11:28 AM, João Eiras jo...@opera.com wrote:
On Thu, 20 Oct 2011 16:39:56 +0200, Igor Oliveira
igor.olive...@openbossa.org wrote:
Hello,
Currently CSSMatrix and SVGMatrix has an immutable API. None of the
method calls change the Matrix, instead, it creates a new Matrix with
the changed value. It can be a problem specially when CSSMatrix is
used together with WebGL. [1]
I would suggest that the matrix should not be a host object. Instead is
should be a pure ecmascript object so it can run closer to the metal (be
jitted easily).
Assuming you mean native object when you refer to pure ecmascript
object, there is no performance benefit, JIT or otherwise. In fact, it's
possible to implement ES functionality with better performance then the
native implementations.
I did suggest previously extending array a bit, like
{length: 6, height: 2, width:3, 0. ..., 1: ..., 2: ..., 3: ..., 4: ..., 5:
..., }
which represents a 2x3 matrix. The matrix would not have any kind of side
effects or limitations, possibly being of any arbitrary size, hence usable
not only by graphical APIs, but by any algebra you throw at it.
The methods you suggest, would then be on the prototype, or in the Math
object.
Re: [XHR2] Streamed send or receive
Thanks for the information! My understanding is that browsers have already been delivering streamed responses in chunks (Transfer-Encoding), so it makes a lot of sense to expose such a semantics explicitly through the XHR2 API. Streamed requests are equally important, e.g. for use cases such as voice translation, to allow the server to receive and process POST data in parallel. In short, can we improve the XHR2 API to expose the standard HTTP semantics of sending or receiving chunked request/response data? - Wenbo On Thu, Oct 6, 2011 at 1:43 AM, Henri Sivonen hsivo...@iki.fi wrote: On Thu, Oct 6, 2011 at 10:57 AM, Wenbo Zhu wen...@google.com wrote: I'd like to hear from the WG if the following use cases or issues have been discussed before. 1) When onreadystatechange is invoked as new response data is being received, currently there is no way to clear any buffered responseText (alike) that has already been consumed. The lack of such a capability will force the server to disconnect to avoid memory overflow on the client-side, e.g. when the server is streaming a large volume of text or binary data to the client. This problem has been solved in Firefox Aurora by adding chunked text and chunked ArrayBuffer response types: https://bugzilla.mozilla.org/show_bug.cgi?id=687087 -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: Proposal for a new Matrix API
On 20/10/11 10:39 AM, Igor Oliveira wrote: Currently CSSMatrix and SVGMatrix has an immutable API. None of the method calls change the Matrix, instead, it creates a new Matrix with the changed value. It can be a problem specially when CSSMatrix is used together with WebGL. [1] SVGMatrix is not immutable. You can modify the a, b, ..., f properties. http://www.w3.org/TR/SVG/coords.html#InterfaceSVGMatrix However the methods that perform operations do return new matrices rather than modifying the one the method is called on. We from WebKit are proposing a new Matrix API(simple as possible), see below or [2], where the standard methods change the matrix(in place operations) and additional methods (multipliedBy, scaledBy and so on) create a new Matrix as is done by CSSMatrix and SVGMatrix. The idea is make this class accepted where CSSMatrix and SVGMatrix is used and be the preferred class for all Matrix needs. [3] I agree that unifying CSSMatrix/SVGMatrix is a good idea, if that is possible. Will look at your specific proposal a bit later.
Re: CfC: publish a Candidate Recommendation of DOM 3 Events; deadline October 21
Hi Art, all, On 10/14/2011 09:27 PM, Arthur Barstow wrote: The people working on the D3E spec (namely Jacob, Doug and Olli) propose below that the spec be published as a Candidate Recommendation and this is a CfC to do so: http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html The comment tracking document for the last LCWD is: http://dev.w3.org/2006/webapi/DOM-Level-3-Events/dc.html This CfC satisfies: a) the group's requirement to record the group's decision to request advancement to CR; and b) General Requirements for Advancement on the Recommendation Track as defined in the Process Document: http://www.w3.org/2005/10/Process-20051014/tr.html#transition-reqs The exit criteria has not yet been added to the ED and I request the Editors to please propose the specific criteria in response to this e-mail before the comment deadline. It is my expectation that Microsoft and Mozilla will complete the test suite [TS] they started and they will implement this CR. As such, I assume the exit criteria will include a requirement that at least two independent implementations pass all of the test cases. As with all of our CfCs, positive response is preferred and encouraged and silence will be considered as agreeing with the proposal. The deadline for comments is October 21 and all comments should be sent to www-dom at w3.org. I used to think that the right approach to DOM 3 Events was to get it published as a Recommendation as soon as possible, and start to work on a higher-quality specification when that happened. However, for various reasons, I've changed my mind, and now think that we should make DOM 3 Events a specification of the quality that is now expected from specifications. Furthermore, I believe a lot of good work has been put into specification, and hope we can move forward with it soon. However, *I do object to the publication* of this specification because the inappropriate resolution of the following issues (in no particular order): First (issue 123), it contradicts an uncontested requirement [1] in DOM4 forbidding the minting of new DOM feature strings, as reported by Anne. [2] Second (issue 179), it ignores the consensus about using DOMException instead of custom exception types like EventException, as noted in WebIDL, [3] which I reported. [4] Third (issue 130), the resolution made to add an informative WebIDL appendix is insufficient. Not only did the editors not list any technical reason for this decision in their reply, [5] despite this being required by the Process document. [6] The only claim that I could find in favour of this decision is that WebIDL is not stable. [7] However, WebIDL's second LC has ended (without, as far as I can tell, too many comments), and as such it is as stable as DOM 3 Events itself, and is indeed moving ahead at a rather much faster pace. Furthermore, the DOM 3 Events specification already (stealthily [8]) depends on the HTML specification, which is even less stable than WebIDL. In fact, it is not clear to me what there is to gain by not referencing WebIDL normatively. In reality, browsers will have to ignore the normative IDL code and use the WebIDL instead. In effect, not referencing WebIDL will only make DOM 3 Events *seem* more stable then it actually is. (I note that the specification doesn't actually define which IDL dialect it uses, though the references section lists OMG IDL.) I am ready to reconsider my objection once the issues I mentioned above are fixed. Of course, if the editors would welcome this, I am happy to offer my help in editing the specification. Thanks Ms2ger [1] http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-features [2] http://lists.w3.org/Archives/Public/www-dom/2011JulSep/0107.html [3] http://dev.w3.org/2006/webapi/WebIDL/#idl-exceptions [4] http://lists.w3.org/Archives/Public/www-dom/2011OctDec/0087.html [5] http://lists.w3.org/Archives/Public/www-dom/2011AprJun/0066.html [6] http://www.w3.org/2005/10/Process-20051014/policies.html#formal-address [7] http://lists.w3.org/Archives/Public/www-dom/2011JulSep/0156.html [8] http://lists.w3.org/Archives/Public/www-dom/2011OctDec/0094.html
[Bug 14364] Add an API to make appcache support caching specific URLs dynamically
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14364 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED Resolution||NEEDSINFO --- Comment #3 from Ian 'Hixie' Hickson i...@hixie.ch 2011-10-21 22:43:39 UTC --- Yeah we're definitely not using data: for this. EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Did Not Understand Request Change Description: no spec change Rationale: What are the use cases for making appcache dynamic? (I'm not saying there aren't any, I just need to know what they are to design the solution for them.) -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: QSA, the problem with :scope, and naming
On 20/10/11 12:39 AM, Timmy Willison wrote:
From the perspective of building a selector engine, I think all
selector engines need something like .findAll, and not something like
:scope.
On Tue, Oct 18, 2011 at 8:00 PM, Alex Russell slightly...@google.com
mailto:slightly...@google.com wrote:
No need to wait. We had something nearly identical for this in Dojo
using an ID prefix hack. It looked something like this:
(function(){
var ctr = 0;
query = function(query, root){
root = root||document;
var rootIsDoc = (root.nodeType == 9);
var doc = rootIsDoc ? root :
(root.ownerDocment||document);
if(!rootIsDoc ||
(~+.indexOf(query.charAt(0)) = 0)){
// Generate an ID prefix for the
selector
root.id http://root.id = root.id
http://root.id||(qUnique+(ctr++));
query = #+root.id
http://root.id+ +query;
}
return Array.prototype.slice.call(
doc.querySelectorAll(query)
);
};
})();
This is exactly the same dance that :scope does.
Sizzle and Slick do the same thing. As far as I can tell, nwmatcher
doesn't deal with it. We can't just add :scope to all selections (for
many reasons) and adding just before QSA would require the same logic
that Alex has demonstrated above.
All of the selector engines do predictions at loadtime on whether QSA
will work. They continue differently beyond that, but one thing every
library has in common is a try/catch around the call to QSA that falls
back to manual parsing if it throws an exception (intentionally
avoiding the need for complete parsing before calling QSA). The point
is it is a misconception that selector engines parse selectors before
delegating to QSA. The number of things libraries want to do before
getting to the QSA call is very minimal. The one that hurts us all
the most is this need for scoping and ':scope' would simply never be
used in a selector engine, since the id trick already works
everywhere. The case Alex wrote above is pretty much the only case
where the selector is parsed beyond checking for tag only, id only, or
class only and it is due to what all of the js libraries has
considered a design flaw in QSA. A method like findAll would fix
that, leaving as much parsing as possible in the hands of the browser.
It was definitely not a design flaw in QSA. As Alex's sample code shows
it is possible to get findAll() behavior using QSA. To do the reverse
would involve calling document.findAll() then filtering for nodes that
are descendants of the invoking node.
Clearly JS libs aren't going to switch from implied :scope to explicit
:scope.
But if findAll() is implemented they can advertise that avoiding
non-standard pseudo selectors gives virtually native performance (on
supporting platforms). I imagine this would be almost equivalent to
deprecating them, which would be a win.
PS - I should say I don't necessarily think the name 'findAll' would
work. I agree it should be short. The equivalent of querySelector
would be find and in library land 'find' selects more than one thing,
but I'm not as concerned about the name.
