RE: Questions on the future of the XHR spec, W3C snapshot
No need to make this a "vs."; we're all friends here :). FWIW previous specs which have needed to become abandoned because they were superceded by another spec have been re-published as NOTEs pointing to the source material. That is what I would advise for this case. Examples: - http://www.w3.org/TR/components-intro/ - https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html - http://lists.w3.org/Archives/Public/www-style/2014Oct/0295.html (search for "Fullscreen") -Original Message- From: Hallvord R. M. Steen [mailto:hst...@mozilla.com] Sent: Friday, October 17, 2014 20:19 To: public-webapps Subject: [xhr] Questions on the future of the XHR spec, W3C snapshot Apologies in advance that this thread will deal with something that's more in the realm of politics. First, I'm writing as one of the W3C-appointed "editors" of the "snapshot" the WebApps WG presumably would like to release as the XMLHttpRequest recommendation, but I'm not speaking on behalf of all three editors, although we've discussed the topic a bit between us. Secondly, we've all been through neverending threads about the merits of "TR, spec stability" W3C style versus "living standard, spec freedom and reality alignment" WHATWG style. I'd appreciate if those who consider responding to this thread could be to-the-point and avoid the ideological swordmanship as much as possible. When accepting editor positions, we first believed that we could ship a TR of XHR relatively quicky. (I think of that fictive TR as "XHR 2" although W3C haven't released any XHR 1, simply because CORS and the other more recent API changes feel like "version 2" stuff to me). As editors, we expected to update it with a "next version" if and when there were new features or significant updates). However, the WHATWG version is now quite heavily refactored to be XHR+Fetch. It's no longer clear to me whether pushing forward to ship XHR2 "stand-alone" is the right thing to do.. However, leaving an increasingly outdated snapshot on the W3C side seems to be the worst outcome of this situation. Hence I'd like a little bit of discussion and input on how we should move on. All options I can think of are: a) Ship a TR based on the spec just *before* the big Fetch refactoring. The only reason to consider this option is *if* we want something that's sort of stand-alone, and not just a "wrapper" around another and still pretty dynamic spec. I think such a spec and the test suite would give implementors a pretty good reference (although some corner cases may not be sufficiently clarified to be compatible). Much of the refactoring work seems to have been just that - refactoring, more about pulling descriptions of some functionality into another document to make it more general and usable from other contexts, than about making changes that could be observed from JS - so presumably, if an implementor followed the TR "2.0" standard they would end up with a generally usable XHR implementation. b) Ship a TR based on the newest WHATWG version, also snapshot and ship the "Fetch" spec to pretend there's something stable to refer to. This requires maintaining snapshots of both specs. c) Ship a TR based on the newest WHATWG version, reference WHATWG's Fetch spec throughout. d) Abandon the WebApps "snapshot" altogether and leave this spec to WHATWG. For a-c the editors should of course commit to updating snapshots and eventually probably release new TRs. Is it even possible to have this discussion without seeding new "W3C versus WHATWG" ideology permathreads? Input welcome! -Hallvord
[xhr] Questions on the future of the XHR spec, W3C snapshot
Apologies in advance that this thread will deal with something that's more in the realm of politics. First, I'm writing as one of the W3C-appointed "editors" of the "snapshot" the WebApps WG presumably would like to release as the XMLHttpRequest recommendation, but I'm not speaking on behalf of all three editors, although we've discussed the topic a bit between us. Secondly, we've all been through neverending threads about the merits of "TR, spec stability" W3C style versus "living standard, spec freedom and reality alignment" WHATWG style. I'd appreciate if those who consider responding to this thread could be to-the-point and avoid the ideological swordmanship as much as possible. When accepting editor positions, we first believed that we could ship a TR of XHR relatively quicky. (I think of that fictive TR as "XHR 2" although W3C haven't released any XHR 1, simply because CORS and the other more recent API changes feel like "version 2" stuff to me). As editors, we expected to update it with a "next version" if and when there were new features or significant updates). However, the WHATWG version is now quite heavily refactored to be XHR+Fetch. It's no longer clear to me whether pushing forward to ship XHR2 "stand-alone" is the right thing to do.. However, leaving an increasingly outdated snapshot on the W3C side seems to be the worst outcome of this situation. Hence I'd like a little bit of discussion and input on how we should move on. All options I can think of are: a) Ship a TR based on the spec just *before* the big Fetch refactoring. The only reason to consider this option is *if* we want something that's sort of stand-alone, and not just a "wrapper" around another and still pretty dynamic spec. I think such a spec and the test suite would give implementors a pretty good reference (although some corner cases may not be sufficiently clarified to be compatible). Much of the refactoring work seems to have been just that - refactoring, more about pulling descriptions of some functionality into another document to make it more general and usable from other contexts, than about making changes that could be observed from JS - so presumably, if an implementor followed the TR "2.0" standard they would end up with a generally usable XHR implementation. b) Ship a TR based on the newest WHATWG version, also snapshot and ship the "Fetch" spec to pretend there's something stable to refer to. This requires maintaining snapshots of both specs. c) Ship a TR based on the newest WHATWG version, reference WHATWG's Fetch spec throughout. d) Abandon the WebApps "snapshot" altogether and leave this spec to WHATWG. For a-c the editors should of course commit to updating snapshots and eventually probably release new TRs. Is it even possible to have this discussion without seeding new "W3C versus WHATWG" ideology permathreads? Input welcome! -Hallvord
Re: test coverage data for XHR spec
On Fri, Oct 17, 2014 at 10:55 PM, Hallvord R. M. Steen wrote: > Should I send you a PR now so you or I can play our with the linking and > styling (I'm very much aware that what the JS currently does to the spec is > ugly), or should I wait a few weeks and try to find time to clean up the > metadata and make sure the links land in the right places in the WHATWG spec? I think it's fine to have it now. It would be nice if it was opt-in through a checkbox so you don't get all the "ugly stuff" by default. -- https://annevankesteren.nl/
Re: test coverage data for XHR spec
>> I can send you a PR for that JSON file if you wish. For example make a new >> folder called "testcoveragedata" or something to put the JSON file inside? > If all we need is a single JSON file and maybe a script let's put them > in the top-level directory. Should I send you a PR now so you or I can play our with the linking and styling (I'm very much aware that what the JS currently does to the spec is ugly), or should I wait a few weeks and try to find time to clean up the metadata and make sure the links land in the right places in the WHATWG spec? -Hallvord
Re: CustomElement: Type extension on custom tag
Ah, interesting.
If custom element interfaces are treated differently, it seems like
this may negatively affect the "HTML as Custom Elements" work
(https://github.com/dglazkov/html-as-custom-elements). Type extensions
may or may not work depending on the element being truly native or
not.
On Thu, Oct 16, 2014 at 7:44 PM, Dominic Cooney wrote:
> Hi Joshua,
>
> I implemented Custom Elements in Chrome.
>
> In the definition construction algorithm, step 8.2, it says:
>
> "If BASE does not exist or is an interface for a custom element, set ERROR
> to InvalidName and stop."
>
> In this case, BASE is the x-button and it is an interface for a Custom
> Element. I think this is the case you're hitting. I think Chrome roughly
> matches the spec in this case.
>
> It's another question whether the spec could be changed to allow this. As an
> implementer, I would need to know if/what order each of the callbacks for
> x-button and x-submit-button were called in when something happened to an
> x-submit-button. There are also interesting cases like what happens if the
> x-submit-button is registered before the x-button, and whether other things
> are possible like type extensions that extend other type extensions.
>
> In short, step 8.2 avoids a lot of potential complexity by limiting what you
> can do with Custom Elements in this specific way.
>
> Dominic
>
>
> On Fri, Oct 17, 2014 at 7:36 AM, Joshua Peek wrote:
>>
>> Is it legal to register a type extension on top of an existing custom tag?
>>
>>
>>
>> var ButtonPrototype = Object.create(HTMLElement.prototype)
>> document.registerElement("x-button", {prototype: ButtonPrototype})
>>
>> var SubmitButtonPrototype = Object.create(ButtonPrototype)
>> document.registerElement("x-submit-button", {extends: "x-button",
>> prototype: SubmitButtonPrototype})
>>
>>
>> Chrome's native registerElement doesn't seem to like this. It throws
>> the following error.
>>
>> DOMException: Failed to execute 'registerElement' on 'Document':
>> Registration failed for type 'x-submit-button'. The tag name specified
>> in 'extends' is a custom element name. Use inheritance instead.
>>
>>
>> The current Custom Element spec doesn't say any specific about this
>> situation. Is Chrome wrong? Or is this something the spec should
>> explicitly disallow?
>>
>
Re: Push API and Service Workers
On Wed, Oct 15, 2014 at 3:07 PM, Shijun Sun wrote: > My understanding here is that we want to leverage the "push client" in the > OS. That will provide new capabilities without dependency on a direct > connection between the app and the app server. > You are correct about leveraging the underlying platform's push system, but without a serviceworker you still require the webapp itself to have an open window to handle the request, otherwise you risk launching an app with a UI when the user is not expecting it. Now the same thing can be accomplished by a push specific system where the app author declares a tiny JS file to be used as the push handler. In this case the 'tiny JS file' is the serviceworker since we are already building the infrastructure in. Nikhil
