date:20111021

Re: CfC: publish a Candidate Recommendation of DOM 3 Events; deadline October 21

2011-10-21 Thread Marcos Caceres



On Friday, 21 October 2011 at 21:42, Ms2ger wrote:

> 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 (http://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.
> 
I also would like to second these objections for the reasons cited above. I'd 
also like to see less overlap between DOM4 and DOM3 Events (and redundancies 
eliminated by, for instance, allowing DOM4 to define the Event interface and 
generic event propagation and behaviour, and DOM3 define other events: e.g., 
mouse, keys, etc.). It's very confusing which document to use right now. So, 
having said that, I would like to see some clarification in DOM3 Events about 
its relationship to DOM4.

Re: [indexeddb] Compound Key support for Primary Keys and Indexes

2011-10-21 Thread Jonas Sicking

On Mon, Sep 12, 2011 at 2:00 PM, Israel Hilerio  wrote:
> On Friday, September 02, 2011 3:33 AM, Hans Wennborg wrote:
>> -Original Message-
>> From: Hans Wennborg [mailto:hwennb...@google.com]
>> Sent: Friday, September 02, 2011 3:33 AM
>> To: Israel Hilerio
>> Cc: public-webapps@w3.org; Jim Wordelman; Dany Joly; Adam
>> Herchenroether; Victor Ngo
>> Subject: Re: [indexeddb] Compound Key support for Primary Keys and
>> Indexes
>>
>> On Tue, Aug 30, 2011 at 9:44 PM, Israel Hilerio 
>> wrote:
>> > Thanks for the feedback.  Answers inline.
>> >
>> > Israel
>> >
>> > On Tuesday, August 30, 2011 9:10 AM, Hans Wennborg wrote:
>> >> On Sat, Aug 27, 2011 at 1:00 AM, Israel Hilerio
>> >> 
>> >> wrote:
>> >> > We looked at the spec to see what it would take to be able to
>> >> > support
>> >> multi-column keys on primary keys & indexes and we found some
>> >> inconsistencies that need to be addressed.  Below is our
>> >> proposal/assumptions on how to constrain the problem and what needs
>> >> to be updated in the spec to support this:
>> >> >
>> >> > . Cursors are automatically sorted in ascending order but they can
>> >> > be
>> >> retrieved in descending order depending on the value passed to the
>> >> IDBObjectStore.createIndex.  In other words, all of the attributes
>> >> that make up the index or the primary key will share the same
>> >> direction.  The default direction will match the single index case.
>> >>
>> >> I'm not sure I'm following. What does "The default direction will
>> >> match the single index case."? And how does the parameters passed to
>> >> IDBObjectStore.createIndex affect the direction of cursors?
>> >
>> > The concern is that compound indexes or keys could have conflicting
>> sorting directions.  For example imagine the following list:
>> >
>> > FirstName1, LastName10
>> > FirstName2, LastName9
>> > FirstName3, LastName8
>> > FirstName4, LastName7
>> >
>> > In this case, property1 is FirstName and property2 is LastName.  If we were
>> to sort using the property1 you will get a different ordered list than if we
>> were to sort using property2.  We're suggesting that we use the first 
>> property
>> in the compound index or key to define the default sort.
>>
>> But http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#key-
>> construct
>> already defines the ordering for all types of keys, including compound ones?
>> So in your example they would be sorted as (FirstName1, LastName10),
>> (FirstName2, LastName9), (FirstName3, LastName8), (FirstName4,
>> LastName7).
>>
>> >> > . KeyRanges will act on the first element of the compound key (i.e.
>> >> > the first
>> >> column).
>> >>
>> >> Why? Compound keys are just another key type; shouldn't one be able
>> >> to specify a KeyRange with compound keys as lower and upper and
>> >> expect it to work as with other keys?
>> >>
>> >
>> > You are correct!  The concern was the complexity this would introduce into
>> the KeyRange mechanism.  In other words, defining the flexibility for a
>> keyRange to be defined and allow each property to be individually
>> parameterized could lead to situations in which one property in compound
>> index can be defined to be ascending while another property could be
>> defined to be descending.  That is the reason we were trying to scope the
>> behavior to the first property in the compound index or key.
>>
>> I still don't understand the problem. The ordering of keys is defined,
>> including for array keys. A key range specifies a range of keys. I don't
>> understand what "situations in which one property in compound index can
>> be defined to be ascending while another property could be defined to be
>> descending" refers to?
>>
>>  - Hans
>
> Thanks for the clarifications.  The point we wanted to ensure was that there 
> was no ability to specify a different sort ordering on compound key paths.  
> If we agree this is not part of the plan then we're okay the way things are 
> in the spec.

Yup. As things stand keys are always sorted in ascending direction in
both indexes and objectStores. And when the key is a compound value,
each component is sorted in ascending direction.

We might want to look into enabling more complex use cases at a later
point, but for now I think we should stick with the current solution.

/ Jonas

Re: QSA, the problem with ":scope", and naming

2011-10-21 Thread Sean Hogan


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 > 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  = root.id
||("qUnique"+(ctr++));
   query = "#"+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.

[Bug 14364] Add an API to make appcache support caching specific URLs dynamically

2011-10-21 Thread bugzilla

http://www.w3.org/Bugs/Public/show_bug.cgi?id=14364

Ian 'Hixie' Hickson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||NEEDSINFO

--- Comment #3 from Ian 'Hixie' Hickson  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: CfC: publish a Candidate Recommendation of DOM 3 Events; deadline October 21

2011-10-21 Thread Ms2ger


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

Re: Proposal for a new Matrix API

2011-10-21 Thread Cameron McCormack


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: [XHR2] Streamed send or receive

2011-10-21 Thread Wenbo Zhu

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  wrote:

> On Thu, Oct 6, 2011 at 10:57 AM, Wenbo Zhu  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

2011-10-21 Thread Rick Waldron

On Fri, Oct 21, 2011 at 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).
>

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: Proposal for a new Matrix API

