There are a lot of grim numbers in here, but the one that really sticks with me is how many of the same, eminently-fixable issues continue to dominate year after year. We’re still talking about contrast, missing labels, empty buttons, and missing alt text. In other words, this is not a story about edge cases. It’s a story about fundamentals.

I appreciate how clearly Anil connects dots that too many people are still treating as separate problems. This isn’t just about AI summaries siphoning traffic from publishers or slop code drowning maintainers or bad actors ignoring long-standing norms like robots.txt. It’s all of those things at once. The through-line is extraction: taking value from open systems without giving anything back, then undermining the very ecosystems that made that extraction possible in the first place.

The good of the web only exists because of the openness of the web. They can’t just keep on taking and taking without expecting people to finally draw a line and saying “enough”.

If you care about the web as a public good, this post is worth your time.

I also appreciate Mark’s call for more ambition here. Too often, we talk about the web as if it’s destined to be an OS for web apps rather than a public-interest platform in its own right. That’s not inevitable. But getting somewhere better requires recognizing that refusal, delay, and strategic disinterest can be every bit as consequential as formal opposition.

A quarter of all webpages that existed at one point between 2013 and 2023 are no longer accessible, as of October 2023. In most cases, this is because an individual page was deleted or removed on an otherwise functional website.

Linkrot, especially in government and legal scenarios, is a tremendous problem, which is why we need services like the Internet Archive and Perma.cc. If you have the means, please consider supporting these, and similar, projects!

The post was largely about how the web enables us to be there for one another in times of crisis. Molly shared how she found solace—while reeling from the emergency hospitalization of her mother—in the support of her community through email, Twitter, and Facebook.

Molly recognized the power of the web—and the Open Web in particular—to connect people and communities for the betterment of all humans. Sure, she saw the downsides too and would grumble about them quite often, but she was a firm believer that the web was a net positive for the world.

As I reflected on her life last year when we lost her, this passage really struck me:

Mortality reminds us in very cold, frightening terms how fragile our life and times truly are. The Web, which is a naturally social and interactive communications platform, can help bring us all closer. The fighting, the drama, the debates - they all become irrelevant in these very mortal moments. Let us all reach for the greatness within ourselves and put it into our Web work every day, because even on those days we feel it’s overwhelming or doesn’t matter, it really truly does. One world, one Web, one love, my brothers and sisters.

I cannot think of a better way to remember Molly on this day.

Much love to you and your communities!

# Sharing, the Old-fashioned Way

When it comes to sharing, there are myriad ways to do it. If you’re at all familiar with my work, it should come as no surprise that I always start with a universally-useable and accessible baseline and then progressively enhance things from there. Thankfully, every social media site I commonly use (with the exception of the Fediverse) makes this pretty easy by providing a form that accepts inbound content via the query string.¹ You can try LinkedIn’s to see it in action.

Each service is a little different, but all function similarly. I support the following ones in this site:

Using this information, I created a partial template for use on any page in this site (though I mainly use it on blog posts right now). Each link includes useful text content (e.g., “Share on __”) and a local SVG of the service’s icon. Here’s a simplified overview of the markup I use:

<ulclass=“social-links social-links–share”><liclass=“social-links__item”><ahref=“{{ SHARE URL }}”class=“social-link”rel=“nofollow”><svg>{{ SERVICE ICON }}</svg><bclass=“social-link__text”>Share on {{ SERVICE NAME }}</b></a></li></ul>

You can check out the baseline experience on this very page by disabling JavaScript.

It’s worth noting that I have chosen not to enforce opening these links in a new tab. You can do that if you like, but on mobile devices I’d prefer the user just navigate to the share page directly. You may have a different preference, but if you decide to spawn a new tab, be sure your link text lets folks know that’s what will happen. I do include a rel="nofollow" on the link, however, to prevent search spiders from indexing the share forms.

If you test out these links, you’ll notice many of the target forms will pick up a ton of information from your page automatically. By and large, this info is grabbed from your page’s Open Graph data (stored in meta tags) or Linked Data (as JSON-LD). You can write that info to your page by hand or use a plugin to generate it for you automatically. There are a ton of options out there if you choose to go the later route (which I’d recommend).

# Enhancement Level 1: Popup Share

If you played around with any of the various share forms, you probably noticed that they are, by and large, designed as discrete interactions best-suited to a narrow window (e.g., mobile) or popup. To provide that experience, I’ve long-relied on a little bit of JavaScript to launch them in a new, appropriately-sized window:

