Repository navigation
Style mixin syntax is incompatible with Sass #1373
Description
Activity
Thanks for the heads up. If we can make these play nicer together we'll do so.
This is an issue with the SASS compiler and should be filed with them.
--my-toolbar-theme:begins a css property and the token stream after it should not be parsed as a rule. This can be seen on Firefox, for example: http://jsbin.com/siwaxeneka/1/edit?html,console,output@sorvell : The SASS guys probably don't want to fix that because, according the W3C specs, the "CSS identifiers (including element names, classes, and IDs in selectors) can contain only the characters [a-zA-Z0-9] and ISO 10646 characters U+00A0 and higher, plus the hyphen (-) and the underscore (_); they cannot start with a digit, two hyphens, or a hyphen followed by a digit."
Consequently --my-toolbar-theme is an invalid selector.
(see sass/sass#1832)Maybe should you consider another way to declare your mixins because it conflicts with existing specs ?Why not _@_mixin like SASS ? (By the way, we already have _@_apply)
Alright, thanks for the update.
We’ve since moved away from using Sass (at least for the time being), so this is not a problem for us at the moment.
I’m just wondering how “dangerous” the Polymer mixin syntax is, if it’s not considered valid CSS? I know Tab Atkins has a proposal for @apply to become a standard at some point, but is there any comments from the Polymer team regarding this? Is this actively being pushes as an upcoming standard, or will it stay Polymer specific for the foreseeable future and always require JS to parse it?
The Polymer is is working with Tab and the spec authors on this one. It's one reason we've moved to css custom properties and mixins to jump ahead of the evolving standards.
Note
--my-toolbar-theme:is how you define a custom property. If the sass compiler can't handle that syntax, then it's a bug. Properties are landing in Chrome and already in FF.Great to hear it’s moving forward, really waiting for these two (custom properties and mixins) to become native so we can take advantage of native cascade with these as well!
I think Sass can handle the custom properties syntax alright, but gets thrown off when you specify a block instead of one property value with it. Anyway, it’s going to be the Sass compiler’s problem, not Polymer’s. So I think you can close this issue :)
Edit: oh, it was closed already :D
Running the following through the Sass compiler:
Results in:
Which is obviously unwanted.
The only workaround I could think right away is to wrap the rule set in quotes (make it a string), and then interpolate that to the output:
Not a huge issue, but it would be great if the custom mixin syntax would work with the Sass compiler as well.