2011-10-21 Thread Boris Zbarsky


On 10/21/11 11:28 AM, João Eiras wrote:

On Thu, 20 Oct 2011 16:39:56 +0200, Igor Oliveira
 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

2011-10-21 Thread João Eiras

On Thu, 20 Oct 2011 16:39:56 +0200, Igor Oliveira  
 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: QSA, the problem with ":scope", and naming

2011-10-21 Thread Willison, Timothy

On Oct 20, 2011, at 4:34 PM, Tab Atkins Jr. wrote:

> On Thu, Oct 20, 2011 at 12:09 PM, Jonas Sicking  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
>

[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

2011-10-21 Thread bugzilla

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.

[selectors-api] Requirements and Use Cases for Scoped Methods

2011-10-21 Thread Lachlan Hunt


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.



  A
  
B

  C

  

  
D
  



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
  
  

"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/
http://www.opera.com/

Re: QSA, the problem with ":scope", and naming

2011-10-21 Thread Jonas Sicking

On Thu, Oct 20, 2011 at 2:33 PM, Lachlan Hunt 
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


 
 
  
  
  
 
 
 


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

Re: CfC: publish a Candidate Recommendation of DOM 3 Events; deadline October 21

Re: [indexeddb] Compound Key support for Primary Keys and Indexes

Re: QSA, the problem with ":scope", and naming

[Bug 14364] Add an API to make appcache support caching specific URLs dynamically

Re: CfC: publish a Candidate Recommendation of DOM 3 Events; deadline October 21

Re: Proposal for a new Matrix API

Re: [XHR2] Streamed send or receive

Re: Proposal for a new Matrix API

Re: Proposal for a new Matrix API

Re: Proposal for a new Matrix API

Re: QSA, the problem with ":scope", and naming

[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

[selectors-api] Requirements and Use Cases for Scoped Methods

Re: QSA, the problem with ":scope", and naming

14 matches

Site Navigation

Mail list logo

Footer information