In this project, we built an entirely new markup-first architecture that minimizes the size of our bundles of code, and the amount of JavaScript code that runs during the initialization path of the UI. This new internal UI architecture is more modular, and we now rely on a repository of web components that are tuned for performance on modern web engines.  We also came up with a set of web platform patterns that allow us to ship new browser features that stay within our markup-first architecture and that use optimal web platform capabilities.

• Added support for the shortcuts manifest member on macOS. Shortcuts are available in the File menu and the Dock context menu. Users can set up custom keyboard shortcuts for them in System Settings > Keyboard > Keyboard Shortcuts > App Shortcuts. (106137954)
• Added support for the categories manifest member on macOS. When creating a Launchpad folder containing web apps, the folder is automatically named accordingly. (116480550)

🎉

• Scroll to Text Fragment
• Service Workers and Shared Workers can access the Permissions API.
• Notification API in dedicated workers.
• Reporting API.
• Screen Orientation API.
• Screen Wake Lock API.
• unprefixed Fullscreen API
• Push in web apps saved to the home screen on iOS
• “id” member in Web App Manifest
• Badging API.
• third-party browsers can Add to Home Screen

https://www.youtube.com/watch?v=9tFYYOifHmI

# Background

In their research, the Otto JS team found that Chrome and Edge each use their own web services to drive their spellchecking services. In Chrome’s case it seems to only be with their “advanced spellcheck” feature turned on. I was able to validate this behavior using Charles on macOS Monterey using the latest Chrome Stable and the latest Edge Canary. I did not see the same exfiltration happen with Safari or Firefox. I created a CodePen form with several fields to test different permutations of form field attributes and behaviors. What I am sharing, below, is a result of that testing.

# What gets sent?

In both Chrome and Edge, the information sent to their services is the text value itself, disconnected from any specific field name. Chrome also sends the user’s language, and country. Edge, which uses the Microsoft Editor service under the hood, also sends a bunch of licensing details and the user’s language.

# Password fields are safe

<inputtype=“password”id=“password”name=“password”/>

Browsers do a lot to protect the contents of password fields already, so I wasn’t surprised to see that the contents of password fields are not passed to a spellcheck service.

If you are not using a true password field, however, the contents of that field are not protected in the same way. If you build a custom password control, you’re on the hook to replicate the entirety of the browser’s feature set when it comes to protecting user data. Unless you’re a glutton for punishment, you should probably just use the built-in password field instead.

# Fields marked readonly and disabled are not exposed

As you’d hope, neither read-only fields nor disabled fields are exposed ot the service. This even holds true when you change the values of these fields programmatically or via DevTools.

I should note, however, that readonly fields are send to the server when the form is submitted and their contents are editable via JavaScript and DevTools, so you should always assume readonly fields are informational for the user only and never trust their contents on the server side. Fields that are marked disabled, in contrast, are never sent to the server.

# You can protect interactive fields with the spellcheck attribute

<inputid=“no-spellcheck”name=“no-spellcheck”spellcheck=“false”/>

The spellcheck attribute can be applied to any element and setting it to “false” instructs browsers to turn off spellchecking services for its contents. The post from Otto JS showed this being used globally on the body element, but that is overkill. It would be better to use the attribute on specific fields you want to protect, as shown above.

# Don‘t forget about password controls that support show/hide

Edge has a neat feature in its password field implementation where it enables a user to toggle the visibility of the password within the control itself. When users show their password using that built-in functionality, no content is shared with the spellchecker. Not all browsers have this feature, however, which has led to JavaScript-based implementations that simply swap the “password” type value for “text” to show the contents and then swap it back again to hide the contents. Here’s a quick & dirty example of what the toggle button’s event handler might look like:

functiontogglePassword(e){var $btn = e.target,$field = $btn.parentNode.querySelector(“input”),state = $field.type;if($btn && $field){if(state ==“password”){$field.type =“text”;$btn.innerText =“Hide”;}else{$field.type =“password”;$btn.innerText =“Show”;}e.preventDefault();e.stopPropagation();}}

The problem with this approach, when it comes to the spellchecker, is that the text field is considered fair game for checking. Its contents aren’t sent right away, but if the field receives focus or its value is changed in any way while in the “text” state, its contents are sent to the spellcheck service.

Protecting the field’s contents are fairly easy, however: turn off the spellchecker for that field, even in its “password” state.

<inputtype=“password”id=“password-show-nospellcheck”name=“password-show-nospellcheck”spellcheck=“false”/>

With spellcheck="false" in place, you can turn the field into a text field safely, without the contents being exposed to the spellcheck service.

HTML is a pretty powerful language and, when wielded properly, can be an excellent tool for protecting user data, provided we use it properly. And know that you know how to protect your users’ sensitive data, minimize this tab and start filing those pull requests…

Nice one Safari team! https://t.co/YTO6rZR3dd

