Bug: CSS Custom Properties can't be set

[hpate-omicron]

CSS Variables cannot be used from Elm at the moment, style "--myvar" "value" is not applied to DOM.

Elm version: 0.19
Browsers: All

Here are some SSCEs, if CSS variables were applied you would see a 200x200 blue box in this Ellie:
https://ellie-app.com/3fpSpnv8nyNa1

Instead, the box is empty

Vanilla HTML + CSS example https://codepen.io/hpate-omicron/pen/BOZzgZ

caniuse data: https://caniuse.com/#feat=css-variables
W3 spec: https://www.w3.org/TR/css-variables/

[brasilikum]

Possible duplicate:
#129

[hpate-omicron]

To address some of the notes on the previous issue:

I'm not sure the exact purpose of CSS variables when you are working in a language that has variables. It seems like this is a 2nd way to do things we can already do differently, except now without any compiler help for types and typos.

I'm not against doing this particularly, but so far I have not seen any cases that definitively show that this is a good thing to have. I prefer to use GitHub for bugs, not feature requests, so I will close.

The main benefit is that the variables can be referenced from other CSS, for instance, I have some code to allow me to make boxes at different aspect ratios. Another use is in theming components.

@supports (--custom: property) {
  [style*="--aspect-ratio"]::before {
    content: "";
    float: left;
    height: 0;
    width: 1px;
    margin-left: -1px;
    padding-bottom: calc(100% / var(--aspect-ratio));
  }
  [style*="--aspect-ratio"]::after {
    content: "";
    display: table;
    clear: both;
  }
}

To the second point, I believe this to be a bug because it doesn't not support the spec, a feature request would be to add something not supported in the CSS spec.

[hpate-omicron]

Turns out there is already a PR that fixes this as well - elm/virtual-dom#127

[brasilikum]

@hpate-omicron So do you think you can close this as discussion is going on elsewhere anyways?

[hpate-omicron]

This one should remain open, the previous issue was marked as a feature request and closed, and the pull request hasn't had any activity on it since it was opened, so this is still an open bug.

[Lattyware]

I'd like to note this is a really important bug to fix for my uses.

One of the core benefits of CSS is that style can be swapped out without changing the content - this means users can do things like having custom style-sheets. If you force the use of elm variables - that no longer works - the style is now embedded in the application and can't be changed in the same way.

If this feature is excluded, it basically means that Elm is dictating the use of inline styles, otherwise you have to refactor styles into elm code whenever you discover you need a variable. You then end up with duplication in your elm and CSS (e.g: if you have a media query that would interact with that variable, you now have to match that query with elm code to do the same thing, and keep it in sync).

[harrysarson]

You can make a port and call out to it when custom variables need updating. That is how I am working around the bug currently.

In js

  app.ports.setCssProp.subscribe(([selector, prop, value]) => {
    for (const $el of document.querySelectorAll(selector)) {
      $el.style.setProperty(prop, value);
    }
  });

In elm

update : Msg -> Model -> ( Model, Cmd Msg )
update msg model =
    case msg of
        ChangeStage change ->
            let
                newStage =
                    max 0 <| min Config.maxStage (model.stage + change)
            in
            { model | stage = newStage }
                |> Cmd.Extra.with
                    (setCssProp ( ".display-panel", "--show-stage", String.fromInt newStage ))
		...
					

[berenddeboer]

Great workaround, but flabbergasted elm won't fix this.

[Lattyware]

As noted in Lattyware/elm-fontawesome-generator#4 this is now a blocking issue for elm-fontawesome.

Custom properties can't simply be replaced with Elm code as suggested elsewhere. Given this seems like a small change that is already implemented, the cost of supporting this seems very low, and as far as I can see, is being held up based on misunderstanding more than anything else.

Furthermore, this is only going to get more important: future tools are being built on top of custom properties, and those will also break without them.

[ChristophP]

Yes, there are tons of libraries that are built on this the standard of CSS custom properties, such as this one. Each component can be customized with custom properties.
https://shoelace.style/components/image-comparer?id=css-custom-properties

There are even new specs building on top of it such as the @property keyword in CSS.
Example: https://css-tricks.com/using-property-for-css-custom-properties/
Spec: https://www.w3.org/TR/css-properties-values-api-1/#example-2

[z5h]

Turns out there is already a PR that fixes this as well - elm/virtual-dom#127

Seeing as there is a fix, can we apply some "persuasion" to get this applied? Perhaps a writeup on Discourse that would help people understand the problem?

[Lattyware]

Turns out there is already a PR that fixes this as well - elm/virtual-dom#127

Seeing as there is a fix, can we apply some "persuasion" to get this applied? Perhaps a writeup on Discourse that would help people understand the problem?

From April last year: https://discourse.elm-lang.org/t/css-custom-properties/5554

Radio silence after asking for the example. I lobbied for this one as hard as I could, but just no response. Evan seems to have decided that the language is frozen for now, so I wouldn't bother engaging until after things are moving again.

[ChristophP]

I remember back then that @Lattyware did a great job explaining why CSS custom properties should be supported and had lots of details in his response in discourse, which sadly never got any reactions from Evan.

However, I think the whole questioning whether it makes sense to support because elm already has variables is a bit like saying: Why should we support web components since you can already make components with Elm/React/Vue/Angular? The fact is that CSS Custom properties are a web standard that is seeing increasing usage and enables animating thins which weren't possible before in many areas including libs that Elm users may rely on.

So I think a better question than Should Elm support this? would be Will any priority be assigned to this given that it's an easy fix and it's impacting many users?

[harrysarson]

Are the any insurmountable issues with patching this in the compiled js?

elm make ... --output elm-needs-patching.js
sed s/domNodeStyle[key] = styles[key]/domNodeStyle.setProperty(key, styles[key])/ elm-needs-patching.js > elm.js
# minify etc

otherwise that should unblock this for you