5 ms·

The myth of the “modern browser”

50 points by v33ra 14y ago

yuhong 14y ago
I am thinking the "HTML5" buzzword is misleading: http://yuhongbao.blogspot.com/2012/07/why-html5-buzzword-is-misnomer.html http://yuhongbao.blogspot.com/2012/07/why-html5-buzzword-is-... IMO "modern browser" isn't too bad if used properly and definitely better than "HTML5".
- azakai 14y ago
  I agree it's misleading, but some companies have spent a lot of money on the HTML5 brand, so expect to see a lot more of it.
  - yuhong 14y ago
    Yea, I know it is not going to disappear overnight. tantek suggested on whatwg IRC to do a CSS-style modularization of HTML, with HTML5 being the CSS 2.1.
yuhong 14y ago
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. "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. " This can happen with anything on the web and the reason why I always pay attention to the date of each article.
Professoroak 14y ago
I, for one, am looking forward to post-modern browsers.
- deleted 14y ago
  [deleted]
cageface 14y ago
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. 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? I don't envy QA teams working on web apps.
- comex 14y ago
  In a word: yes. Features are being added, but not removed - at least, not unprefixed ones, even if the vendor prefix process seems to be a little broken. If your app breaks, it's probably either your fault for trying to manually detect browsers or use unsupported features, or a bug that can be fixed relatively quickly (and in the meantime, you can always advise switching browsers, as ugly as that is). If it doesn't work because the user's browser is too old, the advice should just be to use a browser that keeps itself up to date.
  - cageface 14y ago
    This seems like a very handwavy dismissal of the difficult problem of backwards compatibility. It's hardly a secret that building an acceptably performant web app today requires all kinds of browser-specific tweaks and workarounds. Can I really expect that nobody's going to "fix" the code that made them necessary in some future update to browser X?
    - comex 14y ago
      Yeah, it's a bit handwavey (I'm a little tired)... but your claim that the web platform can't be taken seriously is exaggerated in turn. Unless you're using unstable features (or possibly writing for mobile devices - but that's a separate issue), you really don't need "all kinds of browser-specific tweaks and workarounds". The definition of "unstable features" is a bit nebulous, and it depends on whether you're trying to support all browsers - WebKit is apparently dragging their feet on unprefixing, say, CSS transitions, but Internet Explorer doesn't support them at all - but for most of the relatively old features like that, the spec is settled, so a combination of shims for existing browsers, which libraries can and do provide, and preferred use of the unprefixed feature should pretty much work forever.
Scene_Cast2 14y ago
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?
zenocon 14y ago
Welcome to the world of technical writing.
MatthewPhillips 14y ago
> I think it is time we stopped thinking in browser versions and instead check for availability of features. Great. How? Detecting features can be really 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. Even harder, try detecting mouse support. 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.
- tomjen3 14y ago
  I cannot detect mouse support, except on the assumption of no touch support. But to check for touch support, all you have to do is test for the existence of ontouchstarted on the window object.
  - MatthewPhillips 14y ago
    > I cannot detect mouse support, except on the assumption of no touch support. Bad assumption, you can have a desktop with a touch screen monitor, or a tablet with a bluetooth mouse. > But to check for touch support, all you have to do is test for the existence of ontouchstarted on the window object. Firefox uses the same codebase for desktop and mobile, so you'll get false positives on laptops and desktops. It's silly the hoops we jump through to get to 75% certainty on a feature.
natep 14y ago
> I think it is time we stopped thinking in browser versions and instead check for availability of features. 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...
- christianmann 14y ago
  Yeah, and really it doesn't even look like that. Instead of asking whether the object has the member in question, you just go for it and catch AttributeErrors.
makecheck 14y ago
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.
moron 14y ago
Problem is, users don't run collections of browser features. They run... browsers. So we test with browsers, to verify our code works in those browsers our users run. So we say "this code is supported by browsers 1, 2, and 3." because we know that, because we tested those browsers.
buster 14y ago
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. 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.
- stinos 14y ago
  I don't think the author says versions are useless.. yes they are handy to indicate, well, what version you use, but from a code point of view he is totally right imo. Look at it like this: there's the choice between a) writing a huge if/then/else for every version you can possibly encounter and b) checkig for features. I'd pick b).