—Malte Ubl (@cramforce)

This is great to see! I think link[rel="canonical"] is not used often enough. I’d love to see all sharing protocols adopt this approach for things like cross-posts, m-dot sites, and more.

• Since launching Edge 8 months ago, the team has pushed 12 update releases, 128 new features, and 6,527 bug fixes!
• The team has launched a new, highly transparent bug tracker for Edge: issues.microsoftedge.com.
• The Edge team has done a ton of research into what specs are being used and how they are being used on the open Web. They are starting to share this information on data.microsoftedge.com. It currently consists of 2 parts: 1) usage data from real sites that looks at not only CSS properties in use, but values too; and 2) a catalog of available APIs and a detailed analysis of browser support, down to specific configuration and property values.
• Hot on the tails of RemoteIE opening up for Linux users, RemoteEdge is coming soon! Jacob Rossi showed a screenshot of an Edge instance running on Azure, within Chrome. So cool!
• Text-to-speech directly from within JavaScript!
• The Fetch API!
• Beacons as an alternative to blocking JavaScript requests for telemetry data: navigator.sendBeacon( uri, data ).
• Web notifications!
• WOFF 2 font support for better compression and faster downloads/decompression!
• The team is currently prototyping and investigating Service Workers, Push Notifications, Shadow DOM, Custom Elements, Web Payments, Web Assembly, and ES Modules.
• Cortana in Edge has gotten some major upgrades, such as being able to “Ask Cortana” about an image to get more information (like a recipe for the cookies you saw on Pinterest that did’t include a link).
• Microsoft open-sourced the CSS crawler powering their data portal so other browser vendors can run it too.
• FIDO-based login (like Windows Hello) is coming to the Web!
• Microsoft’s Narrator screen reader now supports a “Developer Mode” that blanks out the current app (such as your browser window) in order to enable you to more easily debug accessibility issues.
• The F12 tools in Edge now enable you to view the previously mysterious Accessibility Tree in addition to allowing you to drill more deeply into the various properties of an element that relate to its accessibility.

I didn’t take a ton of notes in the second half of the day as I was prepping for my own session on accessibility, but other highlights included building & debugging extensions for Edge (tldr; you can easily port Chrome extensions) and cool things you can do using Continuum.

Overall, the event was incredibly informative and has me really excited about the work the Edge team is doing and where the browser is going. The new stuff that‘s ready for prime time will be out for the public in the Anniversary Update of Windows 10 this Summer, but some of it is has already landed in Windows Insider builds.

# 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.

Join the intervention and stop supporting IE8. It’s time for an upgrade.

The reality is that some users don’t have control over the browsers installed on their computers and IE8 may be the best they can muster. Most of us have had the luxury of moving on, but they haven’t. Does that mean we should banish those users from our sites by treating IE8 like that ex who just won’t take a hint? I don’t think so.

Instead, we should approach this problem rationally. Be the bigger person. Call it support vs. optimization, call it cutting the mustard, call it what you will, but by understanding how browsers work, we can reduce our own development headaches and serve more users in the process. Yes, even when they use aging browsers like IE8 or IE7 or (gasp) IE6.

When it comes to HTML and CSS, browsers ignore what they don’t understand. It’s why you can use the section element and the content will still be exposed in Lynx. It’s also why you can use RGBa without IE6 collapsing. Fault tolerance is a really powerful tool and is the foundation of progressive enhancement in HTML and CSS. (In JavaScript things are a little more complicated… we have to use feature detection.)

A simple way to rid yourself of IE8 related headaches is to embrace the idea that web pages don’t need to look (or behave) the same in every browser and look for ways to achieve this while still providing access to your content and tools for less-capable browsers and devices. For example:

<linkrel=“stylesheet”href=“simple.css”/><linkrel=“stylesheet”href=“complex.css”media=“only screen”/>

This simple stylesheet setup will deliver only the simple.css file to browsers that are incapable of understanding media queries. Browsers that do understand them will get both stylesheets. Media queries support is an easy line in the sand we can draw because lack of media query support is in fact the first media query.

Once you’ve done that, it’s as simple as putting all of your advanced styles in the complex.css file. No drama.

On the JavaScript end, you can draw a line in the sand too. Let’s say you don’t want to spend your time debugging JavaScript in IE8. You can just skip it using Conditional Comments:

<!–[ifgteIE9]><!–><scriptsrc=“not-for-ie8.js”></script><!–<![endif]–>

Using an approach like this avoids delivering the contained JavaScript files to IE8 at all, but all other browsers will see them.

If that’s too drastic, use feature detection in your JavaScript files to determine if it is safe to rely on a particular method or capability. Program defensively.

Honestly, I’ve found that approaches like these lead to fewer grey hairs and a lower overall stress level. They make me a happier developer and let me concentrate on building for the future rather than worrying about the past.

But it’s not about breaking up with IE8, it’s about having a realistic and honest relationship with it.

