CORS redirect behavior proposal
Looking at the behavior of existing implementations, we don't seem to have committed to how to handle redirects in CORS yet: IE8 (XDomainRequest): Redirects are not supported Firefox 3.5: If you start off same-origin, you can redirect cross-origin once, and the Origin header gets added at that point. Once you're making cross-origin requests, however, further redirects are not allowed. Safari 4 and Chrome 3: If you start off same-origin, cross-origin redirects are blocked. If you start off cross-origin, you can redirect on that origin, but you can't go to yet another origin. However, this redirect behavior only works with synchronous requests; if you're making an asynchronous request you can't do any redirects. In summary, CORS redirects have not yet been implemented, except for synchronous requests in Safari and Chrome. Furthermore, the Safari and Chrome implementation doesn't yet handle the case where one foreign origin redirects to another. We still have some choice as to what behavior to specify in this case. Goals The first order of business is to make sure that the specification fixes the DELETE request security issue that Tyler Close pointed out. Additionally, it would be nice for the Origin header to be usable as a CSRF defense (eliminating the need for a separate Sec-From header). Proposal Same-origin redirects are allowed. Redirects from same-origin to cross-origin are also allowed. When processing a redirect from one foreign origin to another, the browser replaces the Origin header with null. In this situation, the browser appends a Sec-Redirect-Chain header that allows sophisticated sites to see the list of origins that contributed to this request. Example 1: Suppose a site1.com web page makes an XMLHttpRequest to site2.com, which is redirected to site3.com. The requests to site2.com has a site1.com Origin header, but the request to site3.com has an Origin header of null. When making a request to site3.com, the browser adds a Sec-Redirect-Chain header of http://site1.com, http://site2.com;. Example 2: Suppose a site1.com web page makes an XMLHttpRequest to site1.com, which is redirected to site2.com, which is redirected to site3.com. The requests to site1.com and site2.com have a site1.com Origin header, but the request to site3.com has an Origin header of null. When making a request to site3.com, the browser adds a Sec-Redirect-Chain header of http://site1.com, http://site2.com;. Discussion This proposal defends against the DELETE attack that Tyler pointed out: Suppose a goodsite.com web page makes a DELETE request to attacker.com, which is redirected to victim.com. Previously, the request to victim.com would carry the goodsite.com origin, potentially confusing the victim site into deleting something. Under this proposal, the Origin header would be null, so the victim site would not be confused. To defend itself against CSRF, a simple site just needs to make sure the Origin header contains a whitelisted value. A sophisticated site that uses redirects can look at the Sec-Redirect-Chain and ensure that it trusts all the origins in the list. The Sec-Redirect-Chain header is a tradeoff between complexity and supporting more use cases. If we feel that the Sec-Redirect-Chain header is too complicated, it could be dropped from this proposal.
Re: [widgets] Comments on Section 5 of the 18-Aug-2009 LCWD of AE spec
2009/9/21 Arthur Barstow art.bars...@nokia.com: Hi Marcos, On Sep 21, 2009, at 2:08 PM, ext Marcos Caceres wrote: For the sake of the DoC, can you please acknowledge that the comments below have been addressed and your are satisfied with the way the WG addressed your comments. Based on the exchanges we had regarding the 3 sets of comments I submitted ([1][2][3]) against the 18-Aug-2009 LCWD of the Widgets AE spec, I am satisfied with the way those comments were addressed. Note that since we agreed to publish a new LCWD of that spec, I don't think it is necessary for the WG to complete a DoC doc for the 18-Aug version. Ok, but I am going to going to gather responses regardless because the Process requires us to prove wide review. With PC we were fortunate to get wide review on the second LC, but I fear that we won't get a lot of comments in the second LC of the Widget Interface spec. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
skipping and ignoring
Hi, while writing tests, we've hit upon something that could use a little clarification: the distinction between skip and ignore. One interpretation that we can come to is that the two terms means the same thing for files and attributes, but for XML element processing ignore descends into the content whereas skip just moves on to the next. This is consistent for instance with the specification indicating that element content inside name has to be ignored. It is, however, not consistent with its application to description or icon examples whereby those that don't match the locale are said to be ignored (logically it would be skipped — even though descending into the subtree would likely do nothing). Another interpretation is that when something is ignored the UA must act as if it hadn't even been there in the first place, whereas when skipping it ought to not process it but remember it has seen it. This interpretation is built on the fact that the definitions say that ignore causes the UA to act as if [what is being ignored] is not present whereas skip is to proceed to the next element. It becomes less astract if you look at the following conformance statements. In 10.1.19 Algorithm to Process a Configuration Document, step 11, part A content element, the following normative assertion is made: If this is not the first content element encountered by the user agent, then the user agent must skip this element. A few lines later it is followed by If the src attribute of the content element is absent, then the user agent must skip this element. Take the following configuration: content/ content src=perfectly-good-start-file.html/ You see the first. It doesn't have an @src so you skip it. You reach the second. It's perfectly serviceable, but it's not the first. Or is it? If you consider the first one to have been ignored, then you have to act as if it wasn't there. But instead of ignored it says skipped — and it's not clear whether skipped has the same meaning. If the second element is not taken into account, then we have a potential problem with forward compatibility. Let's imagine that we have v2 out, for which the following is correct: content uri='http://berjon.com/cool-widgets/dahut'/ content src=perfectly-good-start-file.html/ Clearly the desired behaviour is for v2 runtimes to process the first, and v1 runtimes to fallback to the second. The same issue applies to other elements that refer to the skip/ignore distinction. We believe that some editorial improvements to those definitions would be welcome. -- Robin Berjon - http://berjon.com/
[selectors-api] Summary of Feature Requests for v2
Hi, I'm planning to look at beginning work on Selectors API v2 soon to add a number of requested features that didn't make it into the first version. This e-mail is a summary of what is being considered, and is intended to start discussion about which ones are really worth focussing on, and how to ensure they address the use cases appropriately. *Matches Selector* http://www.w3.org/Bugs/Public/show_bug.cgi?id=5865 The suggestion is for being able to check if a given element matches a given selector. There is already similar functionality provided by JQuery and Mozilla have begun working on an implementation for it in Firefox. For the basic case, this is fairly trivial. The method just needs to take a selector and evaluate it against the element, and return true or false. But considering the proposed :scope pseudo-class that has been previously discussed here and in the CSS WG, it might also be nice to check if the element matches the selector in relation to a specified reference element. For example, given 2 elements, div1 and div2, you could check if div2 is a sibling of div1 like this: div2.matchesSelector(:scope~div, div1); In this case, the div1 would be the reference element that is matched by :scope. But we still need to determine how useful such functionality would be, and whether it's worth pursuing it in this next version. *Filtering NodeLists* http://www.w3.org/Bugs/Public/show_bug.cgi?id=5864 The suggestion is for being able to take a NodeList, and filter the nodes to obtain a collection of just those that match a given selector. For example, being able to get a NodeList somehow, do something with it, and then filter it more to work with just a subset: e.g. var list = document.querySelctor(divp); // Do something with list, before obtaining the subset subset = list.filterSelector(.foo); ... We need to find and document the possible use cases for this feature. *Scoped Queries* http://www.w3.org/Bugs/Public/show_bug.cgi?id=5860 This has been discussed extensively in the past. Basically, the idea is that the selector would be evaluated in the scope of the element, in a way more compatible with how libraries like JQuery work. This slightly different from the :scope pseudo-class proposal, see bug for details. *Collective Queries on NodeLists* http://www.w3.org/Bugs/Public/show_bug.cgi?id=7707 The suggestion is to be able to run querySelector() and querySelectorAll() on NodeList, and have the result be the union of results in document order from running the method on each Element in the NodeList. e.g. list.querySelectorAll(p); Would be somewhat equivalent to running list[i].querySelectorAll(p); for on each element in the list, and then building an array with the union of distinct elements from all the results. I've been told that similar functionality for this already exists in JQuery. I believe the expectation is that both NodeList.querySelector() and .querySelectorAll() would work. The difference is that querySelector() on a NodeList would return a NodeList (unlike on Element which just returns a single element) containing the first matches from each node in the list. i.e. equivalent to running list[i].querySelector() on each node and then combining all results into an array. It also seems sensible to allow the new scoped methods to be used in an analogous way on NodeLists. *Namespace Prefix Resolution* http://www.w3.org/Bugs/Public/show_bug.cgi?id=6290 The most controversial issue of the lot. Need to clearly document the use cases and evaluate the problems being solved, and determine if it's really worth addressing in this version. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
[widgets] Draft Agenda for 24 September 2009 Voice Conf
Below is the draft agenda for the September 24 Widgets Voice Conference (VC). Inputs and discussion before the VC on all of the agenda topics via public-webapps is encouraged). Please address Open/Raised Issues and Open Actions before the meeting: http://www.w3.org/2008/webapps/track/products/8 Minutes from the last VC: http://www.w3.org/2009/09/17-wam-minutes.html -Regards, Art Barstow Logistics: Time: 22:00 Tokyo; 16:00 Helsinki; 15:00 Paris; 14:00 London; 09:00 Boston; 06:00 Seattle Duration = 90 minutes Zakim Bridge = +1.617.761.6200, +33.4.89.06.34.99 or +44.117.370.6152 PIN = 9231 (WAF1); IRC channel = #wam; irc://irc.w3.org:6665 Confidentiality of minutes = Public Regrets: Marcos, Marcin, Josh Agenda: 1. Review and tweak agenda 2. Announcements a. News/summary from the Widget Testing event http://www.w3.org/2008/webapps/wiki/TestWorkshop2009 3. Widget Interface spec: proposal to publish LCWD #2 http://dev.w3.org/2006/waf/widgets-api/ 4. Access Requests Policy (WARP) spec: comment period ended Sept 20; review comments http://dev.w3.org/2006/waf/widgets-access/ http://www.w3.org/2006/02/lc-comments-tracker/42538/WD-widgets- access-20090804/ 5. URI Scheme spec: status of LC publication http://dev.w3.org/cvsweb/2006/waf/widgets-uri/ 6. View Modes Media Features spec: proposal to publish FPWD http://dev.w3.org/2006/waf/widgets-vm/vm-mediafeature.src.html 7. View Modes Interfaces spec: Arve (from IRC) the bit that troubles me is rotation http://dev.w3.org/2006/waf/widgets-vm/vm-interfaces.src.html 8. AOB
Re: CORS redirect behavior proposal
On Tue, 22 Sep 2009 20:38:46 +0200, Collin Jackson col...@collinjackson.com wrote: Proposal Same-origin redirects are allowed. Redirects from same-origin to cross-origin are also allowed. When processing a redirect from one foreign origin to another, the browser replaces the Origin header with null. In this situation, the browser appends a Sec-Redirect-Chain header that allows sophisticated sites to see the list of origins that contributed to this request. I don't think this works well with the preflight result cache. For more thoughts on that see this email: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1000.html I agree that it would be good to merge Origin and Sec-From. I've been thinking about a simplification of CORS that would make this possible while avoiding the complexity you run into with the preflight result cache. My proposal is to make redirects not work for cross-origin requests with a preflight. That is, only make them work for simple cross-origin requests. For cross-origin requests with a preflight the redirect status codes would be the equivalent of a network error so we can in the future make changes there. This would allow us to use CORS for the EventSource object (which uses the equivalent of a simple request). It would also make it possible to use it for img. Basically if the resource sharing check is successful we could add a flag to the img so that it does not taint the canvas allowing you to use images from a different server on the canvas element while keeping the ability to export image data. For the scenarios where XMLHttpRequest is involved redirects would not work for now. Maybe something to address in CORS v2 or maybe it turns out it is not really needed. For simple cross-origin requests Origin would be a space-separated list of origins indicating the redirect chain. What order would be best there? This is more or less on what I'm planning to go with (will wait a day or so with specifying to allow for feedback) unless someone has a better idea that keeps things relatively simple and works with the preflight result cache. Kind regards, -- Anne van Kesteren http://annevankesteren.nl/
RE: [selectors-api] Summary of Feature Requests for v2
My first priority would be Matches Selector, and see to that it fulfills the needs for event delegation. Best regards Mike Wilson Lachlan Hunt wrote: Hi, I'm planning to look at beginning work on Selectors API v2 soon to add a number of requested features that didn't make it into the first version. This e-mail is a summary of what is being considered, and is intended to start discussion about which ones are really worth focussing on, and how to ensure they address the use cases appropriately. *Matches Selector* http://www.w3.org/Bugs/Public/show_bug.cgi?id=5865 The suggestion is for being able to check if a given element matches a given selector. There is already similar functionality provided by JQuery and Mozilla have begun working on an implementation for it in Firefox. For the basic case, this is fairly trivial. The method just needs to take a selector and evaluate it against the element, and return true or false. But considering the proposed :scope pseudo-class that has been previously discussed here and in the CSS WG, it might also be nice to check if the element matches the selector in relation to a specified reference element. For example, given 2 elements, div1 and div2, you could check if div2 is a sibling of div1 like this: div2.matchesSelector(:scope~div, div1); In this case, the div1 would be the reference element that is matched by :scope. But we still need to determine how useful such functionality would be, and whether it's worth pursuing it in this next version. *Filtering NodeLists* http://www.w3.org/Bugs/Public/show_bug.cgi?id=5864 The suggestion is for being able to take a NodeList, and filter the nodes to obtain a collection of just those that match a given selector. For example, being able to get a NodeList somehow, do something with it, and then filter it more to work with just a subset: e.g. var list = document.querySelctor(divp); // Do something with list, before obtaining the subset subset = list.filterSelector(.foo); ... We need to find and document the possible use cases for this feature. *Scoped Queries* http://www.w3.org/Bugs/Public/show_bug.cgi?id=5860 This has been discussed extensively in the past. Basically, the idea is that the selector would be evaluated in the scope of the element, in a way more compatible with how libraries like JQuery work. This slightly different from the :scope pseudo-class proposal, see bug for details. *Collective Queries on NodeLists* http://www.w3.org/Bugs/Public/show_bug.cgi?id=7707 The suggestion is to be able to run querySelector() and querySelectorAll() on NodeList, and have the result be the union of results in document order from running the method on each Element in the NodeList. e.g. list.querySelectorAll(p); Would be somewhat equivalent to running list[i].querySelectorAll(p); for on each element in the list, and then building an array with the union of distinct elements from all the results. I've been told that similar functionality for this already exists in JQuery. I believe the expectation is that both NodeList.querySelector() and .querySelectorAll() would work. The difference is that querySelector() on a NodeList would return a NodeList (unlike on Element which just returns a single element) containing the first matches from each node in the list. i.e. equivalent to running list[i].querySelector() on each node and then combining all results into an array. It also seems sensible to allow the new scoped methods to be used in an analogous way on NodeLists. *Namespace Prefix Resolution* http://www.w3.org/Bugs/Public/show_bug.cgi?id=6290 The most controversial issue of the lot. Need to clearly document the use cases and evaluate the problems being solved, and determine if it's really worth addressing in this version. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
[WARP] uri attribute is confusing
Hi, The attribute uri on the access element in WARP is somewhat misleading - what it takes is more a URL pattern than a URI. I would suggest renaming it in urlpattern or just pattern (unless there are already many implementations that rely on that attribute name). There may be lessons to be taken in designing these patterns from POWDER http://www.w3.org/TR/2009/REC-powder-dr-20090901/ - although I suspect the POWDER expressivity needs are much greater than what is needed here. Dom
RE: [widgets] Draft Agenda for 24 September 2009 Voice Conf
Hi Art, All, I would like to suggest to add to the agenda the point that appeared during the widgets testing event. It is related to the Widget Interface, View Modes and patterns. The comments below will be valid also as LC comments to the Widget Interface. The Widget Interface includes width and height attributes. On the other hand the View Modes Interfaces defines the ResolutionChangedEvent event. So we may have at least the following scenarios: Scenario 1: a) the dimensions of the viewport change. b) the ResolutionChangedEvent is fired. c) the widget gets the new dimensions from the event Scenario 2: a) the dimensions of the viewport change. b) the ResolutionChangedEvent is fired. c) the widget gets the new dimensions from the Widget interface (the widget object) Incorporating the onresize handler on the body element, we could have another scenarion: Scenario 2: a) the dimensions of the viewport change. b) the onresize handler is triggered. c) the widget gets the new dimensions from the Widget interface (the widget object) So we have 3 scenarios for 1 thing (notification about changed size and retrieval of the new dimensions). If we want to keep ResolutionChangedEvent, we have two methods of getting the new width/height: i) from the ResolutionChangedEvent ii) from the Widget interface Therefore I suggest picking up one of the following: 1. Drop the ResolutionChangedEvent, mandate onresize handler, keep width/height in the Widget interface. 2. Drop width/height from the ResolutionChangedEvent, ignore onresize handler, keep width/height in the Widget interface. 3. Keep the ResolutionChangedEvent, ignore onresize handler, drop width/height in the Widget interface. Thanks, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Arthur Barstow Sent: Wednesday, September 23, 2009 1:56 PM To: public-webapps Subject: [widgets] Draft Agenda for 24 September 2009 Voice Conf Below is the draft agenda for the September 24 Widgets Voice Conference (VC). Inputs and discussion before the VC on all of the agenda topics via public-webapps is encouraged). Please address Open/Raised Issues and Open Actions before the meeting: http://www.w3.org/2008/webapps/track/products/8 Minutes from the last VC: http://www.w3.org/2009/09/17-wam-minutes.html -Regards, Art Barstow Logistics: Time: 22:00 Tokyo; 16:00 Helsinki; 15:00 Paris; 14:00 London; 09:00 Boston; 06:00 Seattle Duration = 90 minutes Zakim Bridge = +1.617.761.6200, +33.4.89.06.34.99 or +44.117.370.6152 PIN = 9231 (WAF1); IRC channel = #wam; irc://irc.w3.org:6665 Confidentiality of minutes = Public Regrets: Marcos, Marcin, Josh Agenda: 1. Review and tweak agenda 2. Announcements a. News/summary from the Widget Testing event http://www.w3.org/2008/webapps/wiki/TestWorkshop2009 3. Widget Interface spec: proposal to publish LCWD #2 http://dev.w3.org/2006/waf/widgets-api/ 4. Access Requests Policy (WARP) spec: comment period ended Sept 20; review comments http://dev.w3.org/2006/waf/widgets-access/ http://www.w3.org/2006/02/lc-comments-tracker/42538/WD-widgets- access-20090804/ 5. URI Scheme spec: status of LC publication http://dev.w3.org/cvsweb/2006/waf/widgets-uri/ 6. View Modes Media Features spec: proposal to publish FPWD http://dev.w3.org/2006/waf/widgets-vm/vm-mediafeature.src.html 7. View Modes Interfaces spec: Arve (from IRC) the bit that troubles me is rotation http://dev.w3.org/2006/waf/widgets-vm/vm-interfaces.src.html 8. AOB Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
Re: Progress Events - Credits Edits
On Sep 19, 2009, at 15:00 , Charles McCathieNevile wrote: On Sat, 19 Sep 2009 07:55:23 +0200, Garrett Smith dhtmlkitc...@gmail.com wrote: In looking at the credits, I noticed all of: Bjoern Hoehrmann, Björn Hoehrmann, Björn Höhrmann, Bjoern H�hrmann I am not sure if there are two similar BH, as Björn and Bjoern. Entities for the characters should be used. You score a prize. I guess it is time to collapse all the names of the mysterious Mr Hoehrmann into a single identity. Historically this was actually intentional — though its appearance in PE might be through copy and paste. -- Robin Berjon - http://berjon.com/
RE: [widgets] Draft Agenda for 24 September 2009 Voice Conf
Hi, One more comment to the below: There is one use case not handled by the below scenarios: In case the width/height are dropped on the Widget interface, the widget would not know the initial dimensions. E.g. in Win32 each new window get WM_SIZE event with the initial width/height. However, I am not sure whether we should mandate the ResolutionChangedEvent to be used for the initial viewport size. So I would opt for keeping the ResolutionChangedEvent, dropping width/height on the ResolutionChangedEvent, and keeping width/height in the Widget interface. Thanks, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Marcin Hanclik Sent: Wednesday, September 23, 2009 3:22 PM To: Arthur Barstow; public-webapps Subject: RE: [widgets] Draft Agenda for 24 September 2009 Voice Conf Hi Art, All, I would like to suggest to add to the agenda the point that appeared during the widgets testing event. It is related to the Widget Interface, View Modes and patterns. The comments below will be valid also as LC comments to the Widget Interface. The Widget Interface includes width and height attributes. On the other hand the View Modes Interfaces defines the ResolutionChangedEvent event. So we may have at least the following scenarios: Scenario 1: a) the dimensions of the viewport change. b) the ResolutionChangedEvent is fired. c) the widget gets the new dimensions from the event Scenario 2: a) the dimensions of the viewport change. b) the ResolutionChangedEvent is fired. c) the widget gets the new dimensions from the Widget interface (the widget object) Incorporating the onresize handler on the body element, we could have another scenarion: Scenario 2: a) the dimensions of the viewport change. b) the onresize handler is triggered. c) the widget gets the new dimensions from the Widget interface (the widget object) So we have 3 scenarios for 1 thing (notification about changed size and retrieval of the new dimensions). If we want to keep ResolutionChangedEvent, we have two methods of getting the new width/height: i) from the ResolutionChangedEvent ii) from the Widget interface Therefore I suggest picking up one of the following: 1. Drop the ResolutionChangedEvent, mandate onresize handler, keep width/height in the Widget interface. 2. Drop width/height from the ResolutionChangedEvent, ignore onresize handler, keep width/height in the Widget interface. 3. Keep the ResolutionChangedEvent, ignore onresize handler, drop width/height in the Widget interface. Thanks, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Arthur Barstow Sent: Wednesday, September 23, 2009 1:56 PM To: public-webapps Subject: [widgets] Draft Agenda for 24 September 2009 Voice Conf Below is the draft agenda for the September 24 Widgets Voice Conference (VC). Inputs and discussion before the VC on all of the agenda topics via public-webapps is encouraged). Please address Open/Raised Issues and Open Actions before the meeting: http://www.w3.org/2008/webapps/track/products/8 Minutes from the last VC: http://www.w3.org/2009/09/17-wam-minutes.html -Regards, Art Barstow Logistics: Time: 22:00 Tokyo; 16:00 Helsinki; 15:00 Paris; 14:00 London; 09:00 Boston; 06:00 Seattle Duration = 90 minutes Zakim Bridge = +1.617.761.6200, +33.4.89.06.34.99 or +44.117.370.6152 PIN = 9231 (WAF1); IRC channel = #wam; irc://irc.w3.org:6665 Confidentiality of minutes = Public Regrets: Marcos, Marcin, Josh Agenda: 1. Review and tweak agenda 2. Announcements a. News/summary from the Widget Testing event http://www.w3.org/2008/webapps/wiki/TestWorkshop2009 3. Widget Interface spec: proposal to publish LCWD #2 http://dev.w3.org/2006/waf/widgets-api/ 4. Access Requests Policy (WARP) spec: comment period ended Sept 20; review comments http://dev.w3.org/2006/waf/widgets-access/ http://www.w3.org/2006/02/lc-comments-tracker/42538/WD-widgets- access-20090804/ 5. URI Scheme spec: status of LC publication http://dev.w3.org/cvsweb/2006/waf/widgets-uri/ 6. View Modes Media Features spec: proposal to publish FPWD http://dev.w3.org/2006/waf/widgets-vm/vm-mediafeature.src.html 7. View Modes Interfaces spec: Arve (from IRC) the bit that troubles me is rotation http://dev.w3.org/2006/waf/widgets-vm/vm-interfaces.src.html 8. AOB Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke
Re: [AE] Last Call comments (2): discovery localization
On Sep 21, 2009, at 20:08 , Marcos Caceres wrote: 5.1 Localization Shall it be possible for the widget to programmatically discover the localization path it was loaded from (section 9 of PC)? Yes, you can check its URI. If the implementation supports the window object, then it possible. How? window.location will return widget:///foo.html irrespective of whether the runtime loaded /foo.html or /locales/fr/foo.html. -- Robin Berjon - http://berjon.com/
Re: [AE] Last Call comments (2): discovery localization
Robin Berjon wrote: On Sep 21, 2009, at 20:08 , Marcos Caceres wrote: 5.1 Localization Shall it be possible for the widget to programmatically discover the localization path it was loaded from (section 9 of PC)? Yes, you can check its URI. If the implementation supports the window object, then it possible. How? window.location will return widget:///foo.html irrespective of whether the runtime loaded /foo.html or /locales/fr/foo.html. Ah, ok. Yes, forgot about that. Well, the best we can do is give the lang list that the UA is using? Ideas? is this really important? I can see it being useful to know where stuff is being loaded from instead of having to guess where a resource was loaded from.
Re: XHR request state vs provisional responses
On Tue, 25 Aug 2009 17:34:18 +0200, Julian Reschke julian.resc...@gmx.de wrote: was it ever discussed to expose information from provisional HTTP responses (http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.10.1) to clients? That might become interesting once extensions such as http://tools.ietf.org/html/draft-decroy-http-progress-00 ever get deployed... I don't think exposing HTTP 1xx status codes has been discussed before. -- Anne van Kesteren http://annevankesteren.nl/
Re: Progress Events - Credits Edits
On Wed, 23 Sep 2009 15:33:22 +0200, Robin Berjon ro...@berjon.com wrote: On Sep 19, 2009, at 15:00 , Charles McCathieNevile wrote: On Sat, 19 Sep 2009 07:55:23 +0200, Garrett Smith dhtmlkitc...@gmail.com wrote: In looking at the credits, I noticed all of: Bjoern Hoehrmann, Björn Hoehrmann, Björn Höhrmann, Bjoern H�hrmann I am not sure if there are two similar BH, as Björn and Bjoern. Entities for the characters should be used. You score a prize. I guess it is time to collapse all the names of the mysterious Mr Hoehrmann into a single identity. Historically this was actually intentional — though its appearance in PE might be through copy and paste. No, it was done by hand apparently... anyway. Less talk, and maybe I will get to editing the draft :S cheers -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: skipping and ignoring
On Wed, Sep 23, 2009 at 12:44 PM, Robin Berjon ro...@berjon.com wrote: Hi, while writing tests, we've hit upon something that could use a little clarification: the distinction between skip and ignore. One interpretation that we can come to is that the two terms means the same thing for files and attributes, but for XML element processing ignore descends into the content whereas skip just moves on to the next. This is consistent for instance with the specification indicating that element content inside name has to be ignored. It is, however, not consistent with its application to description or icon examples whereby those that don't match the locale are said to be ignored (logically it would be skipped — even though descending into the subtree would likely do nothing). Another interpretation is that when something is ignored the UA must act as if it hadn't even been there in the first place, whereas when skipping it ought to not process it but remember it has seen it. This interpretation is built on the fact that the definitions say that ignore causes the UA to act as if [what is being ignored] is not present whereas skip is to proceed to the next element. It becomes less astract if you look at the following conformance statements. In 10.1.19 Algorithm to Process a Configuration Document, step 11, part A content element, the following normative assertion is made: If this is not the first content element encountered by the user agent, then the user agent must skip this element. A few lines later it is followed by If the src attribute of the content element is absent, then the user agent must skip this element. Take the following configuration: content/ content src=perfectly-good-start-file.html/ You see the first. It doesn't have an @src so you skip it. You reach the second. It's perfectly serviceable, but it's not the first. Or is it? If you consider the first one to have been ignored, then you have to act as if it wasn't there. Ok, I see the confusion. But instead of ignored it says skipped — and it's not clear whether skipped has the same meaning. Good point. The second must not be processes because it is not the first. It don't matter that is serviceable. It might just be that I used ignore where skip was intended. If the second element is not taken into account, then we have a potential problem with forward compatibility. Let's imagine that we have v2 out, for which the following is correct: content uri='http://berjon.com/cool-widgets/dahut'/ content src=perfectly-good-start-file.html/ Clearly the desired behaviour is for v2 runtimes to process the first, and v1 runtimes to fallback to the second. IMO the correct behavior would be for src attributes to take URIs and for the second to be skipped. However, I'm sure you can dream up other examples. The only ever use the first, even if b0rked behavior is based on HTML's behavior (particularly the title element). I'm happy to break ranks with HTML parsing if that is what the WG thinks would be best. However, it's a pretty big change to the parsing model, but if it future proofs us, then it might be worth it. The same issue applies to other elements that refer to the skip/ignore distinction. We believe that some editorial improvements to those definitions would be welcome. Agreed. I'll work on improving those but that depends on if we change the parsing behavior or not to match what you suggested above. -- Marcos Caceres http://datadriven.com.au
Re: Publishing XMLHttpRequest
On Wed, 12 Aug 2009 18:03:52 +0200, Stewart Brodie stewart.bro...@antplc.com wrote: 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 changed my mind and added a section on this by the way: http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#differences (Quite a while ago, but it seems I did not reply to this email.) -- Anne van Kesteren http://annevankesteren.nl/
Re: FYI: W3C Workshop on Access Control Application Scenarios; Nov 17-18 in Luxembourg
On Wed, 23 Sep 2009 02:18:02 +0200, Arthur Barstow art.bars...@nokia.com wrote: Given WebApps' CORS spec, this Workshop (November 17-18 in Luxembourg) may be of interest to you: http://www.w3.org/2009/policy-ws/cfp.html Thanks Art. I looked into this and couldn't really figure out how CORS relates. And if I just misunderstood it, does that mean I should submit a position paper on CORS? The scope seems quite broad so I guess it might fit in somehow, but then we already have a WG that handles it... It also sounds like it has overlap with the IETF activity on OAuth. (Personally I get quite lost in the sea of terminology used on that page :-)) -- Anne van Kesteren http://annevankesteren.nl/
Re: CORS redirect behavior proposal
On Wed, Sep 23, 2009 at 5:34 AM, Anne van Kesteren ann...@opera.com wrote: For simple cross-origin requests Origin would be a space-separated list of origins indicating the redirect chain. When we used this syntax for the Sec-From header, Mark Nottingham advocated using commas to separate the origins to better align with other HTTP headers. What order would be best there? I think the simplest thing is to list the origins in the order in which the user agent encounters them (with adjacent duplicates removed). This is more or less on what I'm planning to go with (will wait a day or so with specifying to allow for feedback) unless someone has a better idea that keeps things relatively simple and works with the preflight result cache. That sounds reasonable to me. I don't quite understand all the constraints we get from the preflight cache, but the rest sounds fine. Thanks, Adam
Re: [widgets] WURI Review pre-LC review
2009/9/17 Robin Berjon ro...@berjon.com: On Sep 3, 2009, at 14:25 , Marcos Caceres wrote: Many specifications in the Web stack depend on a context being defined that includes a current IRI. This is easily provided for documents retrieved over HTTP, or from the local file system, but is currently undefined for documents extracted from within a widget package. I don't like the above. Why are you starting this as an argument? It's not an argument, but I see how to change it. Ok, I'll re-read it before we publish again. This document was published by the Web Applications WG as a Last Call Working Draft. This document is intended to become a W3C Recommendation. If you wish to make comments regarding this document, please send them to public-webapps@w3.org (subscribe, archives). The Last Call period ends 10 November 2009. All feedback is welcome. This LC period is too long. Make it 10th of October or mid October. This is to facilitate two LCs. We'll change that when we really do go to LC. As things stand, we might be delayed a little more so I can address Jere's comments which require some rearchitecting. Ok. This specification defines the widget URI scheme that is used to address resources inside a widget [WIDGETS]. change to inside a widget package That text is gone, but I've changed it elsewhere. Mmmkay. There are many different efforts that have specified URI schemes to access the content of Zip archives, or endeavour to do so. While these endeavour endeavor Perhaps the day you pry my spellchecker from the unflinching grip of my cold, dead fingers. The W3C mandates specs be in en-us [reference-needed] (it's part of a evil ploy the W3C has to enforce the US imperialist agenda through linguistic hegemony). efforts have merit, and while W3C Widgets rely on Zip as a packaging format, the use cases that this specification addresses are radically different. radically is unnecessary. You make grand statements, but then don't back them. What is so radical about what we are doing? Don't tell me (I know how awesome we are!), put in the spec :) Hmmm, it seems to me that you don't know what radically means. It means at its root. We're doing something that is at its roots different. Something that is radically different isn't necessarily radical, in fact there is little connection other than etymological. That being said I've changed it to substantially to make it more K12 compliant :) And there I thought radical meant radical dude! (Thanks A LOT, Ninja Turtles!) The scheme defined in this specification could be used to implement inter-widget communication, but that is outside the scope of this current document. This is not proven. I would just say that cross-widget is out of scope and, may be future work, but not that it could be used for that. Uniquely identifying widgets, or multiple instances of the same widget package, as well as using that to enable inter-widget communication are outside the scope of this document. Nice. 4. Requirements All this should be moved to the widgets requirements doc. I don't have a strong opinion but I'm not sure. The widgets requirements document holds requirements for the whole family, but it stops before the technical implications. I don't think that there's a requirement to have a URI scheme when you go and create a widget platform, it just so happens that the technical decisions we made lead to a place where we need one. But I'm happy to remove them if you want to past them in the WR — the shorter the better! Yes, please. Must not require widget developers to be aware of it for basic tasks Using this scheme as the IRI of resources inside a widget must not force widget developers to be aware of its existence for simple tasks such as linking between widget resources, and would ideally not require such knowledge for advanced tasks either. Yep... but I would qualify this as the whole scheme or must not need to know about every component part of the scheme, as you need to at least know about the path component. I see what you mean — technically if you use the path bit then you know about the scheme, but that's not what I meant, really. People shouldn't have to learn anything to use it for basic tasks (e.g. just do a path). I think most developers don't think that they're using the ipath-noscheme followed by ifragment when they link to marcos.xhtml#nose. So I'm unsure how to change this to reflect both sides. Ok, leave it then (and I've asked before to not to make fun of my nose). A careful review of existing schemes has found that none matches the needs above. existing schemes needs references to all the ones we looked at. careful review review and link it to the wiki or my presentation on the wiki. You might also link to the landscape doc, though I can't remember if I covered that in there or not. It's not in the landscape and I'd really rather not link
Mail List Etiquette How to Loose Your Privileges
All, I think we all appreciate frank and open technical discussions about the Web Applications WG's specifications but we must also be respectful and professional in our exchanges. My personal tolerance for terse exchanges is relatively high but that is not true for everyone and we must respect our differences via our behavior, interactions and responses. More specifically, please read and follow: 1. The Community Principles defined by the W3C's Positive Work Environment Task Force: http://www.w3.org/2007/06/PWET-statement-of-principles.html 2. Section 3.1 of the W3C's Process document; nota bene: the social competence participation requirement: http://www.w3.org/2005/10/Process-20051014/ policies.html#ParticipationCriteria Failure to adhere to the above social norms may result in being removed from a mail list (for at least some period of time). Depending upon the severity, immediate removal may be warranted i.e. no warning(s). So please, use these mail lists for technical discussions only. -Regards, Art Barstow; Co-Chair of the Web Applications WG
Re: [AE] Last Call comments (1)
2009/9/15 Marcin Hanclik marcin.hanc...@access-company.com: The below comments refer to: Widgets 1.0: The widget Interface Editor's Draft 14 September 2009 General: Replace can with may in the whole document. I've used can deliberately throughout the document where statements of fact are made. To use may would result in a conformance clause where one is not needed. 2. Feature Why to repeat the definition from PC? People complain about having to jump from spec to spec. Makes the document easier to read. Getting / Setting Refer to HTML5 for those definitions? No, they are defined in WebStorage but I stole them (muahaha!) :) I only reference other specs where something that affects conformance/behavior is said. Viewport [1] says that scrollbars are part of the rendering area (I do not claim that it is fully correct, I assume scrollbars are a discussion point, specifically in the context of DHTML where they could appear and vanish depending on the dynamic content). My proposal is to make this definition non-final. All definitions: Could we have a document with the definitions for all specifications from the family? That could be possible, but some definitions are inline - better to leave them where they are and just follow the anchors in the document. 3. achived - achieved Fixed. 4. Again about the definitions: Could we have a common definition of the user agent, decoupled from the specs? (e.g. UA in PC is an implementation, here it is a software implementation) Yes, we have talked about this but just haven't got around to doing it. I personally don't think we need an overarching definition, however. The more modular these specs are, the better IMO. We try to make it pretty clear what the dependencies for each UA are. 4.2 a read-only item is an item in a storage area cannot be ... should be a read-only item is an item in a storage area that cannot be ... Fixed. 5. Why aren't the following attributes available on the widget interface? @viewmodes from widget, That's your spec :) Add it as supplemental attribute to the widget interface. @short from name, I would not mind adding this one, maybe calling it widget.shortname. @href from license and license, What is the use case? icons What is the use case? Also, these may be changing dynamically so it makes things a mess. I think we should create and Icon API at some point in the near future (leverage HTML5 cross-doc communication), but we should not add anything poorly specified now. 5. It preferences(via the preferences attribute). Unclear. Yikes, changed it to: The interface also allows authors to access persistently-stored preferences (via the preferences attribute). 5. A user agent should to impose ... Should be A user agent should impose ... I've deleted that assertion (Artb pointed out that it is an untestable weasel assertion). 5. ... global object context of the widget's start file. What about: ... global object context of the document loaded from widget's start file. ??? I'm working on a better definition for this with Robin. 5. In ... global object context of the widget's start file. And A user agent whose start file implements HTML5's Window interface ... The start files refer to 2 different locations. I'm going to rewrite all this. Will let you know as soon as it is done. 5.4 How to handle multiple instances of the same widget? As far as I remember it was to be moved to WURIv2, but it seems important in the context of preferences. No, it's not important. They are bound to the origin of a widget as defined in WURI, and the origin of a widget is universally unique. Hence, preferences are unique and not shared. 5.4 Storage interface: The AE specification should not add interpretation to the WebStorage with regard to the exceptions thrown. It would be better to improve the WebStorage specification. Hixie was the one who said we need to define it here. There is no notion of a read-only items in Web Storage. We can ask Hixie again, but I doubt he will pay us any attention (besides, I agree with him. It should be spec'd in our spec... no need to bloat WebStorage with widget-only stuff). Specifically the NO_MODIFICATION_ALLOWER_ERR shall be presented in WebIDL on Storage interface based on raises keyword of WebIDL. That would be nice. I don't know any WebIDL. Do you want to write a supplemental IDL declaration for us to include in the spec? We can live without it, but would be nice to have (makes the spec easier to understand). 5.4.1 onClick - onclick Fixed (though I don't think case matters in HTML5, the parser still works it out) 5.4.2#3 ... make the preferences attribute a pointer that storage area. Should be ... make the preferences attribute a pointer to that storage area. Fixed. 5.4.2#2.4.1 ... apply the rule for dealing with an invalid Zip archive ... And In the event that an implementation encounters an invalid Zip archive ...
Re: [widgets] Draft Agenda for 24 September 2009 Voice Conf
On Wed, Sep 23, 2009 at 4:36 PM, Marcin Hanclik marcin.hanc...@access-company.com wrote: Hi, One more comment to the below: There is one use case not handled by the below scenarios: In case the width/height are dropped on the Widget interface, the widget would not know the initial dimensions. E.g. in Win32 each new window get WM_SIZE event with the initial width/height. However, I am not sure whether we should mandate the ResolutionChangedEvent to be used for the initial viewport size. So I would opt for keeping the ResolutionChangedEvent, dropping width/height on the ResolutionChangedEvent, and keeping width/height in the Widget interface. I'm still confused as to why we can't keep both. Is it because of redundancy? -- Marcos Caceres http://datadriven.com.au
Re: FYI: W3C Workshop on Access Control Application Scenarios; Nov 17-18 in Luxembourg
Hi Art, Anne, looks like the focus of the CORS specification is on very simple access control that would just express that site A allows access to content if the javascript stuff calls it from a thing found on site B. The workshop deals with conditions (policy) under which a certain resource can be accessed. The conditions include the availability of credentials that include crypto credentials. It will also deal with the question on how to address credentials that are needed to get access. It may also address the question on how to describe the resource you are asserting conditions and access control restrictions on (e.g. clouds). Finally, it deals with privacy semantics and identity management of access control and how to assert them e.g. in XACML conditions. These are only the things I definitely know will come up. So it depends on whether Anne or other Members from the Webapps group see benefit in finding out and contributing to more advanced access control issues. It may be nice for those wanting more power in cross site access control, to want to find out how to use more advanced languages together with CORS. That may be a very useful contribution from folks in webapps. Best, Rigo On Wednesday 23 September 2009, Anne van Kesteren wrote: On Wed, 23 Sep 2009 02:18:02 +0200, Arthur Barstow art.bars...@nokia.com wrote: Given WebApps' CORS spec, this Workshop (November 17-18 in Luxembourg) may be of interest to you: http://www.w3.org/2009/policy-ws/cfp.html Thanks Art. I looked into this and couldn't really figure out how CORS relates. And if I just misunderstood it, does that mean I should submit a position paper on CORS? The scope seems quite broad so I guess it might fit in somehow, but then we already have a WG that handles it... It also sounds like it has overlap with the IETF activity on OAuth. (Personally I get quite lost in the sea of terminology used on that page :-)) signature.asc Description: This is a digitally signed message part.
Re: [AE] Last Call comments (1)
Hmm, I raised this one too. I can't see how the origin handles instances exactly, and the concept of origin doesn't seem all that relevant to our implementation anyway - it looks more like something for browser makers to worry over? Why is origin of a widget preferable to instance of widget? This could be important as some conformance statements relate to the concept, e.g: Upon getting the preferences attribute, the user agent must return a Storage object that represents the storage area for the origin of a widget. If origin of a widget is not a sensible concept for the UA (as opposed to widget instance), does this fail conformance? How would you test for it for the UA anyway? S On 23 Sep 2009, at 17:10, Marcos Caceres wrote: 5.4 How to handle multiple instances of the same widget? As far as I remember it was to be moved to WURIv2, but it seems important in the context of preferences. No, it's not important. They are bound to the origin of a widget as defined in WURI, and the origin of a widget is universally unique. Hence, preferences are unique and not shared. smime.p7s Description: S/MIME cryptographic signature
[widgets] Comments for pre-FPWD of View Modes Media Feature spec
Below are comments regarding rev1.1 of the View Modes Media Feature spec: http://dev.w3.org/cvsweb/2006/waf/widgets-vm/vm-mediafeature.src.html -Regards, Art Barstow 1. Abstract: a. I don't understand the document's content in this context. b. Missing a sentence terminator for the first sentence c. Change the URI under the Widgets 1.0 family of specifications to: http://www.w3.org/2008/webapps/wiki/WidgetSpecs d. Delete , which together standarize widgets as a whole. 2. Status of the Document - change the URI under Editor's Draft to point to the latest Editor's draft of the spec and not a directory. 3. Section 1.1 - the following isn't accurate: [[ This document defines new media feature, its values and the DOM interface for querying the media features and types that apply to a document at a given instance in time, including events to detect when the values of the said features change. ]] Change it to: [[ This document defines a new media feature and its values. ]] 4. Section 1.2 - a User Agent in the context of this spec should implement this spec (not the PC spec) 5. Section 2 - We should strive for more consistency with the various widget spec's Conformance section. To that end, change the title to just Conformance and replace this entire section with just the following text in the Conformance section of the latest Editor's Draft of the widgets Interface spec i.e.: [[ All examples and notes in this specification are non-normative, as are all sections explicitly marked non-normative. Everything else in this specification is normative. The key words must, must not, should, recommended, may and optional in the normative parts of this specification are to be interpreted as described in [RFC2119]. ]] 6. Section 3. and 3.1 a. I think there are problems with all four of the view modes definitions. As such, I would delete all of them and state they are defined in terms of their property values as specified in the table in Section 3.1 b. Rather than use Characteristics and attributes, just use property. For example, the statement: [[ The following attributes - summarized in the table below - characterize each of the values of the 'view-mode' media feature: ]] Would become: [[ The following table defines each of the view-modes' values in terms of its properties. ]] c. The heading of the last column in the table should be shortened to something like width height 7. References a. Delete unused References: DOM2Events, DOM2Style, HTML4, CSS21, Widgets-Landscape, Widgets-Reqs b. Make Normative: [Media Queries]
Re: [selectors-api] Summary of Feature Requests for v2
Mike Wilson wrote:
My first priority would be Matches Selector, and see to that
it fulfills the needs for event delegation.
Is there any special functionality that would be needed to achieve this?
If I understand correctly, event delegation just needs to be able to
check whether the event target element matches a given selector. So it
would be something like:
if (evt.target.matchesSelector(.fooinput.bar)) {
...
}
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: more flexible ABNF for STS?
This sounds like a good idea. One thing we can do to reduce the complexity is to have different grammars for server conformance and for user agent conformance. Essentially, servers would be required to conform to the current grammar, but UAs would be required to conform to the more tolerant grammar. On Mon, Sep 21, 2009 at 4:27 PM, =JeffH jeff.hod...@kingsmountain.com wrote: invalid-STSDirective = name | name : | name : value name = anything but : or ; value = anything but ; I'm not sure what role : is playing here. It might be easier to just omit it from the grammar. Adam
Re: [selectors-api] Summary of Feature Requests for v2
On Wed, Sep 23, 2009 at 4:51 AM, Lachlan Hunt lachlan.h...@lachy.id.au wrote: *Scoped Queries* http://www.w3.org/Bugs/Public/show_bug.cgi?id=5860 This has been discussed extensively in the past. Basically, the idea is that the selector would be evaluated in the scope of the element, in a way more compatible with how libraries like JQuery work. This slightly different from the :scope pseudo-class proposal, see bug for details. Note that what makes the strong, em selector (which apparently some libraries support) hard to support spec-wise is that that is not in fact valid CSS syntax. It's certainly possible to define behavior for it, it's pretty clear to me how it's intended to work, but it would mean specifying our own syntax. However if supporting commaseparated queries is critical for libraries then I see no other choise. We'll one way or another have to specify our own syntax, though it can be heavily based on the productions in the Selector spec. / Jonas
Re: [selectors-api] Scoped Queries
Jonas Sicking wrote: On Wed, Sep 23, 2009 at 4:51 AM, Lachlan Hunt lachlan.h...@lachy.id.au wrote: *Scoped Queries* http://www.w3.org/Bugs/Public/show_bug.cgi?id=5860 This has been discussed extensively in the past. Basically, the idea is that the selector would be evaluated in the scope of the element, in a way more compatible with how libraries like JQuery work. This slightly different from the :scope pseudo-class proposal, see bug for details. Note that what makes the strong, em selector (which apparently some libraries support) hard to support spec-wise is that that is not in fact valid CSS syntax. It's certainly possible to define behavior for it, it's pretty clear to me how it's intended to work, but it would mean specifying our own syntax. It is clear how it is intended to work, but it is less powerful than a :scope selector. I suggest it is a low priority feature. However if supporting commaseparated queries is critical for libraries then I see no other choise. We'll one way or another have to specify our own syntax, though it can be heavily based on the productions in the Selector spec. / Jonas Libraries already parse selector queries anyway. And some of them add non-standard selectors and presumeably will continue to do so. I don't think it is an issue.
Re: [selectors-api] Summary of Feature Requests for v2
I think a couple of those features are pretty low priority: - I don't see the point of collective queries on NodeLists. Are there any references for the proposal? Otherwise I can't think of any useful queries that can't already be achieved with a single querySelectorAll(). - Filtering NodeLists is trivial once we get matchesSelector(). Sean Lachlan Hunt wrote: Hi, I'm planning to look at beginning work on Selectors API v2 soon to add a number of requested features that didn't make it into the first version. This e-mail is a summary of what is being considered, and is intended to start discussion about which ones are really worth focussing on, and how to ensure they address the use cases appropriately. *Matches Selector* http://www.w3.org/Bugs/Public/show_bug.cgi?id=5865 *Filtering NodeLists* http://www.w3.org/Bugs/Public/show_bug.cgi?id=5864 *Scoped Queries* http://www.w3.org/Bugs/Public/show_bug.cgi?id=5860 *Collective Queries on NodeLists* http://www.w3.org/Bugs/Public/show_bug.cgi?id=7707 *Namespace Prefix Resolution* http://www.w3.org/Bugs/Public/show_bug.cgi?id=6290
Re: [selectors-api] Summary of Feature Requests for v2
On Wed, Sep 23, 2009 at 4:51 AM, Lachlan Hunt lachlan.h...@lachy.id.au wrote: Hi, I'm planning to look at beginning work on Selectors API v2 soon to add a number of requested features that didn't make it into the first version. This e-mail is a summary of what is being considered, and is intended to start discussion about which ones are really worth focussing on, and how to ensure they address the use cases appropriately. *Matches Selector* http://www.w3.org/Bugs/Public/show_bug.cgi?id=5865 That helps event delegation pattern. That is, adding an event handler to a container and then inspecting the event's target, to see if what the user interacted with (and what the program should do about it). This approach tends to be a much more efficient pattern than traversing through the entire document to match nodes, and then add event handler callbacks to them. The existing draft encourages less efficient programming style of traversing through the document. Pity. The suggestion is for being able to check if a given element matches a given selector. There is already similar functionality provided by JQuery and Mozilla have begun working on an implementation for it in Firefox. http://www.w3.org/Bugs/Public/show_bug.cgi?id=5865 For the basic case, this is fairly trivial. The method just needs to take a selector and evaluate it against the element, and return true or false. But considering the proposed :scope pseudo-class that has been previously discussed here and in the CSS WG, it might also be nice to check if the element matches the selector in relation to a specified reference element. For example, given 2 elements, div1 and div2, you could check if div2 is a sibling of div1 like this: div2.matchesSelector(:scope~div, div1); The matching seems backwards. Should be on the matcher, instead of the element? I don't see the role of the element being something that does matching. The matching should be something left to some sort of a Matcher. A function to get an actual Selector object would allow the program to creating a cached matcher. var selector = QuerySelector.create(div.panel); var isPanel = selector.matches(event.target); Garrett
Re: [selectors-api] Summary of Feature Requests for v2
Quick Summary of my opinions: Matches Selector: Super-super useful - critical, in fact. We're not able to remove jQuery's selector engine until this is implemented. I'm working with the devs at Mozilla to get an implementation landed. Already have a test suite in place. Filtering NodeLists/StaticNodeLists, Queries on NodeLists/StaticNodeLists: Neither of these are useful, as is, to libraries. What is actually useful is the ability to run these against an array (or array-like collection) of DOM nodes. If I can do: document.querySelectorAll.call([document.getElementById(node1), document.getElementById(node2)], div span); then yes, this proposal is useful. Rarely do libraries store raw NodeLists (they need to be converted into an array or array-like collection first). Scoped Queries: Also critical. As it stands, in jQuery, we just punt whenever does a query rooted to a DOM element and fallback to the old selector engine. Namespace Prefix Resolution: Indifferent. --John On Wed, Sep 23, 2009 at 7:51 AM, Lachlan Hunt lachlan.h...@lachy.id.auwrote: Hi, I'm planning to look at beginning work on Selectors API v2 soon to add a number of requested features that didn't make it into the first version. This e-mail is a summary of what is being considered, and is intended to start discussion about which ones are really worth focussing on, and how to ensure they address the use cases appropriately. *Matches Selector* http://www.w3.org/Bugs/Public/show_bug.cgi?id=5865 The suggestion is for being able to check if a given element matches a given selector. There is already similar functionality provided by JQuery and Mozilla have begun working on an implementation for it in Firefox. For the basic case, this is fairly trivial. The method just needs to take a selector and evaluate it against the element, and return true or false. But considering the proposed :scope pseudo-class that has been previously discussed here and in the CSS WG, it might also be nice to check if the element matches the selector in relation to a specified reference element. For example, given 2 elements, div1 and div2, you could check if div2 is a sibling of div1 like this: div2.matchesSelector(:scope~div, div1); In this case, the div1 would be the reference element that is matched by :scope. But we still need to determine how useful such functionality would be, and whether it's worth pursuing it in this next version. *Filtering NodeLists* http://www.w3.org/Bugs/Public/show_bug.cgi?id=5864 The suggestion is for being able to take a NodeList, and filter the nodes to obtain a collection of just those that match a given selector. For example, being able to get a NodeList somehow, do something with it, and then filter it more to work with just a subset: e.g. var list = document.querySelctor(divp); // Do something with list, before obtaining the subset subset = list.filterSelector(.foo); ... We need to find and document the possible use cases for this feature. *Scoped Queries* http://www.w3.org/Bugs/Public/show_bug.cgi?id=5860 This has been discussed extensively in the past. Basically, the idea is that the selector would be evaluated in the scope of the element, in a way more compatible with how libraries like JQuery work. This slightly different from the :scope pseudo-class proposal, see bug for details. *Collective Queries on NodeLists* http://www.w3.org/Bugs/Public/show_bug.cgi?id=7707 The suggestion is to be able to run querySelector() and querySelectorAll() on NodeList, and have the result be the union of results in document order from running the method on each Element in the NodeList. e.g. list.querySelectorAll(p); Would be somewhat equivalent to running list[i].querySelectorAll(p); for on each element in the list, and then building an array with the union of distinct elements from all the results. I've been told that similar functionality for this already exists in JQuery. I believe the expectation is that both NodeList.querySelector() and .querySelectorAll() would work. The difference is that querySelector() on a NodeList would return a NodeList (unlike on Element which just returns a single element) containing the first matches from each node in the list. i.e. equivalent to running list[i].querySelector() on each node and then combining all results into an array. It also seems sensible to allow the new scoped methods to be used in an analogous way on NodeLists. *Namespace Prefix Resolution* http://www.w3.org/Bugs/Public/show_bug.cgi?id=6290 The most controversial issue of the lot. Need to clearly document the use cases and evaluate the problems being solved, and determine if it's really worth addressing in this version. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] Summary of Feature Requests for v2
On Wed, Sep 23, 2009 at 8:17 PM, John Resig jere...@gmail.com wrote:
Quick Summary of my opinions:
Matches Selector: Super-super useful - critical, in fact. We're not able to
remove jQuery's selector engine until this is implemented. I'm working with
the devs at Mozilla to get an implementation landed. Already have a test
suite in place.
And we have a patch :) So this should be available in Firefox 3.6 I hope.
Filtering NodeLists/StaticNodeLists, Queries on NodeLists/StaticNodeLists:
Neither of these are useful, as is, to libraries. What is actually useful is
the ability to run these against an array (or array-like collection) of DOM
nodes.
Very good input!
If I can do:
document.querySelectorAll.call([document.getElementById(node1),
document.getElementById(node2)], div span); then yes, this proposal is
useful. Rarely do libraries store raw NodeLists (they need to be converted
into an array or array-like collection first).
I think filtering can easily be done using the filter function that's
available in Firefox these days. Don't know what the implementation
situation is for other UAs. But something like
filteredArray = myArrayOfNodes.filter(function(node) { return
node.matchesSelector(someselector); });
For querySelectorAll on arrays to work we'd need some function that
can merge multiple nodelists. Once you have that you can easily use
Array.map to get what you need.
Scoped Queries: Also critical. As it stands, in jQuery, we just punt
whenever does a query rooted to a DOM element and fallback to the old
selector engine.
Does the :scope selector solve things for you? Or does it not because
of selectors like foo, bar, or even foo, bar?
/ Jonas
Re: [selectors-api] Scoped Queries
John Resig wrote: Libraries already parse selector queries anyway. And some of them add non-standard selectors and presumeably will continue to do so. I don't think it is an issue. However the parsing only happens after the selector has been passed to the native querySelectorAll implementation. We assume the qSA will provide the fastest solution. If it throws an exception we then branch off into the old, slower, selector engine and forget qSA entirely. Since there's no good error-reporting coming from qSA we can't, reasonably, determine how or why an error happened (was it a syntax error (foobar)? is the selector supposed to be supported but just isn't (div:nth-of-type(2) in IE 8)? does it look like a valid selector but there's no existing implementation (div:first)?). If there were two solutions, one that forced you to use :scope in front of all queries (or sub-queries) and one that had a separate method that handled cases like div properly, I'd take the latter. Parsing queries sucks and is slow, it's easier to just pass all of that off to the browser. --John Yes, it will have to be a new method. div may be unambiguously :scope div, but if you allow it then people will expect div p to be :scope div pwhich would conflict the current definition.
Re: [selectors-api] Scoped Queries
Jonas Sicking wrote:
On Wed, Sep 23, 2009 at 6:00 PM, Sean Hogan shogu...@westnet.com.au wrote:
Jonas Sicking wrote:
On Wed, Sep 23, 2009 at 4:51 AM, Lachlan Hunt lachlan.h...@lachy.id.au
wrote:
*Scoped Queries*
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5860
This has been discussed extensively in the past. Basically, the idea is
that the selector would be evaluated in the scope of the element, in a
way
more compatible with how libraries like JQuery work. This slightly
different from the :scope pseudo-class proposal, see bug for details.
Note that what makes the strong, em selector (which apparently
some libraries support) hard to support spec-wise is that that is not
in fact valid CSS syntax. It's certainly possible to define behavior
for it, it's pretty clear to me how it's intended to work, but it
would mean specifying our own syntax.
It is clear how it is intended to work, but it is less powerful than a
:scope selector.
I suggest it is a low priority feature.
But a :scope selector by itself doesn't help if the passed in selector
to the library contains a comma separated selector like foo, bar.
However if supporting commaseparated queries is critical for libraries
then I see no other choise. We'll one way or another have to specify
our own syntax, though it can be heavily based on the productions in
the Selector spec.
/ Jonas
Libraries already parse selector queries anyway. And some of them add
non-standard selectors and presumeably will continue to do so. I don't think
it is an issue.
The input I've gotten from library developers is that they would love
to not have to ship a selector engine. Apparently it would reduce the
size of for example jQuery with about 10k which is pretty significant.
/ Jonas
They could. If something like the following is not sufficient it
probably means they aren't happy with the native selector engine. In
that case they will be providing their own anyway.
Element.prototype.queryScopedSelectorAll = function(selector) {
var validSel = :scope + selector.replace(,, , :scope );
return this.querySelectorAll(validSel);
}
Re: [selectors-api] Summary of Feature Requests for v2
On Sep 23, 2009, at 5:26 PM, Jonas Sicking wrote: On Wed, Sep 23, 2009 at 4:51 AM, Lachlan Hunt lachlan.h...@lachy.id.au wrote: *Scoped Queries* http://www.w3.org/Bugs/Public/show_bug.cgi?id=5860 This has been discussed extensively in the past. Basically, the idea is that the selector would be evaluated in the scope of the element, in a way more compatible with how libraries like JQuery work. This slightly different from the :scope pseudo-class proposal, see bug for details. Note that what makes the strong, em selector (which apparently some libraries support) hard to support spec-wise is that that is not in fact valid CSS syntax. It's certainly possible to define behavior for it, it's pretty clear to me how it's intended to work, but it would mean specifying our own syntax. However if supporting commaseparated queries is critical for libraries then I see no other choise. We'll one way or another have to specify our own syntax, though it can be heavily based on the productions in the Selector spec. I think we can define an algorithm for turning an implicitly scoped pseudo-selector like strong, em into a proper selector using :scope -- in this case :scopestrong, :scopeem. We could either have an API entry point that takes a scoped pseudo-selector, defined as transforming to a real selector plus establishing a scope node, or just present the algorithm as an option for libraries that want to expose pseudo-selector syntax. Regards, Maciej
