A thorough explanation of
@supports from Jen, with plenty of smart strategies for using it in your CSS today.
A thorough explanation of
A browser aimed specifically at web developers. It’s got some nice features around mobile device emulation.
Another dive into the archives of the www-talk mailing list. This time there are some gems about the origins of the
input element, triggered by the old
I’ve been thinking about this a lot lately. It feels like a user’s browser history is an incredibly rich seam of valuable information just waiting to be presented in a more interesting way.
Paul argues that the biggest problems for interoperability on the web don’t come from support (or lack of support) for entire features, but from the frustrating inconsistencies when features land in different browsers at different times with different implementations:
- Platform inconsistencies hurt us more than big feature differences, we should start to try and prioritize aligning the platform
- We need better tools to help us understand what the inconsistencies are and guidance on how to manage them
- Developers should raise more issues to keep browser vendors accountable when there are differences
Jason breaks down the myths of inputs being tied to device form factors. Instead, given the inherent uncertainty around input, the only sensible approach is progressive enhancement.
Now is the time to experiment with new forms of web input. The key is to build a baseline input experience that works everywhere and then progressively enhance to take advantage of new capabilities of devices if they are available.
A wonderful deep dive into the history of styling languages before CSS. I love spelunking down these internet history potholes—fascinating stuff!
Here’s an interesting proposal from Google for a user-initiated way of declaring a site’s offline assets should be prioritised (and not wiped out in a clean-up). Also interesting: the way that this idea is being tried out is through a token that you can request …sure beats prefixes!
A great talk from Bruce on the digital self-defence that ad-blockers provide. I think it’s great that Opera are building ad-blocking straight into the browser.
Hidde’s write-up of the Progressive Web App Dev Summit:
It was exciting to hear about the technologies, and to see that a lot of them already work on a great deal of platforms. Most of the major browser vendors expressed how much they liked the idea, so it is realistic to say support will increase in the short term. This, and the fact that all PWA techniques can be regarded as a ‘progressive enhancement’ (with some leniency as to what that term means), entails that we can build Progressive Web Apps today.
Hopefully, we will do so responsibly. Native apps really only work on their particular platforms. PWAs, in theory, can be built to work universally. For everyone with a web enabled device. This is awesome! Major browser vendors are behind the idea, and I think as developers we should be, too.
Cameron looks back on his 2007 Mobile Web Design book:
I don’t anticipate native apps will die off anytime soon. But I’m warming to the idea that they may be less relevant to the future of the web, and I reaffirm that “a browser will be — or should be — sufficient for interacting with web content.”
Progressive web apps are poised to be remarkably relevant to the future of the web. Let’s not screw it up.
Smart thinking from Alex on how browsers could better indicate that a website is a progressive web app (and would therefore benefit from being added to the home screen). Ambient badging, he calls it.
Wouldn’t it be great if there were a button in the URL bar that appeared whenever you landed on a PWA that you could always tap to save it to your homescreen? A button that showed up in the top-level UI only when on a PWA? Something that didn’t require digging through menus and guessing about “is this thing going to work well when launched from the homescreen?”
I agree with everything Andrew says here. Progressive web apps are great, but as long as Google heap praise on mobile-only solutions (like the Washington Post doorslam) and also encourage separate AMP sites, they’re doing a great disservice to the web.
More features arrive regularly to make this “one web” even better and easier to maintain. Service worker, streams, app manifests, payment request, to name a few. But adding these features one at a time to large, mature applications like WaPo or FT or Nikkei is a slow and painstaking process. That’s why it’s taking us a long time for us to tick off all these new features, and why it seems like madness to try and build the entire app several times over.
However, by creating the concept of PWAs and marketing them as they do, Google is encouraging publishers to ‘start again’. And they’re doing exactly the same thing with AMP.
In the web developer community’s collective drive to be more App Like and compete with native apps we may lose or weaken some of the web’s strongest features and we need to consider carefully before we throw away urls or the entire browser chrome in an effort to look like and behave like the cool kids of native.
You’re supposed to be able to create two-handled sliders with
input type="range" but the browser support isn’t there yet. In the meantime, Lea has created a nice lightweight polyfill.
The Working Draft podcast is usually in German, but this episode is in English. It was recorded in a casual way by a bunch of people soaking up the sun sitting outside the venue at Beyond Tellerrand. Initially that was PPK and Chris, but then I barged in half way through. Good fun …if you’re into nerdy discussions about browsers, standards, and the web. And the sound quality isn’t too bad, considering the circumstances under which this was recorded.
Remy looks at the closing gap between native and web. Things are looking pretty damn good for the web, with certain caveats:
The web is the long game. It will always make progress. Free access to both consumers and producers is a core principle. Security is also a core principle, and sometimes at the costs of ease to the developer (but if it were easy it wouldn’t be fun, right?).
That’s why there’ll always be some other technology that’s ahead of the web in terms of features, but those features give the web something to aim for:
Flash was the plugin that was ahead of the web for a long time, it was the only way to play video for heavens sake!
Whereas before we needed polyfills like PhoneGap (whose very reason for existing is to make itself obsolete), now with progressive web apps, we’re proving the philosophy behind PhoneGap:
If the web doesn’t do something today it’s not because it can’t, or won’t, but rather it is because we haven’t gotten around to implementing that capability yet.
Issue 596729 - chromium - Do not show the app banner unless the Manifest has a display set to standalone or fullscreen - Monorail
I am shocked and disgusted by this arbitrary decision by the Chrome team. If your Progressive Web App doesn’t set its manifest to obscure its URL, you get punished by missing out on the add to home screen prompt.
A glanceable one-stop-shop for how today’s browsers are dealing with today’s accessibility features. Then you can dive deeper into each one.
Ted has snuck a blog post out from behind Apple’s wall of silence, and it’s good news: WebKit is not going to use vendor prefixes for new features.
If you want to keep up to date with all the coolest stuff landing in CSS, I recommend bookmarking this ever-changing page.
A trip down memory lane with Håkon.
It’s not like the web has been done. This is history in the making. The web is only 25 years old. It’s going to be around for a long time, so there are lots of things to develop.
While many challenges remain, the good news is … it’s progressive. Developers can already see the benefits by sprinkling in these technologies to their existing websites and proceed to build on them as browsers and operating systems increase support.
Here’s an interesting proposal from ppk: use
requestAnimationFrame to gauge how performant a browser in behaving and then enhance accordingly.
Well, I’m convinced.
I don’t care about Opera Mini (I’m not its Product Manager). In the same way, I don’t care about walking sticks, wheelchairs, mobility scooters or guide dogs. But I care deeply about people who use enabling technologies — and Opera Mini is an enabling technology. It allows people on feature phones, low-powered smartphones, people in low-bandwidth areas, people with very small data plans, people who are roaming (you?) connect to the web.
The videos from EnhanceConf are started to go up already. Stefan’s talk really struck me—all the talks were great but this one had the most unexpected insight for me. It really clarifies a lot of ideas that I’ve been trying to articulate, but which Stefan crystalises by taking the long-zoom view.
This is a really good primer on all the pieces that make up the Houdini approach to CSS—giving authors access to low-level APIs for rendering.
As is often repeated here, it’s still early days and caution is advised, but it’s still a good idea to wrap your head around what’s coming down the standards pipe.
There’s even more specs in Houdini’s list of drafts, but the future of those is rather uncertain and they are not much more than a placeholder for an idea at this point. Examples include custom overflow behaviors, CSS syntax extension API, extension of native scroll behavior and similar ambitious things that allow you to screw up your web app even worse than ever before. Rejoice!
Microsoft are officially on board with implementing Service Workers in Edge:
Roadmap Priority: High — We intend to begin development soon.
I was just helping out with some debugging at work and it reminded me of this great talk/post by Remy:
- Replicate: see the bug
- Isolate: understand the bug
- Eliminate: fix the bug
A great piece by Christian on taking a responsible, customer-focused approach to building on the web.
You don’t have to support old browsers and terrible setups. But you are not allowed to block them out. It is a simple matter of giving a usable interface to end users. A button that does nothing when you click it is not a good experience. Test if the functionality is available, then create or show the button.
We have some new
font keywords that are basically shortcuts to using the system fonts on a device. This article explains the details.
I really, really want to like this article—it’s chock full of confirmation bias for me. But it’s so badly-written …I mean like, just the worst.
Here’s an actual sentence:
So with a capable, HTML-based platform and a well-designed program that makes good use of CSS, one site could support phones, tablets, PCs, and just about anything else with one site.
So, yeah, I’m still linking to it, but instead of it being for the content, it’s because I want to lament the dreadful state of technology writing.
This solution to the mobile tap delay by the WebKit team sounds like what I was hoping for:
touch-action: manipulation;on a clickable element makes WebKit consider touches that begin on the element only for the purposes of panning and pinching to zoom. This means WebKit does not consider double-tap gestures on the element, so single taps are dispatched immediately.
It would be nice to know whether this has been discussed with other browser makers or if it’s another proprietary addition.
It would be convenient to think that because we live in a world where people’s browsers are regularly updating, that we live in a world where the web is in a reliable state.
The web is a continually moving target. It probably changed in the time it took me to write this. If you work with web stuff you need to embrace this fact. It will be the only constant in your career.
Do not panic:
On the web progressive enhancement is and will always be, the methodology of choice. It makes your site robust to the shifting sands of the web front end.
Personally though, I’m still uncomfortable with the assumptions baked into equating particular features with particular browsers …maybe I’ve known PPK too long.
I much prefer to cut the mustard on a case-by-case basis by feature testing the actual APIs I’m about to use in a script. I realise that might be harder to scale, and it’s more verbose, but it’s the only way to be absolutely sure.
A list of known bugs (and workarounds) in flexbox implementations. This is going to be handy to refer back to.
Such a vividly nostalgic project. Choose an obsolete browser. Enter a URL. Select which slice of the past you want to see.
Digital archives in action. Access drives preservation.
Following on from that last link, here’s an in-depth run-down of what you can do in mobile browsers today. I think a lot of people internalised “what you can’t do on the web” a while back—it’s well worth periodically revisiting the feature landscape to revise that ever-shrinking list.
Perhaps the biggest advantage the web has over native apps is how quickly users are able to engage. All that’s between the user and your content is one click.
Visit this site using different browsers on different devices to get a feel for what you can do with web technologies.
Native will always be ahead, but the feature gap is closing impressively fast.
Bruce gives a great run-down of what’s involved in creating one of those new-fangled progressive apps that everyone at Google and Opera (and soon, Mozilla) are talking about: a secure connection, a service worker, and a manifest file.
Crucially, in browsers that don’t support it, you have a normal website. It’s perfect progressive enhancement.
Funnily enough, this here website—adactio.com—is technically a progressive app now.
At their simplest, Progressive Web Apps are application-like things hosted on your web server. If you’re as old as me, you might call them “web sites”
Harry packs a lot of great tips and tricks into one short video about performance troubleshooting. It’s also a great lesson in unlocking some handy features in Chrome’s developer tools.
A look at detecting, pinpointing, measuring, and fixing rendering performance issues.
Are we doomed to see history repeat itself? With the amount of client-side MVC frameworks and the upcoming implementation of the ES6 syntax, will we soon be seeing a repeat of the “browser wars.” Will more websites only work in a select number of browsers with the capabilities to run their code?
Rachel outlines the history of the CSS Grid Layout spec so far:
The process works, as slow as it may seem to us who wait anxiously to be able to take advantage of these techniques. I am happy that we are waiting for something that I really believe has the ability to completely change how we do layout on the web.
The sad history of
I wish I could share in the closing optimism:
Now imagine the future where Web Components are supported natively, and someone else is allowed to write a <better-input>, an element that is a real, encapsulated DOM element, and not just a div soup. Imagine using this <better-input> that isn’t implemented differently in each browser, that looks the same everywhere, and that probably also knows how to bake you a cherry pie.
But I all I can think is:
Now imagine the future where Web Components are supported natively, and everyone is allowed to write a million variations of <my-idea-of-a-better-input>, an element that is an inaccessible div soup under the hood.
Alex recounts the sordid history of vendor prefixes and looks to new ways of allowing browsers to ship experimental features without causing long-term harm.
Fire up Firefox and try out these demos: the CSS
element value is pretty impressive (although there are currently some serious performance issues).
To put it simply, this function renders any part of a website as a live image. A. Live. Image!
A wonderful, wonderful history of the web from Dave at this year’s Beyond Tellerrand conference. I didn’t get to see this at the time—I was already on the way back home—so I got Dave to give me the gist of it over lunch. He undersold it. This is a fascinating story, wonderfully told.
So gather round the computer, kids, and listen to Uncle Dave tell you about times gone by.
The death of the web has been greatly exaggerated.
There’s nothing else like it. It’s constantly improving. It’s up to you what you do with it.
Here’s the video of the panel I participated in at Edge conference, expertly moderated by Lyza.
Thanks to the video editing, you can’t see the face I’m making when the guy from Facebook talks about user-agent sniffing as a totally cool and reliable way of working.
A superb illustration of why playing the numbers game and dismissing even a small percentage of your potential audience could be disastrous.
This is the way to approach building for the web:
I want to make as few of those assumptions as possible. Because every assumption I make introduces fragility. Every assumption introduces another way that my site can break.
It’s progressive enhancement, but like Stuart, Tim is no longer planning to use that term.
I really like Alex’s framing of best-of-breed progressively enhanced websites as “progressive apps” (although Bruce has some other ideas about the naming).
It’s a shame that the add-to-homescreen part isn’t standardised yet though.
Using Progressive Enhancement makes your site better for all users and enables the 275 million users of Opera Mini worldwide.
I believe that Mozilla can make progress in privacy, but leadership needs to recognize that current advertising practices that enable “free” content are in direct conflict with security, privacy, stability, and performance concerns — and that Firefox is first and foremost a user-agent, not an industry-agent.
Progressive Enhancement remains the best option for solving web development issues such as wide-ranging browser support, maintenance and future-proofing your application.
Apps must run on specific platforms for specific devices. The app space, while large, isn’t universal.
Websites can be viewed by anyone with a web browser.
And that doesn’t mean foregoing modern features:
A web browser must only understand HTML. Further, newer HTML (like HTML 5) is still supported because the browser is built to ignore HTML it doesn’t understand. As a result, my site can run on the oldest browsers all the way to the newest ones. Got Lynx? No problem. You’ll still be able to find matches nearby. Got the latest smartphone and plentiful data? It’ll work there, too, and take advantage of its features.
This is why progressive enhancement is so powerful.
My site will take advantage of newer technologies like geolocation and local storage. However, the service will not be dependent on them.
I completely understand Peter’s fears here, and to a certain extent, I share them. But I think there’s a danger in only looking to what native platforms can do that the web doesn’t (yet). Perhaps instead we should be looking to strengthen what only the web can offer: ubiquity, access, and oh yeah, URLs.
This is a wonderful presentation by Kimberley at O’Reilly’s Fluent Conference, running through the history of the Line Mode Browser and the hack project we worked on at CERN to emulate it.
Brad points out the importance of supporting—which is not the same as optimising for—the non-shiny devices out there.
I really like using the Kindle’s browser as a good baseline for checking that information is available and readable.
Charlotte has experimenting with a nice discrete bit of flexbox on her personal site. Here she documents what she did, and what the fallback is.
The launch of the Apple watch prompts Brad to remind us of the benefits of being future-friendly.
Once again, responsive design is not about “mobile”, “tablet”, and “desktop”. It’s about creating experiences meant to look and function beautifully on anything that can access the Web. We don’t know what gizmos will be sitting underneath Christmas trees two years from now, but there’s a damn good chance those gadgets will be able to access the Web.
Everyone who calls for WebKit in Internet Explorer is exactly the same kind of developer who would have coded to Internet Explorer 15 years ago (and probably happily displayed the best viewed in badge).
It’s happening again, and every petulant, lazy developer who calls for a WebKit-only world is responsible.
From the ashes of Opera, a new browser is born. Download the tech preview and take it for a spin—it’s quite nice.
Anna documents the most interesting bit (for me) of her new wearable/watch/wrist-device/whatever — the web browser.
I love Lyza’s comment on the par-for-the-course user-agent string of Microsoft’s brand new Spartan browser:
There must be an entire field emerging: UA archaeologist and lore historian. It’s starting to read like the “begats” in the bible. All browsers much connect their lineage to Konqueror or face a lack-of-legitimacy crisis!
That’s Netscape 1.0n, released in December of 1994, running inside Windows 3.11, released in August of 1993, running inside of Google Chrome 39.0.2171.99 m, released about a week ago, on a Windows 7 PC, released in 2009.
But when it comes to trying to navigate the web with that set-up, things get a bit depressing.
First, the browsers competed on having proprietary crap. Then, the browsers competed on standards support. Now, finally, the browsers are competing on what they can offer their users.
I don’t agree with the conclusion of this post:
But I think the author definitely taps into a real issue:
The real problem is the perception that any code running in the browser is front-end code.
This is something we’re running into at Clearleft: we’ve never done backend programming (by choice), but it gets confusing if a client wants us to create something in Angular or Ember, “because that’s front end code, right?”
The difference between back-enders and front-enders is that the first work in only one environment, while the second have to work with myriad of environments that may hold unpleasant surprises.
Designing primarily in a laptop web browser and testing with a mouse rather than fingers may come to look very out of date soon.
An important clarification from Stephen:
You don’t actually design in the browser
When I speak of designing in the browser, I mean creating browser-based design mockups/comps (I use the terms interchangeably), as opposed to static comps (like the PSDs we’re all used to). So it’s not the design. It’s the visualization of the design—the one you present to stakeholders.
Personally, I think it’s as crazy to start in the browser as it is to start with Photoshop—both have worldviews and constraints that will affect your thinking. Start with paper.
Kenneth has isolated Chrome’s dev tools into its own app. This is a big step towards this goal:
Why are DevTools still bundled with the browsers? What if clicking “inspect element” simply started an external DevTools app?
With DevTools separated from one specific browser, a natural next step would be making the DevTools app work with other browsers.
Like caniuse.com, but for typography features. Find out what’s supported in browsers today.
This strikes me as an eminently sensible idea by Emil: using the picture element to begin providing WebP alternatives to JPG.
Of course, picture-supporting browsers will have to adjust their decision-making algorithm to support this pattern.
Paul Ford’s potted history of web standards, delivered in his own inimitable style.
Reading through the standards, which are dry as can be, you might imagine that standardization is a polite, almost academic process, where wonks calmly debate topics like semicolon placement. This is not the case.
I’m an advocate for progressive enhancement. Tom Dale is not. But even though we may disagree on that, there’s a lot to like in his sensible, balanced answers to some sensationalist linkbaity questions.
It’s not that the pace of innovation on the Web is slower, it’s just solving a problem that is an order of magnitude more challenging than how to build and distribute trusted apps for a single platform. As we saw on the desktop, it may take a few years to catch up to all of the capabilities of a native, proprietary platform, but in terms of the impact it will have on humanity, forgive me for not losing sleep if we have to wait a few years for it to arrive.
I mentioned this a little while back, but it’s worth remembering just how many people are using Opera Mini …and how many more are about to join them.
Bring it on!
Angry, but true.
Don’t lock yourself into a comprehensive technology that may just die within the next few months and leave you stranded. With progressive enhancement you’ll never go wrong. Progressive enhancement means your code will always work, because you’ll always focus on providing a minimal experience first, and then adding features, functionality, and behavior on top of the content.
My name is Jeremy and I am a boring front-end developer.
I share the concerns expressed here about the “sizes” attribute that’s part of the new turbo-powered img element (or “the picture element and its associates”, if you prefer). Putting style or layout information into HTML smells bad.
This is a concern that Matt Wilcox has raised:
Change the design and those breakpoints are likely to be wrong. So you’ll need to change all of the client-side mark-up that references images.
I can give you a current use-case: right here on adactio.com, you can change the stylesheet …so I can’t embed breakpoints or sizes into my img elements because—quite rightly—there’s a separation between the structural HTML layer and the presentational CSS layer.
Following on from that post of Jason’s I linked to, Chris also emphasises that, for most use cases, you probably only need to use srcset (and maybe sizes), but not the picture element with explicit sources.
It’s really, really great that people are writing about this, because it can be quite a confusing topic to wrap your head around at first.
It’s very early days for ServiceWorker, but Jake is on hand with documentation and instructions on its use. To be honest, most of this is over my head and I suspect it won’t really “click” until I try using it for myself.
Where it gets really interesting is in the comments. Stuart asks “What about progressive enhancement?” And Jake points out that because a ServiceWorker won’t be installed on a first visit, you pretty much have to treat it as an enhancement. In fact, you’d have to go out of your way to make it a requirement:
You could, of course, throw up a splash screen and wait for the ServiceWorker to install, creating a ServiceWorker-dependant experience. I will hunt those people down.
Jason points out that the picture element might not be needed for most responsive image use cases; the srcset and sizes attributes will probably be enough—that’s what I’m doing for the photos on my site.
Bruce went to the Extensible Web Summit in Berlin and wrote up his notes.
Sounds like he shares my excitement, but also my nervousness.
There’s also this important point, that Alex would do well to remember before crying “Piffle and tosh!”:
We need to ensure that all devs who want to can participate by allowing ease of collaboration, courteous discourse.
Opera Mini is about to be installed as the default browser on a few more million phones.
Dan Donald gets to the heart of progressive enhancement:
Assumptions in themselves don’t have to be inherently bad but let’s recognise them for what they are. We know very little but that can hopefully enable us to be far more flexible and understanding in what we create.