will-changeproperty that was intended to SOLVE problems for animators may end up doing the opposite.
It seems wise for the browsers to step back and let the spec authors fill in the implementation details and gain consensus before moving forward.
Chrome is going to refuse to parse
document.write for users on a slow connection. On the one hand, I feel that Google intervening in this way is a bit icky, but I on the other hand, I totally support this move.
This keeps happening. Google announce a change (usually related to search) where I think “Ooh, that could be interpreted as an abuse of a monopoly position …but it’s for ver good reason so I’ll keep quiet.”
Anyway, this should serve as a good kick in the pants for bad actors (that’s you, advertisers) to update their scripts to be asynchronous.
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.