Re: [selectors-api] Matching of :scope in document.querySelector(All)
On 2012-11-30 03:01, Boris Zbarsky wrote: When implementing :scope support, I discovered that as things stand this call: document.querySelector(:scope) is specified to return null. In particular http://dev.w3.org/2006/webapi/selectors-api2/#queryselector step 1 calls http://dev.w3.org/2006/webapi/selectors-api2/#determine-contextual-reference-nodes which returns an empty set. Then this empty set is passed as an explicit contextual reference set to selector matching in http://dev.w3.org/2006/webapi/selectors-api2/#evaluate-a-selector so that :scope doesn't match anything. Is this intentional? I believe the spec was written the way it was to deal with the case where an explicitly empty set of reference nodes was given for find() and findAll(). So it seems the current spec ended up treating these in the same way by matching nothing: document.querySelector(:scope) document.findAll(:scope) document.findAll(:scope, null) document.findAll(:scope, []) I would have expected the above call to return the documentElement, which is what :scope would match in a non-scoped stylesheet... I can change the spec to make the first 2 examples above match documentElement, but keep the latter two with explicit refNodes parameters matching nothing. -- Lachlan Hunt http://lachy.id.au/ http://www.opera.com/
Re: CfC: publish WD of XHR; deadline November 29
Just a reminder: this group is a forum for discussion of technical specifications, and follows the existing W3C process. Discussion of what process *should* be is off topic here. On Sun, 02 Dec 2012 12:07:20 +0100, Jungkee Song jungk...@gmail.com wrote: On Sun, Dec 2, 2012 at 11:07 AM, James Robinson jam...@google.com Sure there is if the W3C version is stale, as is the case here. I don't think it's a technical issue to discuss. Right. Although there are technical aspects to the discussion, it is a process issue. There should be corresponding publication rules. We could hassle W3C into updating pubrules so it is clear. I have take the action item. Art, Charles, Doug, Can you help clarifying which links we have to use? By longstanding practice W3C specifications point where possible to references where W3C provides change control, its own guarantee of permanence, and its patent policy. General practice is to point to stable documents in normative references (e.g. the latest /TR version of something), allowing informative references to more or less anything you think is interesting. Until people started playing politics to the point of trying to usurp change control through parallel references it seems nobody was terribly worried about this. The requirement isn't documented in pubrules last I looked, but by process W3C could change that with 10 minutes of work. I am not even sure that the rationale is clearly documented in any one place at the moment. Like the rest of W3C it has developed over a couple of decades. From my understanding reasons for the practice include the following: - W3C aims to provide stable specifications that can be used as references which won't change. This is a general underpinning of its policy for specifications published as TR documents. Making a normative reference to an unstable document obviously defeats this purpose. - Since 2005 W3C patent commitments are given by W3C participants to the work of W3C working groups. Unstable documents that from time to time have, or had, more or less equivalent content, are not a replacement for those who care about W3C's IPR policy - which includes people far beyond the scope of W3C's own membership. Although WHAT-WG is a Community Group, its living standard model has explicitly disavowed making a final specification. This seriously limits patent commitment even from its own members. - A couple of years ago, W3C was granted PAS submission status, after applying for this at the urging of many of its members and of non-member consumers of its specifications. This relies on lots of things, but one of them is a certain clarity of process. ISO accepted W3C's process. I don't know if they would be prepared to accept that of the WHAT-WG. I don't even know anyone who cares enough to find out. In the meantime, I suspect this is another reason not to make normative references to the WHAT-WG's work and in particular to unstable documents. In the proposed version, I've changed the links to the following specs: - [CORS], [DOM], [DOMPS], [HTML] from the WHATWG version to the latest W3C TR doc. - [FILEAPI], [PROGRESSEVENTS], [WEBIDL] from the latest W3C ED to the latest W3C TR doc. I think that was reasonable. If any of those documents don't carry a link to their W3C editors' drafts, it might be useful to also provide them as an *informative* reference. That commit replaced a link to http://xhr.spec.whatwg.org/, last updated roughly a week ago, with a link to http://www.w3.org/TR/XMLHttpRequest/ which is dated January 17th and is missing an entire section (section 6). This change does not affect any links in the result doc, and in fact this proposed publication will reduce the gap. The proposed WD is aligned with the WHATWG version except: - Progress Events is not merged but staying as a separate spec. Seems reasonable. As I said in one-on-one conversation at TPAC (and maybe repeated for minutes - I forget), I would prefer not to merge these. If this is controversial we can raise an issue on it. - Streams API is deferred to next version. You mean next version of XHR, or next draft of this spec? Either way, I don't see that this should stop publication. - The last three commits (Nov 22) in WHATWG has not been incorporated yet. We're publishing a Working Draft. And we are happy to produce a stabilised version and work on a new one. We want better specs, but making perfection the enemy of getting a spec good enough to use is not a goal. It also replaced a link to http://fetch.spec.whatwg.org/# with http://www.w3.org/TR/cors/# which is similarly out of date by the better part of a year and lacking handling for some HTTP status codes. Every single reference updated in this commit changed the document to point to an out-of-date and less valuable resource. It seems that you, like the author of the commit message, mistakenly
Re: CfC: publish WD of XHR; deadline November 29
On 12/03/2012 01:44 PM, Charles McCathie Nevile wrote: Just a reminder: this group is a forum for discussion of technical specifications, and follows the existing W3C process. Discussion of what process *should* be is off topic here. I find it unfortunate that you try to cut off discussions relevant to technical issues with our specifications by calling them process discussions. From my understanding reasons for the practice include the following: - W3C aims to provide stable specifications that can be used as references which won't change. This is a general underpinning of its policy for specifications published as TR documents. Making a normative reference to an unstable document obviously defeats this purpose. The argument that TR documents are in some way more stable than other documents is simply fallacious. This has been discussed at length here and in other venues; I won't go into it again. Furthermore, I should point out that referencing the TR draft of WebIDL would (if anybody tried to implement the TR spec and its TR references; nobody does, of course) lead to a specification that is not implementable. The WebIDL used in XHR is not valid according to the 19 April 2012 CR of WebIDL. - A couple of years ago, W3C was granted PAS submission status, after applying for this at the urging of many of its members and of non-member consumers of its specifications. This relies on lots of things, but one of them is a certain clarity of process. ISO accepted W3C's process. I don't know if they would be prepared to accept that of the WHAT-WG. I don't even know anyone who cares enough to find out. In the meantime, I suspect this is another reason not to make normative references to the WHAT-WG's work and in particular to unstable documents. I do not see how this is relevant; I though the process was clear, and that it did not censor references to particular organizations. That's not in the W3C pub rules or a good idea. It isn't written there, although it has been applied for as long as I can remember (which stretches back to before pubrules was a document). I would love to hear examples of where such a rule was applied before the W3C started co-publishing WHATWG specifications; in particular, cases where the W3C publication was significantly out-of-date in comparison to the alternative. To the extent W3C thinks this should apply, they should indeed write it in there, since it has recently become contentious. As long as the rule doesn't exist, one can hardly expect editors to comply with it. If we expect editors to simply do as we did before, we'd be stuck with DOM2-style specifications; I think we all agree that would not be good for interoperability. Pubrules doesn't, as far as I know, prohibit f-bombs in specs. W3C working group members, including editors, are expected to be socially competent adults, which is a catch-all for what would otherwise be an endless set of statements like people who know not to use the 'f word' in a spec even without a written rule. (If I recall correctly this is in section 3.1 of the process document. It certainly isn't worth looking up). I find this comparison, in particular, to be unhelpful and rather rude. Nobody is suggesting using expletives in specifications. The only parallel I can imagine with the current situation is that some people seem offended by the existence of the WHATWG, and for some reason want to make sure no W3C publication ever mentions it. I had hoped we had been able to come to a somewhat more mature relationship between this WG and the WHATWG after the recent discussions about attribution, but changes like this make me lose confidence in the goals of the W3C Team and the chairs of this WG on this matter. I maintain my technical objections to the publication. HTH Ms2ger
Re: [selectors-api] Matching of :scope in document.querySelector(All)
On 12/3/12 7:33 AM, Lachlan Hunt wrote: So it seems the current spec ended up treating these in the same way by matching nothing: document.querySelector(:scope) document.findAll(:scope) document.findAll(:scope, null) document.findAll(:scope, []) That's how I read it, yes. I can change the spec to make the first 2 examples above match documentElement, but keep the latter two with explicit refNodes parameters matching nothing. That sounds great to me. Thanks! -Boris
RE: Re: Event.key complaints?
When were you thinking of kicking off the DOM4 Events process? I'd like to have a draft up this week. We may also ask for a FPWD if we're ready by the 10th. I want to have D4E rolling so that stuff we chose to punt from D3E has a landing pad. From: gary...@google.com [mailto:gary...@google.com] On Behalf Of Gary Kacmarcik (?) Sent: Friday, November 30, 2012 6:09 PM To: Travis Leithead Cc: Hallvord Reiar Michaelsen Steen; public-webapps@w3.org Subject: Re: Re: Event.key complaints? On Fri, Nov 30, 2012 at 4:29 PM, Travis Leithead travis.leith...@microsoft.commailto:travis.leith...@microsoft.com wrote: Awesome stuff Gary. (And I like that we won't need to change the behavior of key or char in your proposal—that part made me really nervous, since IE has shipped this stuff since 9, and I know our new Win8 app model is using it.) I'm planning in the short term to start a new DOM4 Events spec, which will be the successor to DOM3 Events. I brought this up at TPAC and there were no objections. Gary, I'd love you collaboration on specifying your new code property in that spec. Sounds good to me. I still have some comments to make on the DOM3 Events spec, but I'll still send them out knowing that some of them will need to be punted to DOM4. When were you thinking of kicking off the DOM4 Events process? -Gary
Re: Re: Event.key complaints?
On Mon, Dec 3, 2012 at 9:48 AM, Travis Leithead travis.leith...@microsoft.com wrote: When were you thinking of kicking off the DOM4 Events process? ** ** I'd like to have a draft up this week. We may also ask for a FPWD if we're ready by the 10th. ** ** I want to have D4E rolling so that stuff we chose to punt from D3E has a landing pad. +1 This will make things a lot smoother for D3E I think and allows us to avoid stalling all DOM Event spec work while we try to finalize D3E. *From:* gary...@google.com [mailto:gary...@google.com] *On Behalf Of *Gary Kacmarcik (?) *Sent:* Friday, November 30, 2012 6:09 PM *To:* Travis Leithead *Cc:* Hallvord Reiar Michaelsen Steen; public-webapps@w3.org *Subject:* Re: Re: Event.key complaints? ** ** On Fri, Nov 30, 2012 at 4:29 PM, Travis Leithead travis.leith...@microsoft.com wrote: Awesome stuff Gary. (And I like that we won't need to change the behavior of key or char in your proposal—that part made me really nervous, since IE has shipped this stuff since 9, and I know our new Win8 app model is using it.) I'm planning in the short term to start a new DOM4 Events spec, which will be the successor to DOM3 Events. I brought this up at TPAC and there were no objections. Gary, I'd love you collaboration on specifying your new code property in that spec. ** ** Sounds good to me. I still have some comments to make on the DOM3 Events spec, but I'll still send them out knowing that some of them will need to be punted to DOM4. ** ** When were you thinking of kicking off the DOM4 Events process? ** ** -Gary ** **
Re: [webcomponents]: Changing API from constructable ShadowRoot to factory-like
Sorry for the late response. Adding more create* methods feels like a bug. I understand that there are a couple of concerns/arguments here: - Current implementations that aren't self-hosting are going to have trouble with the idea of unattached (floating) ShadowRoot instances - As a result, the mental model implementers seem to have is that new ShadowRoot(element) has side-effects *on the element*, and that pretty clearly feels wrong. A future when re-attaching a ShadowRoot to a different element solves this (root.attach(element)?), but it's not planned for now. - new may lead to errors when a ShadowRoot instance is allocated out of one window and an element to attach to is from another. The general DOM solution of allocate out of the element's ownerDocument window feels right here, but isn't elegant in some corner cases. So while I still favor something like new ShadowRoot().attach(element) or new ShadowRoot(element), I think I can live with the create*() version for now. I would like for us to support one of the forward-looking versions, however, if only in a known-limited form. On Tue, Nov 20, 2012 at 12:08 AM, Dimitri Glazkov dglaz...@google.comwrote: I made the change to the editor's draft: http://dvcs.w3.org/hg/webcomponents/rev/e0dfe2ac8104 You can read the shiny new parts of the spec here: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#extensions-to-element Please let me know if I goofed up something, preferably by filing bugs :) :DG
RE: [Workers] Worker same-origin and usage in JS libraries...
From: Ian Hickson [mailto:i...@hixie.ch] On Tue, 17 Jul 2012, Ian Hickson wrote: My plan is to make it so that cross-origin URLs start cross-origin workers. The main unresolved question is how to do this in an opt-in manner. The best idea I've come up with so far is having scripts that want to opt-in to being run in such a way start with a line line: // Cross-Origin Worker for: http://example.net ...or (for multiple domains): // Cross-Origin Worker for: http://example.com https://example.org ...or (for any domain): // Cross-Origin Worker for all origins ...but that doesn't seem super neat. Just as an update, I still plan to do this, but I'm currently waiting for browser vendors to more widely implement the existing Worker, SharedWorker, MessagePort, and PortCollection features before adding more features to this part of the spec. It would also be helpful to have confirmation from browser vendors that y'all actually _want_ cross-origin workers, before I spec it. I've had many folks as me why they can't just refer to a cross-origin work in the Worker constructor; after all, they can import the worker's dependent scripts via importScripts cross-origin... The only rationale I could give is that the spec indicates the new worker's origin info was based on the document's that spawned it. If the new worker's origin info is established via the requested resource, then you should get the same functionality, but without the same-origin initial restriction. (This may be an oversimplification, but it worked for me.) As to whether we _want_ it, these same folks are apparantely able to live with the current restrictions. They may just be deferring the bulk of the worker's content to importScripts at present to work-around this limitation.
Re: CfC: publish WD of XHR; deadline November 29
On Sat, 1 Dec 2012, Ms2ger wrote: I object to this publication because of this change: http://dvcs.w3.org/hg/xhr/rev/2341e31323a4 I agree. That change is offensive. It gives credit to dozens of people who have done basically nothing productive at all, for work that a few of us have spent years doing. I find the W3C's behaviour here to be increasingly out of control, as someone I spoke to recently put it. It's discourteous and uncivil. If the W3C wants to write their own specs then that's fine, but stop forking work done by other people who have no interest in working with the W3C at this time. This is just plagiarism. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
DOM Level 3 Events - minor comments
This is a list of typos and other minor formatting problems that I encountered while going through the current DOM Level 3 Event spec. A few of the things listed here are actual errors, but the majority fall into two categories: * Initial capital letter missing at the start of a note or warning. * Sentences glued together with a semi-colon instead of using periods and starting a new sentence. I didn't call out all of these. Many of these are perhaps a bit nit-picky, so please consider them suggestions or feel free to ignore if you disagree. -Gary 1.3 Stylistic Conventions = I'm not sure if it's worth listing them here or not, but the following stylistic conventions are not mentioned in this section even through they are used in the document: * Light green for constants (not to be confused with the brighter green highlighting used for character values. * Yellow for attributes * Blue for methods * Pink for parameters * Orange (with red text) for event types. Actually, these are somewhat hard to read. Has this particular text formatting been verified to be readable by people with color vision problems? 2. Glossary === In *character value*, Note: in source code... should begin with a capital In *candidate event handlers*, ...released or un-frozen after this set of of candidate event handlers... has duplicate 'of' In *event listener*, Note: ...will be provided as the first paramter to the user-defined function... - spelling of parameter In *event order*, Note: there can be... needs initial cap In *focus ring*, A focus ring is a an ordered set of... remove 'a' In *Unicode character categories, The term General Category is capitalized in official Unicode documentation. Suggest rewrite as A subset of the General Category values that are defined for each Unicode code point. This subset contains all the Letter (Ll, Lm, Lo, Lt, Lu), Number (Nd, Nl, No), Punctuation (Pc, Pd, Pe, Pf, Pi, Po, Ps) and Symbol (Sc, Sk, Sm, So) category values. 3.1 Event dispatch and DOM event flow = Caption for Figure 1 should be centered and start with a capital letter. ... The exception itself must not propogate outside the scope of the event handler. Spelling of 'propagate' In Example: In the following code, the exception thrown from the call to throw Error does not propogate into the parent scope, (which would prevent the console.log statement from executing): Comma before paren looks awkward. Spelling of 'propagate'. This specification defines three event phases: capture phase; target phase; and bubble phase. semi-colons should be commas The capture phase: the event object must propagate... initial cap since it starts a sentence. Same for 1, 2 and 3 in this list. 3.2 Default actions and cancelable events = In first Example, ...depends on what happens next--for example, if the user's pointing... double hyphen should be proper em-dash. In second Example, ...event on input type=checkbox elements... the input tag and attributes should be in a monospace font 3.3 Synchronous and asynchronous events === ...ordered by sequence of temporal occurrence, with respect to other events, to changes in the DOM... comma after occurrence makes this harder to read. In first Example, 'keydown' event is listed, but there is no corresponding 'keyup'. Is this intentional? 3.5.1 Activation event synthesis ...of the default actions of that activation trigger; the value of the Event.target... Period instead of semi-colon to ease readability. 3.6 Event exceptions Note: the exception EventException... initial cap. 4. Basic Event Interfaces = Figure 2: graphical representation of the DOM3 Events interface inheritance should have initial capital for 'Graphical' 4.1 Interface Event === For eventPhase, The un-initialized value of this attribute must be 0. could mention the defined constant NONE. Suggest: The un-initialized value of this attribute must be 0 (NONE). For stopImmediatePropagation, I think it would look better if the introduced in DOM Level 3 was enclosed in parentheses, as is done above for Interface Event (introduced in DOM Level 2). But that change would need to be made throughout this document for consistency. 4.3 Interface EventTarget = In the first Note, ...event type (see the List of DOM3 Event Types); for example, a mouseover event type... Semi-colon - period. The sentence is long enough already. The second Note uses italics for the code in ...use of attributes, e.g., onclick=handleClick() (see [HTML5] This isn't consistent with code elsewhere, so I don't believe it was intentional. addEventListener and removeEventListener should have a modified in DOM Level 3 note just like dispatchEvent. dispatchEvent might benefit from an Authoring Note (like
