PPK reads a Hacker News thread so you don’t have to.
This is what Nick Sherman has been banging on about for years, and now the time has come for variable fonts …as long as typographers, browser makers, and standards bodies get behind it.
More details on Ev’s blog.
Alex runs through the features that a progressive web app must have, should have, and would be nice to have.
In general, installability criteria are tightening. Today’s Good-To-Haves may become part of tomorrow’s baseline. The opposite is unlikely because at least one major browser has made a strong commitment to tightening up the rules for installability.
Right now, this is in the nice-to-have category:
Mobile-friendly, not mobile-only.
Personally, I’d put that in the must-have category, and not just for progressive web apps.
Anyway, read on for some advice on testing and tooling when it comes to evaluating progressive web apps.
How Google And Others Are Plotting The Revenge Of The Web App | Fast Company | Business + Innovation
It’s always, um …”interesting” when a mainstream publication covers a topic from the web’s bikeshed. In this case, it’s progressive web apps, and—apart from the sensationalist headline—it’s actually not that bad at all.
A thorough explanation of
@supports from Jen, with plenty of smart strategies for using it in your CSS today.
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.
One more reason why you should never sniff user-agent strings: Internet Explorer is going to lie some more. Can’t really blame them though—if developers didn’t insist on making spurious conclusions based on information in the user-agent string, then browsers wouldn’t have to lie.
Oh, and Internet Explorer is going to parse -webkit prefixed styles. Again, if developers hadn’t abused vendor prefixes, we wouldn’t be in this mess.
Personally, I’m all for more browsers. The more, the merrier.
I, for one, don’t welcome our applinks overlords.
So, you’re checking out your news feed on your Facebook app and you see a CNN post that you want to read. After reading the post on CNN, you decide you want to to read the source article on TMZ…
Some URLs are ugly. Some URLs aren’t. Let’s not sacrifice them.
A lovely post by Mark on the value of URLs.
Right now, this move to remove URLs from the interface of Chrome is just an experiment …but the fact that Google are even experimenting with it is very disturbing.
“Who? Me? No, I was never going to actually blow the web’s brains out—I just wanted to feel the heft of the weapon as I stroked it against the face of the web.”
Derek’s excellent advice on avoiding over-reliance on data attributes has this brilliant nugget of insight:
In the web front-end stack — HTML, CSS, JS, and ARIA — if you can solve a problem with a simpler solution lower in the stack, you should. It’s less fragile, more foolproof, and just works
I like this idea. It would be nice to see it catch on…
- Report a bug for any website or browser.
- Our team of volunteers diagnoses the bug.
- We send a fix to the site owner or browser.
A nice summation by Dan of when it makes sense to use a graphic design tool like Photoshop and when it makes sense to use a web browser.
John echoes some of my recent thinking about what qualifies as a web browser and, by extension, what qualifies as the web:
We shouldn’t think of “the web” as only what renders in web browsers. We should think of the web as anything transmitted using HTTP and HTTPS. Apps and websites are peers, not competitors. They’re all just clients to the same services.
That said, I think he is perhaps underestimating the power of URLs. Addressability—particularly over an extended time period—remains the powerful feature of the web.
A handy way of automating the creation of old-IE stylesheets using Grunt. This follows on from Jake’s work in using preprocessors and conditional comments to send a different stylesheet to IE8 and below—one that doesn’t contain media queries. It’s a clever way of creating mobile-first responsive sites that still provide large-screen styles to older versions of IE.
The importance of long-term thinking in web design. I love this description of the web:
a truly fluid, chaotic design medium serving millions of imperfect clients
Some good ideas on the idea of element-level media queries, a feature that developers are crying out for and browser makers are saying is too hard. This post has some thoughts on how to deal with the potential issues.
A lovely history lesson on CSS from John.
I think Chrome is doing the right thing by removing the 300 millisecond tap delay on sites that set width=device-width — it’s certainly better than only doing it on sites that set user-scalable=no, which felt like rewarding bad behaviour.
John shares his concerns about the increasing complexity involved in developing for the web.
Some excellent research for web developers: find out which unicode characters have the widest support—release useful for choosing icons.
I really like Scott’s approach to defining what “support” means in terms of browsers—it makes a lot sense to break things down to the component level.
The authors of the Extensible Web Manifesto explain the thinking behind their …uh… thinking.
Alex starts with a bit of a rant about the phrase “semantic HTML”, which should really just be “well-written HTML, but there then follows some excellent thoughts on the emergence of meaning and the process of standardising on vocabularies.
Good luck getting that script updated for the thousands of sites and applications, you say to yourself, where it’s laying dormant just waiting to send devices the wrong content based on a UA substring.
Henri gives an overview of the DRM-style encryption proposed for HTML. It’s a very balanced unbiased description, but if you have the slightest concern about security, sentences like this should give you the heebie-jeebies:
This is the worst idea for a W3C community group ever. Come to think of it, it’s the worst idea for an idea ever.
Brian writes up his experience working on the line-mode browser hack event at CERN.
Once you get past the cheesy intro music, there are some gems from Robert Cailliau in here.
I took a little time out of the hacking here at CERN to answer a few questions about the line-mode browser project.
This is what I’m working on today (where by “working on”, I mean “watching other far more talented people work on”).
Alas, that clever SVG fallback trick I linked to a couple of days ago has some unexpected performance side-effects.
Surfin’ Safari - Blog Archive » Improved support for high-resolution displays with the srcset image attribute
WebKit nightlies now have support for
srcset. I’m pleased to see that it’s currently constrained to just handling the case of high-density displays; it doesn’t duplicate the media query functionality of
I’ve always maintained that the best solution to responsive images will be some combination of
picture: they each have their strengths and weaknesses. The “art direction” use case is better handled by
picture, but the “retina” use case is better handled by
A great call-to-arms from Tim, simply asking that we create websites that take advantage of the amazing universality of the web:
The web has the power to go anywhere—any network, any device, any browser. Why not take advantage of that?
Inevitably there is pushback in the comments from developers still in the “denial” stage of coming to terms with what the web is.
A call for developers to let standards bodies know what we want:
It is important that we as developers focus on the right things again. If you encounter a bug, you should not only fix it for your site; you should reach out to browser vendors and web standards people to fix this in a long-term solution. It might cost you a few minutes, but brings a lot of improvement to the whole developer community.
Well, this is interesting: it looks like Chrome might stop waiting 300ms for potential double-tap-to-zoom events if the site is using a meta viewport declaration that sets the width to device-width.
The closing hot topics panel I moderated at this year’s Mobilism conference in Amsterdam, featuring Remy, Wilto, Jake, and Dan.
A great history lesson from Dave.
Ah, I remember when the CSS Zen Garden was all fields. Now get off my CSS lawn.
The battle between web fonts and performance. Ian Feather outlines some possible solutions, but of course, as always, the answer is “it depends”.
An intriguing initiative to tighten up the loop between standards development and implementation.
A terrific quiz about browser performance from Jake. I had the pleasure of watching him present this in a bar in Amsterdam—he was like a circus carny hoodwinking the assembled geeks.
I guarantee you won’t get all of this right, and that’s a good thing: you’ll learn something. If you do get them all right, either you are Jake or you are very, very sad.
Jake casts a scrutinising eye over the way that browsers load and parse scripts …and looks at what we can do about it.
A fascinating look at the history of cookies …from the inventor of cookies.
Joking aside, this is a useful resource for keeping track of the current spread of Android versions.
Wow! The CSS Zen Garden is a decade old. Crazy! It’s a true piece of web history …and it’s back!
A handy plugin for Chrome that always you to inspect media query breakpoints and take screenshots at any of them.
A terrific piece by Remy—based on a talk he gave—on when he uses jQuery and, more importantly, when he doesn’t. His experiences and conclusions pretty much mirror my own, but of course Remy is far more thoughtful and smart than I.
Really good stuff.
Want to style those new HTML5 input types? I hope you like vendor prefixes.
A good history lesson in rendering engines: KHTML, WebKit, and now, Blink.
This is wonderful stuff! I’m a big fan of the
datalist element but I hadn’t realised how it could be combined with
input types like
A handy one-stop-shop for tips on improving front-end performance.
This issue of A List Apart is a great double-whammy. Lara Swanson has a ton of practical tips for front-end performance enhancements, and Brian dives deep into making your own icon fonts.
The “client hints” proposal looks really interesting: a way for user-agents to send data to the server without requiring the server to have a library of user-agent strings. But Scott has a few concerns about some of the details.
The slides from Anna’s terrific talk at the Responsive Day Out.
And this is why user-agent sniffing not a future-friendly technique. A new mobile browser comes along, and it has to spoof a fake UA string to all of these sites.
It’s a Red Queen arms race.
A very hand tip from Ben on using SVG background images with a PNG fallback for IE8 and below.
Everything you ever wanted to know about using SVG today.
A good explanation of the litany of woes that comes from Internet Explorer 8 being the highest that users of Windows XP can upgrade to. It’s a particularly woeful situation if you are a web developer attempting to provide parity. But there is hope on the horizon:
2013 will see the culmination of all these issues; support for IE 8 will drop of rapidly, users of XP will find an increasingly broken web, the cost of building software in XP organisations will increase.
A gorgeous collection of experiments that showcase just how much is possible in browsers today.
Bruce sits down for a chat with Hixie. This is a good insight into the past and present process behind HTML.
A well-reasoned argument for tackling image optimisation on the server, using content-type negotiation.
David takes a look at worldwide trends in web browsing, pointing out where mobile traffic exceeds desktop …and we’re not necessarily talking about smartphones here either.
It would be possible to travel from the Niger Delta on the west coast of Africa, to the horn of Africa on the east coast, without passing through a country where people surf more on desktop than a mobile phone.
Steven Wittens, who gave a terrific talk all about maths at last week’s Full Frontal conference, describes his experience at that most excellent event.
Andrea looks at support for HTML5 input types in IE10 Mobile.
Useful advice from Tim on preparing your responsive site for IE10’s new “snap mode”. Don’t worry: it doesn’t involve adding any proprietary crap …quite the opposite, in fact.
This is an excellent resource from Anna. She’s documenting the browser capabilities of games consoles.
A one-stop-shop for browser-compatibility information. This is MDN, HTML5 Rocks, and Quirksmode all rolled into one.
Hey look; Anna’s in a CSSquirrel comic! And for good reason: Kyle is as impressed as I am with Anna’s research into browsers on gaming devices.
There’s also a call for more community device labs. I approve.
An excellent in-depth article from Anna on the many gaming devices out there that have both an internet connection and a web browser.
Luke collates some useful mobile browsing statistics once again. Most of it is quite US-centric, but this closing point is a whopper:
36 countries more than doubled their Opera Mini user bases in one year.
Bruce writes about a worrying trend in standards work:
Tossing a specification that you’ve written in-house, in secret and already implemented onto a table at W3C, saying “here, standardise this” as you saunter past isn’t a Get Out of Jail Free card for proprietary misdemeanours. And it isn’t standardisation.
Stuart on the importance of View Source.
A great behind-the-scenes look at the redesign (and redevelopment) of Twitter’s mobile subdomain silo. Man, I would love to see this progressively enhanced up to the current widescreen view for “desktop” browsers without the need for separate URLs for any class of device.
But I digress …this is good stuff.
Nicholas is inside my head! Get out of my head, Nicholas!
What makes the web beautiful is precisely that there are multiple browsers and, if you build things correctly, your sites and applications work in them all. They might not necessarily work exactly the same in them all, but they should still be able to work. There is absolutely nothing preventing you from using new features in your web applications, that’s what progressive enhancement is all about.
Here’s a brainbuster for ya: a single file that renders both as HTML and as a JPEG. As an HTML page, it even contains an img element with a src of …itself!
Compare the “view source” output with the generated source output to see it’s being interpreted.
Anna reports on her experience testing on a device we don’t often think about: the Nintendo DS …very popular with the young ‘uns.
A nice timeline visualisation of recent history.
Wilto does an excellent job of summarising the current state of responsive images, highlighting Florian Rivoal’s compromise proposal that combines the best of the picture element with the best of srcset.
Well, I guess this is one way of encouraging people to upgrade their browser.
A nice round-up of the issues around responsive images and their potential solutions.
This is an excellent idea from Jake: use a preprocessor to automatically spit out a stylesheet for older versions of IE that includes desktop styles (garnered from the declarations within media queries).
If you’re a dab hand with Ruby and you’d like to see this in SASS, you can help.
Jason outlines the real challenge to every proposed solution for responsive images: they just don’t jibe with the way that browsers (quite rightly) pre-fetch images.
A well thought-out evaluation on responsive images from Bridget.
Have you thought “There must be a good reason for the blink element.” Well, read on.
Mobile Browser Panel 2012, Mobile Browser Panel at Mobilism 2012 Moderated by Jeremy Keith, this panel features Andrea Trasatti (Nokia), Andreas Bovens (O…
Here’s the video of the mobile browser panel I moderated at Mobilism in Amsterdam. These guys were really good sports to put up with my wisecracking shots for cheap laughs at their expense.
Proposition to change the prefixing policy from Florian Rivoal on 2012-05-04 (firstname.lastname@example.org from May 2012)
This seems like a sensible way for browsers to approach implementing vendor-prefixed CSS properties.
We don’t support Internet Explorer, and we’re calling that a feature | Tips for Freelancers on Time Tracking and Invoicing | Paydirt Blog
This is the absolutely worst way to think about browser support: because the design doesn’t render “pixel perfect” (whatever that means) in a browser, that browser is blocked from accessing content. This is completely unnecessary and shows a fundamental lack of understanding of the web’s greatest feature: progressive enhancement.
Wilto gives a thorough explanation of the state of things with responsive images, particularly the work being done at the Responsive Images Community Group at the W3C.
This is a very in-depth look at how to become a power user of the Web Inspector in Webkit browsers. I’m sitting down with a nice cup of tea to go through all of this.
I had a chat with the guys from Pingdom about performance’n’stuff. If I sound incoherent, that’s because this is a direct transcription of a Skype call, where, like, apparently I don’t, y’know, talk in complete sentences and yeah.
Tim has published the results of a whole bunch of testing he did on how different browsers deal with hidden or replaced images.
This seems like a sensible way of separating capable browsers from legacy browsers: if the browser supports querySelector, localStorage and addEventListener, you’re good to go.
An in-depth look at the BBC News mobile testing process. I think it’s great that people are sharing this kind of information.
A fun little multiplayer game, all possible in the browser thanks to web sockets.
An oldie but a goodie: Clay Shirky looks at the design principles underlying HTML in order to figure out what made it so successful. Even though this is fourteen years old, there are plenty of still-relevant insights here.
A great talk by Nicholas on what progressive enhancement means today. There’s some good ammunition in here.
Scott has created a one-stop-shop for documenting browser bugs in mobile devices. Feel free to add to it.
Mozilla will be supporting H.264 …but they’re not happy about it.
I won’t sugar-coat this pill. But we must swallow it if we are to succeed in our mobile initiatives. Failure on mobile is too likely to consign Mozilla to decline and irrelevance.
Chris defends himself from some inaccuracies I flung his way, regarding fonts and DRM.
Luke rounds up some of the alternatives to bitmap-based images—an increasingly important topic for “resolutionary” “retina’ displays (bleurgh!).
A great post that discusses exactly what we mean when we talk about “supporting” different browsers.
An acid test for mobile browsers. Point your device at rng.io and it will report on how much or little mobile shininess is available.
Mark talks about the tools web designers use and the tools web designers want. The upshot: use whatever you’re most comfortable with.
A really handy test site from Lea that reports your browser’s recognition of CSS properties.
A terrific article from Wilto detailing the thinking that went into the Boston Globe’s responsive image techniques and how browser pre-caching is now throwing a spanner in the works.
Harry interviews Glenn about web intents (web actions). Glenn gives a good clear explanation of what they are.
A very useful site for checking browser support for CSS features. The test cases are really handy and the site gets extra bonus points for not calling itself “HTML5” anything.
Some valuable musings from Ben on how browsers could be better — and I don’t mean the usual moaning about performance or device APIs.
Stephanie details all the things we have to know about when designing for today’s broad range of devices: performance, capabilities, form factor, pixel density, and network latency.
These are all good points but I worry that if we just concentrate on the current device landscape, our processes won’t adapt to the future.
Joni points out a great advantage to the mobile-first approach if you choose not to polyfill for legacy versions of IE: you can go crazy with all sorts of CSS3 goodies in the stylesheet you pull in with media queries.
This helps to clarify the difference between native semantics and ARIA additions.
Heaven Devoid of Stars – a tale of cross-browser kerning | Clagnut § Browsers · Typography · CSS techniques
Richard dives into the differences in how browsers handle kerning. Be sure to click through to the beautiful finished result.
Brad is on a roll. He knocks it out of the park again, this time talking about the difference between supporting the huge range of mobile browsers out there compared to trying to optimise for them.
PPK tests the various ways that mobile browsers handle position:fixed, complete with videos.
An in-depth look at browser polyfills: what they are, how they work, and how you can make your own.
Alex weighs in on the newly-reopened debate on vendor prefixes, roundly squashing Henri’s concerns.
Brad takes a detailed look at mobile browser support for fixed positioning and how it intersects with page zooming.
Luke points out that the web is everywhere: it’s accessible through the browser but also through many native applications. This is the real Web Operating System.
The Web (browser) is inside of every application instead of every application being inside the Web (browser).
Daniel responds to Henri’s call-to-arms on vendor prefixes. While he stridently disagrees with most of what Henri suggests, there is also overlapping agreement: they both want vendor prefixes to ship only in experimental builds, not stable browser releases.
This is a very thoughtful piece by Henri on vendor prefixes and it’s well worth a read …however the thought of one browser implementing support for vendor-prefixed properties intended for a different browser does make me quite quesy.
A wonderfully in-depth article from Zoe on all the practical aspects of using media queries for layout.
Jason continues his look at responsive images techniques by diving into the nitty-gritty of the various options out there.
Jason takes a high-level look at tackling mobile-first responsive images (his next post will dig into the details). This is a really good summation of current thinking. Be sure to read the comments too: Andy chimes in with his experiences.
Paul paints a grim picture of our future support nightmares with multiple Internet Explorers, each one with multiple buggy “compatibility” modes.
Bruce nails his colours to the mast of future-friendliness (and nicely summarises recent heated debates between John Allsopp, Alex Russell and Joe Hewitt).
John pushes back against the idea that browser innovation is moving too slow.
This handy matrix shows the effect of different -webkit-font-smoothing setting on various text combinations (serif/san-serif light/dark, etc.).
I was all set to bristle against an attack on the W3C from Alex …but when I actually read the post, I found it hard to disagree with. If anything, this shows just how much Alex cares about the W3C (probably more than most people).
The conversation in the comments is worth reading too.
Mobile HTML5 - compatibility tables for iPhone, Android, BlackBerry, Symbian, iPad and other mobile devices
This just launched at the Breaking Development conference: another site that uses the term HTML5 to include CSS and Ajax. Still, despite its inaccurate nomenclature, it’s a useful compatibility table of device support in mobile browsers.
An eye-opening insight into web usage on mobile devices in Asia from Paul Rouget.
This abuse of the !important declaration in Firefox’s user-agent stylesheet was driving me crazy recently. Roger proposes a CSS patch, but this is really something that needs to be fixed in the browser.
Jake’s talk at DIBI earlier this year was absolutely fantastic. It features a rape reference, a story about pissing, and a Human Centipede metaphor.
It’s also very, very informative. Watch this.
A valiant attempt to polyfill support for hyphenation in browsers other than the latest Safari and Firefox.
A very clever and tricksy way to sync up multiple devices so that when you refresh a URL or follow a link on one, it happens on all of them. It uses OS X’s Internet Sharing feature combined with locally-hosted Node.js. It’s positively McGyverian!
Finally. Hyphenation on the web.
Pretty much the only forms of Western literature that don’t use hyphenation are children’s books and websites. Until now.
Insanely in-depth look at how browsers work, right down to the nitty gritty. You’d think there’d be a lot of engineering talk, but actually a lot of it is more about linguistics and language parsing.
There are some inaccuracies and misrepresentations in here, but on the whole this is a pretty good round-up of your options when dealing with responsive design in older browsers.
A great reminder from Bruce that we need to remember to use cutting-edge web technology responsibly.
A quick overview and explanation of web intents.
Listen to Josh explain a genuinely useful example of HTML5’s local storage that he’s added to Fontdeck.
This is your one-stop shop for envelope-pushing in the browser:
Everything you ever needed to know about adding HTML5 audio and video to your site, courtesy of the mighty John Allsopp.
New Mobile Safari stuff in iOS5: position:fixed, overflow:scroll, new input type support, web workers, ECMAScript 5 | David B. Calhoun – Developer Blog
An excellent summation of one web developer’s journey with responsive web design.
This dovetails nicely with my recent post about the spirit of distributed collaboration. Here’s a great little bit of near-history spelunking from Paul, all about styling new HTML5 elements in pesky older versions of Internet Explorer.
Luke’s notes from the browser panel I moderated at the Mobilism conference.
Here’s a video of the mobile browser panel I moderated at Mobilism in Amsterdam today. It gets fairly technical for a while but it was mostly a lot of fun.
Well, ya learn something new every day …or at least I did. I had no idea about the rem unit—relative em—for font-sizing in CSS.
Ben Buchanan has a nice round-up of some of the options available when you’re switching over to HTML5.
Translation From MS-Speak to English of Selected Portions of Dean Hachamovitch’s “Native HTML5″ announcement [dive into mark]
Mark Pilgrim translates Dean Hachamovitch’s utterly bizarre and nonsensical announcement of IE10 that kept talking about “native HTML5.”
A quick chat with me in the hallway after my talk in Seattle.
A browser-based ePub reader. ‘Cause it’s (X)HTML all the way down, baby.
A rather vicious evaluation of browser support for the audio element and the audio API. It is divided up into:
- Browsers From Companies That Actually Care About HTML5 Audio
- Browsers From Companies That Hate the Web Enough to Not Support Ogg/Vorbis, but do Have an Audio Tag So They Can Say They Have an Audio Tag (Seriously, Fuck You)
- Browsers That Say They Support HTML5 Audio But Actually Don’t Support HTML5 Audio
A nice’n’small lazy loader that should make life easier when it comes to pollyfilling browser support for nifty HTML5 or CSS3 features.
Some musings from Norman Walsh. I have to say, I’m still not entirely sure why the HTML/XML Task Force exists. The “use cases” described here are vague and handwavey.
PPK on the circle of life when it comes to online technology advances; innovation happens fast in proprietary platforms, but the good stuff ends up being natively supported in browsers. It’s a pretty good ecosystem, all in all.
This script adds user-agent information in class names to the document’s root element so that those user agents can be targeted with CSS. It could be useful, but only in direst need.
An oldie but a goodie. This is why we have standards.
A handy shim for audio: it uses the native implementation where possible and Flash as a fallback.
Nicole proposes an interesting way of clearing floats with a combination of display:table-cell and generated content.
Bobbie Johnson dot org : Ian Hickson on HTML5: “The W3C lost sight of the fact that they have no power”
Bobbie is publishing the interviews he conducted with various HTML5 bods when he was researching his Technology Review article. First up: Hixie.
A delightful online book that makes excellent use of HTML5's history API.
A quick run-through of some of the new HTML5 form features coming in Firefox 4.
All the tests and all the results, all in one place.
A great explanation of the responsive enhancement of this site.
A handy table of new HTML5 elements and whether or not they are exposed to assistive technology.
I couldn't agree more with this rant from Remy. He took the words right out of my mouth.
A very handy page for showing HTML5 form element support in your browser.
An interesting performance proposal from mozilla that will degrade nicely in legacy browsers.
An excellent argument in favour of vendor prefixes in CSS, from Eric.
Steve Faulkner has created a petition to let Google know what screenreader users think of Chrome's appalling lack of basic accessibility hooks.
Tantek is working with Mozilla now. I expect great things will come of this.
Henri Sivonen gives the lowdown on the HTML5 parser that will ship with the next version of Firefox. This is a huge development ...and yet users won't even notice it (by design).
The origins of the blink element are fascinating. To nobody's surprise, alcohol was involved.
Mozilla aims to plug the :visited/getComputedStyle bug/feature.
A thoughtful piece by John Gruber on HTML5 video: yes, software patents are toxic to the web but perhaps H.264 isn't the worst offender.
Encode your video twice (mp4 and ogg) and you can then serve it up in 4 different ways: 2 HTML5 video sources, 1 quicktime player, and 1 Flash player.
This. This right here is how you manage sites in multiple languages. Are you listening, Google?
A fascinating trip down memory lane to the birth of the IMG element.
Test cases for font-linking.
Using Google Chrome Frame in IE will give users of assistive technology the same shitty to non-existent experience they would get in the actual Google Chrome browser.
Getting font-linking to work in all browsers.
Simon St. Laurent explains why mobile support for HTML5 mitigates Microsoft's dominance of desktop web browsing.
A poster campaign aimed at encouraging IT departments to upgrade company browser policy.
Remy's riposte to http://ishtml5readyyet.com/
@font-face for all — Ted shows how to convert TTF files to EOT using the command line.
Trammell outlines the thoughtful, research-based approach that Digg will be taking in phasing out IE6 support.
The smart way to put video on the web: don't choose one single delivery method.
The spectre of patents is hurting progress on the web.
Courtesy of Remy. Doesn't he ever sleep?
A good description of how font linking works.
Andy's excellent presentation from An Event Apart in Boston and @media in London. Required reading/viewing.
The 26 step process required to add +1 to a feature request in IE. Franz Kafka is alive and well and living in Redmond.
Ethan follows up his Fluid Grids article with an equally excellent piece on resizing images.
Here's a different kind of browser stats graph. It shows numbers instead of percentage. Percentage-based graphs don't show just how much the pie has grown over time.
This is kinda sneaky but quite clever. Subtly encourage IE6 users to upgrade.
Remy explains how to get Firefox 2 and Camino to recognise HTML5 structural elements.
Step by step instructions for making your own Internet Explorer voodoo doll to stick pins into.
Great article by Bruce defending the principle of One Web.
Neil explains how you can have your Safari cake and eat it.
Bid farewell to IE6.
Font-weight is still broken in all but one browser | Clagnut Â§ Browsers Â· Typography Â· CSSÂ techniques
A superb bit of browser research by Richard. "Thereâ€™s more to the lives of many typefaces than just Bold and Regular, but almost no browsers follow the proper CSS 1 way of specifying Light, Semibold, Black and other weights. There is a workaround,â€¦
A document outlining browser support standards for bbc.co.uk
This looks like being an excellentâ€”and freeâ€”resource "...meant to provide web application developers, browser engineers, and information security researchers with a one-stop reference to key security properties of contemporary web browsers."
John has come to the same conclusion as Richard with regards to font embedding. In short, the font foundries are missing a huge revenue stream. They could be offering fonts on a per-domain basis (a la Google Maps or any other third-party API). Remâ€¦
Here's a handy little trick from Paul: use conditional comments to add a class to your BODY element, allowing you to target IE without a separate stylesheet.
A great article by Malarkey wherein he lists five examples of progressive enrichment (as Dan is wont to call it) complete with side-by-side comparisons. Useful ammo, this.
The last piece is falling into place. IE8 has ARIA support, Mozilla has ARIA support ...and now WebKit is getting there. Excellent!
David has no sense of humour.
A nice analysis and skewering of Microsoft's proposed default behaviour for version targeting.
Rachel adds her thoughts on Microsoft's broken implementation of version switching—and very good thoughts they are too.
A new version of Dean's IE7 script is available. Given my daily frustrations with IE6, I hope its marketshare declines enough that I can use this as a magic bullet in front-end development.
Like "is it Christmas?" or "is Twitter down?" but less Boolean.
PPK has once again been doing sterling work. He's updated the DOM compatibility chart and things are actually looking pretty good.
Hail to the King... so says Business Week.
The justification behind YSlow. If you've heard Nate Koechley speak, some of this will be familiar to you. It's all solid advice as far as I can tell.
Transcript: Where the rubber meets the road — Web Accessibility and Pragmatism / Geek in the Park 2006 / Bruce Lawson and Patrick H. Lauke / splintered - freelance creativity and design / the portfolio and experimental playground of patrick h. lauke aka
This transcript of Pat'n'Bruce's talk at the Geek in the Park makes for a great, thought-provoking read.
Jon's mock-ups of how microformat detection and display might work in Safari are spot on. It would be so cool if this idea was picked up by browser developers.
A transcript of the Q&A session with Dave.