A Few Things from Chrome Dev Summit 2014

I got to spend the last two days at the Chrome Dev Summit (Thanks Paul Kinlan for inviting me!) I made some notes of a few things that caught my eye.

There was a brief mention of the manifest.json file, which I had never heard of. Apparently it's a Chrome thing that is important for extensions and such, but (is? could be?) brought to the web.

The idea is that you could put a lot of what goes into the <head> in there. Non-vital stuff like the title, meta tags, and whatnot. I suppose it cleans up the document a little bit (at the cost of a request), but most importantly, it means you can fit more into that "first 14K" - which is a big deal for critical path loading.

Speaking of meta tags, here's a new one:

<meta name="theme-color" content="#db5945">

Just a simple way to make your site's look bleed into the browser UI (Chrome on Android, anyway). That's inline with current design trends (e.g. all the transparency / color-bleed-through stuff going on in Yosemite.)

Probably the most exciting thing for me was talk of transitioning elements across page loads.

1. Tell the current page what you intend to transition:

<meta name="transition-elements" content="#move-me, .move-all-these">

2. Link up a special CSS file just for these transitions:

To transition before the exit happens:

<!-- I imagine you'd defer loading of this one -->
<link rel="transition-exiting-stylesheet" href="page-transitions.css">

Or to transition an element to the new place on the entering page:

<!-- But this one you'd want to link up right at the top -->
<link rel="transition-entering-stylesheet" href="page-transitions.css">

3. Use @keyframes to move the elements

