Re: CfC: publish WG Note of UI Events; deadline November 14
On Wed, 2014-11-19 at 09:44 -0500, Arthur Barstow wrote: On 11/19/14 9:35 AM, Anne van Kesteren wrote: On Wed, Nov 19, 2014 at 3:20 PM, Arthur Barstow art.bars...@gmail.com wrote: Although there appears to be agreement that work on the [uievents] spec should stop, the various replies raise sufficient questions that I consider this CfC (as written) as failed. Travis, Gary - would you please make a specific proposal for these two specs? In particular, what is the title and shortname for each document, and which spec/shortname becomes the WG Note? After we have agreed on a way forward, I'll start a new CfC. (I believe the Principle of Least Surprise here means considering specs that currently reference [uievents] or [DOM-Level-3-Events]. F.ex., I suppose a document titled UI Events with a shortname of DOM-Level-3-Events could be a bit confusing to some, although strictly speaking could be done.) My proposal would be to update UI Events with the latest editor's draft of DOM Level 3 Events (title renamed, of course) and have the DOM Level 3 Events URL redirect to UI Events. That would communicate clearly what happened. Yves, Philippe - can Anne's proposal be done? I'm not aware of any reason that would prevent us from doing so. Philippe
CfC: publish Proposed Recommendation of Server-Sent Events; deadline November 28
The latest interop data Zhiqiang generated for Server-sent Events [All] indicates 102/124 passes and [2] isolates the 22 failures with less than two implementations including 9 failures which are due to Web IDL implementation bugs (thus, not counting the WebIDL failures the pass rate is 111/124 or ~90%). The non Web IDL failures are: 1. http://www.w3c-test.org/eventsource/dedicated-worker/eventsource-constructor-non-same-origin.htm 2. http://www.w3c-test.org/eventsource/shared-worker/eventsource-constructor-non-same-origin.htm 3. http://www.w3c-test.org/eventsource/format-field-retry-bogus.htm My take on these failures is: #1 and #2 test the UA's error handling of URLs that cannot be resolved (f.ex. unsupported URL scheme, URL doesn't exist). The failures appear to be relatively low priority implementation bugs (see [Bug119974]) that seem unlikely to occur in a tested deployment. #3 tests the UA's handling of invalid data value for the retry (constructor) parameter. This test actually now passes when I run it on FF beta 34.0 so it should be removed from [2]. Regardless, the failure appears to be a relatively low priority implementation bug that seems unlikely to occur in a tested deployment. As such, this is Call for Consensus to publish SSE as a Proposed Recommendation. If you have any comments or concerns about this CfC, please reply to this e-mail by November 28 at the latest. Positive response is preferred and encouraged, and silence will be considered as agreement with the proposal. The [ED] has changed since the [CR] was published (see [Diff]) so this proposal assumes that if/when there is a resource commitment to include changes on the TR track, that will be done separately. -Thanks, AB [All] http://w3c.github.io/test-results/eventsource/less-than-2.html [2] http://w3c.github.io/test-results/eventsource/less-than-2.html [Bug119974] https://bugs.webkit.org/show_bug.cgi?id=119974 [CR] http://www.w3.org/TR/2012/CR-eventsource-20121211/ [ED] http://dev.w3.org/html5/eventsource/ [Diff] http://services.w3.org/htmldiff?doc1=http%3A%2F%2Fdev.w3.org%2Fcvsweb%2F~checkout~%2Fhtml5%2Feventsource%2FOverview.html%3Frev%3D1.233%3Bcontent-type%3Dtext%252Fhtmldoc2=http%3A%2F%2Fdev.w3.org%2Fcvsweb%2F~checkout~%2Fhtml5%2Feventsource%2FOverview.html%3Frev%3D1.258%3Bcontent-type%3Dtext%252Fhtml
Re: CfC: publish Proposed Recommendation of Server-Sent Events; deadline November 28
+1 On Fri, Nov 21, 2014 at 7:02 AM, Arthur Barstow art.bars...@gmail.com wrote: The latest interop data Zhiqiang generated for Server-sent Events [All] indicates 102/124 passes and [2] isolates the 22 failures with less than two implementations including 9 failures which are due to Web IDL implementation bugs (thus, not counting the WebIDL failures the pass rate is 111/124 or ~90%). The non Web IDL failures are: 1. http://www.w3c-test.org/eventsource/dedicated-worker/ eventsource-constructor-non-same-origin.htm 2. http://www.w3c-test.org/eventsource/shared-worker/ eventsource-constructor-non-same-origin.htm 3. http://www.w3c-test.org/eventsource/format-field-retry-bogus.htm My take on these failures is: #1 and #2 test the UA's error handling of URLs that cannot be resolved (f.ex. unsupported URL scheme, URL doesn't exist). The failures appear to be relatively low priority implementation bugs (see [Bug119974]) that seem unlikely to occur in a tested deployment. #3 tests the UA's handling of invalid data value for the retry (constructor) parameter. This test actually now passes when I run it on FF beta 34.0 so it should be removed from [2]. Regardless, the failure appears to be a relatively low priority implementation bug that seems unlikely to occur in a tested deployment. As such, this is Call for Consensus to publish SSE as a Proposed Recommendation. If you have any comments or concerns about this CfC, please reply to this e-mail by November 28 at the latest. Positive response is preferred and encouraged, and silence will be considered as agreement with the proposal. The [ED] has changed since the [CR] was published (see [Diff]) so this proposal assumes that if/when there is a resource commitment to include changes on the TR track, that will be done separately. -Thanks, AB [All] http://w3c.github.io/test-results/eventsource/less-than-2.html [2] http://w3c.github.io/test-results/eventsource/less-than-2.html [Bug119974] https://bugs.webkit.org/show_bug.cgi?id=119974 [CR] http://www.w3.org/TR/2012/CR-eventsource-20121211/ [ED] http://dev.w3.org/html5/eventsource/ [Diff] http://services.w3.org/htmldiff?doc1=http%3A%2F% 2Fdev.w3.org%2Fcvsweb%2F~checkout~%2Fhtml5%2Feventsource%2FOverview.html% 3Frev%3D1.233%3Bcontent-type%3Dtext%252Fhtmldoc2=http%3A% 2F%2Fdev.w3.org%2Fcvsweb%2F~checkout~%2Fhtml5% 2Feventsource%2FOverview.html%3Frev%3D1.258%3Bcontent-type%3Dtext%252Fhtml
Themeing mechanism for custom elements
It would be nice to have a themeing mechanism baked into the browsers for custom elements, pages, and the whole app. Most UI Widget frameworks today have themeing built in, such as Jquery UI, KendoUI, Wijmo, ect ect. Oses and some other non-web applications have themeing, heck even our browsers can have custom themes. I know the Polymer team is working on making a solution for Polymer by creating custom, re-usable, sharable themes, but this is on a framework by framework basis. I would like to see a spec for themes either for css as a whole or web-components. Another source of inspiration is Asp.net themeing, you can theme a whole app, individual pages, partial pages, or individual components. A standard mechanism would be very useful now that we have custom elements as a standard, almost :), but themes should not just be limited to custom elements they should appy to our existing built in ones as well, buttons, selects, ect. Thanks, Dan
[Bug 27401] New: [Shadow]: Fully explore composition
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27401 Bug ID: 27401 Summary: [Shadow]: Fully explore composition Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: dglaz...@chromium.org QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Blocks: 14978 This is a meta bug for polishing Shadow DOM as a composition primitive. https://gist.github.com/dglazkov/716913d889c38e42d55c With Shadow DOM, the developers finally have the composition boundaries to help them reason about larger web apps in terms of smaller chunks. The actual concept is not unique. What's unique about it is that the Web Platform is also aware of these boundaries. We have a whole set of challenges ahead of us. We need to make sure that the composition boundaries have the right crunchy/gooey balance to be truly useful, we need to build introspection tooling to make these composition boundaries more grokkable. We also need to ensure that these boundaries are designed in a way that allows the browser to help developer build modern UX (http://bit.ly/blink-midnight-train as an example of UX guidelines). Some of these challenges are conflicting with each other, and the problem easily gets into the over-constrained territory. We also need better terminology. Information hiding sounds negative and purposeless. Why would anyone want to hide information? Encapsulation is a super-overloaded term. When you say it to one crowd, they hear iframe. To another crowd, it sounds like something different. I suggest we use the term composition and see how far we can get. For example, the question when should I put things in Shadow DOM? is a symptom of approaching the problem from the wrong angle. It's effectively the same question as when should I put things in a class? I, as a developer, should use Shadow DOM when I need to draw composition boundaries in my code. The consistency of these composition boundaries should be flexible enough to express the degrees of composition I need in each particular case. For example, when I build a my-app element, it seems nonsensical for document.activeElement to return my-app when I focused something inside of it. However, it's equally non-sensical for datetime-input element to _not_ do that. Unfortunately, too often, flexibility is another word for added complexity and unpredictable performance characteristics. This is the hardest constraint. We should avoid adding more bloat to the platform. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 27405] New: [Custom]: Convert all ES5 references to ES6
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27405 Bug ID: 27405 Summary: [Custom]: Convert all ES5 references to ES6 Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: dglaz...@chromium.org QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Blocks: 14968 See bug 26365. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 25714] [Custom]: Move microtask processing to compound microtask
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25714 Dimitri Glazkov dglaz...@chromium.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Dimitri Glazkov dglaz...@chromium.org --- https://github.com/w3c/webcomponents/commit/ffeeba6b1a3446ebc183a0ae2b7ee8445e44635d -- You are receiving this mail because: You are on the CC list for the bug.
