PSA: public-webapps-github archives WebApps' Github activity
[ Bcc: public-editing-tf ] TL;DR: if you want to receive an e-mail notification for Webapps' spec related activity on Github, subscribe to the new public-webapps-github list [p-w-g]. Thanks to Robin's idea and Yves' perseverance, the new p-w-g list gets an e-mail for all of WebApps' GH activity. The following spec repos are now watched: heycam/webidl slightlyoff/ServiceWorker w3c/FileAPIv2 w3c/editing-explainer w3c/manifest w3c/packaged-webapps w3c/permissions w3c/push-api w3c/screen-orientation w3c/selection-api w3c/webcomponents whatwg/streams If any of WebApps' other spec repos are missing, please let me know and I will add a watch for them. Note: This list is primarily for archival purposes. It should *not* be used for discussion purposes. The RSS feed for this list is [RSS]. -Thanks, AB [p-w-g] http://lists.w3.org/Archives/Public/public-webapps-github/ [RSS] http://lists.w3.org/Archives/Public/public-webapps-github/feed.rss
RE: [url] Feedback from TPAC
Apologies for being a late comer to the discussion, but here is some feedback in our implementation. We're looking forward to engaging on these interactions more proactively in the future. On Wednesday, October 29, 2014 6:55 PM, Sam Ruby ru...@intertwingly.net wrote: Now to get to what I personally am most interested in: identifying changes to the expected test results, and therefore to the URL specification -- independent of the approach that specification takes to describing parsing. To kick off the discussion, here are three examples: 1) http://intertwingly.net/projects/pegurl/urltest-results/7357a04b5b A number of browsers, namely Internet Explorer, Opera(Presto), and Safari seem to be of the opinion that exposing passwords is a bad idea. I suggest that this is a defensible position, and that the specification should either standardize on this approach or at a minimum permit this. Yes, we, Microsoft, are of the opinion that exposing passwords is a bad idea. Based on received feedback, customers agree and I suspect our customers are not unique on this opinion. 2) http://intertwingly.net/projects/pegurl/urltest-results/4b60e32190 This is not a valid URL syntax, nor does any browser vendor implement it. I think it is fairly safe to say that given this state that there isn't a wide corpus of existing web content that depends on it. I'd suggest that the specification be modified to adopt the behavior that Chrome, Internet Explorer, and Opera(Presto) implement. Agreed. Standardizing something not used that is not in anyone's interest. What you have posted on Github: https://github.com/rubys/url/tree/peg.js/reference-implementation#readme .. I found I had a hard time determining what should be the parsing output for a number of cases. rings true here. There is no advantage to adding complexity when it is not required. 3) http://intertwingly.net/projects/pegurl/urltest-results/61a4a14209 This is an example of a problem that Anne is currently wrestling with. Note in particular the result produced by Chrome, which identifies the host as a IPV4 address and canonicalizes it. This is the type of interop issue we think should be a focus of the URL specification and the W3C efforts. Finally we are focused at identifying and fixing real-world interop bugs that we see in live sites in support our goal of The web should just work (http://blogs.msdn.com/b/ie/archive/2014/05/27/launching-status-modern-ie-amp-internet-explorer-platform-priorities.aspx). For example, I think you had at one time listed an IE issue in the discussion section of the URL spec - http://intertwingly.net/projects/pegurl/url.html#discuss. This bug was related to a missing / at the front of URLs under certain conditions. Since this issue has been removed from the discussion section, I am hoping you have seen that we have fixed the issue. We are actively pursuing and fixing similar interop bugs. We want the URL spec to be source of interop behavior and believe that our goal is in line with your direction. Cheers, _dave_
Re: [url] Feedback from TPAC
On 11/25/2014 03:52 PM, David Walp wrote: Apologies for being a late comer to the discussion, but here is some feedback in our implementation. We're looking forward to engaging on these interactions more proactively in the future. Thanks! Looking forward to it! Can I ask that you either open an issue or a bug (it matters not which to me) on each of these items. https://github.com/webspecs/url/issues https://www.w3.org/Bugs/Public/enter_bug.cgi?product=WHATWGcomponent=URL Feel free to link back to your original post on this topic in the issue/bug reports: http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0505.html I also actively encourage pull requests, so if you care to propose a change, I encourage you to do so. Finally, I've expanded that list since October. Here's a few more topics that you might want to weigh in on: http://intertwingly.net/projects/pegurl/url.html#discuss And by all means, don't stop there! - Sam Ruby On Wednesday, October 29, 2014 6:55 PM, Sam Ruby ru...@intertwingly.net wrote: Now to get to what I personally am most interested in: identifying changes to the expected test results, and therefore to the URL specification -- independent of the approach that specification takes to describing parsing. To kick off the discussion, here are three examples: 1) http://intertwingly.net/projects/pegurl/urltest-results/7357a04b5b A number of browsers, namely Internet Explorer, Opera(Presto), and Safari seem to be of the opinion that exposing passwords is a bad idea. I suggest that this is a defensible position, and that the specification should either standardize on this approach or at a minimum permit this. Yes, we, Microsoft, are of the opinion that exposing passwords is a bad idea. Based on received feedback, customers agree and I suspect our customers are not unique on this opinion. 2) http://intertwingly.net/projects/pegurl/urltest-results/4b60e32190 This is not a valid URL syntax, nor does any browser vendor implement it. I think it is fairly safe to say that given this state that there isn't a wide corpus of existing web content that depends on it. I'd suggest that the specification be modified to adopt the behavior that Chrome, Internet Explorer, and Opera(Presto) implement. Agreed. Standardizing something not used that is not in anyone's interest. What you have posted on Github: https://github.com/rubys/url/tree/peg.js/reference-implementation#readme .. I found I had a hard time determining what should be the parsing output for a number of cases. rings true here. There is no advantage to adding complexity when it is not required. 3) http://intertwingly.net/projects/pegurl/urltest-results/61a4a14209 This is an example of a problem that Anne is currently wrestling with. Note in particular the result produced by Chrome, which identifies the host as a IPV4 address and canonicalizes it. This is the type of interop issue we think should be a focus of the URL specification and the W3C efforts. Finally we are focused at identifying and fixing real-world interop bugs that we see in live sites in support our goal of The web should just work (http://blogs.msdn.com/b/ie/archive/2014/05/27/launching-status-modern-ie-amp-internet-explorer-platform-priorities.aspx). For example, I think you had at one time listed an IE issue in the discussion section of the URL spec - http://intertwingly.net/projects/pegurl/url.html#discuss. This bug was related to a missing / at the front of URLs under certain conditions. Since this issue has been removed from the discussion section, I am hoping you have seen that we have fixed the issue. We are actively pursuing and fixing similar interop bugs. We want the URL spec to be source of interop behavior and believe that our goal is in line with your direction. Cheers, _dave_
[Bug 27437] New: [Custom]: Be clear about whether attached callback should be enqueued when setting prototype
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27437 Bug ID: 27437 Summary: [Custom]: Be clear about whether attached callback should be enqueued when setting prototype Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: wc...@mozilla.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Blocks: 14968 http://w3c.github.io/webcomponents/spec/custom/#dfn-created-callback: The custom element prototype must be set just prior to invoking callback. If the created callback exists for an element, all other callbacks must not be enqueued until after this created callback's invocation had started. In the steps to set the custom element prototype we have: http://w3c.github.io/webcomponents/spec/custom/#dfn-set-prototype 3.1. Enqueue attached callback for ELEMENT There is instruction to enqueue an attached callback and instruction to not enqueue the attached callback because it happens before invoking the created callback. -- You are receiving this mail because: You are on the CC list for the bug.