@keyframes moveToNewPosition {
  from { /* where ever it was before */ }
  to { top: 0; }

#move-me {
  animation: moveToNewPosition 0.5s;

Surely there was bigger, way more important things being talked about that affect the future of the web. But hey, I like tricks. Apparently this shipped behind a flag in Chrome 38, but I haven't had time to try to get it to work yet.

One prevailing theme, which is all over the industry these days, is that if we want the web to "win" (we do, it's good for the world) we need to make sure it's competitive against native apps. That means things like "installable" sites (presence on home screens), offline capabilities, and real (push) notifications.

Of the latter two, Service Workers is the ticket. It's mostly over my head, but as I understand it, it's access to some lower level web stuff than we've ever had before. Like far better control over offline/cache than we've had before (it's not just "a list of files to store locally" as previous attempts were).

Service Workers will be where you register notifications (i.e. navigator.push.register()) So even if a website is closed, you can still get notifications (somehow). Desktop Safari has them, but it's a propertitary thing I think. Because there will be multiple ways, I'm sure middlemen like Roost will become a way to take advantage of them with less complexity.

The idea is to blur the line better between native apps and websites, and then the all the rest of what makes the web great (cross-platform-ness, URL's, ubiquity...) will lead it to victory.

It was cool to hear Paul Lewis talk about designing a real site (the Chrome Dev Summit site itself). I think we've all seen some "material design" stuff by now, like expanding regions. But it's mostly on mobile apps. It's neat to see it working here in responsive design.

The goal everywhere for a non-janky feel is "60fps". Sixty frames-per-second. Paul talked a lot about getting to that on this site, including little interesting bits like the fact that you don't need 60fps all the time, you just need it when things are moving, so if you can shuffle around expensive operations, do them when nothing is moving.

I attempted to record this GIF at 60fps, but not quite as smooth as real thing.

Paul animated the (deprecated) clip property in CSS to do a lot of this. I talked to him about that, and he said he got better performance out of it than the newer clip-path.

It's not a pure CSS endeavor though. Each animation is handled basically like:

  • Gather a bunch of information information about the current element, via getBoundingClientRect();
  • Animate those positions to new positions

Clever, since you don't have to hard-set anything in CSS (or know anything in advance) to do these animations. The page flow can remain totally normal. I suspect we'll see a lot of this kind of thing going forward. Figure out what's up in JS, animate with CSS.

Here's his talk (and you can get to all the others from there):

Don't miss the bit about using DevTools to inspect and control animations. Like slowing them down, seeing which elements are being affected, and scrubbing through the entire animation with a range slider.

I might be wrong about animations remaining mostly in CSS, since the Web Animations API is coming around.

One author-facing thing it has is .animate() - which is pretty much just like jQuery (or Velocity) .animate() in that you pass it some CSS properties and values and it animates to them. It's just native now instead of requiring a library. I imagine stuff like GSAP will start detecting for native support and using that or falling back to rAF or further.

I talked with Alex Danilo about it and got a stronger understanding. I guess the important bit is that this isn't just a new API for us authors to use, it's a whole animation engine under the hood. So rather than three different animation engines (CSS transitions, which was a different thing that CSS animations, which was a different thing from SMIL), it's just one engine that everything uses.

I've been hearing rumors of SMIL support being ripped out of Blink's SVG support, and kinda wanted to hear about that. Apparently the root of it is that it just kinda sucks that it is it's own whole animation engine and it's the source of quite a few security issues. So now there is apparently a guy who was hired to see if he can make SMIL use the Web Animations API under the hood. If he can, great, if not, SMIL is used so infrequently (and on somewhat unimportant things, like spinners) that it might get ripped out.

My worry is that SMIL can do some pretty cool things that I'm not 100% sure Web Animations API can, like shape morphing and having events (or other animations) trigger animations.

There was lots of Polymer talk. They are in an interesting place with Polymer as far as developer-understanding. I think a lot of people thing of it as "a web components polyfill", but:

  • Web components is really just an umbrella term for four different technologies: templates, custom elements, shadow DOM, and HTML imports. (good tutorial by Google's Rob Dodson).
  • Each of those technologies has a different polyfill
  • None of those polyfills is Polymer

Polymer is:

  • A library that makes web components stuff easier and more powerful
  • Actually really small: 6K gzipped.

A custom element with a custom shadow DOM has a boundary on it. Kinda like an iframe, where the parent page styles don't leak in and styles within don't leak out. That's really cool, but it also might not be ideal all the time, since if you're architecting a whole site around these components, you might want your styles to penetrate these boundaries and style things, like the CSS we're used to.

There has been several attempts at shadow DOM penetrating CSS selectors, like .outside ^^ .inside, some pseudo selector I forget exactly, like .outside:shadow(.inside). There is one that actually works in Chrome now like .outside /deep/ .inside, but apparently that one won't be the answer either (hard to make fast, was one reason I heard.)

I'm anxious to get to a solution here, because it will affect styling SVG <use> through the shadow DOM boundary that happens there which should be pretty dang interesting.

There was a lot of "material design" talk too. I always feel like putting it in quotes for some reason. I quite like it, but I feel like it's just the name of a thing, not a Real Thing. It's a pattern library. It's a set of guidelines. It's just simple, tasteful design. I agree with Khoi Vinh here:

I'm not sure Material Design would attract much notice apart from the Google connection. For the record, I find Material Design to be a nice bit of work and it's certainly attractive, but the rhetoric around it strikes me as a lot of hot air.

A huge company like Google, with a zillion properties, needs a coherent system to tie it all together, and now they have it and that's awesome. You and I can learn from it, but we don't need to use it directly or start weirdly slipping it into casual conversation. Feel free to not use this at your next cocktail party:

"Like, I feel like this material design movement parallels the Arts and Crafts movement of the late 19th century in that its all about simple forms. It's about being economic and careful about what we have. It's about going back to what's simple and important, man."

Chris Palmer talked a lot about Transport Layer Security (TLS). I always called it SSL, but apparently that's like the old version. Basically, URL's that start with https://.

There is a big push to make the whole internet that, and Chris was firmly in support of it. Without it, anybody in the middle of web requests (lots of people) can mess with what goes across. It's become kind of a standard practice for some ISP's to insert their own Google AdSense ID in the HTML of sites in replacement of the owner of the site's. That's insane. Can't be done with HTTPS, because what goes across the wire is encrypted gibberish.

One push-back on this is that HTTPS is "slow", and like all good myths, there is some bits of truth in there. There is some parts of it that can take milliseconds to do. But a lot of it can be mitigated through just doing generally smart things (like concatenating requests). Plus a lot of modern stuff, like the very-awesome stuff in HTTP2 and Service Workers, requires HTTPS, so it's really time to do it.

I think I can easily enough on CSS-Tricks, but on CodePen, anybody can easily link to non-secure resources, so we'll need to evaluate what the UX for that is like on an all HTTPS setup.

PHEW! That's a lot of learning. There was a lot more going on there than this little bit of stuff I covered. And I'm fresh off the heels of two days at An Event Apart so my brain is pretty full.