CSS Browser Support: When Can I Use This?

How to support the show

Patreon

Prices subject to change and are listed in USD

• Support the show from as little as ~$1/month
• Get a shoutout at the end of the episode (while supplies last) for just ~$3/month
• Help support the HTML All The Things Podcast: Click Here

Scrimba Discount!

We receive a monetary kickback when you use our link

• Learn to code using Scrimba with their interactive follow along code editor
• Join their exclusive discord communities and network to find your first job!
• Use this URL to get 10% off on all their paid plans: https://tinyurl.com/ScrimbaHATT

Show Notes

What is browser support disparity?

IE Disparity

• Back in the IE days there was a lot of feature disparity between IE versions
• For example, one of the most popular features of CSS -  “flexbox” -  has only partial support in IE10 and IE11. ("flexbox" | Can I use... Support tables for HTML5, CSS3, etc)
  - Even between these versions
  -- IE10 only supports flexbox at the 2012 syntax with the -ms prefix
  -- Then IE11 partially supports flexbox but it doesn’t require the -ms prefix 
  -- Both IE10 and IE11 have many flexbox bugs
  - IE10 and IE11 does not support some popular flexbox properties including flex-wrap, align-content
  - IE10 and IE11 use different default values for the flex property (0 0 auto) modern browsers (0 1 auto)
• As modern browsers took hold (ie Chrome, Firefox) the disparity between them and IE were even greater
• Since IE was installed by default on Windows PCs, IE was used by many, and so supporting them felt very crucial even as their usage statistics dropped well below 5%

Modern Disparity

":has" | Can I use... Support tables for HTML5, CSS3, etc

• Even as late as 2023, there is still some browser disparity
• Most notably the CSS pseudo-class :has has officially launched in Firefox as of December 2023, having previously been hidden behind a flag
• Chrome has supported since version 105 (released Aug 29, 2022)
• Overall (as of writing this) the global usage stat is 90.14%
  - In comparison, flexbox is at 98.01% (unprefixed and fully supported)
• Is ~90% support enough?

When can you start using a new feature?

• Answer: Varies depending on your technical needs
• Analogy for most websites: I like to think of a website as an app that supports only certain phones 
  - If you want widespread availability then it would not be a good idea to skip modern iPhone due to their popularity.
  - But would it be wise to spend time supporting the Samsung Galaxy S3 from 2012? Probably not because so many people have more modern phones

Where is your website running?

• Is your website on an intranet in a company that solely uses Safari? 
• Anything that is Safari proprietary may be safe to use in this use case then

Do you care about widespread? At scale?

• In the analogy, we already touched on situations where you want to be available as widespread as possible 
• But what about widespread at scale?
• Let’s say you’re going to skip browser support for a browser that has ~5% market share, meaning that you’re appealing to 95% of the market
  - For most websites this sounds very appealing, and offers the opportunity for a stretch goal where they can work on the other 5% later on
  - But for websites at scale, 5% of the market could represent millions of dollars of revenue per year
  - This is why so many enterprise-grade websites support such old browsers, because they’re trying to prevent leaving money on the table 
  - There are also niche markets, such as certain trades, they may focus on different technology (ie auto repair) and won’t upgrade their computers frequently - therefore they may be purchasing parts from your website from an old Windows laptop still running IE11 - do you want to give up that revenue?

Act based on data

• There’s another school of thought when it comes to browser support that states you should be appealing to the modern browsers as they exist today and then use analytics data to determine if you need to add any sort of special support for a particular browser or device
• This method can alienate those that come to the site when it doesn’t work well for their device, but it also does save you time in developing for a wide selection of browsers that may not generate hardly any traffic
• There’s also a happy side effect, of this method, where you end up analyzing data that may help you improve your site’s UX (ie maybe your mobile site is just ok, but you see a lot of traffic coming in from mobile - maybe it’s a place you should invest some time improving)

Audience Expectations

• Owners of old computers and browsers will see their web experience degrade over time, so their expectation may not be very high for your website
• That’s not to say you should deliver them a bad experience, but if you can get most of your website working for them and let’s say laid out in a way that they can read everything but it’s not as fancy as you have for modern browsers - you may consider this a win

Compatibility technologies we can use

• Can I Use
  - Website that allows you to see browser features and how their compatibility stacks up against others
  - The site includes the % of support and notes special cases (ie partial support, behind a flag)
• @supports in CSS
  - @supports is a CSS feature that you can use to check if a particular feature is supported by the user’s browser and manipulate the styles that take effect based on that compatibility
  - It supports multiple arguments (ie if the browser supports flexbox and grid then use these styles)
  - It is not supported by IE, but you can use it in inverse, because everything inside the @supports will be ignored by IE, so you can write your IE code outside the supports and your modern code inside
• Using vendor prefixes when in doubt
  - You can use vendor prefixes (-ms, -webkit) to help certain CSS properties work on browsers that require it
  - You can include prefixed and non-prefixed versions of properties and the proper one will be used by the browser automatically
• Ensuring experiences are “good enough” 
  - This leans on the “Audience Expectations” that we mentioned before, where instead of making sure all the modern conveniences are working on older browsers, you can work to ensure that their experience isn’t broken at least
• Polyfills
  - Polyfills allow web developers to use an API regardless of whether or not it is supported by a browser, and usually with minimal overhead. Typically they first check if a browser supports an API, and use it if available, otherwise using their own implementation.

Episode Source Links

• What percentage of marketshare does a browser need for your support? - Stack Overflow
  - Thread from 2008 debating browser support, with Chrome being the new kid on the block/being actively developed‍
• frontend - How to decide the minimum browser version my website should support? - Stack Overflow
  - Thread from 2019 discussing browser support with a case being made for:
  -- Testing your own analytics and choosing which browsers to support based on that
  -- Reaching 90% of the browser marketshare (in support) and thinking that’s good enough
  -- Trying out the @supports feature for “dynamic CSS stylesheets” based on available features‍
• https://youtu.be/ZzuYbhKVPE0?si=VB9e1kl-aQi08BIT
  - Web Dev Simplified video on @supports in CSS

Links

• ‍Michael LaRocca
  - Author of the Self-Taught the X Generation blog, at selftaughttxg.com