Hacker News new | past | comments | ask | show | jobs | submit login

Perhaps it’s time to approach the problem differently. Here’s what I propose:

If a new HTML element is not supported in browsers with broad usage *but* those browsers are deemed insecure and no longer supported, go ahead.




That's pretty common. The "browserslist" tool allows you to specify which features you want to support in terms of the browsers that support them, and the default is "> 0.5%, last 2 versions, Firefox ESR, not dead", supports all browser versions for which at least one of the following is true:

* Have more than 0.5% market share

* Is one of the last two released versions of that browser type

* Is the Firefox LTS release, which presumably doesn't fit the previous two rows but is deemed useful and modern enough to support.

In addition, all "dead" browsers (any version of IE, and a handful of obsolete mobile browsers) are explicitly not supported.

Of course, the browserslist string can be configured as needed, so if you know all users will be using a certain browser (say in a corporate environment) you can configure that fairly easily, and you can even use your own stats for things like the >2% queries.

This string can be translated into a list of browsers, and then that list of browsers can be translated into a set of supported features, which you can use to warn developers if they use unsupported elements, or pass to the bundler so that only the relevant polyfills get included. There are also more advanced techniques (like building a modern and a legacy bundle which can be loaded as needed depending on the browser).




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: