The myth of the “modern browser”

&#62; I think it is time we stopped thinking in browser versions and instead check for availability of features.<p>Great. How? Detecting features can be <i>really</i> difficult, it's why we need libraries like Modernizr. Some are outright impossible: try detecting touch support. I know you think you can but you can't without UA sniffing.<p>Even harder, try detecting <i>mouse</i> support.<p>I don't know what the history is behind document.implementation.hasFeature but I know that it doesn't work for anything but SVG today. Not sure if that's the way to go but we definitely need a better way that the try/catch and complicated loops we currently employ.

<i>End users should always have the newest browser without having to work on it and thus get new features when they are ready and hotfixes and security fixes in the fastest way possible.</i><p>People chasing the chimera of the browser as universal app platform have lost the forest for the trees. Do you really expect me to take a dev platform seriously that can't be versioned and is constantly being changed out from underneath users?<p>I don't envy QA teams working on web apps.

I, for one, am looking forward to post-modern browsers.

I am thinking the "HTML5" buzzword is misleading: <a href="http://yuhongbao.blogspot.com/2012/07/why-html5-buzzword-is-misnomer.html" rel="nofollow">http://yuhongbao.blogspot.com/2012/07/why-html5-buzzword-is-...</a><p>IMO "modern browser" isn't too bad if used properly and definitely better than "HTML5".

Browser versions are more useful to the end-user who need to upgrade their browser to support your application, but I agree in actual code features should be checked.<p>"The web is full of outdated tutorials and bad advice and the largest part of those happened because a snapshot of browser functionality at that time was considered state of the art and “modern browser” stuff. "<p>This can happen with anything on the web and the reason why I always pay attention to the date of each article.

Let's suppose that a browser vendor claims that they support a feature, when in fact it's broken (either small but annoying bugs, or "horribly"). Therefore you can't trust a browser's self-reported feature set. So, an obvious solution is to create a similar client-side table of features. Why can't we do that now instead?

&#62; I think it is time we stopped thinking in browser versions and instead check for availability of features.<p>This is the pythonic way, right? Instead of trying to determine the class taxonomy of the object you have, you query it for the method you want to use. I could be thinking of something else, though...

It doesn't matter how you call it but you can't just stop "thinking in browser versions", that's a stupid meta-discussion without much practical impact. It's browser versions the end customer uses, it's browser versions selenium tests run on and it's browser versions that are in every contract for a serious website.<p>The point is: In the end the customer doesn't care if you call it modern browser or html5 or interwob2.0, it has to work. The basic notion is that the customer uses a browser and not a feature in some standard called HTML5.

What does it even mean to "have" a feature? Suppose a particular browser implements a feature poorly, or with certain known bugs; you may still need to be able to work around actual behavior.

Welcome to the world of technical writing.