Conditionally using experimental CSS features

[kurtdoherty]

Context

• I recently POC'd out some changes to Elements' TextArea component to bring in behaviour outlined by the Design System. Specifically, the text area should automatically grow or shrink in height according to its text content based on optional minRows and maxRows props;
• This POC was in the context of proving out the Console Cloud product can consume components from Elements without any blocking issues and, Since our existing TextArea component can already resize, I needed to prove out the possibility of adding this behaviour to Elements' TextArea;
• There's a new experimental CSS property known as field-sizing that makes this behaviour trivial to accomplish, though as it's experimental for Chrome, it's not yet supported by Firefox or Safari;
• I'm interested in learning what our posture is toward the conditional use of these kinds of experimental features.

Discussion

The main question here is, are we comfortable leveraging experimental CSS features in our production code?

POC: TextArea w/ field-sizing demonstrates how field-sizing can be used conditionally so that browsers that support it will use it, while others will fallback to a JS-based solution that involves a "shadow" text area that's used to calculate the height the visible text area should have (this is a very common JS approach to autosizing text areas).

The usual concerns with using experimental features in production code exist here, so it's fine if we think they outweigh the benefits of leveraging it when it's available. Personally, I don't have much practical experience/learnings around conditionally using CSS features in production, so I'm very interested in any experience others may have in that space.

Ultimately, I'm suggesting the idea of possibly using field-sizing because:

• The impact to our code is very minimal. There's a few lines of CSS and some feature detection in the JS code too, so it won't be hard to remove if the new property never makes it through the draft spec stage. This also means it's not hard for us to introduce in future if we don't want to start using it now.
• Our CSS-only consumers will get the correct design system behaviour on at least Chrome and Edge, which is really nice for them. This does have the downside of potentially complicating how we can communicate this to those consumers; we could have this out in production in v5.1 and, without us performing any new release of Elements, Firefox and/or Safari could start supporting it and thus, introduce a change in behaviour for our CSS text area class/es.
• It seems like Firefox and Safari may not be too far behind support it themselves, though of course, there'll still be wide array of older versions of all the browsers in the wild that won't.

Extra reading re field-sizing

• CSS field-sizing on the Chrome developer docs.
• Explainer for the proposal.
• Draft specification for the new property.
• WebKit (i.e. Safari) are in the process of implementing it and Firefox support the spec too

[kurtdoherty]

Answered in #136 (comment) by @willmcvay:

@kurtdoherty I am totally fine on using modern CSS features - we have auto-prefixer in the build to handle browser quirks - the only issue will be our friend Safari - we have a lot of mobile iOS users so as long as there is a graceful fallback, it's all good.