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

CSS custom properties (variables) polyfill? #10

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

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

This comment has been minimized.

Show comment
Hide comment
@necolas

necolas 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

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

This comment has been minimized.

Show comment
Hide comment
@rodneyrehm

rodneyrehm Dec 17, 2013

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())

rodneyrehm commented Dec 17, 2013

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

This comment has been minimized.

Show comment
Hide comment
@kaelig

kaelig 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?

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

This comment has been minimized.

Show comment
Hide comment
@necolas

necolas 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.

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

This comment has been minimized.

Show comment
Hide comment
@rodneyrehm

rodneyrehm Dec 17, 2013

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

rodneyrehm commented Dec 17, 2013

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

@necolas

This comment has been minimized.

Show comment
Hide comment
@necolas

necolas Dec 17, 2013

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

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

This comment has been minimized.

Show comment
Hide comment
@tabatkins

tabatkins Dec 17, 2013

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.

tabatkins commented Dec 17, 2013

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

This comment has been minimized.

Show comment
Hide comment
@kaelig

kaelig 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.

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

This comment has been minimized.

Show comment
Hide comment
@ianstormtaylor

ianstormtaylor Dec 17, 2013

Collaborator

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

Collaborator

ianstormtaylor commented Dec 17, 2013

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

@necolas

This comment has been minimized.

Show comment
Hide comment
@necolas

necolas commented Dec 17, 2013

proposed patch: reworkcss/rework-vars#16

@necolas

This comment has been minimized.

Show comment
Hide comment
@necolas

necolas Dec 19, 2013

should be fixed in rework-vars 2.0.2

necolas commented Dec 19, 2013

should be fixed in rework-vars 2.0.2

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