CSS custom properties (variables) polyfill? #10

Closed
kaelig opened this Issue Dec 17, 2013 · 11 comments

Projects

None yet

5 participants

@kaelig
kaelig commented Dec 17, 2013

Hi,

I like the idea behind your work, but at the same time it seems very complex to shim some of the principes behind the spec of custom properties.

Custom properties take the cascade into account, for example:

CSS

body {
    var-default-font: sans-serif;
}
h1 {
    font-family: var(default-font);
}
#awesome {
    var-default-font: serif;
}

HTML

<h1>This text: sans-serif</h1>
<div id="awesome">
  <h1>This text: serif</h1>
</div>

How does Myth polyfill this use case? If it doesn't, can it be specified in the documentation?

@necolas
necolas commented Dec 17, 2013

You can't do that. Despite what the docs say, this isn't a polyfill. Rework's variables cannot be dynamic or know anything about the DOM tree of the nodes they're being applied to. See https://github.com/visionmedia/rework-vars

@rodneyrehm

Not only do they take the cascade into account, they can be changed at runtime. so node.style.varDefaultFont = "foo" (or something equivalent using the CSSOM) would cause all styles using var(default-font) to update their calculated value.

Unless I'm missing something, a fix could simply output

body {
  /* ignored if not supprted, otherwise fully functional */
  var-default-font: sans-serif;
}

h1 {
  /* generated backward-compatible */
  font-family: sans-serif;
  /* ignored if not supprted, otherwise fully functional */
  font-family: var(default-font);
}

/* folding selectors if they change a variable's value */
#awesome h1 {
  /* generated backward-compatible */
  font-family: serif;
  /* ignored if not supprted, otherwise fully functional */
  font-family: var(default-font);
}

Otherwise I wouldn't be able to make use of CSS Variables to the fullest if I were to run myth, or am I missing something the examples don't explain?

*Update: *
Looking at rework-calc dumping the original declaration into the output is not a problem (at least for calc())

@kaelig
kaelig commented Dec 17, 2013

Thanks @necolas for the heads-up. Even though this is not a big deal now (support is almost inexistent at this point), doesn't it partially negates the "future-proof" argument that Myth advertises?

@necolas
necolas commented Dec 17, 2013

Not if you just use global variables until there is adequate browser support for native CSS variables. It's impossible to mimic dynamic variables in a preprocessor.

@rodneyrehm

While we're at it, apparently there's more wrong with the var implementation: css is not order dependent, but myth is

@necolas
necolas commented Dec 17, 2013

Open an issue in the correct repo and we can work out what is the preferred behaviour for a css preprocessor.

@tabatkins

It's not impossible to mimic dynamic variables if you restrict it appropriately. Since you don't actually have the dynamic functionality, restricting the syntax doesn't lose you any powers, it just keeps you within the subset that you can actually simulate.

In particular, it's possible for a preprocessor to correctly simulate variables if they restrict custom properties to show up in blocks with :root selectors only. That way you don't have to understand the tree structure at all, since they're all on one element and they apply to the whole tree. So, in the original CSS example, #awesome { var-default-font: serif; } would have to be flagged as an error.

In addition, you still need to honor the cascade correctly. In the following example:

:root { var-a: "wrong"; }
.foo { content: var(a); }
:root { var-a: "right"; }

The correct value for content is "right", but Myth'll give it "wrong". This can be done easily with a two-pass processor, but it looks like Myth is doing single-pass and getting things wrong.

@kaelig
kaelig commented Dec 17, 2013

@tabatkins Great point. Looks like this discussion belongs into reworkcss/rework-vars#15

My original concern was trying to know if Myth could document the extent of its polyfilling abilities so that users are not lead into a certain misconception of inexistent features.

@ianstormtaylor
Collaborator

@tabatkins totally right, should be a pretty easy bug to fix. i'm planning to patch rework/vars very soon - thanks :)

@necolas
necolas commented Dec 17, 2013

proposed patch: reworkcss/rework-vars#16

@necolas
necolas commented Dec 19, 2013

should be fixed in rework-vars 2.0.2

@kevinSuttle kevinSuttle referenced this issue in postcss/postcss-custom-properties Aug 3, 2016
Open

Runtime support #32

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment