I should rephrase that as... The variables created by Myth are not dynamic so you can't change them at runtime and have those changes cascade through your document (as you can with CSS variables). At least that's my understanding. On Feb 12, 2014 7:32 PM, "Rob Dodson" <[email protected]> wrote:
> You can sort of polyfill CSS variables with Myth ( http://www.myth.io ) > but it sounds like they don't cascade. > On Feb 12, 2014 1:00 PM, "Scott Miles" <[email protected]> wrote: > >> Good questions. :) >> >> - I understand why ^ and ^^ is necessary, but in general doesn't ^ >> and ^^ necessitate a developer to either know the sDOM code or dig into >> it? >> This seems very un-componenty/goes against the idea behind components to >> me. In general would it be considered good practice to use ^ and ^^ >> sparingly? Essentially try not to cross the shadow boundary as much as >> possible? >> >> In general yes, we want folks to avoid ^ and ^^. The vibe is that styles >> are protected by default and you can only break the style encapsulation on >> purpose via ^ and ^^. >> >> However, very often components want to be 'themable', which is to say, >> styled to match a particular environment. In that case we suggest authors >> provide documentation about classes which are 'safely stylable' using ^^. >> >> IOW, the author of input-range (I made that up) defines a 'range-thumb' >> class for end-users to theme his control. Then we can put in our page: >> >> body ^^ input-range ^ .range-thumb { >> color: blue; >> } >> >> >> This is 'safe' because we have a contract with the author about >> '.range-thumb' that leaks nothing about the structure of input-range. >> >> Admittedly, the syntax is a bit nasty, and ^ and ^^ are big hammers. We >> are still working on increasing elegance. >> >> - If styling should be exposed, it seems like CSS variables is the >> way to do it since it provides a nice interface for users which seems more >> componenty to me than ^ and ^^. I was wondering what your thoughts were on >> this. >> >> CSS variables are too specific. You could expose 'font-size' this way, >> but what if I want to change any of the numerous other font properties. >> Trying to expose variables for every possible thing is not practical. >> >> - On first take it seems a bit strange to me that each component has >> to have documentation about what attributes/variables act as the interface >> with the component especially since the 'API' can be arbitrary. >> >> I'm confused how you note that the API is arbitrary and then ask why it >> needs documentation. It needs documentation because it's arbitrary. >> >> - Is there a good polyfill for CSS variables? It seems like it's >> being removed in blink ( >> >> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/ScKw9zYRkBc >> )? >> >> I don't know about CSS Variable polyfills, sorry. Anybody else? >> >> Scott >> >> >> On Wed, Feb 12, 2014 at 12:40 PM, Jay Ryoo <[email protected]> wrote: >> >>> I just started getting into Polymer and am very excited by the prospect >>> of web components. Correct me if I am wrong, but it seems like the central >>> idea is that developers create components and every component has an >>> API-like interface that other developers can use to use the component. >>> >>> I am currently reading Shadow DOM 201 and had some questions regarding >>> ^, ^^, and CSS variables. >>> >>> 1. I understand why ^ and ^^ is necessary, but in general doesn't ^ >>> and ^^ necessitate a developer to either know the sDOM code or dig into >>> it? >>> This seems very un-componenty/goes against the idea behind components to >>> me. In general would it be considered good practice to use ^ and ^^ >>> sparingly? Essentially try not to cross the shadow boundary as much as >>> possible? >>> 2. If styling should be exposed, it seems like CSS variables is the >>> way to do it since it provides a nice interface for users which seems >>> more >>> componenty to me than ^ and ^^. I was wondering what your thoughts were >>> on >>> this. >>> 3. On first take it seems a bit strange to me that each component >>> has to have documentation about what attributes/variables act as the >>> interface with the component especially since the 'API' can be arbitrary. >>> 4. Is there a good polyfill for CSS variables? It seems like it's >>> being removed in blink ( >>> >>> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/ScKw9zYRkBc >>> )? >>> >>> Please let me know if these questions make sense in the context of >>> polymer, as I am new I may not be understanding principles correctly. >>> >>> Thank you >>> - Jay >>> >>> 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/f5d3ffd8-d418-4b7b-9fcd-c4e09f9f20e8%40googlegroups.com >>> . >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >> >> 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/CAHbmOLZkAGu6ybE3EuULiyaeB6r7swrmrivE9YyEzZDPc0-%2Bjw%40mail.gmail.com >> . >> For more options, visit https://groups.google.com/groups/opt_out. >> > 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/CAJj5OwB97TkQcH_G-%2BFYV0r05GGAhzyFeqLMMZhvfDx-BPc_ZA%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
