-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Shim CSS Mixins in terms of CSS Custom Properties #3587
Conversation
make `getComputedStyleValue` work with native custom properties.
```css --foo: { color: red; border: 2px solid black; } @apply --foo; ``` becomes ```css --foo-color: red; --foo-border: 2px solid black; color: var(--foo-color); border: var(--foo-border); ```
move apply-shim to lib Fix some tests
* fix custom-style test's late registrations.
No more global for defaults No need to process keyframe rules
Fix up shim var syntax `var(--a, --b)` to `var(--a, var(--b))` Disable native variables in Safari 9.1 until https://bugs.webkit.org/show_bug.cgi?id=155782 is fixed
Test new `@apply --foo` syntax Test aliasing mixins with var Test fixing bad var syntax `var(--a, --b)` -> `var(--a, var(--b))`
Clean up dependencies in apply-shim Remove lazyRegister hack
Enabled only if support is detected and `lazyRegister` setting is used. Override with `Polymer = {useNativeCSSProperties: true}` before polymer is loaded.
- Copy css-build status to cloned style in main document - Move css-build status out of ast - Instead forward a reference to the style in the ast walker callback
More easy to see that no work happens if using a targeted css build with native custom properties
var combinedProps = mixinValues; | ||
if (oldProperties) { | ||
combinedProps = Polymer.Base.mixin(oldProperties, mixinValues); | ||
} else { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is the else here? Don't we always want to update the property map with the list of all properties that have been used for that mixin?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we are using mixin
, the reference in the map is always the same and we don't need to set
again.
Add test to show that redefining a mixin works as expected
checking for native css custom properties is not needed in the property shim anymore
Comments LGTM! |
For re-writing the @apply rules, should we consider something less direct than --mixin-prop to avoid possible collisions with other custom properties? For example,
is going to get rewritten as:
In this case they probably do the same thing, but the collisions could result in unintentional behavior. I'm stretching for an example here, but I can just about imagine a developer using Anyway, it seems like we should either a) document this potential funkiness, or b) use a less common character to combine the mixin and prop. |
@arthurevans That's a reasonable point. How about '$' or '~' as a separator? |
Differentiates apply-shim variables more obviously from user variables #3587 (comment)
@arthurevans Went with |
👍 |
LGTM, can merge when ready... |
@apply
to N custom propertiesIf native css custom properties supported, all style work will happen at registration time (+/- shadydom shimming).
Use of
updateProperties
to modify or create mixins is not supported.Fixes #3503