In Lisa’s analogy, the protons of a digital project are Web standards and Key Performance Indicators (KPIs). She believes that without these key ingredients, projects will often career out of control. Her reasoning? We all need to know how we should be doing things in order to work together well (Web standards) and we need to know what our expectations are for the project to be successful (KPI).

This really resonated with me. Mainly, it resonated because I am a Web standards guy, but I also believe in the importance of standards across the board. I think projects need copywriting standards, design standards, performance standards, coding standards, and many other kinds of standards as well. Standards hold a project together. For real.

That’s why Web standards are so important.

Without standards, the Web was an unruly mass of spaghetti code. I started working on the Web in 1996. I know, I lived it.

We used to deliver separate browser-specific JavaScript and CSS files to different User Agents. Our HTML code had to be 3-4 times as hefty to support all of the various ways browsers had decided to implement the same features. It was horrible and made building anything remotely interesting a truly painful endeavor.

Then browser makers got together to codify HTML into a generally agreed-upon set of elements and attributes that would allow authors like me to write pages that would Just Work™. That work extended into CSS, and so on, and so forth. I can’t thank them enough for doing that.

Tuesday also saw the W3C officially make Pointer Events a recommendation. I’d always liked the idea of Pointer Events because it abstracts the traditional concept of a click into a generic interaction that could be triggered by a mouse, a finger, a pen, an eye movement, or any other interaction method we come up with in the future. Sure, I work for Microsoft now—they proposed this idea—but that isn’t the reason I like the concept. I like it because it doesn’t tie us down to a single way of interacting with Web content that necessitates the creation of new specs when new interaction methods are invented. It’s future friendly and embraces the “continuum of experience” I evangelize incessantly.

When Pointer Events were first proposed, there was a lot of support behind them. Obviously Microsoft was on board, but Mozilla was too. And Google was all about Pointer Events for a while and was already using them when they did an abrupt about-face and decided they were ripping them out of Blink in favor of overhauling Touch Events (which Apple supports and which Pointer Events were intended to supersede).

And so now we have a recommendation from the W3C that browsers implement Pointer Events. Developers want them and it seems Apple doesn’t. And because Apple doesn’t want them, Google doesn’t want them now either. To quote Rick Byers (of Google) in a Pointer Events meeting in late 2014:

No argument that PE is more elegant. If we had a path to universal input that all supported, we would be great with that, but not all browsers will support PE. If we had Apple on board with PE, we’d still be on board too. The equation has shifted for us.

So, effectively, Apple is holding the Web back. Tim Kadlec wrote a great piece discussing the core issue at play here:

Let’s set any opinions about Pointer Events aside. Frankly, I need to do a lot more digging here before I have any sort of strong opinion in one direction or another. There is a bigger issue here. We have a recurring situation where all vendors (save for Apple) show interest in standard, but because Apple does not express that same interest, the standard gets waylaid.

This whole thing has caused quite a kerfuffle in the Web community. Obviously, some people are demonizing Apple (and, by proxy, Google) for holding us back. Others are quick to excuse Apple because of their history of pushing the Web forward (see CSS transitions, animations, etc.).¹ Personally, I don’t think anything is ever truly black and white. Every company does some good things and some bad things. To channel Lisa Welshman again, it’s like yin and yang: The light has a little bit of the dark in it, and the dark has a little bit of the light in it.

Generally, I’ve found that Apple tends to do what is best for Apple, without considering how it affects designers, developers, or the Open Web. On this issue however, I just haven’t figured out their angle yet.

Some of their past decisions have offered a clear view into their motivations. Take offline for instance. Apple supports the Application Cache API (as most modern browsers do), but there’s a catch: You can’t store audio files in the cache. That makes it nearly impossible to build a decent game in HTML because you won’t get sound effects if you aren’t connected to the Web. But for Apple it makes perfect sense: They sell games in the App Store.

Their motivations behind other decisions are more murky, however. For example, Safari implements the HTML5 Form Validation API, which means it knows if a field is valid or invalid. The catch? It won’t halt the submission of an invalid form. Every other modern browser acts as you’d expect.² I don’t get it. I used to think/hope they just had not figured out how they wanted to handle notifying the user of the error, but it’s been like this for about 5 years.

I’ll let Tim jump in again here:

Apple has a very, very strong influence over what standards get adopted and what standards do not. Partly it’s market share, partly it’s developer bias (see, for example, how other vendors eventually felt forced to start supporting the webkit prefix due to vendor prefix abuse).

Apple simply does not play well with other vendors when it comes to standardization. The same sort of things we once criticized Microsoft for doing long ago, we give Apple a pass on today. They’re very content to play in their own little sandbox all too often.

He’s channeling a bit of Remy Sharp there (circa 2012):

When are we, as a web development community, going to stop giving Apple a free fucking pass?

