Fight the scourge of performance-killing redirect-laden t.co links in Twitter’s web interface with this handy Chrome extension.
A handy Chrome extension to simulate different kinds of visual impairment.
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!
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?”
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.
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.
Oh, what a spray! What a lovely spray!
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.
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.
Here’s a nice little UI addition to Chrome. When you focus on the URL bar, if the current site has site-specific search discoverable via rel=”search”, then you get a greyed-out hint to press tab so you can start searching the site.
Some URLs are ugly. Some URLs aren’t. Let’s not sacrifice them.
Nat’s take on Chrome’s proposal to bury URLs:
The URLs are the cornerstone of the interconnected, decentralised web. Removing the URLs from the browser is an attempt to expand and consolidate centralised power.
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.”
Web-Thang is a chrome extension that replaces all instances of the term ‘web thang’ or ‘web thang/web thang’ with the term ‘web thang’.
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.
A description of the shockingly cavalier attitude that Chrome takes with saved passwords:
Today, go up to somebody non-technical. Ask to borrow their computer. Visit chrome://settings/passwords and click “show” on a few of the rows. See what they have to say.
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.
A handy plugin for Chrome that always you to inspect media query breakpoints and take screenshots at any of them.
A good history lesson in rendering engines: KHTML, WebKit, and now, Blink.
Best. Chrome extension. EVER!
Paul’s Chrome extension replaces every instance of “the cloud” with “the moon” (something I do in my head anyway).
It’s forked from an extension that replaces every instance of “the cloud” with “the clown.”
Oh, and Ben has written a version for Safari …forked from code that converts every instance of “the cloud” to “my butt.”
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.
A quick overview and explanation of web intents.
More brilliant and useful code from Glenn: copy and paste contact details from one URL into a form on another URL.
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
An argument against skeuomorphic design. The Windows Mobile 7 design vocabulary is rightly praised for its no-nonsense beauty.
A Huffduffer extension for Chrome — thanks to Jeremy Carbaugh.
I’ll be adding a link to this from the footer of Huffduffer for Chrome users.
A delightful online book that makes excellent use of HTML5's history API.
A new HTML5 resource from Paul Irish and other Googlers.
Steve Faulkner has created a petition to let Google know what screenreader users think of Chrome's appalling lack of basic accessibility hooks.
Best. Bug report. Ever.
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.
A blog of all things webkit, itself showcasing some of the CSS niceties in the rendering engine.