Use prefixes for CSS properties

[danielhickman]

Re: #528 > comment thread

@danielhickman:

[...]
Speaking of other issues, is creating another to discuss prefixing properties a good idea? I thought it would be smart for experimental technologies such as this one.

@wbamberg:

[...]

• how to handle prefixed properties
• how to handle partially supported properties (i.e. when not all choices are supported)
• how to do support detection for things that aren't properties

Currently we just have data-property - it feels like we might need a more sophisticated way for an example to express the things the editor needs to test

[welcome]

👋 Thanks for opening your first issue here! If you're reporting a 🐞 bug, please make sure you include steps to reproduce it.

[danielhickman]

My first idea was mdn/browser-compat-data. That's a new project, right? I honestly thought these two wonderful changes to MDN were meant to go hand in hand and I was surprised when I didn't see it used. This would take care of a lot of these issues together if implemented correctly, right?

I've always been taught to not screw around with user-agent parsing and this wouldn't work on all browsers in the same way so I'm unsure if "implemented correctly" is non-trivial or even possible.

[wbamberg]

Structured browser compat data (aka BCD) is a wonderful project with lots of interesting applications both inside and outside the MDN website itself. But I'm not convinced it's appropriate here (although I could be convinced, perhaps).

I think it's worth thinking about what exactly our problem is and how we would like the editor to behave:

1. On some browsers, the examples won't work: meaning, the browser won't understand the particular CSS in the "example choice". The user won't see any effect, and will be confused or might think something is broken. In this kind of situation we'd like to explain to the user that this CSS isn't supported in the current browser, and that's why they don't see anything.

2. Sometimes this will only apply to particular choices.

3. Sometimes this will apply to the entire example (e.g. Firefox and text-decoration-skip-ink), and maybe we want to do something different in those cases (like not display the editor at all).

4. Sometimes the browser might need the property to be prefixed. In situations like this the example choices might contain the prefixed versions too (as in https://developer.mozilla.org/en-US/docs/Web/CSS/background-clip) but I think we can't always rely on this.

5. Sometimes the user will edit our example choice. The result might (a) apply fine, (b) be unsupported by the browser, or (c) be invalid. It would be very helpful to distinguish these cases so we can give the user some feedback (at the moment we don't distinguish "unsupported" and "invalid" here).

BCD is great for answering questions like: "which browsers (vendors and versions) support this feature?". But we have a slightly different question: "does this particular browser support this feature?". For individual example choices, it's an even more concrete question: "does this particular browser support this particular bit of CSS"? And there's an alternative way to answer that question, which is what we do now: just test it.

We could use BCD in situations like (3) above - where we just want to know at a high level if an item is supported, and maybe not show the editor at all if it isn't. But even in this case its not obvious that this is superior to what we do now (for example, what about versions? What if our browser just added support, but the user is on an older browser. Does this mean we have to figure out the version of our browser and compare that with the BCD? Why would we do that, when we can just test it?).

For more fine-grained situations it gets harder. For example, consider rgb(). According to the spec you can omit the commas between the values, like this: rgb(255 255 128). Firefox supports this from version 52. Chrome doesn't support it until 65 - so it's not yet supported in the released version. BCD expresses this with a subfeature whose description is "Space-separated functional color notations" (https://github.com/mdn/browser-compat-data/blob/master/css/properties/color.json#L508, https://developer.mozilla.org/en-US/docs/Web/CSS/color_value#Browser_compatibility). I find it hard to imagine how we could write something generic that could look at a CSS string like: "background-color: rgb(255 255 128);" and map it successfully to that part of the BCD, and so understand that this browser does not support that CSS.

I don't think this is a failing of BCD: I don't think it's realistic to expect BCD to be able to express this kind of stuff in a way that's easily machine-mapped to some CSS. Still, I think we would be better off finding out if some CSS is supported by trying to apply it in the browser.

One difficulty with this approach would be dealing with syntax errors: if some CSS fails to apply, is it because the browser doesn't support it, or because the CSS is invalid? For the initial choices given in the editors, we should be able to assume it's correct of course, but when the user edits a choice, we should check it's valid. For this I think we should look at https://github.com/csstree/validator to validate the CSS: then if it's valid, try to apply it, and if it doesn't apply, treat it as unsupported.

[danielhickman]

That confirms the issues I believed that the BCD system would have for this use.

Using what we do now we can look for vendor prefixes fairly easily the same way. Maybe an indication badge on the editor for if it finds and uses a prefixed version would be better than hardcoding and showing all prefixes to save vertical space.

autoprefixer is also interesting and could possibly play a role. To add all prefixes rather than detected ones if that is better.

The validator is a great idea and totally should be used. I think that'd be very helpful for people learning the syntax (or me with that obnoxious background shorthand haha).

It doesn't look like any of these solutions can solve the issue of not knowing if a certain property of a value is compatible. Is that the case?

[kenrick95]

Just a thought, I think we could make use of CSS.supports() function to check whether current CSS property-value pair is supported by browser or not instead of getting the compatibility data from browser-compat-data. (and to get broader browser support, probably polyfill could be added)

[danielhickman]

I didn't know about that function. It looks like a good idea. What are your thoughts @wbamberg?

[wbamberg]

Sorry, I haven't forgotten about this, but have had no time to properly think about it all :(. I am going to though, soon.