Blog

#development

#web-standards

The web, at its best, should be resilient. Nothing warms my heart more than a 20 year old page that’s still kicking, a 10 year old link that redirects properly onto a completely new domain or platform or a modern site that can serve something useful to a 15 year old browser. To me, that’s the web at its best.

HTML + CSS + Javascript

Someone replied to my big #bbd17 post yesterday about my advocating for sites that work in IE 6. To note, it’s the quote above that this is in reference to.

As a front-end web developer, I do not test regularly in IE 6. I haven’t tested in IE 6 in a very long time. However, I write structured HTML that can be displayed without CSS. I write JS that isn’t necessary for the display and functionality of the page. So these things gracefully degrade.

No, my pages are not pixel-perfect in 15 year old browsers. But the content is accessible.

This year we saw Groupon, Spotify, and DirecTV decide to only support Google Chrome. For the web standards crowd, that should enough of a rallying cry for the cause. But how did we get here? Does anyone give a shit anymore?

Last year, Jeffery Zeldman wrote:

Many web developers have “moved on” from a progressive-enhancement-focused practice that designs web content and web experiences in such a way as to ensure that they are available to all people, regardless of personal ability or the browser or device they use.

And this is the foundation for what has happened. Many web developers have moved on from Progressive Enhancement. Supporting multiple browsers is much easier with Progressive Enhancement. You rely on the error recovery that HTML and CSS provides. You build on that. Layout your page for your Lowest Common Denominator. Mobile. Then, if CSS Grid is available, enhance the layout. Provide a zip-code-based location lookup tool. Then, if the Geolocation API is available, add a button to use your location.

This was one of many big pushes of the Web Standards movement. Before the Web Standards movement, “Best viewed in Internet Explorer” was a common badge. Developers would choose to only support and test for one browser and, often, block anyone coming from different browsers. As I wrote in June, I remember when I first got my Mac in 2004, many sites blocked me altogether. IE 6 didn’t exist for Mac and many sites required it.

So what? “What’s so bad about only supporting Chrome?”, you may ask. It represents over 75% of web traffic, right? So did Internet Explorer back in the day. That would be the same argument many used at that time. Back in that day, there were major feature differences between IE and Firefox/Netscape. Because standards didn’t exist, Internet Explorer and its competitors invented new features. Lots of new features. The features that were the same were often implemented differently. So supporting multiple browsers required lots of effort depending on what you needed. IT departments would prevent employees from installing other browsers and then build internal applications to run on IE only. But IE wasn’t available everywhere. My Mac couldn’t access my bank’s website in 2004 unless I set it to spoof the IE user agent. So the features that the bank needed were supported in Safari, but they had a block for browsers other than IE. If I didn’t know how to change my user agent, I’d have been blocked by something as important as accessing my bank.

Today, Edge, Firefox, Chrome, and Safari are relatively the same. Build something for Safari and it will mostly just work in Firefox. I built a project this Fall that took two months worth of work to build and only a couple hours to fix a few minor things in Firefox and IE/Edge. No big deal. But if I want to access the desktop site for Spotify on my 13” iPad Pro, they block it. I cannot install Chrome. Or Firefox. On iOS, my only option is Safari.

Support any user, no matter what browser they have. That is the job of a web developer. A user running IE 6 should be able to still view your website built in 2017. It may not have all the bells and whistles, but it should work. Because the web browser has great error recovery. A user that has JavaScript turned off and a screen reader reading the content of your site to them should be able to access your site. Unless you can make an argument that a feature is an absolute must, you should be progressively adding it.

So we are coming full circle. Overuse of JavaScript. Using JavaScript to build static, undynamic, barely-interactive websites. Supporting only certain browsers for no technical reason. Best viewed in Chrome.

We— those that believe in Web Standards, those that fought in the first battles and pushed our fellow developers to learn more and produce more inclusive, accessible, cross-platform websites— we need to stand once again for Web Standards. We need to make it clear what the best practices are and fight against the bad practices where we work. There are no excuses in 2017. Web development has gotten easier. Forking code for multiple browsers is significantly less necessary today. Changes are, usually at best, a few hours of work for big projects. No excuses.

