This is an interesting approach that didn't occur to me! Similar to Anne's
concerns, this would require you to have more knowledge of the internals of
the super-class component. If you own both components then this is fine.
Also if this means we can remove a complex piece from the spec to help
On Thu, Apr 16, 2015 at 7:07 AM, Wilson Page wilsonp...@me.com wrote:
This is an interesting approach that didn't occur to me! Similar to Anne's
concerns, this would require you to have more knowledge of the internals of
the super-class component. If you own both components then this is fine.
Updated https://www.w3.org/Bugs/Public/show_bug.cgi?id=28446 with the
latest, to keep the history in bug.
:DG
On Thu, Apr 16, 2015 at 7:52 AM, Dimitri Glazkov dglaz...@google.com
wrote:
On Thu, Apr 16, 2015 at 7:07 AM, Wilson Page wilsonp...@me.com wrote:
This is an interesting approach that
On Wed, Apr 8, 2015 at 8:17 AM, Anne van Kesteren ann...@annevk.nl wrote:
* Multiple shadow roots. We'd like to retain this feature.
Although it has complexity, we've heard from both Firefox UI and
Firefox OS application developers that the moment your library gets
sophisticated, you want this
On Thu, Apr 16, 2015 at 2:41 AM, Elliott Sprehn espr...@chromium.org wrote:
I don't think you need to duplicate anything. The super class can still fill
in the original shadow root, then the subclass can modify it. This is the
same concept of the prototype inheritance, your methods will shadow
On Tue, Apr 14, 2015 at 5:38 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Apr 8, 2015 at 6:11 PM, Dimitri Glazkov dglaz...@google.com
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
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 ann...@annevk.nl wrote:
On Wed, Apr 8, 2015 at 6:11 PM, Dimitri Glazkov dglaz...@google.com
!-- Whoops, my draft got cut off. --
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
On Wed, Apr 8, 2015 at 6:11 PM, Dimitri Glazkov dglaz...@google.com 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
On Wed, Apr 8, 2015 at 9:56 AM, Hayato Ito hay...@chromium.org wrote:
At the same time, however, I still have a concern, Do developers really
need such a fine-grained control? Is it too early optimization, isn't?
There has been pretty clear feedback from e.g. Ember that not exposing
the
Anne, Thank you for sharing.
I'm feeling that we might want to divide each feature provided by ShadowDOM
into more fine-grained opt-in/opt-out features, if developers want it.
At the same time, however, I still have a concern, Do developers really
need such a fine-grained control? Is it too early
11 matches
Mail list logo
