Aaand this is why I need to read all the docs. That's exactly what I need, thanks! On Aug 5, 2014 10:06 AM, "Steve Orvell" <[email protected]> wrote:
> Do you agree (in which case this leakage might be considered a bug) or is >> there a different philosophy at play that I might not have considered? > > > I think in general, we totally agree. The contract between an element and > it's light dom should be clear and specific. > > In the case of `core-selector`, it's purpose is to manage and display a > selection state for its items. The items may be its light dom. We've made > the decoration that's applied to the selected item highly configurable. You > can set the selectedClass, selectedProperty, and/or selectedAttribute > that's applied to the selected item and any of these can be disabled. > > > On Fri, Aug 1, 2014 at 10:54 AM, Michael Bleigh <[email protected]> wrote: > >> Here's a general "food for thought" type question: when and in what >> fashoin is it appropriate for custom elements to manipulate the Light DOM? >> To me one of the biggest benefits of WC is the ability to have complex >> display logic without polluting the DOM. However, in some cases that >> doesn't *quite* happen. For instance, if I use <core-selector> then the >> "core-selected" class is applied to whatever element is currently selected. >> >> While this may be mostly benign in the most basic use case, I have a more >> advanced use case where I am exposing <content> to a <core-selector> inside >> my own custom element. For example: >> >> <polymer-element name="my-element" attributes="active"> >> <template> >> <!-- some other stuff goes here --> >> <core-selector> >> <content selector="my-sub-element"></content> >> </core-selector> >> </template> >> <script><!-- ... --></script> >> </polymer-element> >> >> >> I have separate logic that applies a boolean "active" attribute to the >> currently selected item, and ideally that would be the ONLY material change >> to the Light DOM. However, as it stands the active element gets both a >> "core-selected" class and the "active" element. This may seem like not a >> big deal (and mostly it isn't), but I'm specifically building this element >> to be tool-friendly and now I have an unexpected side effect to handle. >> >> One solution to this, of course, is to extend and modify core-selector to >> suit my own needs, but I thought it was worth bringing up in the context of >> a larger discussion. To me Light DOM manipulation by custom elements should >> only ever be for semantic, not display or convenience, purposes. Do you >> agree (in which case this leakage might be considered a bug) or is there a >> different philosophy at play that I might not have considered? >> >> Thanks! >> >> Follow Polymer on Google+: plus.google.com/107187849809354688692 >> --- >> You received this message because you are subscribed to the Google Groups >> "Polymer" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/polymer-dev/2b3d05f5-d885-41c2-8617-9530e68dc853%40googlegroups.com >> <https://groups.google.com/d/msgid/polymer-dev/2b3d05f5-d885-41c2-8617-9530e68dc853%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > Follow Polymer on Google+: plus.google.com/107187849809354688692 --- You received this message because you are subscribed to the Google Groups "Polymer" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/CABrD70DmuK%3DdDoNewJr6evOPVjAsZrhkdnzOtevYqTNBhLtYSA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