functionpopup(e){var $link = e.target;while($link.nodeName.toLowerCase()!=“a”){$link = $link.parentNode;}e.preventDefault();var popup = window.open($link.href,“share”,“height=500,width=600,status=no,toolbar=no,popup”,);try{popup.focus();e.preventDefault();}catch(e){}}var screen_width =“visualViewport”in window? window.visualViewport.width: window.innerWidth,$links = document.querySelectorAll(“.social-links–share a”),count = $links.length;if(screen_width >600){while(count–){$links[count].addEventListener(“click”, popup,false);$links[count].querySelector(“.social-link__text”).innerHTML +=" (in a popup)“;}}

The first chunk defines a new function called popup() that will act as the event listener. It takes the event (e) as an argument and then finds the associated link (bubbling up through the DOM as necessary in that while loop). Once it finds the link, the function opens a new popup window (using window.open()). Then, to check if the popup was blocked, it attempts (within the try…catch) to focus it. If the focus succeeds, which means the popup wasn’t blocked, the script prevents the link from navigating the user to the href (which is the default behavior, hence e.preventDefault()).

The second block defines a couple of variables we’ll need. First, it captures the current screen_width using either the window’s visualViewport (if available) or its innerWidth (which is more old school). Next it grabs the social links ($links) and counts them for looping purposes (count).

The final block is a conditional that checks to see if the screen_width is wider than 600px (an arbitrary width that just feels right… your mileage may vary). If the screen is wider than that threshold, it loops through the links,² adds the click handler, and adds some text to the link label to let folks know it will open a popup.

And with that, the first layer of enhancement is complete: Users with JavaScript support who also happen to be using a wider browser window will get the popup share form if the popup is allowed. If the popup isn’t allowed, they’ll default to the baseline experience.

# Enhancement Level 2: OS Share

A few years back, browsers began participating in OS-level share activities. On one side, this allowed websites to share some data—URLs, text, files—to other apps on the device via navigator.share(). On the other side of the equation, Progressive Web Apps could advertise themselves—via the Manifest’s share_target member—as being able to receive content shared in this way.

Sharing a URL and text is really well supported. That said, it’s only been around a few years at this point and some browsers require an additional permission to use the API.³ For these reasons, it’s best to use the API as a progressive enhancement. Thankfully, it’s easy to test for support:

if(“share”in navigator){// all good!}

For my particular implementation, I’ve decided to swap out the individual links for a single button that, when clicked, will proffer the page’s details over to the OS’s share widget. Here’s the code I use to do that:

var $links = document.querySelector(”.social-links–share"),$parent = $links.parentNode,$button = document.createElement(“button”),title = document.querySelector(“h1.p-name,title”).innerText,$description = document.querySelector(‘meta[name=“og:description”],meta[name=“description”]’,),text = $description ? $description.getAttribute(“content”):“”,url = window.location.href;$button.innerHTML =“Share <svg>…</svg>”;$button.addEventListener(“click”,function(e){navigator.share({ title, text, url });});$parent.insertBefore($button, $links);$links.remove();

The first block sets up my variables:

• $links - A reference to the list (ul) of sharing links;
• $parent - the parent container of that list;
• $button - the button I’m going to swap in for the links;
• title - The page title (either from the page’s h1 or title element);
• $description - A reference to a meta description element;
• text - The text content of that description, if one is found; and
• url - The URL to be shared.

The second block sets up the button by inserting the text “Share” and an SVG share icon and setting an event listener on it that will pass the collected info to navigator.share().

The third and final block swaps out the link list for the button.

# Putting It All Together

The final step to putting this all together involves setting up the conditional that determines which enhancement is offered. To keep everything a bit cleaner, I’m also moving each of the enhancements into its own function:

!(function(window, document, navigator){functionprepForPopup(){// popup code}functionpopup(){// popup event handler}functionswapForShareAPI(){// share button code}if(“share”in navigator){swapForShareAPI();}else{prepForPopup();}})(this,this.document,this.navigator);

With this setup in place, I can provide the optimal experience in browsers that support the web share API and a pretty decent fallback experience to browsers that don’t. And if none of these enhancements can be applied, users can still share my content to the places I’ve identified… no cookies or third-party widgets required.

You can see (and play with) an isolated demo of this interface over on Codepen.

This is a tough post to write, to be honest. It’s difficult to articulate just how influential Molly has been on my own work, my philosophical approach to web design, and my career.

# Molly was warm and welcoming

Molly was there when I gave my first talk. 2003. COMDEX. I’d been invited out by the World Organization of Webmasters to give a talk on XHTML. The talk was solid. My delivery was atrocious. Molly was quick to come up after and congratulate me. I was floored.

I told her how excited I was to see her and Eric Meyer give a talk on CSS later in the day. She told me Eric had had to cancel his trip last minute and asked me if I would be interested in giving the talk with her. Just like that. I don’t know that she had any idea who I was (I’d only just published my first piece in A List Apart a few months earlier). But that was how Molly rolled. She saw my passion for web standards and somehow knew I’d be able to step up.

That one welcoming gesture was huge for me. And it was the start of a long collaboration and friendship. After that talk, we met up in Vegas again in 2004 and then went on a speaking tour the U.S. together in 2005, running web standards workshops where we taught people the fundamentals of HTML, CSS, JavaScript, and accessibility. I learned so much from her during that time and bore witness, over and over, to her immense capacity for welcoming people, bringing them together, breaking bread, building her tribe… she was the very embodiment of the word hospitable.

And gregarious. Her boisterous laugh was infectious and memorable. I can still hear it echoing in my ears.

# Molly was generous with her time

I don’t know that I’ve ever met someone who gave as much of herself as Molly did. She always, always put others first, sometimes to her own detriment.

When I first met Molly, she was leading the Web Standards Project (WaSP). She poured her heart and soul into that organization and the cause of web standards. I lost count of how many events she spoke at, often on her own dime. She invited educators into her home to teach them how to properly teach the next generation of web designers and developers… for free.

She always put her advocacy for the cause first… a double edged sword we’ve since named advocacy fatigue. It took a toll on her—mentally, physically, and spiritually—and she took the occasional break from it, but she never gave up on the fight for a more egalitarian web.

# Molly created opportunities for others

Another aspect of Molly’s giving nature was her insistence on opening doors for people, career-wise. I witnessed her pass along amazing opportunities that found their way into her inbox with an incredible amount of joy. Like doling out incredible gifts for a holiday.

One such gift she handed me was the opportunity to do some work with Adaptive Path. Through her introduction, I got the chance to work with an amazing team on several projects… all from my living room thousands of miles from their San Francisco offices. That was the kind of sway she pulled.

That work led to a part-time role (and health insurance) at Bolt|Peters, where I worked on Ethnio. That role gave me the freedom to quit my day job at an ad agency and begin building my own consulting business, which I launched a few months later and ran for over a decade.

All because of the doors Molly opened.

In a separate path, she invited me to join WaSP, where I worked on a lot of JavaScript-focused efforts. That led to me working with Microsoft on improvements to IE7 and IE8 and—years later—to me eventually joining Microsoft as a web standards advocate.

All because of the doors Molly opened.

And I was not alone. Wherever and whenever Molly saw an opportunity to help someone on their career journey, she would help them. Book contracts. Speaking engagements. Networking. Freelance work. If Molly saw any way she could help you, she did. No ego. No expectations. Selfless.

Her example is what inspired me to build my mentoring program. I don’t know that I can ever do as much good as she did for people, but she made me want to try.

# Molly wanted the web to win

If you know Molly’s name, this is probably why. She was a staunch—and loud—advocate for web standards and accessibility. A veteran of the browser wars (and subsequent skirmishes), she knew the landscape and she knew how imperative it was for standards to emerge and for browsers to implement them consistently.

I wasn’t there for the meeting, but she told me Bill Gates tried to tell her the web was “done” ’round about the IE6 days and she yelled at him. While she wasn’t one to shy away from the occasional embellishment, she was just as unlikely to shy away from a confrontation over the viability and future of the web… so it would not surprise me at all to hear that she’d yelled at him.

Molly was a lioness—nurturing and maternal to the web and its denizens and a fierce protector when they were threatened. She saw the potential of the web as a great equalizer and bristled when folks would try to wall it off or exclude people—especially disempowered people—from accessing it.

That passionate support for the open web never wavered, even when Molly became ill. In fact we’d been talking about whether it might make sense to re-launch WaSP this year, a decade after we’d shuttered it because we thought the work was done—it wasn’t.

# Molly will live on in our memories and our craft

Knowing Molly affected me. Deeply. Her kindness, thoughtfulness, generosity, and passion live on in everyone her life and work touched. Including me.

I don’t know what to make of a world without Molly, but I hate that we’re living in one. She truly was a force of nature and, as such, has left an indelible mark on this industry.

I’m so thankful to have known her. To have received her mentorship. To have called her a friend.

Goodnight Mols. I love you.

# Other folks’ memories of Molly

• John Allsopp
• Faruk Ateş
• Deborah Edwards-Oñoro
• Meryl Evans
• Jason Grigsby
• Stephen Hay
• Jay Hoffman
• Bruce Lawson
• Matt May
• Eric Meyer

More on front-end.social by following #MollyHolzschlag.

Know of others? Please share them.

When you set up a custom domain with GitHub pages, you have to point your domain at GitHub’s servers. There are a bunch of ways to do this, but if you use an A record, you need to be careful with your DNS settings. The site in question had a wildcard hostname (*) A record pointed at GitHub’s servers. At the time I’d set it up, that was the recommendation if you wanted all traffic to go to the same place.

Fast forward a few years and it’s become a known exploit of GitHub Pages: when wildcard hostnames are in play, any repo can add a CNAME file to their repository and claim ownership of a hostname belonging to that domain. GitHub even warns you not to do this anymore, but I hadn’t checked the docs in years. In my particular case, it was an archived domain that I don’t really use anymore, but I wouldn’t have been aware of the DNS hijack if the attacker hadn’t taken the step of claiming the domain on Google’s Webmaster Central.

Thankfully the fix was simple: Remove the wildcard A record and point the Apex domain at GitHub’s IP addresses.

If you use GitHub pages to host any of your own domains, I highly recommend auditing their DNS records to ensure this doesn’t happen to you. You can also use domain verification for GitHub Pages and organizations to further protect yourself.

In the 21st century, more and more information is “born digital” and will stay that way, prone to decay or disappearance as servers, software, Web technologies, and computer languages break down. The task of internet archivists has developed a significance far beyond what anyone could have imagined in 2001, when the Internet Archive first cranked up the Wayback Machine and began collecting Web pages…

#Max Cantor: Growing Up Online: Penpals and PHP

I still remember the first time a friend with a different provider gave me their email address. I was used to the cozy confines of AOL, where emailing another user required only their “screen name”–what we think of today as the part that goes before the @ sign. (Mine was Maxinator1.)

“What’s this funny stuff at the end, after your screen name?” I asked.

“That’s the domain. Mine’s compuserve dot com. Yours must be AOL dot com.”

“What? You can’t not be on AOL.”

“Why not?”

“How do you look at keywords?”

“I don’t!”

#Rina Henderson: The web. Why do I like it?

Believe it or not, the invention of the web was not to give me something to do when I grew up.

#Amberley Romo: The Road So Far, Pt II

I see power in the web for the very real capacity it has for good — communication and connection, access to communication, and on and on. And just like magic, it can be wielded in the interest of the light or the darkness (and those lines aren’t always the clearest). I want to do what I can to use it for good.

#river kanies: Why I chose to become a web startup consultant

I will never stop learning, and I will never stop putting myself out of my financial and intellectual comfort zone. I think that, ultimately, this attitude will lead me to be very successful, even if it means being dirt poor for the next few years :}

#Manuel Matuzovic: This is not a New Year’s resolution

Web design and web development are not (just) about writing the most flexible, reactive and dynamic app, impressing colleagues and clients, and earning awards. First and foremost it’s about people using our products. I believe that from time to time we all need to be reminded of that fact.

#Max Böck: Three Goals for 2017

I can still remember what it was like to build my first website. I had absolutely no clue how to do stuff, it was all trial and error. But going back and forth between blogs, tutorials and stack overflow, watching other people work, shamelessly copying bits and pieces—I improved.

The fact that I can just hit view source on any website and see how it’s made still amazes me.

Altough I have a degree in web development now, I can honestly say that I learnt most of what I do by soaking up information available on the open web.

This is only made possible by lots of talented people who not only produce great work, but dedicate their time and energy to show others how to do it, too. I don’t know any other profession with such an open exchange of knowledge.

People from around the world actually work together on open-source projects, just to build something that others can use. Top developers in the field will share their latest findings publicly in carefully crafted tutorials and code examples on Github.

Think about how amazing that is—an entire industry where you can learn every last secret of the trade for free—all you need is dedication and an internet connection.

#Kyle Jones: Looking Ahead—and to the Side

“Inter-Connectivity.” It’s a word I learned from an administrator at work. He challenged his team to reach out and reach through to other organizations. Organizations that are probably striving for the same goal that we are, but are too focused to look left or right to see others that are trying to do the same thing.

…

It’s why I love the web. The Internet seems to have a knack for inter-connectivity (hyperlinking, search results, purchase recommendations, @mentions, etc). It doesn’t come as naturally for humans at times. It takes risking assumptions and being intentional. Sometimes we need more of that spiderweb mentality and reach out, not just up or down. My administrator was telling us that, yes, we do a great work, but don’t be blinded to think we’re the only ones. Just imagine what good we could do together with more partners that don’t exactly look or function just like us.

#Ste Grainer: Seeking Mentorship

I started making websites in the mid-90s when I was still in high school. I was fascinated that I could put something up on the web and people anywhere in the world could see it if they knew where to look. That feeling still inspires me, even after 20 years.

#Ivan Zusko: Mentor: Be or not to be

Every time you are revising your knowledge and things you used to accept as ‘it is so simply because it is so’. And very often can happen that during a process of your professional evolution (in fact does not matter what kind of profession you belong to), you were missing some obvious details which could make your present life as the established professional much easier. The most trivial question can open your eyes on some hidden secrets which were escaping from your attention just because there were dozens and dozens of the different and the more interesting things that seemed more important at that time.

#Joanne Daudier: How I Got Started in Tech

What I love about being a developer is that I’m always learning something new and meeting other more senior devs that are so willing to lend a helping hand to newbies.

#Tyler Malone: State of a Career

I love what I do now because my experience in development has been diametrically opposed to that previous job. Solutions to problems are almost never a 1:1 ratio, collaboration is embraced, the pursuit of continual learning is highly encouraged, and the communities I’ve been a part of have been thoroughly supportive.

#Tabassum Mohamed Fakier: Career goals

I thought this was going to be difficult to answer, but it’s actually quite simple - albeit long-winded. I love the immense potential it represents; allowing people to help themselves, allowing people to help others directly, fostering connections in lieu of constant personal contact, delivering new experiences, helping people do good things for free - I could go on. There are just so, so, so many reasons why the web is important. The web extends beyond just websites for me: I used it as a crutch to overcome social anxieties and excessive shyness. I taught myself how to code using resources my parents would not afford on paper. I expressed myself. I entertained myself. I made friends when it was difficult for me to maintain friendships at school - and some of these individuals are close friends of mine seven years later. Heck, the web even introduced to me to my soulmate who is with me in Australia. I loved being on the web and I always wanted to be a creator on it.

There are so many lines being crossed for the sake of monetisation, for the sake of control, and I want this to change. Ultimately, I really want to give back in honour of the faceless strangers that made a lot of my life happen the way it did. The web should be better for everyone.

#Brian Bell: The Puddle Jumper

As a kid, I rarely played with a toy the same way twice. When I got older I spent my waking hours flipping, spinning, and grinding at the skatepark. In school, I pursued graphic design. A few months into my first nine-to-five, I discovered the web.

Every decision along the way was made with that question top-of-mind, “What else can I do with this?”

#Todd Libby: Mentoring

I want to keep learning until my children send me into a home, or even when I finally take that dirt nap I hear about.

I truly wish I could mentor all of these folks this year, but I’m only one guy with a day job and a family I’d like to see on occasion. This is going to be one heck of a tough choice. I’d like to take a moment to thank each and every one of these folks (and all of the other applicants) for sharing their stories and their goals with me, with us.

I urge you to read their posts and maybe write one of your own.

Toward the end of his second piece, Eran nailed my long-time contention in this quasi-fictional war between the Web and native:

It’s never really app vs native. It’s a complicated tradeoff between multiple factors and no matter how much you read about it, how many statistics you collect, how many experts you talk to, you will still have to figure it out on your own, based on the specific properties of the experience you are building. And keep evaluating your decisions.

As with everything, the right choice often depends on a variety of factors, many of which are likely to change.

In the end, I typically fall down on the side of the Web because I find its “messy” nature to be one of its great strengths. The Web is malleable and capable of being different things for different people. This flexibility allows it to travel further and empower more people than platform-specific apps ever will. I guess that’s why I am so stoked about progressive web apps too. When done well, they enable useful tools to go further and reach more people while providing many of the benefits of an installed application. If they’re successful, they really could be the best of both worlds.

Anyway, both posts are well worth a read:

• The Fucking Open Web
• The Open Web, Fuck Yeah! (the rebuttal)

Note: I no longer use “native” in this context, but it remains in quoted material.

When I was mid-way through writing the Second Edition of Adaptive Web Design, I realized that it was pretty likely some of the links I was referencing might disappear over the years. Little did I know, some of them would disappear while I was writing the book!

The Internet Archive’s Wayback Machine is pretty good, but it doesn’t archive everything, and I often find captured pages end up broken—especially if they rely heavily JavaScript, but often images go missing as well. I wanted to make sure that when you pick up the book a year from now or even 10 years from now, the links will still work.

I evaluated a few options for creating a permanent archive of each and every link in the book (there are over 200), but then it dawned on me that Perma.cc might be the perfect answer.

Perma.cc was created by the Harvard Library Innovation Lab in reaction to the paper I mentioned earlier. It is a distributed archive of URLs for scholarly and legal documents, supported not only by Harvard, but over 90 (and counting!) libraries, distributed all over the world. It’s also open source. Each URL is preserved as a live view, an archived view, and a screen capture taken when the link is added. Archived URLs are kept for a minumum of 2 years, but may be “vested” into the permanent archive by a member organization.

I had contributed some CSS to the project a while back, so I reached out to my contacts to see if they might be interested in vesting all of the links for the book. Turns out they were big fans of the First Edition and enthusiastically offered their support.

Converting all of the links took time (and a lot of double- and triple-checking), but the result is that every article, blog post, and web page that I referenced in the book will remain accessible to you in perpetuity. I think that’s pretty awesome. And, as an added bonus, since Perma.cc creates unique URLs that are relatively short, those of you who read it in print won’t have to re-type the often incredibly-lengthy original URLs.

I can’t thank Matt Phillips, Adam Ziegler, Jack Cushman, and everyone else at the Harvard Library Innovation Lab enough for creating Perma.ccand for offering their service to my readers. You all are amazing!

# New Features vs. Interoperability

One of the arguments PPK makes is against browsers competing on features. It really rang true to me:

I call for a moratorium on new browser features of about a year. Let’s postpone all completely new features that as of right now don’t yet work in any browser.

Browsers are encouraged to add features that are already supported by other browsers, and to write bug fixes. In fact, finding time for these unglorious but necessary jobs would be an important advantage of the moratorium. As an added bonus it would decrease the amount of tools web developers need.

Back in January, I wrote about how I was excited by Microsoft’s announcement of “Project Spartan” (now “Microsoft Edge”) and it’s focus on interoperability. Interoperability’s a long word, so I’m gonna go with “interop” from here on out.

I was not on the Microsoft payroll at the time, but I was still stoked to see their focus on interop in the new rendering engine. They’d even gone, in my humble opinion, above and beyond in this regard—aliasing Webkit’s experimental, legacy CSS syntaxes to their modern, standards-based implementations. This ensured poorly coded sites worked well in their browser and didn’t penalize users for a designer’s mistake. Talk about being a good web citizen!

Of course, Microsoft Edge wasn’t the first browser to do this. IE 7 Mobile implemented -webkit-text-size-adjust back in 2010. Opera and Mozilla also felt the pressure and eventually implemented -webkit- vendors prefixes in versions of their browsers. It’s a weird world when one browser vendor is forced to implement another’s proprietary syntax just to make the web work, but it’s the sad state of things in our full StackOverflow development world.

With the move away from vendor prefixes in CSS to “feature flags”, you’d think this sort of thing would be behind us, but it’s not. Karl Dubost, of Mozilla, recently bemoaned the implications of Apple’s latest vendor prefix silliness on his blog. In that post, he made a keen observation:

We have reached the point where browser vendors have to start implementing or aliasing these WebKit prefixes just to allow their users to browse the Web, see Mozilla in Gecko and Microsoft in Edge. The same thing is happening over again. In the past, browser vendors had to implement the quirks of IE to be compatible with the Web. As much as I hate it, we will have to specify the current -webkit- prefixes to implement them uniformly.

I completely understand PPK’s desire for browsers to apply the brakes a bit and focus on interop. With new features being added to “the web”—but in reality only browser X, Y, or Z—on the regular, without guaranteed interop, it feels like we’re stirring up the browser wars again. All the new shiny is exciting, but I lived through the browser wars the first time and they sucked for everyone involved. Web standards helped us get everyone on the same page and brokered what we’d hoped was going to be a lasting peace.

Now I’m not sure I agree with applying the brakes for a specific amount of time, but I do see great value in prioritizing interop over new features. And when browsers do implement new features, they should definitely put them behind feature flags (or some similar opt-in) to ensure we—the web development community—don’t start relying on some fancy new feature before it’s been vetted. Feature flags are awesome because they allow me, a designer, to experiment with a new technology in my own browser without affecting things for everyone else on the open web.

We used to think vendor prefixes were enough of a deterrent to using a particular experimental CSS property or JavaScript method. Sadly that’s turned out to not be the case. I would bet good money on the sad reality that 80% of the working web designers out there don’t understand that -*- means “experimental” or even “proprietary”. We—the web design authors, speakers, educators, and other influencers—did a shitty job landing that message with the industry as a whole. But even if we’d hounded people about it, it probably wouldn’t have mattered: Vendor-prefixed properties work. And now they work even in browsers they were never meant to.

So, here’s what I’d love to see browser vendors do:

1. Prioritize interop over new features. Don’t halt development on new features, just put them on the back burner so the rising tide can, as they say, lift all the ships. Web developers and end users all benefit when there’s feature parity and stability among browsers.
2. Put a ban on vendor-prefixes. They are not generally understood to be experimental. If you feel you must use a vendor prefix, ensure it’s only enabled by a corresponding feature flag.
3. Use feature flags (or some similar opt-in) to enable developers to test experimental features in their own browsers, but also to ensure they aren’t available on the “open web” before they’re ready.

# The Web vs. Platform-Specific Development

PPK has harped on this a few times. There is currently a palpable tension between platform-specific development and the web. It’s driving most of the new features in the web “platform”¹ and it’s giving many of us old-timers a touch of angina.

The reason is simple: The web was created as a massively interconnected document repository. A wealth of knowledge dependent on the hyperlink and the URL. The web was (and indeed still is) stateless by default, meaning it has no idea who you are or what you’ve done from request to request. This is very egalitarian: everyone has access and anyone can contribute.

As more businesses moved online, the web became necessarily transactional. Suddenly websites needed to know information about your “state” so they could sell you things and track your movements around their site and the rest of the web. With the advent of cookies and the Common Gateway Interface (CGI), a web server could adjust the content it sent in response to a request, based on what it knew about you and what you were doing.

Taking this simple capacity a step further, it became possible to write actual software on the web. Content management systems were probably the first big chunk of software to move online, but more soon followed. JavaScript came along and allowed us to add a bit of logic to the client side, reducing our reliance on round-trips to the server. Then we got Ajax and the whole JavaScript world exploded. We now have web-based photo editors, integrated development environments (IDEs), games, and more, all reliant on JavaScript’s ability to interact with the browser and manipulate what the user sees in real-time.

There were earlier machinations certainly, but the last ten years have seen the biggest push to bring more traditional software-like interactions to the web. Dozens of organizations, big and small, are trying to make their mark creating the framework for building these “next-generation” web-based app experiences. Honestly, I don’t have a problem with that. I don’t really have an interest in client-side frameworks, but I don’t have a problem with them either… provided developers who wish to bring their programming talents to the web take a little time to learn about the medium.

If you don’t take the time to understand how the web works, you’ll spend half your time cursing it and the other half trying to work around the things that frustrate you (which you will probably write off as “poorly designed” or “ill-conceived”). If you don’t understand how the web works, you’ll build fragile experiences that collapse like a house of cards when any one of your many dependencies—the network, JavaScript, some particular element or browser API—isn’t available. If you don’t understand how the web works, what you build will simply be on the web, not of it.

I don’t particularly care much about bringing “native like” experiences to the web. It’s not that I don’t write software (I do), I just don’t really care if something I make for the web feels like a piece of installed software. I’ll do everything in my power to ensure my users have a great experience, but I know that each person’s experience will be a little bit different and I no longer feel the need to enforce my will on their experience. I’d rather create many ways for someone to interact with the things I build and hope one or more of those work well for whoever happens by and whatever device they happen to be using.

Platform-specific software and the web have always co-existed. We had installed software on computers long before the web even existed and we will continue to have installed software for as long as there are computers. Some software will move to the web if it makes sense for it to do so. Other software will remain platform-specific. Either option could be right or wrong depending on what you are trying to do. For instance, I would never personally write a photo editor in the browser because image processing requires a lot of memory and CPU cycles. Putting it in a browser moves it one more level away from the hardware. Abstraction eases development, but it invariably increases overhead and reduces performance.

Traditional software and the web can and should co-exist. They also can and should continue to inform one another. Ultimately, that will help us better serve the needs of our users, however they use our creations.

# Change vs. Stagnation

Underpinning this whole “platform-specific vs. web” thing is, I think, a feeling many of us old-timers have that our web—the web we grew up building—is slipping away from us. We cling to the idea of the web as an open platform² for people to share their thoughts, passions, and cat photos. We like the web as it was originally. We like the web as we made it.

The web is changing. In some ways it’s changing for the better, in some ways for the worse. It’s a far different beast today than when Tim Berners-Lee typed that first <HEADER> and you can certainly do a lot more in the browser now than you could when I first picked up HTML. But I don’t think halting progress on the web is desirable.

As Jake points out in his response, stagnation is not a good policy. Stagnation pretty much killed BlackBerry. It also led to a lot of developer frustration in the guise of IE 6.

Change is not inherently bad. It’s pace can be quite frustrating at times, though. PPK certainly seems to be feeling that way about its speed now just as Alex Russell lamented its plodding progress back in 2007. But when you take a step back, especially with a historical perspective, you see the changes are cyclical in many ways. The bandwidth issues we dealt with during the dial-up era are with us again in the form of mobile networks. The lessons we learned building a web for 640x480 screens are equally applicable in a world of wearables. And the text-based interactions we created in the very early days will serve as a template as we move boldly forward into the realm of voice-driven user experiences.

# Cutting Edge vs. Craft

In his post, PPK also complained that we’re simply getting too many new features on the web, which makes it hard to keep up. More than that, however, it makes it hard to truly come to a deeper understanding of how these different pieces work. To really hone our craft. In other words, it’s becoming harder to be an expert generalist.

Jake and Bruce completely get this, as do I. Lyza Danger Gardener has even given an amazing talk on the topic. The sheer volume of new drafts, specs, and concepts (not to mention tooling options) is overwhelming. I’m sure I don’t know half of the features that are in the HTML5 spec, let alone the umpteen CSS3 modules. I probably never will. And I’m ok with that. I’ll pick and choose the bits I’m interested in playing around with and find ways to integrate them into my practice a little at a time. That’s how we learn. That’s how we’ve always learned.

To assuage PPK’s fears, however, I would argue that there are a lot more of us working on the web now than there were in the more leisurely paced days he remembers so fondly. And we’re sharing what we learn. Whether driven by altruistic desire to spread knowledge or an interest in rockstar-like fame in the industry (or even a smidge of both), it doesn’t really matter how it happens—the fact is that it does. We learn and we share. And the tools we have today make it even easier to do so. Not only do we have the usual magazine and blogging outlets, but we also have CodePen and JS Bin and Github and more.

We each have the capacity to research the hell out of one specific area of web design and be the conduit for that knowledge into the web design hive mind. Look at Sara Soueidan with SVG or Rachel Nabors with CSS Animation or Zoe Mickley Gillenwater with flexbox. Individually, we will never be able to learn it all, but collectively we can. Together, we can tackle any problem by accessing what we need to know when we need to know it.

# Developer Convenience vs. User Needs

Another angle in this very dense piece from PPK was around tooling and polyfills:

We get ever more features that become ever more complex and need ever more polyfills and other tools to function—tools that are part of the problem, and not of the solution.

The whole “polyfill it and move on” movement has him a little annoyed. I share his sentiment. I don’t think a JavaScript-based solution should be considered “good enough” for interop. JavaScript is not guaranteed. Moreover, JavaScript implementations are also never going to be as fast as a browser implementation. If browsers want to pick up a polyfill and implement it behind the scenes, that’s fine because it will run faster, but loading up our websites with potentially megabytes worth of polyfills in order to use new “standards” seems ludicrous.

As an industry, we are doing an awful lot of navel gazing. We are spending more time solving our own development problems (legitimate in some cases, fabricated in others) by throwing more and more code at the problem. As a consequence, our users are paying the price in slower sites, heavier web pages, poor performance, and bad experiences (or no experience). And, on top of that, we’re solving our problems not their problems.

# All is not lost

We are designers. Design is about solving problems for our users, not creating new ones for them. Whether we are writing code, sketching interfaces, authoring copy, curating content, or building servers, we should make each and every decision based on what will benefit our users. If it means we can’t use some shiny new technology, so be it. We can still play with the new stuff in our own browser, on our personal sites, and on CodePen. We can learn about them in our own experimentation and share that knowledge with the rest of our industry. We can improve our craft. The web can get better.

Note: I no longer use “native” in this context, but it remains in quoted material.

To me, she’s always been a bit gimmicky. When she debuted on the iPhone 4S, I thought the voice recognition stuff was neat, but I didn’t see her as being anything close to the “digital assistant” Apple promised us. The idea was good, but the implementation was about as inspiring as my then 5-year-old Garmin. Oh, but she couldn’t give you turn by turn directions.

Sure, Siri’s gotten better, but not much.

Now, after reading Dan Kaplan’s excellent TechCrunch post lamenting the Siri that could have been, I realize how much better she could—nay should—be. You see, prior to being bought by Apple, Siri Assistant was pretty damn useful. She was a true digital assistant, capable of setting up a whole evening of fun for you by purchasing movie tickets, getting you dinner reservations, and even hailing you a cab. Pre buy-out, her creators even had plans to supercharge Siri by giving her predictive awareness (think Google Now). Dan offered a few examples of how this might work:

• “Hey Dan, your flight to NYC has just been canceled! Would you like me to book the next one?”
• “Hey Dan, you weren’t at home when your package got delivered. Would you like me to redirect it to your office?”
• “Hey Dan, you’ve got a coffee meeting downtown in 25 minutes. How about I summon a Lyft?”

Given Siri’s previous capabilities and the plans her creators had, how did she become so lame?

Personally, I think the reason is simple: Apple doesn’t get the web. Sure there are a lot of incredibly smart and talented people who work at Apple who clearly do understand what the web is and how it works, but I think as a company Apple doesn’t. Or worse it does, but they can’t control it or monetize it, so they’re not interested.

It’s a feeling I’ve had for quite some time, but reading this piece (especially in light of Jeremy Keith’s fantastic post about the movement of many web companies toward creating more walled gardens) really convinced me. I mean take a look at Maps.

Prior to iOS 6, Google Maps was the de-facto mapping and directions app. It offered your standard driving and walking directions, but it also offered public transit directions based on public data (much of which Google has coalesced into Google Maps Transit). Now, with Apple’s homegrown Maps, if you want to get transit directions, you need to download a separate app from the App Store. Travel a lot? Try 8 differnet apps. Or 10.

Instead of using existing APIs to make transit directions native to Maps, they opted to fragment the experience.*

Sure, you might argue that the Maps team may have had to cut the transit feature due to time or budget constraints, but they found the time to make the maps three-dimensional. Just sayin’.

Clearly Apple could have used any of the publicly available transit APIs to accomplish this task, but they didn’t. The same goes for Siri. There are a ton of freely-available resources out there to collect information and then do something useful with it—to truly allow Siri to become the digital assistant of our dreams—but Apple doesn’t seem to have any interest. And I think their software is suffering for it.

* I’m all for de-coupling functionality in order to scale application logic, but de-coupling (a.k.a. fragmenting) the user experience is downright baffling. Especially for a company that prides themselves on both design and user experience.