They’re consistently lacking in the open discussion in to improving the gateway to the web: the browser. Sure, they landed an impressive mobile browsing experience back when the iPhone launched and it’s a great device, but there’s some serious questioning about whether they’re purposely cock-blocking web development and purposely hindering our advancement as a web industry.

WebGL is in mobile Safari, yet only available if accessed via a WebView object, not the real Safari (which is a WebView anyway…). It was recently discovered that they moved all web data storage (Web Storage, Appcache, etc) in a temporary data store meaning that it can be wiped at any time without warning.

Even the mighty PPK who tells entire browser vendors “fuck you”, doesn’t call Apple out, allowing them to slither on.

Why is it we continue to allow Apple to get away with it? And can this ever change?

As Tim points out, Apple certainly isn’t the only company that plays games when it comes to standards:

The other vendors aren’t exactly perfect either. The Microsoft folks, no doubt reeling from all the negativity aimed at them over the years, have more than once been content to let everyone else duke it out over a standard, only getting involved late when a consensus has been reached. The Blink folks, despite being the best positioned to take a stand, have been happy to play the “Apple won’t do it so I guess we won’t either” card on multiple occasions.

But he’s also quick to highlight the disappointing reality about Apple with respect to the other browser vendors:

It’s easy to reach the Mozilla, Google and Microsoft folks to discuss their thoughts on these emerging standards. That’s a much harder thing to do with the Apple crew.

Apple is very much a black box and their processes are incredibly opaque. Now I’m no hater, I use their products daily.³, but I am also not an apologist. I think relationships are improved with honesty and openness. I honestly wish Apple’s processes—at least when it comes to the Web—were more open.⁴ Heck, they often don’t even show up to meetings at the W3C. If we knew what they were thinking or why they were doing things, we could at least understand where they were coming from rather than having to speculate about their motivations. Whether we agree or not is irrelevant.

Regardless, we are where we are and I can’t help but wonder one thing: If we stop giving Apple a free pass and continue marching forward without them, will they eventually be forced to scramble to catch up like Microsoft did when IE6 sat on the shelf for so long? I don’t know what the answer is, but I sincerely hope they come around and begin to treat the Web with the respect it deserves before that happens.

When browsers refuse to implement Web standards, we all lose. And we take one step closer to the swirling pit of chaos and spaghetti code we thought we’d put behind us.

You’ll never believe this one weird trick that takes the pain out of cross browser testing: Progressive enhancement.

—Orde Saunders 🔟 (@decadecity)

Let me back up a bit here. As many of you know, I’ve been working on the Web for a long time and, like many old codgers, lived through the first browser wars and remember not only the unveiling of Internet Explorer 6—which was pretty amazing for its time—but I also worked on the Web for the entire 5 years that browser sat on the shelf.¹

By the time Internet Explorer 7 came out in late 2006, there had been a number of advancements on the Web. And there was more competition for user and developer mindshare. Safari popped up shortly after IE6’s launch and was gaining traction on the Mac with its port of Konqueror’s layout engine, KHTML, which they renamed WebKit. Netscape was in it’s death throes, but Firefox arose from the ashes² and was capturing an ever-growing share of the market with its improved security, extensibility through browser plug-ins, and tabbed browsing. Not only that, but the Mozilla core of Firefox had also been spun into several other browsers that were similarly taking off: Camino, Flock, SeaMonkey, Galeon, and Epiphany. And then, of course, the Opera browser was still going strong on the desktop and growing rapidly in the mobile space.³

When IE7 finally made it out into the world, developers were at peak frustration when it came to dealing with standards-compatibility issues in IE. So it’s no surprise that the messaging focus for IE7 was, at least in terms of the Web designer/developer audience, focused on apologizing for the past and promising that they cared about (and were supporting) interoperable Web standards.

And this was an earnest sentiment, it wasn’t bullshit. I remember Chris Wilson—then Platform Architect of Internet Explorer Platform team—telling me he had personally printed out the entire CSS 2.1 spec and put it on the desk of each developer working on Trident, the browser’s rendering engine.

And IE7, for all of its faults, was an improvement over IE6. A few years later, IE8 was an improvement over that. And, a little later, IE9 gave us a completely reborn Internet Explorer, largely free of the layout and rendering quirks we had earned so much grey hair fighting. And so on. And so on. But all the while, the drumbeat from the IE team was this: Now with more standards support!

And it wasn’t just IE that was making this claim. Other browsers began to tout their support of one particular standard or another that the others didn’t in hopes of getting developers to pay more attention to them.

Some time before the launch of IE8, I remember having a conversation with Chris Wilson over drinks at a conference. We talked at length about the state of Web standards, browsers, and the like. During the course of our chat, he offered up his dream:

I’ll be happy when browsers stop competing on standards support and start competing on chrome.⁴

It stuck with me because what he was saying made a lot of sense: Standards-compliance should be a given; browsers should be competing on the extra stuff they offer.

