browser-compat-data VS flexbugs

> a lot of the data on the site actually comes from MDN

Eh... not really.

The feature support matrix (as linked on CanIUse) comes from the browser-compat-data repo. Here's the HTML element's source data: https://github.com/mdn/browser-compat-data/blob/main/html/el...

This doesn't contain the testing and usage info that CanIUse cites for support, though, just which browser versions included which features.

CanIUse also points to their own repo, which contains a lot of data: https://github.com/fyrd/caniuse

But I can't find an easy entry point to find where they're getting the numbers for a specific element. The data on there seems to be primarily for features.

So the more precise question is, where is CanIUse getting HTML element testing and usage numbers from? Because that seems to be the issue.

The key factor for web development to stop new CSS features is cross-platform compatibility. If you want to know the compatibility data of a new feature, you can get it through platforms such as Can I Use , Browser Compat Data and Time to Stable .

Yes, Mozzila’s browser-compat-data (https://github.com/mdn/browser-compat-data) is the authoritative source.

Just noting that the browser support matrix is right here: https://web.dev/patterns/advanced-apps/contacts/#:~:text=con...

It's an Eleventy widget powered by MDN's browser-compat-data: https://github.com/mdn/browser-compat-data.

https://developer.mozilla.org Is your best friend, they even have an examples how to use it

Visit any website on https://developer.chrome.com, https://developer.mozilla.org or https://docs.microsoft.com.

W3Schools and MDN Web Docs are two great resources to learn about elements and all about HTML and CSS. Kevin Powell has a great YouTube channel which explains everything you search for. If you want to incline in your HTML and CSS skills pretty quickly, think of your objective, maybe even sketch it out, then search absolutely everything on Google and it will give you the answer. If not, this subreddit is always open. Bon voyage

For old features yes, for new ones it depends.

https://github.com/philipwalton/flexbugs

First, we read all the articles that showed us how to use it. Then we need to understand the axes. After that, we needed to wait for browser support. In the meantime, some of us brave enough used float fallbacks. On top of all that, we needed to deal with bugs. Those were the happy times, but they got us to this point in the frontend development phase.

To actually contribute, there's some flexbox bugs here which are still valid. https://github.com/philipwalton/flexbugs

If you find yourself in a situation when you have to solve a flexbox related layout bug for IE11, you might want to have a look at this collection of known issues and workarounds which helped me a great deal in the past.

For functional stuff, sure, but I don't think this is achievable within the UI domain. CSS rules have implementation details that change how you write it, for example there's a documented set of issues in flex implementations maintained here: https://github.com/philipwalton/flexbugs

It might be practical and possible to become mainstream for some domains, but it's doubtful for others.

For example, I've regularly ran into flexbox issues that are Safari-specific. I've discovered these by testing in other browsers and confirming that the issue only shows up in Safari. A good reference of Flexbox browser-specific bugs is Philip Walton's flexbugs repo.