Skip to content
This repository has been archived by the owner on Feb 18, 2022. It is now read-only.

Runtime support #32

Closed
ebryn opened this issue Apr 29, 2015 · 15 comments
Closed

Runtime support #32

ebryn opened this issue Apr 29, 2015 · 15 comments

Comments

@ebryn
Copy link

ebryn commented Apr 29, 2015

Have you thought at all about how we might be able to support custom properties being modified at runtime? That would get us closer to a higher fidelity transpilation/polyfill.

@MoOx
Copy link
Contributor

MoOx commented Apr 30, 2015

I think transpilation is not directly related to a polyfill.

Doing a polyfill can be done by two ways:

  • use postcss on the front with this plugin and some specific added code to compute thing on runtime
  • make a lighter polyfill that still need to parse stylesheets.

In all situations, this doesn't seems to be directly related to the code of this plugin.

@ebryn
Copy link
Author

ebryn commented May 1, 2015

I know it's not totally on topic, but I wanted to start a discussion about possible runtime support because I've personally heard it used as an argument for not using custom properties yet. It appears the Polymer team is exploring a runtime based solution themselves: https://github.com/Polymer/polymer/blob/0.8-preview/PRIMER.md#custom-css-properties

@MoOx
Copy link
Contributor

MoOx commented May 1, 2015

it used as an argument for not using custom properties yet

We are using custom properties syntax only. That what people should understand.

That said if they have a nice polyfill that would be cool.

@kevinSuttle
Copy link

@kevinSuttle
Copy link

Check out this thread @MoOx

segmentio/myth#10 (comment)

@MoOx
Copy link
Contributor

MoOx commented Aug 3, 2016

So what? This plugin is a fork for rework-vars, so I am aware of the entire discussion around this. I am leaving this issue open for people looking for option, but as said before, we can't handle this in postcss.

@kevinSuttle
Copy link

Is it at least possible to read the var values inside of something like React?

@MoOx
Copy link
Contributor

MoOx commented Aug 3, 2016

For that you should do the opposite: use the "variables" option to define your variables via javascript (so easily accessible in any js context).

@kevinSuttle
Copy link

So, in that case do you need to import your webpack config to a JS context, or can you make a file with a default export that = the object that contains the values and just require() it in both the JS context and webpack config?

@MoOx
Copy link
Contributor

MoOx commented Aug 3, 2016

I think you just answered yourself with your last option ;)

@kevinSuttle
Copy link

kevinSuttle commented Aug 3, 2016

Haha. Indeed.

// Colors.js
const colorConstants = {
  PrimaryThemeColor: '#3acfb6',
  SecondaryThemeColor: '#16a78f',
}

module.exports = colorConstants;
// webpack.config.js
// ...
const colorConstants = require('./src/Themes/Colors');
// ...
    customProperties({
          preserve: true,
          variables: colorConstants,
          appendVariables: true,
     }),

@kevinSuttle
Copy link

That said if they have a nice polyfill that would be cool.

@ebryn https://github.com/webcomponents/shadycss

@luwes
Copy link

luwes commented Jul 13, 2017

I got a basic solution for this issue.
https://github.com/luwes/postcss-custom-properties-map

It's a PostCSS plugin to generate a JS lookup map with rules that have declarations with custom CSS props. The idea is to only include this map if native custom CSS props are not supported. Then we loop through those rules, find the matching ones in sheet.cssRules and change the props with the actual values. Looping through the sheets cssRules is probably the most expensive and could be optimized I think. Maybe by having a separate stylesheet for only custom css properties or putting the props at the top or bottom of your sheet and having a break rule...

@luwes
Copy link

luwes commented Aug 5, 2017

New and improved CSS var shim with example, https://github.com/luwes/postcss-var-shim

@MoOx
Copy link
Contributor

MoOx commented Aug 6, 2017

Some people like to play with fire.

@MoOx MoOx closed this as completed Aug 6, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants