Thanks for the info. The polymer-project page works great on Safari, but the JSBin shows the same behavior I was working on yesterday.
This is Safari's inspector on polymer-project.org: <https://lh4.googleusercontent.com/-pP3FZzFGvdc/UuE_gN0WuYI/AAAAAAAAAww/Nzjej6oQxL4/s1600/Screen+Shot+2014-01-23+at+9.05.47+AM.png> ... and on the JSBin: <https://lh5.googleusercontent.com/-_MWV_XlYdCA/UuE_q7QA-KI/AAAAAAAAAw4/vNESIb5eaRk/s1600/Screen+Shot+2014-01-23+at+9.05.12+AM.png> The "content" value is an unknown character, not a string, so I'm thinking that maybe Safari misunderstands the encodings. I noticed that the components at polymer-project.org are vulcanized, does that process separate the styles out of the components? -Benjamin On Wednesday, January 22, 2014 12:35:33 PM UTC-7, Eric Bidelman wrote: > > Hi Ben, > > We're using FontAwesome in components on polymer-project.org's the > left-side nav > icons<https://github.com/Polymer/docs/blob/master/sass/site.scss#L216> > . > > Here's a working demo of what you're after: > http://jsbin.com/ekESeMUV/1/edit > > It should work in both native and polyfill Shadow DOM. If you want the > FontAwesome stylesheet to be a dependency of your elements, package > everything up in an HTML Import. > > --- > Note: you *should* be able to move the stylesheet inside the > <polymer-element>, but I ran into issues with @font-face in shadow roots ( > crbug.com/336876). A similar bug <http://crbug.com/332577> for @keyframes > definitions was recently fixed in Canary. The workaround for now is to use > polymer-scope="global": > > <link rel="stylesheet" href="..." polymer-scope="global"> > > But again, the recommended approach is to use an Import instead of relying > on polymer-scope="global". > > > On Wed, Jan 22, 2014 at 10:43 AM, Benjamin Howe <[email protected]<javascript:> > > wrote: > >> I've been working an issue where Safari somehow messes up the character >> encoding in the CSS included in an element definition: >> >> <polymer-element name="ui-icon"> >> <template> >> <style> >> :host { >> font-family: FontAwesome; >> content: "\f097"; >> } >> </style> >> </template> >> </polymer-element> >> >> Safari tries to decode "\f097" too early, and the icon doesn't work. >> >> The resolve was to separate the styles into an external, document level >> stylesheet: >> >> ui-icon { >> font-family: FontAwesome; >> content: "\f097"; >> } >> >> According to the Polymer docs on styling: >> >> Because polyfilling the styling behaviors of Shadow DOM is difficult, >>> Polymer has opted to favor practicality and performance over correctness. >>> For example, the polyfill’s do not protect Shadow DOM elements against >>> document level CSS. >> >> >> Does this mean that with native ShadowDOM support, my ui-icon select will >> not find its element if it's inside a ShadowDOM? My tests so far seem to >> indicate that it does (with the experimental web features flag on in >> Canary), so I'm wondering if Polymer is hacking the native implementation >> to be consistent, or what exactly is going on. >> >> 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] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/polymer-dev/d5a438a4-2e4b-4bec-803b-19053bfad955%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/18e5dd7c-6192-487e-9ff2-19477e436c58%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
