Allow specifying multiple fallback values for inline styles (e.g. for vendor prefixing with SSR)

[AntouanK]

I've been using the "string" hack to override CSS values in React components.

For example, if you want to have display with different values, you do

styleObj.display = '-webkit-box;display: -moz-box;display: -ms-flexbox;display: -webkit-flex;display: flex';

I have an npm module for poly-filling my styles in my React components.
https://www.npmjs.com/package/poly-style

All of that worked perfectly in v0.14. No warnings no nothing.
Updated to v15.0 today, and everything is breaking.
a) Normally there are deprecation warnings. I didn't notice any warnings on that change.
b) in the changelog I cannot see anything related to that, to understand what changed.

Am I missing something?

[gaearon]

I don’t think setting a property value to something like 'value; other-name: other-value' was ever officially supported. It might have worked by coincidence because, as mentioned prominently in the blog post, we used innerHTML to populate the initial tree when a component is mounted. It so happens that this hack you were using is compatible with the way we used to glue HTML code on initial mount.

However I don’t think this way of specifying multiple CSS values for a single property was every supported. You won’t find it anywhere in the documentation or example. Moreover, I’m pretty sure it was broken before 15 in a different way: yes, mounting a component with a style like this would work in 0.14, but updating it would fail for the same reasons this doesn’t work at all in React 15. Updates were always using DOM API for setting styles rather than innerHTML, so this hack would not work with updates. React 15 just normalizes the behavior between mounting and updates, and always uses DOM API to create DOM elements.

I see your point though. I don’t have a good solution to this inside React. This was discussed in #2020 (comment) before, and the conclusion is you should probably handle this outside React by feature testing. For example you can create a DOM element once when your code initializes, set different values of style.display on it, and see whether it sticks or gets reset. When it sticks, it means the browser supports the given value. This way you can build up a dictionary of mappings between standard values and the ones supported by the browser. Most likely there are some libraries that can do this for you.

I hope this helps! This isn’t a bug as you were relying on a hack, and we never officially supported it, as explained in #2020 (comment).

[AntouanK]

Thanks for the response.

It's a hack in a sense that you don't set the "CSS" values directly. But all you do is set a string to a
variable.
It's a valid value as a string.

JS does not allow the same key in an object to have different values, so there's no other way to do that.

Yes, maybe attribute checking would be a workaround, but it's impossible to do that server side.
(also it's a lot of work to get it right)

Since react is removing a value depending on it's content, shouldn't you document that and warn the users? I don't understand why you think it's OK to hide from documentation. For anyone that uses inline styles, it's very important to know that.
Normally react is very good at throwing warnings/errors.

If I stringify the style attribute value myself and set it, is that also a behaviour that react is going to intercept? Shouldn't the user be able to set any attribute value he/she wants?

PS. it worked fine in 0.14 with updates. Check my app that uses that : https://hack.ernews.info

[gaearon]

Since react is removing a value depending on it's content, shouldn't you document that and warn the users?

It’s not React removing the value. Your browser does it. Try to assign a string like this to node.style.display without React (or just in style inspector) and you will see that this is the case.

We documented that React is switching to using createElement() in the blog entry several times. That is the reason why anything relying on concatenation will break. In my opinion this was clearly a leaking implementation detail and relying on such details always comes at your own risk.

PS. it worked fine in 0.14 with updates.

Would you mind providing a specific example code in JSFiddle that demonstrates it working? I don’t see how updates could possibly work correctly because React always used style DOM API for updates, and it can’t work the way you describe just because you rely on string concatenation which doesn’t happen in this case.

[AntouanK]

I see.
Maybe I don't understand exactly how it works then.
I'll work on some examples and I'll post any solution I find.

Thanks.

[gaearon]

Here’s a scenario that world not work in 0.14:

1. On initial render, display is none
2. After an update, it is set to this long string

So even the existing “support” for it was inconsistent and confusing. It was broken already, you just happened to be lucky to not hit these cases.

I agree it’s not good we don’t have a good solution for auto prefixing multiple values. We could potentially allow this by letting you pass an array for the value. Let’s reopen to hear what others think.

cc @zpao

[oliviertassinari]

This way you can build up a dictionary of mappings between standard values and the ones supported by the browser. Most likely there are some libraries that can do this for you.

Yes, indeed https://github.com/rofrischmann/inline-style-prefixer is a good prefixing library.
You can use it to use the right prefixed property.
E.g display: 'flex', will become display: '-webkit-flex',.

However, when dealing with server-side rendering, things get tricky.
In my case, this solution is not enough. I prefix for all user agent on the server side and only for the browser agent on the client side. As pointed out here #1979. I think that it's a good trade-off for server side caching.

I feel like we have only two options:

• Only prefix for the user-agent on the server side
• Drop the inline style for a CSS based solution

[AntouanK]

@gaearon Like you said, the fact that react was using innerHTML made that possible. So the browser picked up that string and only applied the value that it accepted.
I don't see any good way now to set the style with multiple values for display for example.

I will work on attribute checking for fixing my app on v15, but server-side rendering will be impossible now for inline styles.
( I'm only talking for cases where like display you need different values on the same key. prefixed keys are different so it's fine )

Do you think it's important enough for react to treat style attribute as a special case and provide a solution on this?
Since a JS object is not enough to cover cases like the above.

I mostly think that flex-box is a common case that users are going to need to polyfill for the next couple of years.

[AntouanK]

FWIW, I just updated my module to make some simple checks on runtime for IE and Safari.
https://github.com/AntouanK/poly-style/blob/master/src/polyStyle.js
Seems like on other platforms flex works fine... at least for my needs.
Probably needs a lot more work to get every single edge case poly-filled.

Server-side rendering is going to be an issue though.

[zpao]

This was never an officially supported use case so we're unlikely to do anything about this in the short term. The fact that it ever worked was simply a by-product of how we optimized initial render in the past.

On the client-size we've generally recommended something that picks the right values for you based on the user agent, but as noted, that's not great for server rendering. My recommendation has always been to just use plain old style sheets for this. There are several places where the DOM APIs don't support all of the things you can do with stylesheets in an optimized way (:hover is another example - adding and removing specific styles in JS in response to events is pretty crappy even if it's possible).

Inline styles (read: JS styles) is something we're investigating more over the coming months. I'm sure that will shape how we think of styles in React in the future, but right now we aren't planning on changing anything. The issue you're having and other related issues are all a part of the considerations.