Auto-prefix @supports rules

[blicksky]

I'm wondering if it would be possible to add support for auto-prefixing the conditions within @supports rules. Here's a reduced example from a use-case I have:

glamorous.div({
    '@supports (pointer-events: none) and ((appearance: none) or (-webkit-appearance: none) or (-moz-appearance: none))': {
        appearance: none
    }
});

It would be great if I didn't have to know and list each of the vendor prefixed appearance properties that inline-style-prefixer will replace for the appearance: none declaration in the style object. I submitted https://github.com/rofrischmann/inline-style-prefixer/issues/138 to see if inline-style-prefixer could add support for this, but it seems to be out of scope for that library.

I came up with the following experiment, which works, but uses non-public APIs:

import prefixer from 'glamor/lib/prefixer';
import { processStyleName } from 'glamor/lib/CSSPropertyOperations';

const prefixedAppearance = prefixer({appearance: 'none'});

const supportsAppearance = Object
    .keys(prefixedAppearance)
    .map((prefixedProperty) => {
        const property = processStyleName(prefixedProperty);
        const value = prefixedAppearance[prefixedProperty];

        return `(${property}: ${value})`;
    })
    .join(' or ');

glamorous.div({
    `@supports (pointer-events: none) and (${supportsAppearance})`: {
        appearance: none
    }
});

Would it be possible to make this more generic and include it in glamor such that this happens automatically?

[threepointone]

yeah, I think this would be a good thing to enable via glamor. I'll have a look soon. thanks!

[blicksky]

Thanks. I'd be happy to help with a PR if you can help me understand the right place to add this. I'm also curious what you think would be the right API for this. We could have glamor find and transform the properties in their hyphenated form within the @supports clause in property keys, but that feels different than the camelCased properties defined as object literals everywhere else. Is that alright, or is it worth adding a new export that let's you define a @supports clause as an object literal?