[Bug 28659] [Shadow]: Remove Section 8. "HTML Elements and Their Shadow Trees" from the spec
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28659 Hayato Ito changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Hayato Ito --- Removed at https://github.com/w3c/webcomponents/commit/1dde369cda8568561ce56e9d29e41669ff3ccf1f. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 16103] Remove DOMStringList usage
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16103 Joshua Bell changed: What|Removed |Added Resolution|LATER |DUPLICATE --- Comment #25 from Joshua Bell --- 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 changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Joshua Bell --- 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?
On Tue, May 19, 2015 at 10:09 AM, Domenic Denicola wrote: > From: Elliott Sprehn [mailto:espr...@chromium.org] > > > Given the widget that expects a ui-collapsible-header > in the content model, with slots I can write: > > > > > > ... > > > > > > > > ... > > > > > > 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. or or ) act as dumb containers. > This was reinforced by the examples in the proposal, which use 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. > 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 . and 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 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 inserts and want to change it. They'd much rather do and do whatever they want instead. - E
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.
Re: [webcomponents] How about let's go with slots?
On Tue, May 19, 2015 at 10:09 AM, Domenic Denicola 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. or or ) act as dumb containers. > This was reinforced by the examples in the proposal, which use 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<
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?
From: Elliott Sprehn [mailto:espr...@chromium.org] > Given the widget that expects a ui-collapsible-header in the > content model, with slots I can write: > > > ... > > > > ... > > > 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. or or ) act as dumb containers. This was reinforced by the examples in the proposal, which use 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 if we were trying to match HTML. This would be easier to refactor later, e.g. to Header for Foo https://example.com/help-for-foo";>(?) 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="".
Re: [webcomponents] How about let's go with slots?
On Mon, May 18, 2015 at 8:54 PM, Hayato Ito 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" , it may want to allow the selection of subclasses of that element but not other arbitrary elements.
[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.