> > 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/CA%2BrMWZjJ1Z8RiOMY0xn9jQZ4rp%2BXOv3CC1aqwG5ux305sxog%2Bg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
