Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied
On Sun, 17 Jun 2012 13:10:11 +0200, Kang-Hao (Kenny) Lu kennyl...@csail.mit.edu wrote: 1. Explicitly undefine this case. That would not be my preference. 2. Spec IE9, Firefox13 and Opera12alpha's behavior Roughly speaking, the choice is an invalid token or '|' whichever comes first, but I'd note that in the corner case These are valid: |a *|a My proposed spec change: # If the group of selectors include namespace prefixes that need to # be resolved, the implementation must raise a NAMESPACE_ERR # exception. s/NAMESPACE_ERR/SYNTAX_ERR/ -- Simon Pieters Opera Software
Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied
On 2012-06-18 04:29, Boris Zbarsky wrote: Consider how this is parsed in a depth-first recursive descent parser: a|b +, 1) The identifier a is scanned. This might be a tag name or a namespace; look at the next token. 2) The symbol '|' is scanned. Great. a was a namespace. Resolve it. And you're done. You have an error and bail out. You never even got to the '+'. This is a good reason not to strictly define one having precedence over the other. That leaves 2 options: Leaving it explicitly undefined (only mildly better than the current situation) or using only syntax error. Since it seems there are no objections to the latter option, and a few people in favour of that, I've tentatively updated both drafts to reflect this. It now states: If the group of selectors include namespace prefixes that need to be resolved, the implementation must raise a SYNTAX_ERR exception I also removed the note about non-namespace supporting implementations throwing a syntax error instead of a namespace error. http://dev.w3.org/2006/webapi/selectors-api/#resolving-namespaces http://dev.w3.org/2006/webapi/selectors-api2/#resolving-namespaces -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: CfC: publish FPWD of Fullscreen spec; deadline May 24
On 5/30/12 10:38 AM, ext Daniel Glazman wrote: Le 30/05/12 14:43, Arthur Barstow a écrit : Chris, Daniel, Peter - when will the CSS WG make a decision on the FPWD? We'll try to make one today during our weekly conf-call. Please note that we're going to review the bits of this document falling under CSS WG's wings. In particular section 6. Peter and I already have discovered a few things : 1. position: center in section 6.1 refers to an Editor's Draft that is not actively discussed at this time. Only normative references should be made to CSS specs or the Fullscreen draft will have to wait until that ED becomes a REC to itself become a REC. 2. the ::backdrop pseudo-element is not explained in the document outside of section 6.2. It's unclear to me why it is needed, what it represents, etc. 3. the parenthesis in section 6.2 seems to me to contain a copy/paste error above the element below the element 4. layer and layer 10 in section 6.1 are unclear. Layer is used nowhere in CSS references used in this spec. This must be clarified. Does the latest ED http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html address the above concerns? -Thanks, AB I note that these 4 points should have been resolved long ago but nobody ever pinged the CSS WG about this document between beginning of february and now. I request that joint efforts become really joint efforts, thanks. Outside of the direct scope of the CSS WG, I would personnally add: 1. the definition of requestFullScreen() says what are the steps it should run but it does not even say what feature it provides. I think a sentence saying The requestFullScreen() method sends a request for the Element to go fullscreen. Please see section 7 for the Security Considerations attached to this method. is needed. 2. allowfullscreen and iframe in section 7 should be hyperlinks. I note the reference is at WHATWG while it should be at W3C. /Daniel
Re: Updates to Selectors API
On 6/14/12 10:11 AM, ext Lachlan Hunt wrote: Hi, I have updated the specification for Selectors API Level 1, which is currently in CR. Most of it was editorial in nature, to bring it in line with Selectors API Level 2, except without adding any of the new features like findAll() or or matches(). Importantly, the IDL has now been updated to comply with the most recent WebIDL specificiation. This was basically to split it up into 3 partial interfaces, just like what was previously done in v2. Some of the prose was rewritten, but none of the changes should adversely affect implementation requirements. This was mostly done by back porting the content from v2, but while ensuring that all the normative references still refer to the older, stable specs. (e.g. DOM3Core instead of using DOM4, as is used in the v2 draft.) This now makes v1 a proper subset of v2. In the process, I also made a few minor editorial changes to v2 just to tidy it up. At this stage, we should be able to publish v1 as a revised CR, or possibly move it up to PR. I like the changes Lachlan, especially the new section 6.4. Although I have argued to the Advisory Committee and Advisory Board the process should (under certain circumstances) permit a CR to be directly re-published as a CR, that currently is not possible. Nevertheless, I think it could be a bit tricky to argue to the Director in this case that there were no substantive changes (e.g. the new 6.4) so my recommendation is that we publish a new LCWD with the minimum 3-week review period (and make sure all of the changes can be reviewed). At the end of the LC review period, if no substantive changes are needed, and we already have sufficient interop data (i.e. the 2009 CR exit criteria is already met), we could skip a new CR and directly publish a PR. Do you or Chaals have the interop data now (and if so, where is it)? What do you think about going the LC-PR route? We can also publish v2. as a new WD. If you want me to start a CfC to publish a new WD of v2, just let me know. -Thanks, Art Alternatively, we could forgo any further progress with v1 and let v2 supersede it entirely, at which point I could simply rename it back to Selectors API without a version number and move on. (This is my preferred approach). http://dev.w3.org/2006/webapi/selectors-api/ http://dev.w3.org/2006/webapi/selectors-api2/
Re: Updates to Selectors API
On 2012-06-18 13:57, Arthur Barstow wrote: In the process, I also made a few minor editorial changes to v2 just to tidy it up. At this stage, we should be able to publish v1 as a revised CR, or possibly move it up to PR. I like the changes Lachlan, especially the new section 6.4. Although I have argued to the Advisory Committee and Advisory Board the process should (under certain circumstances) permit a CR to be directly re-published as a CR, that currently is not possible. Nevertheless, I think it could be a bit tricky to argue to the Director in this case that there were no substantive changes (e.g. the new 6.4) so my recommendation is that we publish a new LCWD with the minimum 3-week review period (and make sure all of the changes can be reviewed). OK. Let's get started on that process. Do you or Chaals have the interop data now (and if so, where is it)? What do you think about going the LC-PR route? Opera, Firefox, Safari, Chrome and IE all pass 100% of the baseline (HTML/CSS 2.1 selectors) and additional (HTML/Selectors 3) tests. Firefox, Safari and Chrome also pass 100% of the XHTML/Selectors 3 tests. Opera only passes 99.2% of these and IE only passes 67.7% of these. However, these are additional tests that are not required to declare interoperability of the API, as the failures relate more to XHTML and Selectors support, rather than any particular bug with the API. http://dev.w3.org/2006/webapi/selectors-api-testsuite/ Do I need to prepare some kind of formal testsuite report with the results for each test? However, with the recent change from NAMESPACE_ERR to SYNTAX_ERR, this test suite will need to be updated with new tests, so this will likely delay PR for a little bit longer. We can also publish v2. as a new WD. If you want me to start a CfC to publish a new WD of v2, just let me know. Yes please. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: Updates to Selectors API
On 6/18/12 8:34 AM, ext Lachlan Hunt wrote: On 2012-06-18 13:57, Arthur Barstow wrote: In the process, I also made a few minor editorial changes to v2 just to tidy it up. At this stage, we should be able to publish v1 as a revised CR, or possibly move it up to PR. I like the changes Lachlan, especially the new section 6.4. Although I have argued to the Advisory Committee and Advisory Board the process should (under certain circumstances) permit a CR to be directly re-published as a CR, that currently is not possible. Nevertheless, I think it could be a bit tricky to argue to the Director in this case that there were no substantive changes (e.g. the new 6.4) so my recommendation is that we publish a new LCWD with the minimum 3-week review period (and make sure all of the changes can be reviewed). OK. Let's get started on that process. OK, I'll start the CfC for LC today. Do you or Chaals have the interop data now (and if so, where is it)? What do you think about going the LC-PR route? Opera, Firefox, Safari, Chrome and IE all pass 100% of the baseline (HTML/CSS 2.1 selectors) and additional (HTML/Selectors 3) tests. Firefox, Safari and Chrome also pass 100% of the XHTML/Selectors 3 tests. Opera only passes 99.2% of these and IE only passes 67.7% of these. However, these are additional tests that are not required to declare interoperability of the API, as the failures relate more to XHTML and Selectors support, rather than any particular bug with the API. http://dev.w3.org/2006/webapi/selectors-api-testsuite/ Do I need to prepare some kind of formal testsuite report with the results for each test? Yes, we do need to document the spec has interoperable implementations (and that is typically called the interop report). I think we have considerable flexibility on the format of the data. Here are a couple of examples: * Cam's Element Traversal http://www.w3.org/2008/webapps/ElementTraversal/index.html * Marcos' widget spec http://dev.w3.org/2006/waf/widgets/imp-report/ However, with the recent change from NAMESPACE_ERR to SYNTAX_ERR, this test suite will need to be updated with new tests, so this will likely delay PR for a little bit longer. OK, that's good to know. The LC's status section should include the URI of the interop report although that document can be empty when the LC is published. (I think the status section should also mention the group expects to skip CR and go directly to PR.) We can also publish v2. as a new WD. If you want me to start a CfC to publish a new WD of v2, just let me know. Yes please. Will do. -Thanks, Art
CfC: publish WD of Selectors API Level 2; deadline June 25
Lachlan would like to publish a new Working Draft of the Selectors API Level 2 spec and this is a Call for Consensus to do so using the following Editor's Draft as the basis http://dev.w3.org/2006/webapi/selectors-api2/. Agreement to this proposal: a) indicates support for publishing a new WD; and b) does not necessarily indicate support of the contents of the WD. If you have any comments or concerns about this proposal, please reply to this e-mail by June 25 at the latest. Positive response to this CfC is preferred and encouraged and silence will be assumed to mean agreement with the proposal. -Thanks, AB
CfC: publish a LCWD of Selectors API Level 1; deadline June 25
Lachlan has made some changes to the Selectors API Level 1 spec (last published as a CR) and we consider the changes sufficient to require the spec be published as a Working Draft (see the [1] thread). As such, this is a Call for Consensus to publish a new LCWD of this spec using the following document as the basis http://dev.w3.org/2006/webapi/selectors-api/. This CfC satisfies the group's requirement to record the group's decision to request advancement for this LCWD. Note the Process Document states the following regarding the significance/meaning of a LCWD: [[ http://www.w3.org/2005/10/Process-20051014/tr.html#last-call Purpose: A Working Group's Last Call announcement is a signal that: * the Working Group believes that it has satisfied its relevant technical requirements (e.g., of the charter or requirements document) in the Working Draft; * the Working Group believes that it has satisfied significant dependencies with other groups; * other groups SHOULD review the document to confirm that these dependencies have been satisfied. In general, a Last Call announcement is also a signal that the Working Group is planning to advance the technical report to later maturity levels. ]] If you have any comments or concerns about this CfC, please send them to public-webapps@w3.org by June 25 at the latest. Positive response is preferred and encouraged and silence will be considered as agreement with the proposal. The proposed LC review period is 3 weeks. -Thanks, AB [1] http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/1189.html
[selectors-api] Consider backporting find() behavior to querySelector()
So http://dev.w3.org/2006/webapi/selectors-api2/ introduces the methods find() and findAll() in addition to querySelector() and querySelectorAll() and changes the scoping behavior for the former methods to match what people expect them to do. I'm not convinced that doubling the API surface is a good idea. If we were to do that every time we find that a shipped API has suboptimal behavior, the API surface on the Web would grow exponentially and we wouldn't make the overall situation any better. What if we find a new problem with find() after it has shipped? Do we introduce yet another method? I think we should instead either fix the old API (if it turns out to not Break the Web) or live with past mistake (if it turns out it does). To find out whether it Breaks the Web (and the breakage can't be evanged), I suggest we ship the backwards-incompatible change to querySelector() in nightly/aurora (or equivalent) in one or more browsers for some time. -- Simon Pieters Opera Software
Re: [selectors-api] Consider backporting find() behavior to querySelector()
(12/06/18 22:45), Simon Pieters wrote: I think we should instead either fix the old API (if it turns out to not Break the Web) or live with past mistake (if it turns out it does). To find out whether it Breaks the Web (and the breakage can't be evanged), I suggest we ship the backwards-incompatible change to querySelector() in nightly/aurora (or equivalent) in one or more browsers for some time. I didn't read through all the QSA threads, but isn't the function name itself a mistake that many people don't want to live with? I'd rather like to see querySelector() marked as deprecated so it doesn't appear in tutorials in the future. Cheers, Kenny
RE: [selectors-api] Consider backporting find() behavior to querySelector()
-Original Message- From: Kang-Hao (Kenny) Lu [mailto:kennyl...@csail.mit.edu] (12/06/18 22:45), Simon Pieters wrote: I think we should instead either fix the old API (if it turns out to not Break the Web) or live with past mistake (if it turns out it does). To find out whether it Breaks the Web (and the breakage can't be evanged), I suggest we ship the backwards-incompatible change to querySelector() in nightly/aurora (or equivalent) in one or more browsers for some time. I didn't read through all the QSA threads, but isn't the function name itself a mistake that many people don't want to live with? I'd rather like to see querySelector() marked as deprecated so it doesn't appear in tutorials in the future. Despite being non-optimal according to a vocal sub-set of people, querySelector[All] has been deployed in browsers for around 3-4 years. I strongly oppose any notion of altering its behavior now. As to find/findAll, let's just make sure we get the behavior right the second time so we don't go through this again.
RE: publish WD of Selectors API Level 2; deadline June 25
From: Arthur Barstow [mailto:art.bars...@nokia.com] Lachlan would like to publish a new Working Draft of the Selectors API Level 2 spec and this is a Call for Consensus to do so using the following Editor's Draft as the basis http://dev.w3.org/2006/webapi/selectors-api2/. Positive response to this CfC is preferred and encouraged and silence will be assumed to mean agreement with the proposal. I support the publication of a new WD. -Travis
[Bug 17538] New: [IndexedDB] Remove error clauses for invalid index keys
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17538 Summary: [IndexedDB] Remove error clauses for invalid index keys Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: dave.n...@w3.org ReportedBy: jsb...@chromium.org QAContact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org The exception tables for IDBObjectStore's add() and put() methods include: DataError The calculated key for the insertion was not a valid key. Also thrown if the calculated key for any of the indexes which belong to this object store had a calculated key which was not a valid key However, consensus was reached that if the calculated key for an index is not a valid key then that index is simply skipped rather than failing the add()/put() -see steps for storing a record into an object store. I believe the second sentence (Also thrown if...) should be removed. -- Configure bugmail: https://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 FPWD of Fullscreen spec; deadline May 24
Sorry, looks like I accidentally dropped webapps from the CC list. Sending again... On 06/01/2012 05:02 AM, Anne van Kesteren wrote: On Wed, May 30, 2012 at 5:47 PM, fantasaifantasai.li...@inkedblade.net wrote: Though it seems likely that 'fixed' is required here, no? The top layer concept is also used by HTML for itsdialog element. This response doesn't seem to match the quoted sentence. ?? (You can add a note that the behavior of future values of 'position' is undefined, since we don't know what they will be and whether they'll need to be forced to 'fixed'.) I expect we'll just update the specification. If it's still actively edited at that point, sure. Since it is a pseudo-element, it should specify what properties apply to it. I'm not sure that anything other than the background properties need apply, but the spec should be explicit about what does and does not apply, at least in terms of CSS2.1 properties. Clarified. You also need to state its relationship to other elements in the tree. Right now its inheritance behavior is undefined. ~fantasai
Re: CfC: publish FPWD of Fullscreen spec; deadline May 24
On 06/18/2012 04:09 AM, Arthur Barstow wrote: On 5/30/12 10:38 AM, ext Daniel Glazman wrote: Le 30/05/12 14:43, Arthur Barstow a écrit : Chris, Daniel, Peter - when will the CSS WG make a decision on the FPWD? We'll try to make one today during our weekly conf-call. Please note that we're going to review the bits of this document falling under CSS WG's wings. In particular section 6. Peter and I already have discovered a few things : 1. position: center in section 6.1 refers to an Editor's Draft that is not actively discussed at this time. Only normative references should be made to CSS specs or the Fullscreen draft will have to wait until that ED becomes a REC to itself become a REC. 2. the ::backdrop pseudo-element is not explained in the document outside of section 6.2. It's unclear to me why it is needed, what it represents, etc. 3. the parenthesis in section 6.2 seems to me to contain a copy/paste error above the element below the element 4. layer and layer 10 in section 6.1 are unclear. Layer is used nowhere in CSS references used in this spec. This must be clarified. Does the latest ED http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html address the above concerns? It looks like you missed #2. ~fantasai
