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.
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.
The theme-color thing landed in Firefox OS 2.1 too.
Better a full brain than a full colon.
— Clinton Gallagher @virtualCableTV @METROmilwaukee
I am gung-ho and support ripping SMIL out of Blink and everything else as soon as possible. SMIL was developed with good intentions but has always been poorly documented, there are no development and testing tools to speak of and finally, the browser wars killed the SMIL golden goose long ago.
For me, the best part of deprecating SMIL will be the topsy-turvy disruption of the digital signage markets whose software vendors have used SMIL for programmatic control of assets displayed to the screen; that gives us “normal” client-side developers an open window to launch our own products and services giving us a leg up as the old school signage vendors rewrite their apps.
….Did you just quote yourself?
Hey Chris!
Was great to see you at CDS. Thanks for making the time to come out for it.
The Web Manifest format is JSON, but it’s totally different from the Chrome Extensions format. You can read up on it here: https://w3c.github.io/manifest/
Most of the metadata it supports is the kind of stuff you wind up repeating today to support creating shortcuts when you save something as a bookmark.
Thanks so much for writing up Navigation Transitions! SO excited to see what your readers cook up with them.
Regards
I’m still waiting for a <foot> (content below <body>) to store all those extra meta tags, as well as all the don’t-run-until-page-has-loaded scripts. But offloading the meta tags to a separate file could work, too.
I’ve used tricks to “stuff the DOM” but using data- attributes is now the de facto standard trick acknowledged by W3C noting the following useful insight:
http://caniuse.com/#feat=dataset
// use case
‘‘
let’s take another try to express that use case
<i data-[name]=”[value]”
data-[name]=”[value]”
data-[name]=”[value]”
…
>
I’m not 100% up-to-date on web animations, but the idea is to have a core API that integrates CSS, SVG/SMIL and pure JavaScript animations. It’s not a replacement for SVG animation markup, just an interface to control it.
In particular, the latest editor’s draft says:
In other words, SMIL support might be removed, but you would still have <animate> elements (and their siblings) in SVG. The SMIL specs are actually much more complex than what is implemented in browsers for SVG. It’s maybe more of an acknowledgement that existing SVG animation is a separate fork of SMIL, and allowing it to grow up independently (and move in with CSS and JavaScript in a big happy family called Web Animations).
As I said, I haven’t been following the discussion too closely, so if someone can correct me, please do!
Excellent read…very informative….
Those new meta tags in regards to page transitions just sound amazing…can not wait to try those out…
Does that theme colour change the colour of the browser UI ?
Anyways…thanks for sharing what you learned…
Michael!
Awesome post +1, From me
nice information its help to make more like material transitions for web app. here some webfont related to google material design. http://mirchu.net/material-design-icons/
Hey Google! You have “copied” my idea :P lmao
Or maybe I’ve copied yours, but I’ve used it before you… umh..
http://www.mywebexpression.com (click on one of the tails on bottom of the page)
Ouch. And that from the guys that tell us how important it is to minimize the number of HTTP requests for external ressources – couldn’t they find a better way to do this, like somehow extend media query syntax for this purpose (or basically anything else that would allow us to keep that within a single CSS resource together with the rest of the page’s formatting)?