[widgets] HTML5 dependency blocking Widget Interface Proposed Recommendation
Hi All, As I understand it, the W3C's publication precedence re normative references for a Proposed Recommendation, is that all W3C normative references must be at CR or a later maturity level. With today's publication of a CR of Web IDL [WebIDL-CR], the only W3C normative reference in the Widget Interface Candidate Recommendation [TWI-CR] that is not at CR or later is HTML5. Philippe, Ian - my understanding is that if the WG can show its uses of HTML5 are restricted to stable parts of the HTML5 spec, the Director will relax this publication precedence i.e. the Widget Interface may be published as a Proposed Recommendation. Is this correct? Marcos - would you please enumerate the CR's uses of HTML5 and state whether each usage is to a stable part of HTML5? -Thanks, AB [TWI-CR] http://www.w3.org/TR/2011/CR-widgets-apis-20111213/ [WebIDL-CR] http://www.w3.org/TR/2012/CR-WebIDL-20120419/
Re: [widgets] HTML5 dependency blocking Widget Interface Proposed Recommendation
On 19 Apr 2012, at 7:48 AM, Arthur Barstow wrote: Hi All, As I understand it, the W3C's publication precedence re normative references for a Proposed Recommendation, is that all W3C normative references must be at CR or a later maturity level. With today's publication of a CR of Web IDL [WebIDL-CR], the only W3C normative reference in the Widget Interface Candidate Recommendation [TWI-CR] that is not at CR or later is HTML5. Philippe, Ian - my understanding is that if the WG can show its uses of HTML5 are restricted to stable parts of the HTML5 spec, the Director will relax this publication precedence i.e. the Widget Interface may be published as a Proposed Recommendation. Is this correct? This is my expectation: https://lists.w3.org/Archives/Member/chairs/2011JulSep/0092.html Ian Marcos - would you please enumerate the CR's uses of HTML5 and state whether each usage is to a stable part of HTML5? -Thanks, AB [TWI-CR] http://www.w3.org/TR/2011/CR-widgets-apis-20111213/ [WebIDL-CR] http://www.w3.org/TR/2012/CR-WebIDL-20120419/ -- Ian Jacobs (i...@w3.org)http://www.w3.org/People/Jacobs/ Tel: +1 718 260 9447
Re: [widgets] HTML5 dependency blocking Widget Interface Proposed Recommendation
On Thursday, 19 April 2012 at 13:48, Arthur Barstow wrote: Marcos - would you please enumerate the CR's uses of HTML5 and state whether each usage is to a stable part of HTML5? 1. A browsing context that comes into existence after initialization. The concept of a browsing context is defined in [HTML]. Multiple widget instances can be instantiated from a single widget package. A widget instance is unique and does not share any DOM attribute values, widget storage area, or [Web Storage] storage areas with any other widget instance. Browsing context is a concept - and a well understood one at that. 2. User agent implementing [HTML]'s Window interface must implement the Widget interface as the widget attribute of the window object in the manner defined by the WindowWidget interface. The window object is present in all browser implementations. Widgets to put any additional requirements on it. 3. When getting or setting the preferences attribute, if the origin of a widget instance is mutable (e.g., if the user agent allows document.domain to be dynamically changed), then the user agent must perform the preference-origin security check. The concept of origin is defined in [HTML]. Origin is concept that is well understood - as is the same origin policy used by browsers. Hope that helps! -- Marcos Caceres http://datadriven.com.au
Re: [widgets] HTML5 dependency blocking Widget Interface Proposed Recommendation
On 4/19/12 8:57 AM, ext Ian Jacobs wrote: On 19 Apr 2012, at 7:48 AM, Arthur Barstow wrote: Hi All, As I understand it, the W3C's publication precedence re normative references for a Proposed Recommendation, is that all W3C normative references must be at CR or a later maturity level. With today's publication of a CR of Web IDL [WebIDL-CR], the only W3C normative reference in the Widget Interface Candidate Recommendation [TWI-CR] that is not at CR or later is HTML5. Philippe, Ian - my understanding is that if the WG can show its uses of HTML5 are restricted to stable parts of the HTML5 spec, the Director will relax this publication precedence i.e. the Widget Interface may be published as a Proposed Recommendation. Is this correct? This is my expectation: https://lists.w3.org/Archives/Member/chairs/2011JulSep/0092.html WebApps does all of its work in the Public. As such, would you or PLH please forward that email to a Public list (preferably public-webapps)? -Thanks, AB
Re: [widgets] HTML5 dependency blocking Widget Interface Proposed Recommendation
On Thursday, 19 April 2012 at 14:10, Arthur Barstow wrote: On 4/19/12 8:57 AM, ext Ian Jacobs wrote: On 19 Apr 2012, at 7:48 AM, Arthur Barstow wrote: This is my expectation: https://lists.w3.org/Archives/Member/chairs/2011JulSep/0092.html WebApps does all of its work in the Public. As such, would you or PLH please forward that email to a Public list (preferably public-webapps)? It says we can freely distribute the proposal to the group, so here it is: Dear Chairs, Documentation of our current practices for [0] for normative references states: In general, documents do not advance to Recommendation with normative references to W3C specifications that are not yet Recommendations. However, several Working Groups have expressed a desire to reference the HTML5 specification [1] even as a draft. The current expectation [2] is that the HTML5 specification will become a Recommendation in 2014. To address the needs of these groups sooner than 2014, we propose the following for normative references to HTML5 (and only to HTML5) from specifications scheduled to become Recommendations before HTML5. Please, provide feedback and comments on this proposal until 22 September 2011 . Unless there are objections, we plan to implement this proposal shortly thereafter. Feel free to circulate this proposal to your Working Groups. Philippe Le Hégaret and Ian Jacobs [0] http://www.w3.org/Guide/transitions [1] http://www.w3.org/TR/html5/ [2] http://www.w3.org/2011/02/htmlwg-pr.html = Proposal for Normative References While HTML5 is not a Recommendation * A Working Group X may propose normative references from a Proposed Recommendation or Recommendation to a set of definitions or implementable features in the HTML5 specification [1]. * Working Group X must indicate the presence of these references in any Proposed [Edited] Recommendation or Recommendation transition request. * The Director will evaluate these references and approve them when satisfied that Working Group X has provided evidence that: - The HTML Working Group has addressed all issues associated with the referenced HTML5 features or definitions, and that all issues have been resolved at least 60 days before the date of Working Group X's transition request. - All referenced HTML5 features have been implemented. Preferably, Working Group X should be able to demonstrate two interoperable implementations of each feature. If the Director believes that immediate Advisory Committee review is critical to the success of a technical report, the Director may accept normative references even without adequate HTML5 implementation experience.
CfC: publish Proposed Recommendation of Widget Interface; deadline April 26
Now that the normative references for the Widget Interface spec have advanced and we have documented the spec only uses stable features of HTML5 [1], the Widget Interface is ready for publication as a Proposed Recommendation. As such, this is Call for Consensus to publish a PR of this spec using the following ED as the basis: http://dev.w3.org/2006/waf/widgets-api/ Note the Process Document includes the following regarding the entrance criteria for a PR and the WG's requirements: [[ http://www.w3.org/2005/10/Process-20051014/tr.html#cfr * Shown that each feature of the technical report has been implemented. Preferably, the Working Group SHOULD be able to demonstrate two interoperable implementations of each feature. ]] As documented in this spec's CR [2], the CR exit criteria was met before the CR was published. If you have any comments about this proposal, please send them to public-webapps@w3.org by April 26 at the latest. Positive response is preferred and encouraged and silence will be considered as agreeing with the proposal. -AB [1] http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0246.html [2] http://www.w3.org/TR/2011/CR-widgets-apis-20111213/
Re: [widgets] HTML5 dependency blocking Widget Interface Proposed Recommendation
On Thu, Apr 19, 2012 at 7:06 AM, Marcos Caceres marcosscace...@gmail.comwrote: On Thursday, 19 April 2012 at 13:48, Arthur Barstow wrote: Marcos - would you please enumerate the CR's uses of HTML5 and state whether each usage is to a stable part of HTML5? 3. When getting or setting the preferences attribute, if the origin of a widget instance is mutable (e.g., if the user agent allows document.domain to be dynamically changed), then the user agent must perform the preference-origin security check. The concept of origin is defined in [HTML]. Origin is concept that is well understood - as is the same origin policy used by browsers. TWI [1] does not define the origin of a widget instance. Nor does HTML5. It is also confusing to say that HTML5 defines the 'concept of origin', given that it normatively refers to The Web Origin Concept [2]. TWI needs to be more specific about what aspect of Origin is being referenced and where that specific aspect is defined. [1] http://www.w3.org/TR/2011/CR-widgets-apis-20111213/ [2] http://tools.ietf.org/html/rfc6454
Re: [widgets] HTML5 dependency blocking Widget Interface Proposed Recommendation
On Thursday, 19 April 2012 at 15:58, Glenn Adams wrote: On Thu, Apr 19, 2012 at 7:06 AM, Marcos Caceres marcosscace...@gmail.com (mailto:marcosscace...@gmail.com) wrote: On Thursday, 19 April 2012 at 13:48, Arthur Barstow wrote: Marcos - would you please enumerate the CR's uses of HTML5 and state whether each usage is to a stable part of HTML5? 3. When getting or setting the preferences attribute, if the origin of a widget instance is mutable (e.g., if the user agent allows document.domain to be dynamically changed), then the user agent must perform the preference-origin security check. The concept of origin is defined in [HTML]. Origin is concept that is well understood - as is the same origin policy used by browsers. TWI [1] does not define the origin of a widget instance. That's because they are not bound to any particular URI scheme. Just to some origin. Nor does HTML5. It is also confusing to say that HTML5 defines the 'concept of origin', given that it normatively refers to The Web Origin Concept [2]. TWI needs to be more specific about what aspect of Origin is being referenced and where that specific aspect is defined. As there are no interoperability issues, I don't agree the TWI spec needs to be updated any further. It's just a simple spec and any further clarifications would just be academic. [1] http://www.w3.org/TR/2011/CR-widgets-apis-20111213/ [2] http://tools.ietf.org/html/rfc6454 -- Marcos Caceres http://datadriven.com.au
Re: [widgets] HTML5 dependency blocking Widget Interface Proposed Recommendation
On Thu, Apr 19, 2012 at 9:02 AM, Marcos Caceres marcosscace...@gmail.comwrote: On Thursday, 19 April 2012 at 15:58, Glenn Adams wrote: On Thu, Apr 19, 2012 at 7:06 AM, Marcos Caceres marcosscace...@gmail.com (mailto:marcosscace...@gmail.com) wrote: On Thursday, 19 April 2012 at 13:48, Arthur Barstow wrote: Marcos - would you please enumerate the CR's uses of HTML5 and state whether each usage is to a stable part of HTML5? 3. When getting or setting the preferences attribute, if the origin of a widget instance is mutable (e.g., if the user agent allows document.domain to be dynamically changed), then the user agent must perform the preference-origin security check. The concept of origin is defined in [HTML]. Origin is concept that is well understood - as is the same origin policy used by browsers. TWI [1] does not define the origin of a widget instance. That's because they are not bound to any particular URI scheme. Just to some origin. Nor does HTML5. It is also confusing to say that HTML5 defines the 'concept of origin', given that it normatively refers to The Web Origin Concept [2]. TWI needs to be more specific about what aspect of Origin is being referenced and where that specific aspect is defined. As there are no interoperability issues, I don't agree the TWI spec needs to be updated any further. It's just a simple spec and any further clarifications would just be academic. [1] http://www.w3.org/TR/2011/CR-widgets-apis-20111213/ [2] http://tools.ietf.org/html/rfc6454 in that case, please record an objection on my part
Re: [widgets] HTML5 dependency blocking Widget Interface Proposed Recommendation
On Thursday, 19 April 2012 at 16:04, Glenn Adams wrote: On Thu, Apr 19, 2012 at 9:02 AM, Marcos Caceres marcosscace...@gmail.com (mailto:marcosscace...@gmail.com) wrote: On Thursday, 19 April 2012 at 15:58, Glenn Adams wrote: On Thu, Apr 19, 2012 at 7:06 AM, Marcos Caceres marcosscace...@gmail.com (mailto:marcosscace...@gmail.com) (mailto:marcosscace...@gmail.com) wrote: On Thursday, 19 April 2012 at 13:48, Arthur Barstow wrote: Marcos - would you please enumerate the CR's uses of HTML5 and state whether each usage is to a stable part of HTML5? 3. When getting or setting the preferences attribute, if the origin of a widget instance is mutable (e.g., if the user agent allows document.domain to be dynamically changed), then the user agent must perform the preference-origin security check. The concept of origin is defined in [HTML]. Origin is concept that is well understood - as is the same origin policy used by browsers. TWI [1] does not define the origin of a widget instance. That's because they are not bound to any particular URI scheme. Just to some origin. Nor does HTML5. It is also confusing to say that HTML5 defines the 'concept of origin', given that it normatively refers to The Web Origin Concept [2]. TWI needs to be more specific about what aspect of Origin is being referenced and where that specific aspect is defined. As there are no interoperability issues, I don't agree the TWI spec needs to be updated any further. It's just a simple spec and any further clarifications would just be academic. [1] http://www.w3.org/TR/2011/CR-widgets-apis-20111213/ [2] http://tools.ietf.org/html/rfc6454 in that case, please record an objection on my part What, exactly, are you objecting to? Can you demonstrate that there is an issue?
Re: [widgets] HTML5 dependency blocking Widget Interface Proposed Recommendation
On Thu, Apr 19, 2012 at 9:04 AM, Glenn Adams gl...@skynav.com wrote: On Thu, Apr 19, 2012 at 9:02 AM, Marcos Caceres marcosscace...@gmail.comwrote: On Thursday, 19 April 2012 at 15:58, Glenn Adams wrote: On Thu, Apr 19, 2012 at 7:06 AM, Marcos Caceres marcosscace...@gmail.com (mailto:marcosscace...@gmail.com) wrote: On Thursday, 19 April 2012 at 13:48, Arthur Barstow wrote: Marcos - would you please enumerate the CR's uses of HTML5 and state whether each usage is to a stable part of HTML5? 3. When getting or setting the preferences attribute, if the origin of a widget instance is mutable (e.g., if the user agent allows document.domain to be dynamically changed), then the user agent must perform the preference-origin security check. The concept of origin is defined in [HTML]. Origin is concept that is well understood - as is the same origin policy used by browsers. TWI [1] does not define the origin of a widget instance. That's because they are not bound to any particular URI scheme. Just to some origin. Nor does HTML5. It is also confusing to say that HTML5 defines the 'concept of origin', given that it normatively refers to The Web Origin Concept [2]. TWI needs to be more specific about what aspect of Origin is being referenced and where that specific aspect is defined. As there are no interoperability issues, I don't agree the TWI spec needs to be updated any further. It's just a simple spec and any further clarifications would just be academic. [1] http://www.w3.org/TR/2011/CR-widgets-apis-20111213/ [2] http://tools.ietf.org/html/rfc6454 in that case, please record an objection on my part just to be clear, I mean an objection to publishing as PR unless this is clarified; i believe this is an issue because the concept and use of origin is (1) very complex and (2) thus prone to misinterpretation; for example, it is not well recognized that HTML5 itself does not require a UA to send an Origin header in a URL request (see [3]) [3] https://www.w3.org/Bugs/Public/show_bug.cgi?id=16574
Re: [widgets] HTML5 dependency blocking Widget Interface Proposed Recommendation
On Thursday, 19 April 2012 at 16:11, Glenn Adams wrote: in that case, please record an objection on my part just to be clear, I mean an objection to publishing as PR unless this is clarified; i believe this is an issue because the concept and use of origin is (1) very complex and (2) thus prone to misinterpretation; for example, it is not well recognized that HTML5 itself does not require a UA to send an Origin header in a URL request (see [3]) Yes, but those are issue of RFC6454 and the HTML5 spec (as well as Web Storage). But what does this have to do with Widgets?
Re: [widgets] HTML5 dependency blocking Widget Interface Proposed Recommendation
On Thursday, 19 April 2012 at 16:14, Marcos Caceres wrote: On Thursday, 19 April 2012 at 16:11, Glenn Adams wrote: in that case, please record an objection on my part just to be clear, I mean an objection to publishing as PR unless this is clarified; i believe this is an issue because the concept and use of origin is (1) very complex and (2) thus prone to misinterpretation; for example, it is not well recognized that HTML5 itself does not require a UA to send an Origin header in a URL request (see [3]) Yes, but those are issue of RFC6454 and the HTML5 spec (as well as Web Storage). But what does this have to do with Widgets? Glenn and I discussed this on IRC. Glenn suggested I add the following to the definition of a widget instance: The origin of a widget instance is the origin of the Document object associated with the widget instance's browsing context. I agree with Glenns recommendation, so I've go ahead and added that: http://dev.w3.org/2006/waf/widgets-api/#widget-instance -- Marcos Caceres http://datadriven.com.au
Re: [widgets] HTML5 dependency blocking Widget Interface Proposed Recommendation
On Thu, Apr 19, 2012 at 9:49 AM, Marcos Caceres w...@marcosc.com wrote: On Thursday, 19 April 2012 at 16:14, Marcos Caceres wrote: On Thursday, 19 April 2012 at 16:11, Glenn Adams wrote: in that case, please record an objection on my part just to be clear, I mean an objection to publishing as PR unless this is clarified; i believe this is an issue because the concept and use of origin is (1) very complex and (2) thus prone to misinterpretation; for example, it is not well recognized that HTML5 itself does not require a UA to send an Origin header in a URL request (see [3]) Yes, but those are issue of RFC6454 and the HTML5 spec (as well as Web Storage). But what does this have to do with Widgets? Glenn and I discussed this on IRC. Glenn suggested I add the following to the definition of a widget instance: The origin of a widget instance is the origin of the Document object associated with the widget instance's browsing context. I agree with Glenns recommendation, so I've go ahead and added that: http://dev.w3.org/2006/waf/widgets-api/#widget-instance thanks Marcos, I drop my objection; regarding the reference to HTML5, it would be an improvement if you could change section 6.5 from: The concept of origin is defined in [HTML]http://dev.w3.org/2006/waf/widgets-api/#html5 . to The concept of origin of a Document object is defined in [HTML]http://dev.w3.org/2006/waf/widgets-api/#html5 .
Re: [widgets] HTML5 dependency blocking Widget Interface Proposed Recommendation
On Thu, Apr 19, 2012 at 10:02 AM, Marcos Caceres marcosscace...@gmail.comwrote: On Thursday, 19 April 2012 at 16:57, Glenn Adams wrote: thanks Marcos, I drop my objection; regarding the reference to HTML5, Yay! :) it would be an improvement if you could change section 6.5 from: The concept of origin is defined in [HTML] ( http://dev.w3.org/2006/waf/widgets-api/#html5). to The concept of origin of a Document object is defined in [HTML] ( http://dev.w3.org/2006/waf/widgets-api/#html5). Done, and committed: http://dev.w3.org/2006/waf/widgets-api/#origin thanks for the speed of light resolution! :)
Re: [CORS] Applying preflight cache to an entire domain?
Thanks for the clarification, that makes sense. A little background on why I'm thinking about this. I've been investigating CORS performance on mobile. Mobile is a great use case for CORS since it is mostly guaranteed to be supported (at least on iOS and Android). However, the cost of making two HTTP requests per logical request can be expensive, especially in a mobile environment. The preflight cache is keyed on the origin/url pair. Furthermore, Chrome includes a max-preflight time on 5 minutes (not sure if other browsers do the same). So in an ideal scenario, the browser will be making one preflight request every 5 minutes. That doesn't sound so bad, but consider a typical RESTful API, where each resource is represented by a different url. The preflight cache will yield a cache hit in very narrow situations (perhaps while updating the same resource over and over again, or polling a particular endpoint). So I'm concerned that the cache-hit ratio in real world applications will actually be quite low. It would be nice to have some sort of solution to this. Thanks, Monsur On Wed, Apr 18, 2012 at 11:50 AM, Anne van Kesteren ann...@opera.comwrote: On Wed, 18 Apr 2012 18:34:42 +0200, Monsur Hossain mon...@gmail.com wrote: Ah thank you! I agree that url canonicalization is a difficult issue to solve. FWIW, I was envisioning something much simpler. The CORS spec makes it clear that cache lookup should be done by origin and request url. So instead of specifying a url to this Access-Control-Policy-Path header, it would be just one of three values: - url - (default behavior) Cache lookup is done by origin and request url, as the spec indicates now - origin - Cache lookup is done by origin only. Preflight response applies to any request from this origin. - any - Cache lookup applies to *any* origin making requests to the domain. This would fit in with the current preflight caching model while still allowing some flexibility to servers implementing CORS. The reason why we wanted it scoped was because people had concerns about giving any URL on a server control over which other resources would end up being shared. The scenarios typically involved large organizations with many different teams operating on a single origin. If one of those teams thinks sharing with everyone is fine, the rest can be comprised. And such a mistake is rather easy to make. Another general concern that has been frequently raised and why the specification has so many flags for enabling additional features such as headers and methods, is that people easily shoot themselves in the foot. Your proposal makes it rather easy for them to shoot themselves in the foot. -- Anne van Kesteren http://annevankesteren.nl/
