Re: CfC: publish Proposed Recommendation of Web Messaging; deadline March 28
On Sat, 21 Mar 2015 13:52:25 +0100, Arthur Barstow art.bars...@gmail.com wrote: As previously mentioned on [p-w], the test results for Web Messaging [All] indicate significant interoperability with only two tests that have less than two passes [2]. The two tests, including a short analysis of the failure, are: 1. http://www.w3c-test.org/webmessaging/with-ports/026.html; this test failure (which passes on Firefox) can be considered more of a Web IDL implementation issue and thus not a significant interop issue. 2. http://www.w3c-test.org/webmessaging/without-ports/025.html; this test failure (which passes on IE) is considered an implementation bug (MessageChannel and MessagePort are supposed to be exposed to Worker) that is expected to be fixed. Cindy created a Draft PR [PR] that includes Hixie's updates since the [CR] was published (but not the PortCollection interface [PC] which is not broadly implemented). Overall, we consider the changes since the CR as non-substantive bug fixes and clarifications that align the spec with current implementations, and that the test suite tests the updated spec. See [Diff] for all of changes between the CR and the draft PR and note the draft PR's status section includes a short summary of the changes. As such, this is a Call for Consensus to publish a Proposed Recommendation of Web Messaging using the [PR] as the basis. Agreement with this CfC means you consider the test results shows interoperability and the changes since CR are not substantive. If you have any comments or concerns about this CfC, please reply to this e-mail by March 28 at the latest. Positive response is preferred and encouraged, and silence will be considered as agreement with the proposal. If there are no non-resolvable objections to this proposal, the motion will carry and we will request the PR be published. Opera supports publishing. -Thanks, ArtB [p-w] https://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0627.html [All] http://w3c.github.io/test-results/webmessaging/all.html [2] http://w3c.github.io/test-results/webmessaging/less-than-2.html [PR] http://www.w3.org/TR/2015/PR-webmessaging-20150407/ [CR] http://www.w3.org/TR/2012/CR-webmessaging-20120501/ [PC] http://dev.w3.org/html5/postmsg/#broadcasting-to-many-ports [Diff] https://www.diffchecker.com/qswiibb5 -- Simon Pieters Opera Software
[Bug 28353] New: [Shadow]: Use a parent/child relationship in the composed tree for some elements, i.e. ol/li
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28353 Bug ID: 28353 Summary: [Shadow]: Use a parent/child relationship in the composed tree for some elements, i.e. ol/li Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: hay...@chromium.org QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Blocks: 14978 For example, suppose the following case: div id=shadow-host summarysummary/summary /div #shadow-root-of-the-shadow-host details content/content divdetails/div /details Unfortunately, this should not be rendered as intended, if we interpret the spec [1] strictly. [1]: https://html.spec.whatwg.org/multipage/forms.html#the-summary-element The spec says: Contexts in which this element, summary, can be used: As the first child of a details element. The same discussion might be also applied to the following elements, including, but not limited to: - tr/td - ol/li I've not investigated carefully yet. We have to investigate further. In Blink, AFAIR, we've spent some efforts to support these elements so that they are rendered correctly as intended even though they form a parent/child relationship in the composed tree, rather than in a node tree. However, I'm afraid that no one has a clear idea what behavior is correct. If we are to support these cases, the spec must specify that somehow. -- You are receiving this mail because: You are on the CC list for the bug.
