The subtle difference between progressive enhancement and graceful degradation is lost on too many. Many of those that support “mobile first” don’t support progressive enhancement, which is an oxymoron.
Mobile first is progressive enhancement. Start with the most important part of any site: content. Mark it up. Semantically. Why? Because some readers experience your site without CSS. It’s true. Some just want the content. Screenreaders and search engines are the largest of these.
Then style the content. That’s the CSS. Mobile first says start with the LCD, the Lowest Common Denominator: mobile. But make sure that your CSS works in the LCD. That might be IE 9. It might be IE 11. Look at your analytics if possible. Progressive enhancement means add features when available. Progressively enhancing. You see? So if you are using a feature that is only available to IE 11 and better (Chrome, Firefox, etc.) and you need to support IE 9, make sure that the feature is not necessary for the user experience.
Then JavaScript. Understand that some have JavaScript disabled. Whether it be over-cautious IT departments, search engines that cannot handle rendering and parsing JavaScript, users with bad network connectivity that fails to load it, or most importantly screenreaders that help those with handicaps consume the content of the web. JavaScript is an enhancement. So long as you have the last two components set, your page works fine when JS is turned off. So, as features are available, use them.
But see, too many developers these days have abandoned this methodology that fueled the Web Standards movement. Instead, sites require over 300 kilobytes of JavaScript libraries and don’t load anything if JavaScript is disabled. Instead of starting with content, they start with jQuery, Angular, React, or whatever the library de jour is. Everything is built in JavaScript. This is graceful degradation, start with the Greatest Common Denominator. Except many aren’t even testing for the LCD. They aren’t turning off JS to make sure that their site will work for those that disable JS. Often they even break the most basic components of the web browser: the URL and the back/forward buttons.
We need to get back to progressive enhancement as the standard. We need to get back to the promise that the web is accessible to all, no matter the device they use.
Permalink
When every new website on the internet has perfect, semantic, accessible HTML and exceptionally executed, accessible CSS that works on every device and browser, then you can tell me that these languages are not valuable on their own. Until then we need to stop devaluing CSS and HTML.
Mandy Michael
Preach! It’s all I see these days in job descriptions. JAVASCRIPT! Ninja preferred. Rockstar acceptable. And then they produce crap frontend code. Their HTML and CSS is restricted to Bootstrap at best, custom crap with style attributes all over the place at worst. When I was their age, the emphasis of frontend was on the other side of the triangle: HTML and CSS. Without these, your JavaScript means nothing. Even if you are embedding your CSS and HTML in your JavaScript. Shudder.
Permalink
DirecTV has announced that they will only support Internet Explorer starting in July. Sorry, my bad. They will only support Chrome. Still, just as bad a move.
I remember when I got my first Mac back in 2004. Many sites still only supported Internet Explorer 6. And IE6 didn’t exist on Mac. Only IE5 did. Off the top of my head, the biggest two sites that I frequented that did this were my bank and Old Navy. Yes, Old Navy, an ecommerce site, in 2004 only supported IE6. No reason for it, as they didn’t use much DHTML— the hip term for JavaScript at the time— and certainly had no features that would require a specific browser, but that was the way things were done in the early 2000’s. You picked one or two browsers to support and that was it.
When jQuery first came out in 2006, it was built around browser-detection based forking. If IE, do things this way; if Firefox, do things this way. It wasn’t long before they abandoned that and went to feature-detection. If the browser supported this feature, do things this way; otherwise, do things this way.
When iPhones first hit, the popular thing was to look for a user-agent string that included iPhone. If present, deliver an iPhone experience. Then responsive web design hit in 2010 and we started targeting screen dimensions.
This was the push for the longest time. Get away from detecting browsers and specific devices. Look instead at what the browser and device are capable of, and progressively enhance the UX from there. Build for the lowest common denominator.
But now, so many sites are built to require JavaScript. React, Angular, Vue, and other JavaScript frameworks have taken over front-end development. We are including so much JavaScript on our sites that we need task management scripts and package managers to keep everything straight. Our engineering has gotten more complex than ever necessary.
And, to make matters worse, we are starting to see developers getting back to supporting specific browsers. When your front-end uses very specific, new technologies, that is the choice a developer has to make. Either a) don’t use it, as the support isn’t great yet; b) use progressive enhancement and provide a feature when available; c) find a polyfill to provide support to the greatest number of users. There should be no d) only support Chrome.
If you don’t learn your history, you are damned to repeat it.
Permalink