Bleeding Boundaries

65 views
Skip to first unread message

Michael Bleigh

unread,
Aug 1, 2014, 1:54:29 PM8/1/14
to polym...@googlegroups.com
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!

Steve Orvell

unread,
Aug 5, 2014, 1:06:17 PM8/5/14
to Michael Bleigh, polym...@googlegroups.com
 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.


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 polymer-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/2b3d05f5-d885-41c2-8617-9530e68dc853%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Michael Bleigh

unread,
Aug 5, 2014, 1:09:24 PM8/5/14
to Steve Orvell, polymer-dev

Aaand this is why I need to read all the docs. That's exactly what I need, thanks!

Reply all
Reply to author
Forward
0 new messages