But the core principles and mechanisms [of CSS] are no more complicated than they were a decade or even two decades ago. If anything, they’re easier to grasp now, because we don’t have to clutter our minds with float behaviors or inline layout just to try to lay out a page. Flexbox and Grid (chapters 12 and 13, by the way) make layout so much simpler than ever before, while simultaneously providing far more capability than ever before.

Eric Meyer

I built my first couple of layouts with Grid over the last weeks. Hot dog. Things that would have taken me forever with floats took me just a couple lines of code with Grid. I’ve been using Flexbox for a while, to the point of mostly knowing the syntax, but Grid is a brand new beast.

It is astonishing that we have, for almost 20 years of CSS, never had a native layout system. Now we do. Instead of complex (and large) libraries like Bootstrap, we can now do complex layout with simple syntax. Hell, we can do far more complex, asymmetric and two-dimensional layout with Grid that we would never consider doing before. A renaissance in web design is coming. But are front-end developers up to snuff?

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.

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.

Remember faux columns? I just did equal-height columns with flexbox yesterday. The old days sucked.

Now if we could just convince the kids to stop putting HTML and CSS inside the JavaScript…

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.

The codebase on big sites isn’t impenetrable because developers slavishly followed arbitrary best practices. The codebase is broken because developers don’t talk to each other and don’t make style guides or pattern libraries. And they don’t do those things because the people who hire them force them to work faster instead of better. It starts at the top.

Must read for front-end developers. No, seriously. Don’t, please don’t let the speed at which you write code influence the future maintainability of your code.

I tried to find a couple of quotes from this article, but I think I need this entire section to sum up where I am as a web developer.

Many web developers have “moved on” from a progressive-enhancement-focused practice that designs web content and web experiences in such a way as to ensure that they are available to all people, regardless of personal ability or the browser or device they use.

Indeed, with more and more new developers entering the profession each day, it’s safe to say that many have never even heard of progressive enhancement and accessible, standards-based design.

For many developers—newcomer and seasoned pro alike—web development is about chasing the edge. The exciting stuff is mainly being done on frameworks that not only use, but in many cases actually require JavaScript.

The trouble with this top-down approach is threefold:

Firstly, many new developers will build powerful portfolios by mastering tools whose functioning and implications they may not fully understand. Their work may be inaccessible to people and devices, and they may not know it—or know how to go under the hood and fix it. (It may also be slow and bloated, and they may not know how to fix that either.) The impressive portfolios of these builders of inaccessible sites will get them hired and promoted to positions of power, where they train other developers to use frameworks to build impressive but inaccessible sites.

Only developers who understand and value accessibility, and can write their own code, will bother learning the equally exciting, equally edgy, equally new standards (like CSS Grid Layout) that enable us to design lean, accessible, forward-compatible, future-friendly web experiences. Fewer and fewer will do so.

Secondly, since companies rely on their senior developers to tell them what kinds of digital experiences to create, as the web-standards-based approach fades from memory, and frameworks eat the universe, more and more organizations will be advised by framework- and Javascript-oriented developers.

Thirdly, and as a result of the first and second points, more and more web experiences every day are being created that are simply not accessible to people with disabilities (or with the “wrong” phone or browser or device), and this will increase as standards-focused professionals retire or are phased out of the work force, superseded by frameworkistas.

Zeldman

I’ve personally been building websites since 2001. The web standards movement was just beginning. In 2004, I was part of a state web development competition through my high school and they required our sites be built in XHTML and CSS. I felt the push back against ugly, inaccessible plugins— like Flash— and bad JavaScript practices from the start. Fast forward seven years and I led the charge for responsive web design at a Chicago-based agency, declaring that we shouldn’t upcharge our clients for something that is absolutely necessary. That was before we reached 50/50 desktop-to-mobile traffic.

Progressively enhanced, responsive, and accessible websites are in my blood. And that’s why it pains me so much to be rehashing conversations from the start of the standards movement as to why we shouldn’t require JavaScript, or assume that our user’s device supports fill-in-the-blank, or even assume our users can see like we do. And I’m having to rehash these conversations regularly with the Angular and React JavaScript frameworkistas.

We fought this fight for a reason and it matters today more than ever. Tomorrow is Blue Beanie Day. I’m old enough to remember why. I will be wearing one to stand for accessibility and progressive enhancement. I hope you do too.