Which brings me back to today’s announcement. Standards-compliance wasn’t mentioned⁵ by Joe Belfiore in his walkthrough of “Project Spartan”. Instead, Joe focused on the value adds in the browser: in-app note taking, a focused reading mode, cross-device synchronization, and Cortana integration.

This is a major milestone for IE in my opinion and it makes me wonder if we’ve finally reached the place that Chris dreamed about all those years ago. I certainly hope so.

But why this urge to re-style page elements that end-users are familiar with? … Or is it that we love native look and feel, except when we don’t?

Speaking as the guy who not only wrote JavaScript to help me create an accessible select element alternative, but who also made it the focus of a case study (image) in AdvancED DOM Scripting, I am fully aware of the desire to have it both ways. I have not often seen the desire for both in a single individual, but it does happen in one particular instance occasionally.

Based on my own experience, I see the following arguments in favor of changing the display of a native control quite often:

1. It doesn’t look good to me.
2. It is not “on brand”.
3. It clashes with our brand’s color scheme.
4. We want the web experience to feel like a native app.
5. It doesn’t behave how we think it should.

(n.b. Browsers have done a pretty good job reducing the amount of color and the overall visual strength used in native controls to help them better blend in with a wide variety of designs, so clashes as mentioned in #3 happen far less often than they did nearly a decade ago.)

As the weathered, battle tested (and, admittedly, somewhat jaded) front-end dev that I am, I typically push back with one or more of the following:

In Addressing Desired Design Changes

In terms of aesthetics (addressing arguments 1, 2, and 3), I understand where you’re coming from. Native controls are not the most appealing things, but they are familiar to your users. A select box they see on your site that looks like the one they see on Wikipedia or their banking site will be immediately recognizable. Sure, the looks and feel may differ from browser to browser, but most people use only a small number of browsers throughout the day—at work, at home, on their device—and if you want to ensure the design of a form control feels “right” in the browser they are using, sometimes it’s best to let go of that control.

In Addressing OS Parity

I can understand the desire to have a form control in a web page look and feel like the same (or a similar) control within the native operating system (argument 4), but I am not sure that’s a rabbit hole you want to go down. Here’s why: Achieving exact design and functional parity between a native control and a web control quite often requires extra markup, a bunch of CSS, and a bit of JavaScript. Anything is achievable with unlimited time and budget, so it’s completely doable, but it would be good to estimate the cost to see if you still think it is a worthwhile endeavor.

Assuming it is, we then have the question of which operating system to model the control after. Or maybe you want to offer a different take on the control based on the operating system your user is using. In that case, we may need to multiply the original estimate by the number of operating systems you want to support. But it’s worth noting that, in the Android world, different device manufacturers often “skin” the operating system to look different from other ones. Sometimes they even do it on a device-by-device basis. We’ll need to figure out which ones you want to include in your native control matrix and multiply the estimate accordingly.

Then there’s maintenance. We’ll need to test these native-like controls on each of their corresponding platforms and test the script that determines which experience gets delivered to which device to make sure we’re not accidentally sending the wrong experience. We’ll also need to test the delivery script on every other browser in our test matrix to ensure it is not causing issues there.

What should we do when a new operating system version is rolled out? iOS, for example, has made radical shifts in the design of their native controls in each major release. We’ll probably want to create unique versions of the control for each version of each OS we support and we’ll need to keep tabs on upgrades so we don’t end up confusing our users if they visit our site in iOS 7 and have a control that looks like it’s from iOS 6. We’ll need to add the number of OS versions into the multiplier as well.

Ok, and finally: How many controls did you want to apply this approach to again?

Or we could use the native form control and it will just work.

In Addressing Altered Behavior

I completely agree that not all native controls work exactly how I would like, but there are several risks in changing the expected behavior of a native control.

First of all, there’s the possibility we could actually end up making the interface more confusing or that the change in behavior might not be exactly what our user’s wanted (either based on what they are used to or our mental model not aligning with theirs). In order to rule out these issues, we should run a few rounds of usability tests. These could be quick café tests or more formal studies depending on the budget.

Assuming our tests go well, we will need to maintain this code and do all of the requisite browser testing. And potentially upgrade our code as new browsers and browser versions come out. Depending on the complexity of the code, this could become a large requirement, but if it is ultimately in the service of making the web a better, more usable interaction environment, it could be worth it.

For what it’s worth, if we go this route and are successful, we should consider getting involved in the spec-writing process at the W3C or WhatWG. We should contribute our recommended changes back to the community and share what we learned. If we make a compelling argument, perhaps our idea will become part of some future standard and we can taper off our browser testing when the change goes native.

As you can probably tell, I’m not a really big fan of changing existing controls as I feel it can amount to a wasted effort. That said, if there are design improvements to be made—“design” in the true sense: being about how usable something is, not just how aesthetically-pleasing it is to someone (e.g. improving contrast, making the control more intuitive, etc.)—I’m willing to accept the change as something we should do and then work to make sure that change has been vetted and, if successful, given away for inclusion in other projects. If it solves a major issue on the web, I want to give that change every opportunity to make it into the appropriate spec by talking to the appropriate folks about it both in-person, in blog posts, and on the appropriate mailing list. If the change solves a problem in a specific browser, I want to see it incorporated into said browser and will file a bug report and try to build momentum around it by engaging the community.

Anyway, that’s my general position on augmenting native controls. What are your thoughts on the topic?

But why this urge to re-style page elements that end-users are familiar with? … Or is it that we love native look and feel, except when we don’t?

Speaking as the guy who not only wrote JavaScript to help me create an accessible select element alternative, but who also made it the focus of a case study (PNG, 128kB) in AdvancED DOM Scripting, I am fully aware of the desire to have it both ways. I have not often seen the desire for both in a single individual, but it does happen in one particular instance occasionally.

Based on my own experience, I see the following arguments in favor of changing the display of a browser-delivered UI control quite often:

1. It doesn’t look good to me.
2. It is not “on brand”.
3. It clashes with our brand’s color scheme.
4. We want the web experience to feel like a platform-specific app.
5. It doesn’t behave how we think it should.

(n.b. Browsers have done a pretty good job reducing the amount of color and the overall visual strength used in their UI controls to help them better blend in with a wide variety of designs, so clashes as mentioned in #3 happen far less often than they did nearly a decade ago.)

As the weathered, battle tested (and, admittedly, somewhat jaded) front-end dev that I am, I typically push back with one or more of the following:

# In Addressing Desired Design Changes

In terms of aesthetics (addressing arguments 1, 2, and 3), I understand where you’re coming from. Browser-delivered UI controls are not the most appealing things, but they are familiar to your users. A select box they see on your site that looks like the one they see on Wikipedia or their banking site will be immediately recognizable. Sure, the looks and feel may differ from browser to browser, but most people use only a small number of browsers throughout the day—at work, at home, on their device—and if you want to ensure the design of a form control feels “right” in the browser they are using, sometimes it’s best to let go of that control.

# In Addressing OS Parity

I can understand the desire to have a form control in a web page look and feel like the same (or a similar) control within the operating system (argument 4), but I am not sure that’s a rabbit hole you want to go down. Here’s why: Achieving exact design and functional parity between a platform-specific control and a web control quite often requires extra markup, a bunch of CSS, and a bit of JavaScript. Anything is achievable with unlimited time and budget, so it’s completely doable, but it would be good to estimate the cost to see if you still think it is a worthwhile endeavor.

Assuming it is, we then have the question of which operating system to model the control after. Or maybe you want to offer a different take on the control based on the operating system your user is using. In that case, we may need to multiply the original estimate by the number of operating systems you want to support. But it’s worth noting that, in the Android world, different device manufacturers often “skin” the operating system to look different from other ones. Sometimes they even do it on a device-by-device basis. We’ll need to figure out which ones you want to include in your platform-like control matrix and multiply the estimate accordingly.

Then there’s maintenance. We’ll need to test these platform-like controls on each of their corresponding platforms and test the script that determines which experience gets delivered to which device to make sure we’re not accidentally sending the wrong experience. We’ll also need to test the delivery script on every other browser in our test matrix to ensure it is not causing issues there.

What should we do when a new operating system version is rolled out? iOS, for example, has made radical shifts in the design of their platform-specific controls in each major release. We’ll probably want to create unique versions of the control for each version of each OS we support and we’ll need to keep tabs on upgrades so we don’t end up confusing our users if they visit our site in iOS 7 and have a control that looks like it’s from iOS 6. We’ll need to add the number of OS versions into the multiplier as well.

Ok, and finally: How many controls did you want to apply this approach to again?

Or we could use the browser-delivered form control and it will just work.

# In Addressing Altered Behavior

I completely agree that not all browser-delivered UI controls work exactly how I would like, but there are several risks in changing the expected behavior.

First of all, there’s the possibility we could actually end up making the interface more confusing or that the change in behavior might not be exactly what our user’s wanted (either based on what they are used to or our mental model not aligning with theirs). In order to rule out these issues, we should run a few rounds of usability tests. These could be quick café tests or more formal studies depending on the budget.

Assuming our tests go well, we will need to maintain this code and do all of the requisite browser testing. And potentially upgrade our code as new browsers and browser versions come out. Depending on the complexity of the code, this could become a large requirement, but if it is ultimately in the service of making the web a better, more usable interaction environment, it could be worth it.

For what it’s worth, if we go this route and are successful, we should consider getting involved in the spec-writing process at the W3C or WhatWG. We should contribute our recommended changes back to the community and share what we learned. If we make a compelling argument, perhaps our idea will become part of some future standard and we can taper off our browser testing when the change lands in the platform.

As you can probably tell, I’m not a really big fan of changing existing controls as I feel it can amount to a wasted effort. That said, if there are design improvements to be made—“design” in the true sense: being about how usable something is, not just how aesthetically-pleasing it is to someone (e.g. improving contrast, making the control more intuitive, etc.)—I’m willing to accept the change as something we should do and then work to make sure that change has been vetted and, if successful, given away for inclusion in other projects. If it solves a major issue on the web, I want to give that change every opportunity to make it into the appropriate spec by talking to the appropriate folks about it both in-person, in blog posts, and on the appropriate mailing list. If the change solves a problem in a specific browser, I want to see it incorporated into said browser and will file a bug report and try to build momentum around it by engaging the community.

Anyway, that’s my general position on augmenting browser-delivered UI controls. What are your thoughts on the topic?

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

“It makes more sense to have our experts working with the open source communities to further improve WebKit and Chromium, rather than developing our own rendering engine further. Opera will contribute to the WebKit and Chromium projects, and we have already submitted our first set of patches: to improve multi-column layout.”

I am hopeful that Opera’s eagerness to help improve Webkit does not peter out over time. After all, it’s tempting to just take the Webkit core and just drop it into your own browser’s chrome, allowing your team to focus on the browser itself rather than the rendering engine. That is, after all, the dream from many authors’ and implementors’ standpoints: browsers compete on features, not standards support.

So, on the surface, this sounds great: Opera adopts Webkit. Chrome and Safari are already Webkit. Blackberry, Palm, Android, iOS, Symbian, and many more all use Webkit. That means fewer headaches for me, right? Well, not really. As PPK informed us years ago there is no one Webkit (on mobile or desktop).

Webkit is what you what you want it to be

You see, as an open source project, Webkit is constantly evolving. That’s a good thing as it means newly-proposed features roll quickly into it. As open source software, however, it is also modifiable. That means not only will you have differences between nightly builds of Webkit as new features are added and bugs are fixed, but each browser built on it can choose to jettison certain features or add ones of their own.

Apple, creators of the Webkit engine (who based their own work on the KHTML rendering engine) for example, have implemented the HTML5 form validation API for JavaScript, but have yet to expose it in the UI. Chrome, on the other hand, implements both. Similarly, Apple also disabled the “file” input type on iOS versions prior to 6. From an implementor standpoint, it’s nice because they can pick and choose their build to be tailored to highlight the strengths (or mask the weaknesses) of their browser or OS, but there is a dark side too: A company can choose to opt-out of specific standards in order to undermine the web as a platform.

One of the most egregious (in my opinion at least) examples of this is how Apple has treated multimedia on iOS. First, they made it impossible to cache audio & video files for offline use. You could make an argument that this keeps sites from bogging down a device with lots of files, but if you put a user in control of what’s cached & how much room it can take, that’s completely avoidable. But, when you consider that you can’t control the playback of media files solely via JavaScript (without requiring user interaction such as a tap), it becomes clear that Apple doesn’t really want competition from web-based apps. Want to make a web-based game that works offline on iOS and includes sound? Sorry!

Now Apple isn’t the only company to have tweaked their Webkit instances. HTC is pretty infamous for monkeying around with both Android in general and Webkit specifically too, and they are by no means alone in that. Along the way many of implementors have augmented Webkit for one reason or another and a few introduced serious bugs in the process. Here’s are just a few implementation issues I’ve come across, but there are hundreds more:

• in early versions of webOS, use of optimizeLegibility caused text to disappear entirely;
• in Chrome, when using a font with ligatures, words containing the letter “q” disappeared entirely (it wasn’t a font issue either, the font was from Google’s service and worked fine in other Wekbit browsers including Chromium for Linux); and
• the native Android browser has an incredibly difficult time dealing with overlays, light boxes, and the like when any sort of interactive element (e.g. a link or form control) sits under that layer, often leading to inadvertent taps.

But the implementors are not the only ones introducing bugs.

Webkit itself suffers from numerous long-standing, serious bugs

Overall, Webkit is a pretty awesome rendering engine. It’s fast, lightweight, and does a damn good job laying out pages. But it’s not a panacea. It has its issues.

A brief sojourn through the Webkit bug tracker (and Chromium’s if you’re up for it) reveals a litany of well-documented, long-standing, serious usability, accessibility, and standards-implementation bugs that have not been touched. Here are a couple I’ve been tracking:

• Webkit Issue 5566 (October 2005): Alt text is not always displayed when the image is missing. That’s a big deal.
• Webkit Issue 15816 (November 2007): You cannot select multiple non adjacent items in a multiple select control with the keyboard only.
• Chromium Issue 37721 (March 2010): When you trigger an anchor link (e.g. a “skip to”), focus never leaves the link and travels to the target, which is a big no-no according to the WCAG (Web Content Accessibility Guidelines).

Now, as the number of companies using (and forking) the Webkit core has increased, the capacity to address these bugs has increased as well. Still, it seems bug fixes are always lagging behind new feature implementations. And then there’s always the folks who want to use a piece of open source software as-is, with little concern for making it better. Hopefully the addition of the incredibly smart developers from Opera to the mix (many of whom are accessibility experts) will bode well for issues like these to be remedied.

What does this mean for standards?

Webkit is pretty solid in its standards support. It has also been the testing ground for countless HTML5 and CSS3 proposals, many of which have gained traction. With Opera ditching Presto for Webkit, however, I’m a little concerned this may not bode well for the ratification of future standards.

You see, the web standards process requires that Proposed Recommendation at the W3C should have at least 2 interoperable implementations before it can become a Recommendation. With the Opera moving to Webkit, we are left with one less potential implementor as I don’t think you can consider the same Webkit implementation in Safari, Chrome, and Opera to be anything more than the one aggregate implementation. If you considered it as 3 independent implementations, it would essentially grant Webkit license to deem pretty much anything they come up with a standard, making a mockery of the whole process. And so we are more reliant than ever on the Internet Explorer, Mozilla, and Webkit teams being on the same page (and timeline) when it comes to implementations or the whole process will stall.

From what I gather—granted, it’s been a while since I sat through a W3C Working Group meeting, so my impression could be misguided—things at the W3C seem to be moving along much more smoothly than they have in the past, so perhaps my concern for the standards development process is unwarranted. I hope so, but only time will tell.

Further reading:

• The Pros and Cons of a Webkit Monoculture
• Opera’s WebKit Move Isolates Mozilla
• Think One Fewer Browser Means Less Work? Think Again
• Apple And Google Still Lead WebKit Development But More Smaller Companies Contributing
• WebKit is the jQuery of Browser Engines
• The WebKit Culture Web Rendering Engine Diversity
• WebKit: An Objective View

WebKit, the rendering engine at the heart of Safari and Chrome, living in iPhones, iPads and Android devices, is now the over-dominant browser on the mobile Web and technically, the mobile Web is full of works-only-in-WebKit web sites while other browsers and their users are crying. Many sites are sniffing the browser’s User-Agent string and filtering out non-WebKit browsers. As in the past with IE6, it’s not a question of innovation but a question of hardware market dominance and software bundled with hardware. But there is an aspect of the problem we did not have during the IE6 era: these web sites are also WebKit-specific because they use only “experimental” CSS properties prefixed with -webkit- and not their Mozilla, Microsoft or Opera counterparts. So even if the browser sniffing goes away, web sites will remain broken for non-WebKit browsers…

In many if not most cases, the -webkit- properties WebKit-specific web sites are using do have -moz-, -ms-, -o- equivalents. Gradients, Transforms, Transitions, Animations, border-radius, all interoperable enough to be browser-agnostic. Their web authors need only a few minutes to make the site compatible with Mozilla, Microsoft or Opera. But they never did it.

Without your help, without a strong reaction, this can lead to one thing only and we’re dangerously not far from there: other browsers will start supporting/implementing themselves the -webkit- prefix, turning one single implementation into a new world-wide standard. It will turn a market share into a de facto standard, a single implementation into a world-wide monopoly. Again. It will kill our standardization process. That’s not a question of if, that’s a question of when.

This idea has been floated in conversations for a few years, but this portion of Dan’s post represents an official discussion at the CSS Working Group. An official discussion that Adobe, Apple, Disruptive Innovations, Google, HP, Microsoft, Mozilla, Opera and the W3C were all participating in.

While it is true that writing them all out is tedious, vendor-specific prefixes serve a very valuable purpose: they allow a browser manufacturer to experiment with a property before it becomes an official part of the spec. And during that experimental phase, the syntax can (and often does) change. If you use vendor-specific prefixes, you do so at your own risk. That’s not to say you shouldn’t use them, but it is to say that you should be careful about when and how you use them.

The value of vendor-specific prefixes is not really in question here though; they are not the problem. We are. We are apparently too lazy to implement CSS in a consistent cross-browser fashion. WTF?!

Please, I beg you: Take 10 minutes out of your day today and update every site you can to use the other vendor-specific prefixes (and non-prefixed) versions of each -webkit- property you find, even if you’re not sure it exists yet. And if you need help, ask.

UPDATE: If you want to scan your server for files that might need adjustment, try this from the command line:

If you want to run it locally on a Mac, you should change the folder to ~/Sites.

UPDATE #2: I created a petition and a pledge:

1. Tell Microsoft, Mozilla, and Opera not to implement the -webkit- vendor prefix, and
2. Pledge to update every site you can to use the other vendor-specific prefixed (and non-prefixed) versions of each -webkit- property you find, even if you’re not sure it exists yet

Sign the petition “Don’t make -webkit- prefixes a de facto standard” on Change.org.