[Bug 28659] New: [Shadow]: Remove Section 8. HTML Elements and Their Shadow Trees from the spec
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28659 Bug ID: 28659 Summary: [Shadow]: Remove Section 8. HTML Elements and Their Shadow Trees from the spec 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 I think that we should remove 8. HTML Elements and Their Shadow Trees section from the spec. This section doesn't have any value as before, given that we don't add a shadow root to these elements. Unless there is an objection, let me remove it in a few days. -- You are receiving this mail because: You are on the CC list for the bug.
Re: [webcomponents] How about let's go with slots?
On Mon, May 18, 2015 at 8:54 PM, Hayato Ito hay...@chromium.org wrote: The hint we can use is: - tag name - id attribute - class attribute - any other attributes. (Okay to have a dedicated attribute, such as 'content-slot') - The position of the node in the list - Other status, such as :focused (in CSS's terminology) - Anything else? Another potential hint is element class/type/instanceof. I can see a situation where I'd want to select any element that is an `instanceof` HTMLButtonElement. Or if a third-party library creates an element that selects ui-dropdown, it may want to allow the selection of subclasses of that element but not other arbitrary elements.
RE: [webcomponents] How about let's go with slots?
From: Elliott Sprehn [mailto:espr...@chromium.org] Given the widget ui-collapsible that expects a ui-collapsible-header in the content model, with slots I can write: ui-collapsible my-header-v1 slot=ui-collapsible-header ... /... /ui-collapsible ui-collapsible my-header-v2 slot=ui-collapsible-header ... /... /ui-collapsible within the same application. It also means the library can ship with an implementation of the header widget, but you can replace it with your own. This is identical to the common usage today in polymer apps where you annotate your own element with classes. There's no restriction on the type of the input. I see. Thanks for explaining. I think this model you cite Polymer using is different from what HTML normally does, which is why it was confusing to me. In HTML the insertion point tags (e.g. summary or li or option) act as dumb containers. This was reinforced by the examples in the proposal, which use div content-slot= with the div being a clear dumb container. You cannot replace them with your own choice of container and have things still work. As such, I think it would make more sense to write ui-collapsible ui-collapsible-header my-header-v1/my-header-v1 /ui-collapsible-header /ui-collapsible ui-collapsible ui-collapsible-header my-header-v2/my-header-v2 /ui-collapsible-header /ui-collapsible if we were trying to match HTML. This would be easier to refactor later, e.g. to ui-collapsible ui-collapsible-header my-icon/my-icon Header for Foo a href=https://example.com/help-for-foo;(?)/a /ui-collapsible-header /ui-collapsible However, I understand how this departs from the Polymer/select= model now. Polymer/select= allows anything to stand in and be distributed to the appropriate destination location, whereas HTML only allows certain tag names. I am not sure which the original proposal from Jan, Ryosuke, and Ted *intended*, although I agree that as presented it leans toward Polymer/select=.
PSA: HTML5 Web Messaging is a W3C Recommendation
Congratulations to Ian and all the contributors! On 5/19/15 12:53 PM, Coralie Mercier wrote: It is my pleasure to announce that HTML5 Web Messaging is published as a W3C Recommendation http://www.w3.org/TR/2015/REC-webmessaging-20150519/ This specification defines two mechanisms for communicating between browsing contexts in HTML documents. All Members who responded to the Call for Review [1] of the Proposed Recommendation supported the publication of this specification as a W3C Recommendation, or abstained. Please join us in thanking the Web Applications Working Group [2] for their achievement. This announcement follows section 8.1.2 [3] of the W3C Process Document. For Tim Berners-Lee, Director; Philippe Le Hegaret, Interaction Domain Lead, Xiaoqian Wu Yves Lafon, Team Contacts; Coralie Mercier, Acting Head of W3C Marketing Communications [1] https://lists.w3.org/Archives/Member/w3c-ac-members/2015AprJun/0004.html [2] https://www.w3.org/2008/webapps/ [3] http://www.w3.org/2005/10/Process-20051014/acreview.html#ACReviewAfter
Re: [webcomponents] How about let's go with slots?
On Tue, May 19, 2015 at 10:09 AM, Domenic Denicola d...@domenic.me wrote: From: Elliott Sprehn [mailto:espr...@chromium.org] Given the widget ui-collapsible that expects a ui-collapsible-header in the content model, with slots I can write: ui-collapsible my-header-v1 slot=ui-collapsible-header ... /... /ui-collapsible ui-collapsible my-header-v2 slot=ui-collapsible-header ... /... /ui-collapsible within the same application. It also means the library can ship with an implementation of the header widget, but you can replace it with your own. This is identical to the common usage today in polymer apps where you annotate your own element with classes. There's no restriction on the type of the input. I see. Thanks for explaining. I think this model you cite Polymer using is different from what HTML normally does, which is why it was confusing to me. In HTML the insertion point tags (e.g. summary or li or option) act as dumb containers. This was reinforced by the examples in the proposal, which use div content-slot= with the div being a clear dumb container. You cannot replace them with your own choice of container and have things still work. li is actually just a layout mode, you can make anything a list item by doing display: list-item. There's no special content model for ul. details and select are examples of selection based on tag name. In general these dumb containers have proven harmful though because they insert extra boxes around your content and are not configurable which are annoying for authors. They're the reason we keep coming back to trying to figure out how to customize option instead of just letting you replace it with your own widget we tell to layout/paint at a specific size like other platforms would. ex. Authors don't like the disclosure triangle that summary inserts and want to change it. They'd much rather do div slot=summary and do whatever they want instead. - E
Re: [webcomponents] How about let's go with slots?
On Tue, May 19, 2015 at 10:09 AM, Domenic Denicola d...@domenic.me wrote: I think this model you cite Polymer using is different from what HTML normally does, which is why it was confusing to me. In HTML the insertion point tags (e.g. summary or li or option) act as dumb containers. This was reinforced by the examples in the proposal, which use div content-slot= with the div being a clear dumb container. You cannot replace them with your own choice of container and have things still work. Not sure what you mean by Polymer model. When we have custom elements, the assumption of dumb containers simply goes out of the window. :DG
[Bug 16103] Remove DOMStringList usage
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16103 Joshua Bell jsb...@google.com changed: What|Removed |Added Resolution|LATER |DUPLICATE --- Comment #25 from Joshua Bell jsb...@google.com --- Marking this as a dupe of the newer bug. *** This bug has been marked as a duplicate of bug 28067 *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 26492] IndexedDB: add/put/update operations should define ordering of clone vs. keypath evaluation
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26492 Joshua Bell jsb...@google.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Joshua Bell jsb...@google.com --- This has been fixed in the V2 spec, although it may not match reality exactly. https://w3c.github.io/IndexedDB/ -- You are receiving this mail because: You are on the CC list for the bug.
RE: [webcomponents] How about let's go with slots?
From: Dimitri Glazkov [mailto:dglaz...@google.com] Not sure what you mean by Polymer model. I was referring to Elliot's This is identical to the common usage today in polymer apps where you annotate your own element with classes. When we have custom elements, the assumption of dumb containers simply goes out of the window. I don't think it has to, as I showed in my message.
