I Am Finley

Web Standards

DirecTV Will Only Support Internet Explorer Come July

0 Comments

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

KISS My Classname

0 Comments

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.

Permalink

Blue Beanie Day and Why It Matters Now More Than Ever #a11y

0 Comments

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.

Permalink