> Unfortunately, Web browsers are still not 100% identical in their behavior, so Web pages may behave differently on different browsers. For this class, the reference browser is Chrome: your project solutions must work on Chrome, and the CAs will use Chrome to test them. Your solutions need not work on any browser other than Chrome. You may use a different browser to develop your solutions if you wish (Chrome, Firefox, and Safari all have very similar behavior), but please test on Chrome before submitting. We do not recommend that you use Internet Explorer for development: historically, its behavior has been quite different from the other browsers, so things that work on IE may not work on Chrome, and vice versa.
I have mixed feelings on this. Sure...open web, and everything. But in academia, Chrome is one of the more ubiquitous dev environments to be used...I remember being locked into Visual Studio. And purportedly, the class isn't just about job skills...it's attempting to teach HTML/CSS/HTTP/JS to students who may have not had real exposure to any of those concepts, on top of Angular/Mongo/Node/Express. Restricting the environment allows at least for more consistent instruction/grading.
I don't have mixed feelings about this. A course name "Web Applications" should start by explaining the fundamental difference between "Applications" and "Web Applications", the second of which is accessed via browsers, which the developer has no control over. It's a pretty crucial concept.
As far as grading, I wouldn't expect responsive design or old IE support, but it should work in all current, major desktop browsers. It's really not hard, you just have to be conscientious of the fact that there are multiple browsers out there.
Not the first time that I see academia teaching their students the wrong way of doing things. I had to work with some graduates with certain strange ideas about approaching the work and tried to teach them an alternative, at least open their eyes and consider the possibility that what they are doing might not be the right way. Tough job. Sometimes it feels easier to hire somebody with no programming skills and teach them from scratch than to change the mental pathways of stubborn graduates.
On that note, my experience has been that academic environment often does more damage than good to its students. It sometimes takes a monumental effort to make the graduates unlearn all the wrong things they learned in the academic environment before they can proceed further in their professional development without all that bad baggage that keeps pulling them in the wrong direction.
It's like children mistreated by their parents in their youth who will carry their psychological trauma from the childhood through the years and that would detrimentally affect their lives until they get some professional help from a skilled counselor.
This is really bad considering MEAN is a) much less popular (IMO it's dying down), b) much less beginner friendly, c) much less easy to work with than Rails.
Bravo! As a Firefox user, the trend of web developers only testing in Chrome (and ending up using features that only work in Chrome) is getting really annoying. Most of the time, the fixes are really simple, like including more prefixes than -webkit.
Very happy to see Mozilla raising awareness around this issue.
Personally, I have Firefox and Chrome open side by side for development. If those two work, Safari and Edge generally will too. I'll add IE specific rules/hacks afterward.
If your app only works in Webkit / Blink, you've written a Chrome App and not a Web App.
Your CUSTOMERS do not want to see "To use this site / app, stop using the web browser you've chosen to use (or your company has chosen for you) and go install this instead!"
I didn't realize Chrome was becoming the default testing environment. I find it weird, given its terrible font rendering. I tried using Chrome but just couldn't. Smaller size fonts render weak, pale, bleak, like drawn with a dull pencil. I found it rather difficult to read large bodies of text in Chrome which was giving me quite a bit of eye strain. Not sure why anyone would want to test their pages in that in my opinion broken rendering engine.
I'm aware there is a setting which has to do with subpixel rendering or whatever this is called, I tried switching it on and off for no perceivable visual change. So I gave up on Chrome.
IE also has had broken font rendering since they moved to subpixel rendering several years ago, but at least it draws fonts in a strong and dark fashion making them more readable than in Chrome.
Personally, I design for Firefox which I consider the gold standard of web development. Then, at some intervals I check if things are okay in IE and Chrome and usually they are fine. Chrome was useful once in helping me spot some sort of a race condition, its developer tools also conveniently allow you to quickly bypass caching for testing purposes, but other than that I found it useless and unusable.
Right on. The tools we have at our finger tips as web developers are so accessible and comprehensive that there is little excuse for not testing an app across a range of user interfaces/platforms. I shiver to think how much deep DIY happened at every layer of development and deployment in previous software generations.
If I may contribute to the article somehow, I'd tell people this: stop using JavaScript for basic markup. I sigh every time I visit a site whose entire navigation structure is spit out in front of me as a disorganized wall of text, and only when I enable JavaScript that mess gets cleaned up and arranged back into something organized. It's just no way to design pages. CSS is for visual appearance and styling. JavaScript is for interactivity. If you can't give your site a proper look without resorting to JavaScript then you have no business designing web pages yet and need to go learn the basics first.
For a long time in the early 2010s, Chrome had superior developer tools built-in, while Firefox needed addons like Firebug and the Web Developer Toolbar. While these addons were good, you needed to know about them and download them separately, whereas Chrome shipped with better out of the box.
It took several years for Firefox to catch up [1], and in that time, Chrome's market share exploded, and Chrome's underpinnings V8 and Webkit found new uses outside of Chrome. Furthermore, Firefox was late to Android, where the Android Browser, and later Chrome dominated.
Part of the problem is a website/webapp developed and debugged using Chrome will work with Firefox more often than not -- so some people have been cultured to not even bother checking it in Firefox. Ironically, if more things broke spectacularly, more people would test in another browser.
This PR effort is nice, but it won't reverse the tide on its own. However, once Servo is released and sees use in an embedded setting, developers will no longer be able to get by without developing (or testing) on a Mozilla engine.
And ironically enough, whatever they use to set width of the text doesn't work for me.
Web working for everyone is easy, you just don't add crapton of pointless script bloat and use what's been working for decades - unless you need to do something special, but then you can't expect it to work for everyone.
This is what's so frustrating to me. A perfectly working web is easy. Most sites actually put more effort into making it work less. This is insane to me. Keep it simple and minimal (in size, features, frameworks, etc, not "lots of whitespace") and it will work for more users. Most sites are not special snowflakes. There are exceptions where lots of formatting/scripting needs to happen, but most sites are better off without.
Is there any research about whether users prefer web "applications" (SPAs and everything related) or good old web pages?[1] Hackernews and sites similar to this work on pretty much all browsers and devices. So, other than clients wanting to put big CSS banners and animations and using bootstrap and The Theme™[2], is there any valid reason to intentionally bloatify a page?
Edit: Sorry for not being clear, I meant websites where SPAs are not required, and plain old websites would do. In other words, do users (unconsciously?) prefer eye-candy over readability?
[1]: The benefits which users will prefer "applications" for like progressive enhancement with offline first thingy isn't here yet, and virtually no one is using it in real life. So please don't count on that yet.
[2]: http://adventurega.me/bootstrap/#
Everything in the web technology stack has been intertwined to the point where incomplete browser support for some JavaScript API could cause a bug with any level of severity, ranging from “site is ugly” to “nothing works at all”. (And it drives me crazy when some site can’t even show me a critical button because of its fanciness.)
There needs to be more work separating a critical base set of features from the rest. There needs to be more separation of the fancy from the functional (i.e. instead of requiring some bizarre mixture of JavaScript support in order for anything to look right, you have two choices: “turn on animation support” or “turn off animation support”, or some such division).
Maybe we should go back to XHTML and get serious about syntax enforcement. Suggested XHTML 3 rules:
- Everything is UTF-8.
- All tags must balance and nest properly.
- Any syntax errors or JavaScript errors generate a visible error message for the user telling them the site is broken. Then everything renders in the default font with default formatting.
- When something goes wrong, the site gets a HTTP PUT request with an error report, so sites can tell this happened.
That last feature would make it possible to fix things.
Maybe you should go back and lesrn why XHTML was never a good idea. You will discover a lot of interesting things, like MIME types, rendering modes, etc.
Browsers did show errors when illegal XHTML was served with proper MIME type, made no one happy.
> Any syntax errors or JavaScript errors generate a visible error message for the user telling them the site is broken.
This would make users not use the browser that implemented it.
> When something goes wrong, the site gets a HTTP PUT request with an error report, so sites can tell this happened.
If I bother to implement a handler just to get error reports from browsers, I surely took first the easier step to open my website in such a browser to check how it looks.
Making sure a website works for everyone is exactly what the company I'm working for [1] is focussing on.
We run a large grid of all different browsers, both old and new versions. You create a test where you verify certain aspects of your website and then run it on all these versions on our grid.
With the feedback we provide (screenshots/videos) you can fix any issues that may have come up across different browsers/versions.
While I understand and agree with what the article is saying, I think a primary driver for other browsers catching up was that they were forced to because developers refused to spend the time dealing with quirks and browsers that didn't correctly implement standards.
Necessity is the mother of invention.
If developers catered to the other browsers like they used to we wouldn't have seen the dramatically improved compatibility we now have.
Good article. Web standards and portability should be a much higher priority. A little off topic, but I like to use Chrome for anything touching Google, Facebook, and Twitter, and use Firefox for everything else. Another good practice is setting browsers to delete all cookies when the browser shuts down. With password managers, this is not much of a nuisance, and makes me feel like I am getting extra privacy and safety.
"it was found that there are more hard of hearing users in the United States than the population Spain and more users who are blind and low-vision than the population of Canada."
Really? There's more than 35 millions internet users with vision impairment? The previous section says there are 8 million people with vision impairment in the USA.
If they include world-wide users, I can see 35 million users being a reasonable statistic. If we're talking about just the USA though, depending on the definition of "blind and low-vision," I found figures between 8 million [1] and 22.5 million [2].
Yeah ok, but am I supposed to find workarounds for your bugs to support your browser? Or should I just tell users we don't support firefox until the bug is fixed?
My website has a position:fixed canvas area that works in every browser except Firefox. For firefox I have to re-apply the fixed property regularly for it to sick, otherwise the canvas scrolls with the rest of the interface.
I really believe Mozilla, Google, Apple, and Microsoft should consider working together. A single open source code base - rendering engine would be a better result for the web than multiple competing engines. The linux kernel takes contributions from thousands of organizations and it's true we do have BSD and it's great - linux as a unified open source code base serves everyone better than when we had multiple fragmented unix variations. There will always be room for experimental rendering engines and JavaScript runtime engines. But having a unified rendering engine and even unified JavaScript engine IMO would be a huge advance!
I recommend looking up the term 'software monoculture'. What you're talking about is, at least in my opinion, one of the worst things that could ever happen to the web, and already unfortunately, a serious risk with the prevalence of other browsers also being Chromium-based.
Competition in the software space is what encourages innovation to happen. Problems being tackled in different ways by different groups often leads to the best solution being found among them.
Not to mention respect for meta-standards. Trying to parse RSS feeds is an impossible job. Let alone the RSS/atom dichotomy, nobody respects the standards, or purposely violates them.
> Millions of websites have compatibility problems on one or more of the major browsers, leading to a poor user experience.
Can we just let these older browsers die out by not developing for them? Surely the users using them will update once every website they visit is broken.
Personally I only add the html5shiv and make HTML5 elements display block.
When I think about this problem, I feel like there are 2 major priorities that tug from different ends of the spectrum on this issue.
1) I want innovation. I want new features for the web. I don't want innovation to be hampered by the priority of making features cross-browser compatible.
2) I want cross-browser compatibility. I don't want to have to develop N apps (N representing the total # of browsers my website / app supports).
Personally I don't care if X browser has feature Y. As a developer, if I find a feature I want to program into my website / application, I don't want to have to wait for N-1 other browsers to implement this feature before I start using it.
I want to be able to "declare" or send a "hint" in my HTTP headers (or meta tags?) telling the browser that my site is supported by X,Y,Z browser engines. Each browser would implement a bare bones interface that decouples the "chrome" of the browser window from the "application" window, and makes the application window interchangeable (plug n play) with other browser engines. This would make browser engines interchangeable without requiring a user to close one browser and open another.
Granted, if a user doesn't have browser engine 'X', and refuses to download / install it, that's my loss as a developer / website owner. Or of course I could write some graceful degradation into my app / website. Already I hear some folks saying "but this is what we do now". Not quite. It's a subtle but I think important difference. Most people are willing to install (or already have installed) all major browsers on their computers. The point is, currently we must develop for / test for all major browsers to get the desired reach (or to prevent a user from having to switch browsers). This alternative approach moves the needle when a user installs a browser, not when they use the browser. So if there are a substantial # of people who have both Chrome / Firefox installed on their computers, but 'X'% of those people regularly use Firefox, I can still develop ONLY for Chrome and still get the desired reach into the world's population who have internet access.
There are of course going to be pros / cons no matter what you do, but given the above priorities, and the predispositions of all actors involved (web browser developers, web browser users, website / web app developers) I really think this is going to be the most scalable, least intrusive / obstructive path forward.
[+] [-] danso|9 years ago|reply
http://web.stanford.edu/class/cs142/
It requires students to test on Chrome:
> Unfortunately, Web browsers are still not 100% identical in their behavior, so Web pages may behave differently on different browsers. For this class, the reference browser is Chrome: your project solutions must work on Chrome, and the CAs will use Chrome to test them. Your solutions need not work on any browser other than Chrome. You may use a different browser to develop your solutions if you wish (Chrome, Firefox, and Safari all have very similar behavior), but please test on Chrome before submitting. We do not recommend that you use Internet Explorer for development: historically, its behavior has been quite different from the other browsers, so things that work on IE may not work on Chrome, and vice versa.
I have mixed feelings on this. Sure...open web, and everything. But in academia, Chrome is one of the more ubiquitous dev environments to be used...I remember being locked into Visual Studio. And purportedly, the class isn't just about job skills...it's attempting to teach HTML/CSS/HTTP/JS to students who may have not had real exposure to any of those concepts, on top of Angular/Mongo/Node/Express. Restricting the environment allows at least for more consistent instruction/grading.
[+] [-] nathancahill|9 years ago|reply
As far as grading, I wouldn't expect responsive design or old IE support, but it should work in all current, major desktop browsers. It's really not hard, you just have to be conscientious of the fact that there are multiple browsers out there.
[+] [-] AndreyErmakov|9 years ago|reply
On that note, my experience has been that academic environment often does more damage than good to its students. It sometimes takes a monumental effort to make the graduates unlearn all the wrong things they learned in the academic environment before they can proceed further in their professional development without all that bad baggage that keeps pulling them in the wrong direction.
It's like children mistreated by their parents in their youth who will carry their psychological trauma from the childhood through the years and that would detrimentally affect their lives until they get some professional help from a skilled counselor.
[+] [-] sotojuan|9 years ago|reply
And I say this as a JavaScript dev.
[+] [-] RodericDay|9 years ago|reply
Damn. I would definitely not take that class.
[+] [-] nathancahill|9 years ago|reply
Very happy to see Mozilla raising awareness around this issue.
Personally, I have Firefox and Chrome open side by side for development. If those two work, Safari and Edge generally will too. I'll add IE specific rules/hacks afterward.
[+] [-] skrowl|9 years ago|reply
Your CUSTOMERS do not want to see "To use this site / app, stop using the web browser you've chosen to use (or your company has chosen for you) and go install this instead!"
[+] [-] AndreyErmakov|9 years ago|reply
I'm aware there is a setting which has to do with subpixel rendering or whatever this is called, I tried switching it on and off for no perceivable visual change. So I gave up on Chrome.
IE also has had broken font rendering since they moved to subpixel rendering several years ago, but at least it draws fonts in a strong and dark fashion making them more readable than in Chrome.
Personally, I design for Firefox which I consider the gold standard of web development. Then, at some intervals I check if things are okay in IE and Chrome and usually they are fine. Chrome was useful once in helping me spot some sort of a race condition, its developer tools also conveniently allow you to quickly bypass caching for testing purposes, but other than that I found it useless and unusable.
[+] [-] fabiogo|9 years ago|reply
[+] [-] amelius|9 years ago|reply
Instead W3C should have chosen simpler primitives from which developers can build complicated (formatting) rules themselves.
Simpler primitives is also better from a security perspective.
By designing the web for average users instead of for developers, W3C has shot itself in the foot.
[+] [-] AndreyErmakov|9 years ago|reply
[+] [-] niftich|9 years ago|reply
It took several years for Firefox to catch up [1], and in that time, Chrome's market share exploded, and Chrome's underpinnings V8 and Webkit found new uses outside of Chrome. Furthermore, Firefox was late to Android, where the Android Browser, and later Chrome dominated.
Part of the problem is a website/webapp developed and debugged using Chrome will work with Firefox more often than not -- so some people have been cultured to not even bother checking it in Firefox. Ironically, if more things broke spectacularly, more people would test in another browser.
This PR effort is nice, but it won't reverse the tide on its own. However, once Servo is released and sees use in an embedded setting, developers will no longer be able to get by without developing (or testing) on a Mozilla engine.
[1] https://techcrunch.com/2013/03/18/mozilla-promises-to-improv...
[+] [-] vanderZwan|9 years ago|reply
http://khan.github.io/tota11y/
[+] [-] bostonvaulter2|9 years ago|reply
As a side note I wish that there was a link to "installing" tota11y near the top of that site.
[+] [-] Aoyagi|9 years ago|reply
Web working for everyone is easy, you just don't add crapton of pointless script bloat and use what's been working for decades - unless you need to do something special, but then you can't expect it to work for everyone.
[+] [-] CaptSpify|9 years ago|reply
[+] [-] awalGarg|9 years ago|reply
Edit: Sorry for not being clear, I meant websites where SPAs are not required, and plain old websites would do. In other words, do users (unconsciously?) prefer eye-candy over readability?
[1]: The benefits which users will prefer "applications" for like progressive enhancement with offline first thingy isn't here yet, and virtually no one is using it in real life. So please don't count on that yet. [2]: http://adventurega.me/bootstrap/#
[+] [-] makecheck|9 years ago|reply
There needs to be more work separating a critical base set of features from the rest. There needs to be more separation of the fancy from the functional (i.e. instead of requiring some bizarre mixture of JavaScript support in order for anything to look right, you have two choices: “turn on animation support” or “turn off animation support”, or some such division).
[+] [-] Animats|9 years ago|reply
- Everything is UTF-8.
- All tags must balance and nest properly.
- Any syntax errors or JavaScript errors generate a visible error message for the user telling them the site is broken. Then everything renders in the default font with default formatting.
- When something goes wrong, the site gets a HTTP PUT request with an error report, so sites can tell this happened.
That last feature would make it possible to fix things.
[+] [-] rimantas|9 years ago|reply
[+] [-] spriggan3|9 years ago|reply
[+] [-] euyyn|9 years ago|reply
This would make users not use the browser that implemented it.
> When something goes wrong, the site gets a HTTP PUT request with an error report, so sites can tell this happened.
If I bother to implement a handler just to get error reports from browsers, I surely took first the easier step to open my website in such a browser to check how it looks.
[+] [-] defied|9 years ago|reply
We run a large grid of all different browsers, both old and new versions. You create a test where you verify certain aspects of your website and then run it on all these versions on our grid.
With the feedback we provide (screenshots/videos) you can fix any issues that may have come up across different browsers/versions.
[1] https://testingbot.com
[+] [-] bcheung|9 years ago|reply
Necessity is the mother of invention.
If developers catered to the other browsers like they used to we wouldn't have seen the dramatically improved compatibility we now have.
[+] [-] mark_l_watson|9 years ago|reply
[+] [-] greenshackle|9 years ago|reply
Really? There's more than 35 millions internet users with vision impairment? The previous section says there are 8 million people with vision impairment in the USA.
[+] [-] Sgt_Apone|9 years ago|reply
[1]- https://nfb.org/blindness-statistics [2] - http://www.afb.org/info/blindness-statistics/adults/facts-an...
[+] [-] jay_kyburz|9 years ago|reply
My website has a position:fixed canvas area that works in every browser except Firefox. For firefox I have to re-apply the fixed property regularly for it to sick, otherwise the canvas scrolls with the rest of the interface.
The bug is logged with Mozilla, but nobody over there cares. If they don't care, why should I care? https://bugzilla.mozilla.org/show_bug.cgi?id=1258911
[+] [-] taf2|9 years ago|reply
[+] [-] ocdtrekkie|9 years ago|reply
Competition in the software space is what encourages innovation to happen. Problems being tackled in different ways by different groups often leads to the best solution being found among them.
[+] [-] nachtigall|9 years ago|reply
[+] [-] gkya|9 years ago|reply
[+] [-] return0|9 years ago|reply
[+] [-] lllorddino|9 years ago|reply
Can we just let these older browsers die out by not developing for them? Surely the users using them will update once every website they visit is broken.
Personally I only add the html5shiv and make HTML5 elements display block.
[+] [-] ngrilly|9 years ago|reply
Where does this figure come from?
[+] [-] datashovel|9 years ago|reply
1) I want innovation. I want new features for the web. I don't want innovation to be hampered by the priority of making features cross-browser compatible.
2) I want cross-browser compatibility. I don't want to have to develop N apps (N representing the total # of browsers my website / app supports).
Personally I don't care if X browser has feature Y. As a developer, if I find a feature I want to program into my website / application, I don't want to have to wait for N-1 other browsers to implement this feature before I start using it.
I want to be able to "declare" or send a "hint" in my HTTP headers (or meta tags?) telling the browser that my site is supported by X,Y,Z browser engines. Each browser would implement a bare bones interface that decouples the "chrome" of the browser window from the "application" window, and makes the application window interchangeable (plug n play) with other browser engines. This would make browser engines interchangeable without requiring a user to close one browser and open another.
Granted, if a user doesn't have browser engine 'X', and refuses to download / install it, that's my loss as a developer / website owner. Or of course I could write some graceful degradation into my app / website. Already I hear some folks saying "but this is what we do now". Not quite. It's a subtle but I think important difference. Most people are willing to install (or already have installed) all major browsers on their computers. The point is, currently we must develop for / test for all major browsers to get the desired reach (or to prevent a user from having to switch browsers). This alternative approach moves the needle when a user installs a browser, not when they use the browser. So if there are a substantial # of people who have both Chrome / Firefox installed on their computers, but 'X'% of those people regularly use Firefox, I can still develop ONLY for Chrome and still get the desired reach into the world's population who have internet access.
There are of course going to be pros / cons no matter what you do, but given the above priorities, and the predispositions of all actors involved (web browser developers, web browser users, website / web app developers) I really think this is going to be the most scalable, least intrusive / obstructive path forward.
[+] [-] unknown|9 years ago|reply
[deleted]