inline styles and vendor prefix for values

[ronag]

How would I write the following css using inline styles?

.page-wrap {
  display: -webkit-box;
  display: -moz-box;
  display: -ms-flexbox;
  display: -webkit-flex;
  display: flex;
 }

Wouldn't be nice if react could internally automatically handle vendor prefixes (similar to stylus + nib)?

[syranide]

Related #723, it's complicated because vendor-prefixes are there for a reason and simply acting as if they weren't there means disregarding at least a part of an intentional design decision. For run-time styles, for maximum performance, one should feature test the browser and only apply styles that are valid (and perhaps fall back to a different layout entirely sometimes). Only for server-rendered DOM would the full list of variations be output.

I have no practical advice/insight here for the time being though.

[zpao]

Right now the only way to do this exactly as you want is with regular CSS. Stylus/nib generate CSS so it works for them. We operate on the DOM node itself which doesn't allow you to specify multiple values like this.

You could do what @syranide said and feature/browser detect before specifying the style value. I actually think that's something a whole library could be built for to target React users, but I don't think React should do it itself.

[whodidthis]

It seems impossible(?) to use inline flexbox with server-rendered DOMs.

dangerouslySetInnerHTML already exists so could be nice if there was a similar way to use a string with inline styles.

[appsforartists]

Autoprefixing every style is probably out-of-scope for React (just the db for autoprefixer is 500KB), but especially with the push towards inline styles with React Native, it would be nice if foundational technologies like Flexbox and transform were autoprefixed by React. They're consensus APIs that are unprefixed by everyone but Safari.

To that end, I whipped this up last night. It solves the problem as long as you remember to litter your codebase with autoprefixStyleProp calls. I'd love to see a similar solution built-in to React.

[wmertens]

@appsforartists https://github.com/cgarvis/react-vendor-prefix does this too but also handles animation properties...
This seems to be a common problem, and indeed broken for server-side rendering.

[elgerlambert]

Ran into this issue myself. Initially solved it by creating a 'display-flexbox' class as per the suggestions above. While tracking down an issue in material-ui, I noticed they had found/thought of an alternative.

Apparently you can add more display properties by specifying them as the value of your display key:

display: '-webkit-box; display: -moz-box; display: -ms-flexbox; display: -webkit-flex; display: flex',

Bit of a hack, but doesn't seem too bad. It solves the issue I was having with Safari (8.0.7) and things are still working in Chrome and FF. I haven't checked IE or older browsers.

Kind regards

[wmertens]

Wow, I am stunned that that works

On Tue, Jul 21, 2015 at 11:39 AM Elger Lambert notifications@github.com
wrote:

Ran into this issue myself. Initially solved it by creating a
'display-flexbox' class as per the suggestions above. While tracking down an
issue in material-ui
mui/material-ui#1212, I noticed they
had found/thought of an alternative.

Apparently you can add more display properties by specifying them as the
value of your display key:

display: '-webkit-box; display: -moz-box; display: -ms-flexbox; display: -webkit-flex; display: flex',

Bit of a hack, but doesn't seem too bad. It solves the issue I was having
with Safari (8.0.7) and things are still working in Chrome and FF. I
haven't checked IE or older browsers.

Kind regards

—
Reply to this email directly or view it on GitHub
#2020 (comment).

Wout.
(typed on mobile, excuse terseness)

[zpao]

FWIW, that hack only works on initial render and only because we use innerHTML. Any updates to display will then break. If at some point we change to actually using createElement, there is no guarantee it will continue to work.

[elgerlambert]

Thanks for your comment @zpao! That's good to know/be aware of.