Skip to main content

Have swapped instances adopt the color variable and mode that was set on the first instance within the object/component.


Basically to mimic the kind of cascading that happens with CSS.


My example situation:



  • A button that can have several icons within it, via instance swap.

  • The button I’ve made to have border, fill, and contents colors via theme and state modes—which respond to the container it’s in.

  • The default icon instance within the primary button is assigned the primary contents color.

  • The default icon instance within the secondary button is assigned the secondary contents color.

  • The initial color of the icons within the a separate icon library file can’t be both the primary and secondary colors—SO it would be best if the incoming instance adopted the color and mode of the default instance if it has been assigned there.


Conversely I’d think there could be situations where you’d want to insure the swapped instances keep their original colors, so I figure it should be an option. But this is my situation and I don’t know if just removing an assigned color would actually be all the control we’d need if we didn’t want what I’m asking for.

Also to follow up, this is important to be able to support the natural stacking of containers with backgrounds you find on a lot of pages/screens.


Example of a page:

Site/app theme > negative space > content area > section > promo area


Within the content area, section, and promo area there many items of text, icons, buttons, and so on that each need to auto-adapt to the sub-theme they’re in. Currently the only way for these to display correctly is to manually set each sub-item to be a certain theme. Then if you want to support another site/app theme, you have to go in and manually update all of these layers again.

Thanks for the additional feedback!


We’ll pass it onto our team for consideration.

Reply


Terms & ConditionsCookie settings