Re: [webcomponents] How about let's go with slots?
I assume you mean to have tag names in addition to content-slot, and not as opposed to content-slot? On Mon, May 18, 2015 at 3:45 PM, Domenic Denicola wrote: > From: Dimitri Glazkov [mailto:dglaz...@google.com] > > > What do you think, folks? > > Was there a writeup that explained how slots did not have the same > performance/timing problems as select=""? I remember Alex and I were pretty > convinced they did at the F2F, but I think you became convinced they did > not ... did anyone capture that? > > My only other contribution is that I sincerely hope we can use tag names > instead of the content-slot attribute, i.e. instead of content-slot="dropdown">. Although slots cannot fully emulate native > elements in this manner (e.g. //), they would at > least get syntactically closer, and would in some cases match up (e.g. > /). I think it would be a shame to start proliferating > markup in the vein if we eventually want to > get to a place where shadow DOM can be used to emulate native elements, > which do not use this pattern. >
Re: Proposal for changes to manage Shadow DOM content distribution
Hi Ryosuke, I want to start by thanking you, Ted, and Jan for taking the time to make this proposal. I read through the proposal, and had a quick question about how redistribution should work with this slot concept. I created a quick example that would take two date inputs (start date and end date) and distribute them through the example , but I found myself stuck. I can't name the two date inputs with the same slot or they will end up in only one of the content elements, but only takes inputs with slot "inputElement". How should this work? I drafted a quick gist to illustrate this: https://gist.github.com/azakus/676590eb4d5b07b94428 Thanks! On Tue, Apr 21, 2015 at 8:19 PM, Ryosuke Niwa wrote: > Hi all, > > Following WebApps discussion last year [1] and earlier this year [2] about > template transclusions and inheritance in shadow DOM, Jan Miksovsky at > Component Kitchen, Ted O'Connor and I (Ryosuke Niwa) at Apple had > a meeting where we came up with changes to the way shadow DOM distributes > nodes to better fit real world use cases. > > After studying various real world use of web component APIs as well as > exiting GUI frameworks, we noticed that selector based node distribution as > currently spec'ed doesn't address common use cases and the extra > flexibility CSS selectors offers isn't needed in practice. Instead, we > propose named insertion "slots" that could be filled with the contents in > the original DOM as well as contents in subclasses. Because the proposal > uses the same slot filling mechanism for content distributions and > inheritance transclusions, it eliminates the need for multiple shadow > roots. > > Please take a look at our proposal at > https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution > > [1] > https://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0151.html > [2] > https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0611.html > >
Re: Mozilla and the Shadow DOM
We found some timing issues with polyfill HTML Imports and native Custom Elements in Chrome that made us force the Custom Elements polyfill when HTML Imports is polyfilled. I don't remember the specifics, but I filed the github issue to either track down and resolve the issues, or provide a flag to override this behavior for Mozilla to use in testing. Sorry for the grumbly note, we've tried very hard to make sure Polymer !== Web Components in public discourse to keep people from conflating the two. On Tue, Apr 14, 2015 at 12:29 PM, Daniel Freedman wrote: > Just to close the loop, filed > https://github.com/webcomponents/webcomponentsjs/issues/289 to track the > specific Polymer web component polyfill blocker. > > On Tue, Apr 14, 2015 at 5:38 AM, Anne van Kesteren > wrote: > >> On Wed, Apr 8, 2015 at 6:11 PM, Dimitri Glazkov >> wrote: >> > Thanks for the feedback! While the iron is hot I went ahead and >> > created/updated bugs in the tracker. >> >> A problem I have with this approach is that with Shadow DOM (and maybe >> Web Components in general) there's a lot of open bugs. Of those bugs >> it's not at all clear which the editors plan on addressing. Which >> makes it harder to plan for us. >> >> >> Also, a point that I forgot to make in my initial email is that >> Polymer makes it rather hard for us to ship any part of Web Components >> without all the other parts (and in the manner that Chrome implemented >> the features): >> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1107662 >> >> > The linked bug is simply incorrect. Polymer depends on webcomponentsjs ( > https://github.com/webcomponents/webcomponentsjs) for browsers without > all the Web Components specs, but each part is feature detected, with > separate checks for Custom Elements, HTML Imports, and ShadowDOM, as well > as HTML Template, constructable URL, and MutationObserver > > Chrome did not implement and ship all the specs at once, so Polymer has > had to feature detect from the start. > > >> >> -- >> https://annevankesteren.nl/ >> >> >
Re: Mozilla and the Shadow DOM
Just to close the loop, filed https://github.com/webcomponents/webcomponentsjs/issues/289 to track the specific Polymer web component polyfill blocker. On Tue, Apr 14, 2015 at 5:38 AM, Anne van Kesteren wrote: > On Wed, Apr 8, 2015 at 6:11 PM, Dimitri Glazkov > wrote: > > Thanks for the feedback! While the iron is hot I went ahead and > > created/updated bugs in the tracker. > > A problem I have with this approach is that with Shadow DOM (and maybe > Web Components in general) there's a lot of open bugs. Of those bugs > it's not at all clear which the editors plan on addressing. Which > makes it harder to plan for us. > > > Also, a point that I forgot to make in my initial email is that > Polymer makes it rather hard for us to ship any part of Web Components > without all the other parts (and in the manner that Chrome implemented > the features): > > https://bugzilla.mozilla.org/show_bug.cgi?id=1107662 > > The linked bug is simply incorrect. Polymer depends on webcomponentsjs ( https://github.com/webcomponents/webcomponentsjs) for browsers without all the Web Components specs, but each part is feature detected, with separate checks for Custom Elements, HTML Imports, and ShadowDOM, as well as HTML Template, constructable URL, and MutationObserver Chrome did not implement and ship all the specs at once, so Polymer has had to feature detect from the start. > > -- > https://annevankesteren.nl/ > >
Re: [Shadow] Q: Removable shadows (and an idea for lightweight shadows)?
How would you style these "shadow" children? Would the main document CSS
styles affect these children?
On Thu, Mar 26, 2015 at 11:36 AM, Travis Leithead <
travis.leith...@microsoft.com> wrote:
> > From: Justin Fagnani [mailto:justinfagn...@google.com]
> >> Elements expose this “shadow node list” via APIs that are very similar
> to
> >> existing node list management, e.g., appendShadowChild(),
> insertShadowBefore(),
> >> removeShadowChild(), replaceShadowChild(), shadowChildren[],
> shadowChildNodes[].
> >
> >This part seems like a big step back to me. Shadow roots being actual
> nodes means
> >that existing code and knowledge work against them.
>
> "existing code and knowledge work against them" -- I'm not sure you
> understood correctly.
> Nodes in the "shadow child list" wouldn't show up in the childNodes list,
> nor in any of the
> node traversal APIs (e.g., not visible to qSA, nextSibling,
> previousSibling, children, childNodes,
> ect.
>
> Trivially speaking, if you wanted to hide two divs that implement a "stack
> panel" and have some
> element render it, you'd just do:
> element.appendShadowChild(document.createElement('div'))
> element.appendShadowChild(document.createElement('div'))
>
> Those divs would not be discoverable by any traditional DOM APIs (they
> would now be on the
> "shadow side"), and the only way to see/use them would be to use the new
> element.shadowChildren
> collection.
>
> But perhaps I'm misunderstanding your point.
>
> >The API surface that you'd have to duplicate with shadow*() methods would
> be quite large.
>
> That's true. Actually, I think the list above is probably about it.
>
>
Re: [Custom] Custom elements and ARIA
Why not put the `implicitAria` role on the element's prototype?
That way each instance can override with the attribute in a naive and
natural manner: `el.role = "link"`.
This would necessitate some getter/setter logic for the aria properties to
handle the something like the case with conditional states, but
as long as the custom setter/getters can call the HTMLElement's role
setter/getters, then I think we can keep the deep magic in the UA's
bindings.
On Thu, Aug 28, 2014 at 2:24 PM, Domenic Denicola <
dome...@domenicdenicola.com> wrote:
> Thanks to all for their responses. The fact that I misread a bunch of
> authoring requirements as UA requirements made things a lot more
> complicated than they are in reality.
>
> I updated my ARIA summary [1] and illustrative scenarios [2] to reflect
> the actual spec/browser behavior. And, given the much-easier requirements,
> I was able to draft up a pretty simple solution:
>
> https://gist.github.com/domenic/8ae33f320b856a9aef43
>
> I still need to investigate whether this kind of solution is feasible from
> an implementation perspective, but from an author perspective it seems
> natural and easy to use.
>
> Would love to hear what others think.
>
> [1]: https://gist.github.com/domenic/ae2331ee72b3847ce7f5
> [2]: https://gist.github.com/domenic/bc8a36d9608d65bd7fa9
>
>
> -Original Message-
> From: Domenic Denicola [mailto:dome...@domenicdenicola.com]
> Sent: Wednesday, August 27, 2014 19:43
> To: public-webapps
> Subject: [Custom] Custom elements and ARIA
>
> TL;DR: we (Google) are trying to explain the platform with custom elements
> [1], and noticed they can't do ARIA as well as native elements. We would
> like to prototype a solution, ideally as a standardized API that we can let
> authors use too. (If that doesn't work, then we can instead add a
> non-web-exposed API that we can use inside Chrome, but that would be a
> shame.) A succinct statement of the problem is that we need some way to
> explain [3]. The rest of this mail explains the problem in great depth in
> the hopes other people are interested in designing a solution with me.
>
> Also, in the course of figuring all this out, I put together an intro to
> the relevant aspects of ARIA, which you might find useful, at [2].
>
> ## The problem
>
> Right now, custom elements can manually add ARIA roles and stoperties (=
> states or properties) to themselves, by setting attributes on themselves.
> In practice, this kind of allows them to have default ARIA roles and
> stoperties, but they are fragile and exposed in a way that is incongruous
> with the capabilities of native elements in this regard.
>
> For example, if we were to implement `` as a custom element, we would
> attempt to give it the separator role by doing `this.setAttribute("role",
> "separator")` in the `createdCallback`. However, if the author then did
> `document.querySelector("custom-hr").setAttribute("role", "menuitem")`,
> assistive technology would reflect our `` as a menu item, and
> not as a separator. So **unlike native elements, custom elements cannot
> have non-overridable semantics**.
>
> Furthermore, even if the author wasn't overriding the role attribute,
> there would still be a difference between `` and ``. Namely,
> `document.querySelector("hr").getAttribute("role") === null`, whereas
> `document.querySelector("custom-hr").getAttribute("role") === "separator"`.
> So **unlike native elements, custom elements cannot have default ARIA roles
> or stoperties without them being reflected in the DOM**.
>
> As another example, imagine trying to implement `` as a custom
> element. To enforce the restriction to a role of either `button` or
> `menuitem`, the custom element implementation would need to use its
> `attributeChangedCallback` to revert changes that go outside those
> possibilities. And that of course only occurs at the end of the microtask,
> so in the meantime screen-readers are giving their users bad information.
> And even then, the experience of the attribute value being reverted for the
> custom element is not the same as that for a native element, where the
> attribute value stays the same but the true ARIA role as reflected to
> screenreaders remains `button`. So: **unlike native elements, custom
> elements cannot robustly restrict their ARIA roles to certain values**.
>
> Finally, consider how `` synchronizes `aria-expanded` with the
> `open` attribute. To implement this with custom elements, you would use the
> `attributeChangedCallback` to set an `aria-expanded` attribute. But again,
> the author could change it via `setAttribute`, causing it to be
> out-of-sync. The takeaway here is that **unlike native elements, custom
> elements cannot reserve the management of certain stoperties for
> themselves**.
>
> In the end, trying to manage one's ARIA state HTML attributes is fragile,
> and lacks the conceptual stratification and the resultant power of the
> internal state/mutable HTML attribute approach used by
Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)
On Fri, Feb 14, 2014 at 5:39 PM, Ryosuke Niwa wrote: > On Feb 14, 2014, at 5:17 PM, Alex Russell wrote: > > On Fri, Feb 14, 2014 at 3:56 PM, Ryosuke Niwa wrote: > >> On Feb 14, 2014, at 2:50 PM, Elliott Sprehn wrote: >> >> On Fri, Feb 14, 2014 at 2:39 PM, Boris Zbarsky wrote: >> >>> On 2/14/14 5:31 PM, Jonas Sicking wrote: >>> Also, I think that the Type 2 encapsulation has the same characteristics. If the component author does things perfectly and doesn't depend on any outside code >>> >>> And never invokes any DOM methods on the nodes in the component's >>> anonymous content. Which is a pretty strong restriction; I'm having a bit >>> of trouble thinking of a useful component with this property. >>> >>> >> I think my biggest issue with Type-2 is that unlike the languages cited >> for providing "private" it's trying to mimic it provides no backdoor for >> tools and frameworks to get at private state and at the same time it >> doesn't add any security benefits. >> >> >> Except that JavaScript doesn’t have “private”. >> > > Right, it only has the stronger form (closures) > > > I don’t think we have the stronger form in that using any builtin objects > and their functions would result in leaking information inside the closure. > > Ruby, Python, Java, C# and almost all other modern languages that >> provide a private facility for interfaces (as advocated by the Type-2 >> design) provide a backdoor through reflection to get at the variables and >> methods anyway. This allowed innovation like AOP, dependency injection, >> convention based frameworks and more. >> >> So if we provide Type-2 I'd argue we _must_ provide some kind of escape >> hatch to still get into the ShadowRoot from script. I'm fine providing some >> kind of "don't let CSS styles enter me" feature, but hiding the shadowRoot >> property from the Element makes no sense. >> >> >> I don’t see how the above two sentences lead to a consolation that we >> must provide an escape hatch to get shadow root from script given that such >> an escape hatch already exists if the component authors end up using >> builtin DOM functions. >> > > It's the difference between using "legit" methods and "hacking around the > platform". If it's desirable to allow continued access in these situations, > why isn't .shadowRoot an acceptable speed bump? > > > The point is that it’s NOT ALWAYS desirable to allow continued access. We > saying that components should have a choice. > > If it's not desirable, isn't the ability to get around the restriction *at > all* a bug to be fixed (arguing, implicitly, that we should be > investigating stronger primitives that Maciej and I were discussing to > enable Type 4)? > > > Are you also arguing that we should “fix” closures so that you can safely > call builtin objects and their methods without leaking information? If > not, I don’t see why we need to fix this problem only for web components. > > We all agree it's not a security boundary and you can go through great >> lengths to get into the ShadowRoot if you really wanted, all we've done by >> not exposing it is make sure that users include some crazy >> jquery-make-shadows-visible.js library so they can build tools like Google >> Feedback or use a new framework or polyfill. >> >> >> I don’t think Google Feedback is a compelling use case since all >> components on Google properties could simply expose “shadow” property >> themselves. >> > > So you've written off the massive coordination costs of adding a uniform > to all code across all of Google and, on that basis, have suggested there > isn't really a problem? ISTM that it would be a multi-month (year?) project > to go patch every project in google3 and then wait for them to all deploy > new code. > > > On the other hand, Google representatives have previously argued that > adding template instantiation mechanism into browser isn’t helping anyone, > because framework authors would figure that out better than we can. > > I have a hard time understanding why anyone would come to conclusion that > forcing every single web components that use template to have: > > > this.createShadowRoot().appendChild(document.importNode(template.contents)); > I don't understand how this pertains to encapsulation. Could you elaborate? > > is any less desirable than having components that want to expose > shadowRoot to write: > > this.shadowRoot = createShadowRoot(); > The other hand of this argument is that components that wish to lock themselves down could write: this.shadowRoot = undefined; Of course, this does would not change the outcome of the Shadow Selector spec, which is why a flag for createShadowRoot or something would be necessary to configure the CSS engine (unless you're ok with having the existence of a property on some DOM object control CSS parsing rules). (Also your example would not handle multiple shadow roots correctly, here's one that would) var sr = this.shadowRoot; var newSr = this.createSha
Re: Controling style of elements in Injection Points
And here's yet another version that should be usable in Stable Chrome and
Canary: http://codepen.io/anon/pen/ybEch
On Tue, Dec 10, 2013 at 4:08 PM, Daniel Freedman wrote:
> I've updated your pen with the other minor syntax changes that have
> occured in Chrome Canary:
>
> @host -> :host
>
> template.content.cloneNode(true) -> document.importNode(template.content)
>
> ::content p {} will always win over ::content {}, so I moved the black
> color to the style for p { }
>
> http://codepen.io/anon/pen/tcjeh
>
>
> On Tue, Dec 10, 2013 at 2:58 PM, Enrique Moreno Tent <
> enriquemorenot...@gmail.com> wrote:
>
>> Thank you all! Finally I understand how it works :)
>>
>> I made a small pen to illustrate this better
>> http://codepen.io/dbugger/pen/Hyihd
>>
>>
>> On 1 December 2013 23:35, Daniel Freedman wrote:
>>
>>> ::content is behind the "Experimental Web Platform Features" chrome
>>> flag, along with the unprefixed createShadowRoot.
>>>
>>>
>>> On Fri, Nov 29, 2013 at 6:00 AM, Enrique Moreno Tent <
>>> enriquemorenot...@gmail.com> wrote:
>>>
>>>> I have actually have gotten to work with ":-webkit-distributed(p)" but
>>>> as I read it has been deprecated and ":content p" should work (but it
>>>> doesnt).
>>>>
>>>> Do I need maybe to activate a flag? Im using Chrome 31 under Ubuntu, in
>>>> case it matters.
>>>>
>>>>
>>>> On 28 November 2013 18:39, Enrique Moreno Tent <
>>>> enriquemorenot...@gmail.com> wrote:
>>>>
>>>>> Thank you :) But it is quite confusing to understand how it works. I
>>>>> have tried to update my example, but still doesn't seem to work. Could you
>>>>> tell me, in my example, what would be the selector? I tried "p::content",
>>>>> but as you see that doesnt seem to work.
>>>>>
>>>>> My use case example, again, is here:
>>>>> http://codepen.io/dbugger/pen/Hyihd
>>>>>
>>>>>
>>>>> On 28 November 2013 09:58, Hayato Ito wrote:
>>>>>
>>>>>> Yeah, Chrome has already implemented that. I've implemented that. :)
>>>>>>
>>>>>>
>>>>>> On Thu, Nov 28, 2013 at 6:25 PM, Enrique Moreno Tent <
>>>>>> enriquemorenot...@gmail.com> wrote:
>>>>>>
>>>>>>> Oh, interesting! Has this been implemented in any browser?
>>>>>>>
>>>>>>>
>>>>>>> On 28 November 2013 08:46, Hayato Ito wrote:
>>>>>>>
>>>>>>>> We can use '::content' pseudo elements if we want to apply styles
>>>>>>>> to distributed nodes from a shadow tree.
>>>>>>>>
>>>>>>>> See
>>>>>>>> http://w3c.github.io/webcomponents/spec/shadow/#content-pseudo-element
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Nov 28, 2013 at 9:14 AM, Enrique Moreno Tent <
>>>>>>>> enriquemorenot...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Hello, I have been experimenting with Web Components and I have an
>>>>>>>>> issue, which I think I have represented fairly clear here:
>>>>>>>>>
>>>>>>>>> (Tested on Chrome)
>>>>>>>>> http://codepen.io/dbugger/pen/Hyihd
>>>>>>>>>
>>>>>>>>> If I understood correctly, one of the points of web components is
>>>>>>>>> to control the presentation of our component. That is why we have the
>>>>>>>>> Shadow Boundary. BUT what happens with the elements that are
>>>>>>>>> represented
>>>>>>>>> with ? They are not considered part of the shadow, therefore
>>>>>>>>> the
>>>>>>>>> styles that the author decides to apply on them, will "invade" the Web
>>>>>>>>> Component.
>>>>>>>>>
>>>>>>>>> Any thought on this?
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Enrique Moreno Tent, Web developer
>>>>>>>>> http://enriquemorenotent.com
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Hayato
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Enrique Moreno Tent, Web developer
>>>>>>> http://enriquemorenotent.com
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Hayato
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Enrique Moreno Tent, Web developer
>>>>> http://enriquemorenotent.com
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Enrique Moreno Tent, Web developer
>>>> http://enriquemorenotent.com
>>>>
>>>
>>>
>>
>>
>> --
>> Enrique Moreno Tent, Web developer
>> http://enriquemorenotent.com
>>
>
>
Re: Controling style of elements in Injection Points
I've updated your pen with the other minor syntax changes that have occured
in Chrome Canary:
@host -> :host
template.content.cloneNode(true) -> document.importNode(template.content)
::content p {} will always win over ::content {}, so I moved the black
color to the style for p { }
http://codepen.io/anon/pen/tcjeh
On Tue, Dec 10, 2013 at 2:58 PM, Enrique Moreno Tent <
enriquemorenot...@gmail.com> wrote:
> Thank you all! Finally I understand how it works :)
>
> I made a small pen to illustrate this better
> http://codepen.io/dbugger/pen/Hyihd
>
>
> On 1 December 2013 23:35, Daniel Freedman wrote:
>
>> ::content is behind the "Experimental Web Platform Features" chrome flag,
>> along with the unprefixed createShadowRoot.
>>
>>
>> On Fri, Nov 29, 2013 at 6:00 AM, Enrique Moreno Tent <
>> enriquemorenot...@gmail.com> wrote:
>>
>>> I have actually have gotten to work with ":-webkit-distributed(p)" but
>>> as I read it has been deprecated and ":content p" should work (but it
>>> doesnt).
>>>
>>> Do I need maybe to activate a flag? Im using Chrome 31 under Ubuntu, in
>>> case it matters.
>>>
>>>
>>> On 28 November 2013 18:39, Enrique Moreno Tent <
>>> enriquemorenot...@gmail.com> wrote:
>>>
>>>> Thank you :) But it is quite confusing to understand how it works. I
>>>> have tried to update my example, but still doesn't seem to work. Could you
>>>> tell me, in my example, what would be the selector? I tried "p::content",
>>>> but as you see that doesnt seem to work.
>>>>
>>>> My use case example, again, is here:
>>>> http://codepen.io/dbugger/pen/Hyihd
>>>>
>>>>
>>>> On 28 November 2013 09:58, Hayato Ito wrote:
>>>>
>>>>> Yeah, Chrome has already implemented that. I've implemented that. :)
>>>>>
>>>>>
>>>>> On Thu, Nov 28, 2013 at 6:25 PM, Enrique Moreno Tent <
>>>>> enriquemorenot...@gmail.com> wrote:
>>>>>
>>>>>> Oh, interesting! Has this been implemented in any browser?
>>>>>>
>>>>>>
>>>>>> On 28 November 2013 08:46, Hayato Ito wrote:
>>>>>>
>>>>>>> We can use '::content' pseudo elements if we want to apply styles to
>>>>>>> distributed nodes from a shadow tree.
>>>>>>>
>>>>>>> See
>>>>>>> http://w3c.github.io/webcomponents/spec/shadow/#content-pseudo-element
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Nov 28, 2013 at 9:14 AM, Enrique Moreno Tent <
>>>>>>> enriquemorenot...@gmail.com> wrote:
>>>>>>>
>>>>>>>> Hello, I have been experimenting with Web Components and I have an
>>>>>>>> issue, which I think I have represented fairly clear here:
>>>>>>>>
>>>>>>>> (Tested on Chrome)
>>>>>>>> http://codepen.io/dbugger/pen/Hyihd
>>>>>>>>
>>>>>>>> If I understood correctly, one of the points of web components is
>>>>>>>> to control the presentation of our component. That is why we have the
>>>>>>>> Shadow Boundary. BUT what happens with the elements that are
>>>>>>>> represented
>>>>>>>> with ? They are not considered part of the shadow, therefore
>>>>>>>> the
>>>>>>>> styles that the author decides to apply on them, will "invade" the Web
>>>>>>>> Component.
>>>>>>>>
>>>>>>>> Any thought on this?
>>>>>>>>
>>>>>>>> --
>>>>>>>> Enrique Moreno Tent, Web developer
>>>>>>>> http://enriquemorenotent.com
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Hayato
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Enrique Moreno Tent, Web developer
>>>>>> http://enriquemorenotent.com
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Hayato
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Enrique Moreno Tent, Web developer
>>>> http://enriquemorenotent.com
>>>>
>>>
>>>
>>>
>>> --
>>> Enrique Moreno Tent, Web developer
>>> http://enriquemorenotent.com
>>>
>>
>>
>
>
> --
> Enrique Moreno Tent, Web developer
> http://enriquemorenotent.com
>
Re: [webcomponents] Auto-creating shadow DOM for custom elements
I've been thinking through the implications of this "auto shadow" proposal, and I'm glad people are seeing the utility of , but I don't think this feature would see much use. Developers want data-binding, and the auto cloning does not give them a favorable timing model. They want to set those up before the ShadowDOM is stamped, on a per-instance level. If they were to use the automatic template, it would be far too late, and there could be unnecessary network requests or FOUC. To remove a bit of vaguness from this scenario, Polymer elements use data-binding in almost all cases. Event handlers, computed properties, MVC, everywhere. As such, no Polymer element would use the automatic registration argument. I doubt that elements created with other libraries like Ember or Angular would make much use of it either. However, if some low level data-binding primitives were introduced to the platform, there would be some real merit in an automatic template argument. There would have to be some modifications to the proposal, such as adding hooks for data-binding information to be given to the template instance, but I think those details can be discussed when such a data-binding spec arrives. Until data-binding primitives arise, I think this automatic template is a premature discussion. On Sat, Dec 7, 2013 at 8:33 PM, Rafael Weinstein wrote: > On Sat, Dec 7, 2013 at 6:56 PM, Ryosuke Niwa wrote: > >> >> > On Dec 7, 2013, at 3:53 PM, Rafael Weinstein >> wrote: >> > >> > The issue is that being an element and having shadow DOM -- or any >> display DOM, for that matter -- are orthogonal concerns. >> > >> > There are lots of c++ HTML elements that have no display DOM. Polymer >> already has an even larger number. >> >> While that's true in browser implementations, there is very little >> authors can do with a plain element without any shadow content it since >> JavaScript can't implement it's own style model (i.e. creating a custom >> frame object in Gecko / render object in WebKit/Blink) or paint code in >> JavaScript. >> >> If the only customization author has to do is adding some CSS, then we >> don't need custom element hook at all. >> >> > I'm was thinking about elements whose purpose isn't presentational. For > example, or
Re: Controling style of elements in Injection Points
::content is behind the "Experimental Web Platform Features" chrome flag, along with the unprefixed createShadowRoot. On Fri, Nov 29, 2013 at 6:00 AM, Enrique Moreno Tent < enriquemorenot...@gmail.com> wrote: > I have actually have gotten to work with ":-webkit-distributed(p)" but as > I read it has been deprecated and ":content p" should work (but it doesnt). > > Do I need maybe to activate a flag? Im using Chrome 31 under Ubuntu, in > case it matters. > > > On 28 November 2013 18:39, Enrique Moreno Tent < > enriquemorenot...@gmail.com> wrote: > >> Thank you :) But it is quite confusing to understand how it works. I have >> tried to update my example, but still doesn't seem to work. Could you tell >> me, in my example, what would be the selector? I tried "p::content", but as >> you see that doesnt seem to work. >> >> My use case example, again, is here: http://codepen.io/dbugger/pen/Hyihd >> >> >> On 28 November 2013 09:58, Hayato Ito wrote: >> >>> Yeah, Chrome has already implemented that. I've implemented that. :) >>> >>> >>> On Thu, Nov 28, 2013 at 6:25 PM, Enrique Moreno Tent < >>> enriquemorenot...@gmail.com> wrote: >>> Oh, interesting! Has this been implemented in any browser? On 28 November 2013 08:46, Hayato Ito wrote: > We can use '::content' pseudo elements if we want to apply styles to > distributed nodes from a shadow tree. > > See > http://w3c.github.io/webcomponents/spec/shadow/#content-pseudo-element > > > On Thu, Nov 28, 2013 at 9:14 AM, Enrique Moreno Tent < > enriquemorenot...@gmail.com> wrote: > >> Hello, I have been experimenting with Web Components and I have an >> issue, which I think I have represented fairly clear here: >> >> (Tested on Chrome) >> http://codepen.io/dbugger/pen/Hyihd >> >> If I understood correctly, one of the points of web components is to >> control the presentation of our component. That is why we have the Shadow >> Boundary. BUT what happens with the elements that are represented with >> ? They are not considered part of the shadow, therefore the >> styles >> that the author decides to apply on them, will "invade" the Web >> Component. >> >> Any thought on this? >> >> -- >> Enrique Moreno Tent, Web developer >> http://enriquemorenotent.com >> > > > > -- > Hayato > -- Enrique Moreno Tent, Web developer http://enriquemorenotent.com >>> >>> >>> >>> -- >>> Hayato >>> >> >> >> >> -- >> Enrique Moreno Tent, Web developer >> http://enriquemorenotent.com >> > > > > -- > Enrique Moreno Tent, Web developer > http://enriquemorenotent.com >
Re: [HTML Imports]: Sync, async, -ish?
I don't see this solution scaling at all. Imports are a tree. If you have any import that includes any other import, now the information about what tags to "wait" for has to be duplicated along every node in that tree. If a library author chooses to make any sort of "all-in-one" import to reduce network requests, they will have an absurdly huge list. For example: Brick or Polymer On Thu, Nov 21, 2013 at 2:21 PM, Daniel Buchner wrote: > Steve and I talked at the Chrome Dev Summit today and generated an idea > that may align the stars for our async/sync needs: > > > > The idea is that imports are always treated as async, unless the developer > opts-in to blocking based on the presence of specific tags. If the parser > finds custom elements in the page that match user-defined "elements" tag > names, it would block rendering until the associated link import has > finished loading and registering the containing custom elements. > > Thoughts? > > - Daniel > > > On Wed, Nov 20, 2013 at 11:19 AM, Daniel Buchner wrote: > >> >> On Nov 20, 2013 11:07 AM, "John J Barton" >> wrote: >> > >> > >> > >> > >> > On Wed, Nov 20, 2013 at 10:41 AM, Daniel Buchner >> wrote: >> >> >> >> Dimitri: right on. >> >> >> >> The use of script-after-import is the forcing function in the blocking >> scenario, not imports. >> > >> > Yes. >> >> >> >> Let's not complicate the new APIs and burden the overwhelming use-case >> to service folks who intend to use the technology in alternate ways. >> > >> > I disagree, but happily the current API seems to handle the >> alternative just fine. The case Steve raise is covered and IMO correctly, >> now that you have pointed out that link supports load event. His original >> example must block and if he wants it not to block it's on him to hook the >> load event. >> >> >> >> For my bit, as long as the size of the components I include are not >> overly large, I want them to load before the first render and avoid getting >> FUCd or having to write a plethora of special CSS for the not-yet-upgraded >> custom element case. >> > >> > According to my understanding, you are likely to be disappointed: the >> components are loaded asynchronously and on a slow network with a fast >> processor we will render page HTML before the component arrives. We should >> expect this to be the common case for the foresable future. >> > >> >> There is, of course, the case of direct document.register() invocation >> from a script tag, which will/should block to ensure all elements in >> original source are upgraded. My only point, is that we need to be >> realistic - both cases are valid and there are good reasons for each. >> >> Might we be able to let imports load async, even when a script proceeds >> them, if we added a *per component type* upgrade event? (note: I'm not >> talking about a perf-destroying per component instance event) >> >> > jjb >> >> >> >> Make the intended/majority case easy, and put the onus on the less >> common cases to think about more complex asset arrangement. >> >> >> >> - Daniel >> >> >> >> On Nov 20, 2013 10:22 AM, "Dimitri Glazkov" >> wrote: >> >>> >> >>> John's commentary just triggered a thought in my head. We should stop >> saying that HTML Imports block rendering. Because in reality, they don't. >> It's the scripts that block rendering. >> >>> >> >>> Steve's argument is not about HTML Imports needing to be async. It's >> about supporting legacy content with HTML Imports. And I have a bit less >> sympathy for that argument. >> >>> >> >>> You can totally build fully asynchronous HTML Imports-based >> documents, if you follow these two simple rules: >> >>> 1) Don't put scripts after imports in main document >> >>> 2) Use custom elements >> >>> >> >>> As an example: >> >>> >> >>> index.html: >> >>> >> >>> ... >> >>> >> >>> .. >> >>> >> >>> my-ad.html: >> >>>
Re: [HTML Imports]: Sync, async, -ish?
On Wed, Nov 20, 2013 at 9:51 AM, John J Barton
wrote:
> Another alternative:
>
> First let's agree that Souder's example must block:
>
>
>
> ...
>
>
>
> var link = document.querySelector('link[rel=import]');
> var content = link.import.querySelector('#imported-content');
> document.getElementById('import-container').appendChild(content.cloneNode(true));
>
>
> If we don't block on the script tag then we have a race between the
> querySelector and the import, fail.
>
> To me the async solution is on the script, just like it is today load
> events:
>
>
>
> var link = document.querySelector('link[rel=import]');
>
>
> link.addEventListener('load', function() {
> var content = link.import.querySelector('#imported-content');
>
> document.getElementById('import-container').appendChild(content.cloneNode(true));
>
>
> }
>
>
> Now the script still blocks but it is short and just registers a handler.
> When the link loads it is executed. Here the dependency is correctly set by
> the script tag.
>
> But I don't see a 'load' event in the Import spec,
> http://www.w3.org/TR/html-imports/
>
The link element already has a generic "load" event in the HTML spec:
http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#attr-link-crossorigin(I
tried to get as close as possible to the actual line without
overshooting).
> jjb
>
>
> On Mon, Nov 18, 2013 at 1:40 PM, Dimitri Glazkov wrote:
>
>> 'Sup yo!
>>
>> There was a thought-provoking post by Steve Souders [1] this weekend that
>> involved HTML Imports (yay!) and document.write (boo!), which triggered a
>> Twitter conversation [2], which triggered some conversations with Arv and
>> Alex, which finally erupted in this email.
>>
>> Today, HTML Imports loading behavior is very simply defined: they act
>> like stylesheets. They load asynchronously, but block
Re: [Shadow DOM] Simplifying level 1 of Shadow DOM
On Wed, May 1, 2013 at 11:49 AM, Ryosuke Niwa wrote: > On Apr 30, 2013, at 12:07 PM, Daniel Freedman wrote: > > > I'm concerned that if the spec shipped as you described, that it would > not be useful enough to developers to bother using it at all. > > I'm concerned that we can never ship this feature due to the performance > penalties it imposes. > > > Without useful redistributions, authors can't use composition of web > components very well without scripting. > > At that point, it's not much better than just leaving it all in the > document tree. > > I don't think having to inspect the light DOM manually is terrible I'm surprised to hear you say this. The complexity of the DOM and CSS styling that moden web applications demand is mind numbing. Having to create possibly hundreds of unique CSS selectors applied to possibly thousands of DOM nodes, hoping that no properties conflict, and that no bizarre corner cases arise as nodes move in and out of the document. Inspecting that DOM is a nightmare. Just looking at Twitter, a Tweet UI element is very complicated. It seems like they embed parts of the UI into data attributes (like data-expanded-footer). That to me looks like a prime candidate for placement in a ShadowRoot. The nested structure of it also suggests that they would benefit from node distribution through composition. That's why ShadowDOM is so important. It has the ability to scope complexity into things that normal web developers can understand, compose, and reuse. > , and we had been using shadow DOM to implement textarea, input, and other > elements years before we introduced node redistributions. > Things like and are trivial compared to a youtube video player, or a threaded email list with reply buttons and formatting toolbars. These are the real candidates for ShadowDOM: the UI controls that are complicated. > > On May 1, 2013, at 8:57 AM, Tab Atkins Jr. wrote: > > > It's difficult to understand without working through examples > > yourself, but removing these abilities does not make Shadow DOM > > simpler, it just makes it much, much weaker. > > It does make shadow DOM significantly simpler at least in the areas we're > concerned about. > > - R. Niwa > > >
Re: [Shadow DOM] Simplifying level 1 of Shadow DOM
I'm concerned that if the spec shipped as you described, that it would not be useful enough to developers to bother using it at all. Without useful redistributions, authors can't use composition of web components very well without scripting. At that point, it's not much better than just leaving it all in the document tree. I too would like to see the Web develop organically bits at a time, but ShadowDOM fundamentally changes how the DOM works. This feels like at the inception of the automobile, deciding that a gasoline engine is too complicated and instead selling customers a horse hitched to body. We won't get good feedback on developer uptake if we take out the biggest gamechanger. On Tue, Apr 30, 2013 at 11:10 AM, Ryosuke Niwa wrote: > I'm concerned that we're over engineering here. > > I do understand adding reprojection significantly reduces the need to > write author scripts, > but I would like to see us implement the truly minimal set of features, > have all browsers ship it, > and see how authors, particularly that of high profile websites such as > Facebook and Twitter use it in real life. > > Granted, I know people have talked to developers and got feedback, etc… > but nothing beats the use in production code. > > I'd like to see the Web platform improve organically by means of positive > feedback loop between browser vendors > and Web developers. Take position: sticky for example. We saw web > developers using JavaScript and CSS to > emulate a particular mode of layout so we've added a new CSS value to > natively support that. > > For reprojection, I don't think we have sufficient data points to tell how > exactly authors are going to use or > what they're going to create with shadow DOM, and what percentage of > common use cases reprojections address. > > On Apr 30, 2013, at 10:52 AM, Erik Arvidsson wrote: > > The thing about reprojection is that it makes implementers life harder > but it makes developers life easy. I'd rather have us do the hard work > here. > > For the record, we have two independent implementations of the Shadow > DOM spec so that should debunk some of the myths that this is too hard > to implement and maintain. > > On Tue, Apr 30, 2013 at 10:37 AM, Ryosuke Niwa wrote: > > On Apr 25, 2013, at 2:42 PM, Edward O'Connor wrote: > > First off, thanks to Dimitri and others for all the great work on Shadow > DOM and the other pieces of Web Components. While I'm very enthusiastic > about Shadow DOM in the abstract, I think things have gotten really > complex, and I'd like to seriously propose that we simplify the feature > for 1.0, and defer some complexity to the next level. > > I think we can address most of the use cases of shadow DOM while > seriously reducing the complexity of the feature by making one change: > What if we only allowed one insertion point in the shadow DOM? Having > just 1 insertion point would let us push (most? all?) of this complexity > off to level 2: > > * distribution, getDistributedNodes(), etc. > * selector fragments & matching criteria > * /select/ combinator > * > * ? > * reprojection > > > I'm in favor of removing all forms of redistributions except the one where > the entire content is inserted at exactly one location. > > This will reduce things authors can do but it will considerably reduce the > implementation complexity and eliminates almost all performance penalties. > > - R. Niwa > > > > > > -- > erik > > >
Re: [webcomponents] linking using ?
The spec you're looking for is https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/components/index.htmlwhich defines On Fri, Mar 15, 2013 at 7:07 AM, Mike Kamermans wrote: > Hey all, > > I searched the archive at > http://lists.w3.org/Archives/Public/public-webapps/ and checked out > the > https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html#definitions > and > https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html > specs, but couldn't find anything about this in them: > > are there provisions in the spec (or is it in the works) to add a new > link type so that if some person A defines a stack of useful > templates, and person B wants to use those templates, they can include > them on their own page using href="http://personA/templates.html";> (or rel="components", or some > other relation name that makes sense for the role the link plays)? I > was thinking about this in terms of using web components for something > like Mozilla's Popcorn Maker, where it would be really cool if we > could define all our components as templates, and then tell everyone > "this is our collection of templates, go grab > popcorn.webmaker.org/templates.html if you want to use these on your > own pages!". I really love the idea of web components, but it feels > like being able to share them in the same way you can share .js or > ..css files would make them ridiculously powerful on the future web =) > > - Mike "Pomax" Kamermans > Mozilla Foundation > > >
