CSS has changed a lot in the last couple of years. It feels like we're getting new features monthly now. New features are well and all, but it's hard to keep up with what's fully supported or safe to use.
Enter progressive enhancements: code features and syntax that provides you with safe fallbacks in case your users visits your website in a browser that lacks support.
Here are a few simple CSS properties and techniques that are safe to use; enhancing the experience for some users, but provides satisfying fallbacks for others.
Better text with text-wrap: pretty and text-wrap: balance
Not all browsers support the text-wrap values balance and pretty, but they are safe to use.
If you're not familiar with these values they are ways to "fix" your text to look (you've guessed it) prettier or more balanced.
pretty fixes the problem with "orphan" words, when the last word of a paragraph of text wraps to a new line, leaving it all alone at the bottom. pretty ensures that the last word gets accompanied by another, which is great for headings (NOTE: Don't use it for larger portions of body text, as it uses a slower algorithm to calculate the best outcome).
MDN documentation for text-wrap: pretty
balance adjusts your paragraphs so that the text is wrapped in a way that balances the number of characters on each line, enhancing layout quality and legibility. It's useful for paragraphs of a certain length, e.g. leading text or some marketing copy inside a banner. (NOTE: Do not use this on all <p> tags in your body text. The calculating of the perfect balance based on the number of characters is computationally expensive, so the browsers have a cap on this feature based on lines of text: six or less for Chromium, and ten or less for Firefox)
MDN documentation for text-wrap: balance
Demo
The fallback
The only thing that happens if the browser doesn't support these features is that the text will have orphans or might not be as balanced as you'd prefer. And that's OK; we've lived with this for 30+ years of web browsing, so it's not harming the experience of users with not-supported browsers.
Auto-growing form fields with field-sizing: content
Ever been frustrated that <textarea>s doesn't automatically grow when you write in them? Well, that's finally being fixed, with field-sizing: content.
This property and value will make your <input>, <select> or <textarea> automatically grow based on its content. I recommend you use it for <textarea> especially, and it is safe to use today, even though it's marked "experimental" by MDN.
MDN documentation for field-sizing
Demo
The fallback
The fallback for this is simple: the fields won't grow if a browser doesn't support the feature. And that's OK, too!
The psuedo elements ::marker and ::placeholder
Want to style the disc indicators on list items in an <ul>, change the colors of the numbers in an <ol>, or style the placeholder of an <input>? You can, using psuedo selectors like ::marker and ::placeholder.
Note that the ::marker element is a weird one, as there's only a handful of properties that will work with this selector:
- All
fontproperties - The
white-spaceproperty -
color -
text-combine-upright,unicode-bidi, anddirectionproperties - The
contentproperty - All
animationandtransitionproperties
Read more about it here: MDN documentation for ::marker
For ::placeholder you can do pretty much anything you can do with normal text, change the color, font-weight, font-family etc., but please keep in mind that the placeholder of an input still should look like a placeholder, not look like there's already a value typed into the input.
MDN documentation for ::placeholder
Demo
The fallback
These doesn't work in every browser or browser versions, but using them won't ruin anything either, making it a perfect progressive enhancement. Markers like discs and numbers will fallback to have the same color as the list item's text, while the placeholder will have the browser's built-in style.
In conclusion
It's hard to keep up with what's safe to use in CSS, as Baseline (from webstatus.dev) and caniuse.com only states if something is available in a certain browser version, not what will happen to your UI if the selector, property or value isn't supported.
Always figure out what fallbacks the experimental or less-supported functionality will yield.
Top comments (0)