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.
But to check for touch support, all you have to do is test for the existence of ontouchstarted on the window object.
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.
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.
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.
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?
However I started to get some more serious bugs popping up recently.
Last week was the break-points were not hit anymore(a little nightmare, now solved! But made me go back to Firefox for a week).
And this week are visual errors, like trailing borders when mouse overing links, round corners that are cut,...
All in all, I find more positive reasons than negative to live on a moving platform, and knowing that my clients will run the same and last version as I do.
If you're a hacker, you can use Firefox until Google resolves the bug and pushes a new update. But if you're an end user at a bank, your PC is locked down and you can't install another browser (even if you knew how). That little bug in Chrome 188.8.131.52 that got fixed in Chrome 184.108.40.206 the next day could cost the bank millions of dollars as 15,000 people sit at their desks for a day unable to enter transactions.
Businesses like this have to be able to install browsers using a controlled process in which all their web apps get tested with the new version of the browser. And installing a new browser on 15,000 machines takes a lot of IT man-hours (remember, the users don't know how or aren't allowed to install their own software), so there has to be a pretty good justification to upgrade.
Welcome to the grim realities of corporate computing...
By the way, you don't have to be a large bank for something like this to affect you. You could be some tiny business like a real estate broker that depends on a web app but is not big enough to be able to afford a full-time IT staffer to maintain your software for you. I guess my point is that once you're out of the world of software developers, minor problems with browsers can be very costly and upgrading to a new version constantly can be risky.
Exactly. I have to assume the people that don't get this have never worked in these environments.
IMO "modern browser" isn't too bad if used properly and definitely better than "HTML5".
"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.
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...
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.