50 points by v33ra 14y ago

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

azakai 14y ago
I agree it's misleading, but some companies have spent a lot of money on the HTML5 brand, so expect to see a lot more of it.
- yuhong 14y ago
  Yea, I know it is not going to disappear overnight. tantek suggested on whatwg IRC to do a CSS-style modularization of HTML, with HTML5 being the CSS 2.1.

yuhong 14y ago

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. "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. " This can happen with anything on the web and the reason why I always pay attention to the date of each article.

Professoroak 14y ago

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

deleted 14y ago
[deleted]

cageface 14y ago

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. 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? I don't envy QA teams working on web apps.

comex 14y ago
In a word: yes. Features are being added, but not removed - at least, not unprefixed ones, even if the vendor prefix process seems to be a little broken. If your app breaks, it's probably either your fault for trying to manually detect browsers or use unsupported features, or a bug that can be fixed relatively quickly (and in the meantime, you can always advise switching browsers, as ugly as that is). If it doesn't work because the user's browser is too old, the advice should just be to use a browser that keeps itself up to date.
- cageface 14y ago
  This seems like a very handwavy dismissal of the difficult problem of backwards compatibility. It's hardly a secret that building an acceptably performant web app today requires all kinds of browser-specific tweaks and workarounds. Can I really expect that nobody's going to "fix" the code that made them necessary in some future update to browser X?
  - comex 14y ago
    Yeah, it's a bit handwavey (I'm a little tired)... but your claim that the web platform can't be taken seriously is exaggerated in turn. Unless you're using unstable features (or possibly writing for mobile devices - but that's a separate issue), you really don't need "all kinds of browser-specific tweaks and workarounds". The definition of "unstable features" is a bit nebulous, and it depends on whether you're trying to support all browsers - WebKit is apparently dragging their feet on unprefixing, say, CSS transitions, but Internet Explorer doesn't support them at all - but for most of the relatively old features like that, the spec is settled, so a combination of shims for existing browsers, which libraries can and do provide, and preferred use of the unprefixed feature should pretty much work forever.

Scene_Cast2 14y ago

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?

zenocon 14y ago

Welcome to the world of technical writing.

MatthewPhillips 14y ago

> I think it is time we stopped thinking in browser versions and instead check for availability of features. Great. How? Detecting features can be really 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. Even harder, try detecting mouse support. 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.

tomjen3 14y ago
I cannot detect mouse support, except on the assumption of no touch support. But to check for touch support, all you have to do is test for the existence of ontouchstarted on the window object.
- MatthewPhillips 14y ago
  > I cannot detect mouse support, except on the assumption of no touch support. Bad assumption, you can have a desktop with a touch screen monitor, or a tablet with a bluetooth mouse. > But to check for touch support, all you have to do is test for the existence of ontouchstarted on the window object. Firefox uses the same codebase for desktop and mobile, so you'll get false positives on laptops and desktops. It's silly the hoops we jump through to get to 75% certainty on a feature.

natep 14y ago

> I think it is time we stopped thinking in browser versions and instead check for availability of features. 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...

christianmann 14y ago
Yeah, and really it doesn't even look like that. Instead of asking whether the object has the member in question, you just go for it and catch AttributeErrors.

makecheck 14y ago

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.

moron 14y ago

Problem is, users don't run collections of browser features. They run... browsers. So we test with browsers, to verify our code works in those browsers our users run. So we say "this code is supported by browsers 1, 2, and 3." because we know that, because we tested those browsers.

buster 14y ago

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. 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.

stinos 14y ago
I don't think the author says versions are useless.. yes they are handy to indicate, well, what version you use, but from a code point of view he is totally right imo. Look at it like this: there's the choice between a) writing a huge if/then/else for every version you can possibly encounter and b) checkig for features. I'd pick b).