(angelina fabbro) Good afternoon, everybody.

The title of my talk is The Return of Inspector Webb.

And the subtitle is, Web Components-- a Year Later.

As Paul mentioned, I'm Angelina Fabbro.

I'm from a very sunny place, Vancouver, Canada.

This is me on Twitter.

I haven't pushed the slides up to get hugged yet, but I will after the talk, I promise.

If you want to follow me I'll tweet them.

I'm sure that Fronteers will retweet them, because there are some links that I put together for you guys in here.

So follow for slides.

And also I make a joke that I do-- someone made this joke to me the other day, that I do panned evangelism, because there are lots of pandas in my stream there.

So, yeah, of course.

I work at Mozilla.

You might be familiar with us for one reason or another.

I spend a lot of my time these days working on Firefox OS.

I know there was a talk early this morning that talked about Firefox OS so it's not news for me to mention that.

Once upon a time at JSConf EU 2012 I gave a talk on web components.

And specifically I focused on Shadow DOM, which is the glue technology of web components.

And since then, when it comes to conferences, it's been pretty much the number one topic that people say, hey, we'd really like you to come talk at our conference.

Can you do something on web components? And I'm like, Yeah, but you guys I do other stuff too.

But they're like, no, no we really want web components.

And to be honest I'm not really surprised.

The technologies for web components have exploded in popularity, because they allow us to really change how we do things in the front-end.

So I decided that for Fronteers-- because this is approximately just a little bit more than a year since I gave that initial talk, it might be a good idea to do an updated talk with some more details.

This format is actually longer than the one at JSConf EU.

And give everybody an idea of what the current landscape is for these technologies.

What they do and what their current browser implementations are.

So web components are the new HTML5.

Probably most of the developers in this room, and people that will be watching this video later, understand that the term HTML5 does not necessarily refer to a version of HTML5.

Once upon a time, people made the argument to me that HTML5 stood for-- well, you know, it's a group of things.

It's HTML5, and it's CSS level 3 modules, and it's JavaScript.

And what they really were trying to say is that with these technologies and their latest incarnation we were able to build rich featureful applications in the browser.

So that's what HTML5 came to mean.

So web components are going through a transitional naming headache in the same sense.

Web components don't really refer to one specific technology.

They refer to a set of technologies that rather enable the creation of web components, which are modular, re-usable, ideally encapsulated blocks of code for building maintainable applications in the front end.

So shadow DOM, sounds kind of spooky.

How many people here are familiar with shadow DOM at least a little bit? OK, so it's like a third of you maybe.

I didn't want to make too many assumptions about the level of knowledge of the audience.

So we're going to go over Shadow DOM and other associated technologies.

So to begin with their shadow DOM, but we're also going to talk about HTML templates.

We're going to talk about HTML imports.

And we're going to talk about custom elements.

And we might even talk about decorators, which doesn't have a spec, but it's the explainer and I'm asked about it a lot.

So we'll touch upon that a little bit today, too.

So Shadow DOM, if you haven't heard about it before, it's the ability to take a document and hide it inside of an element inside of your parent document.

So if you imagine a page that has five divs in it, and you create one of these magic shadow documents you can hide it inside one of those divs.

And it has a lot of the properties-- in fact, most of the properties of a regular fully fledged document.

So you can add children to it.

You can manipulate it.

You can apply styles to things inside that document, or that shadowed document, rather.

But the knowledge-- like anything about that document, the parent scope, the parent document, doesn't know anything about it.

So if you were to have a shadow document hiding inside one of these five divs in your page, and that shadow document also contains some divs and you iterated over the parent document, the parent document would still only have five divs according to what your code returns.

So the key concept for what Shadow DOM introduces is it introduces a soft boundary of encapsulation.

I say soft because there are ways to reach in and reach out of these boundaries.

And also the important thing is that the rendering of a Shadow Tree replaces that of its Host Tree.

So I was talking about this host div-- excuse me.

I was talking about this host div that we may hide a Shadow Tree in it.

And I'm going to give you an example in a moment here.

When we actually insert things into the Shadow Tree the rendering of that shadow tree replaces the rendering of the Host Node.

And it's important to note that the rendering happens, but we don't actually replace the Host Nodes children or anything like that, just the rendering of them.

So the parent document doesn't actually know that this widget that you've styled is actually something else.

It kind of reminded me of this actually.

I love this.

Sir, are you aware that you're a cat? If you pulled the document that that div was actually secretly a widget for controlling the volume on your cool new music player.

The document would be like, well I can't see it.

So it's not there.

So let's use some examples with cats, right? So right here I have an unordered list of three cats, and they're pretty cool.

And so maybe a markup looks something like this.

I've got an honorary list of cats, and maybe I've decided arbitrarily that the second two cats are more awesome than the first cat.

Sorry first cat.

Look, he looks kind of sad anyway.

So I got this markup and I've decided to put classes appropriately on the list elements for the cats that I find more awesome than the first cat.

The next thing that I'm going to want to do is-- sorry the resolution here is a little bit tight.

So hopefully you can read that.

So I'm going to grab the element cat-- so that was my honorary list-- pop it in this variable cats.

And then I'm going to create a Shadow Root on it with this function here and store the result of that in this variable, Shadow Cats.

So Shadow Cats now contains my shadow document.

And then I'm going to set the inner HTML of that to this string right here.

So I've added my own list element, but I've also done something really interesting over here with this content tag.

This is a special tag that allows me to say to the Shadow Tree, hey, at this particular insertion point please grab elements from the host's children that match the criteria of the selector.

So what should happen here is the-- pardon me.

The list elements that had the class of awesome will be inserted at this point here.

So really what we should get back is only two cats.

And so we would get something kind of like this.

So that's all well and good, but let's actually do some more demo-ey kind of stuff.

So I haven't been able to enjoy too much of the conference, because I had some unfortunate illness.

But what I did do is in a fevered state I hacked up this demo thing.

So that you can actually visit it.

The top one there it's actually hosted.

If you are tinkering with it while I'm speaking, please note that the third demo will only work in Chrome Canary with the HTML imports flag turned on.

So if you click and it doesn't work that's the reason why.

And then the second link, of course, is just the repository with a disclaimer saying this is a fever produced code.

So that, you know, Douglas Crockford doesn't find it and hate me forever, because it's pretty bad.

But the point is that it works.

So let's actually go over to Chrome Canary.

So I did have a nice grid of three by three cats but that's OK.

We're going to remix some cats.

And so what I wanted to do with this minimal example is right now there are a lot of really cool frameworks and polyfills for all of these features, shadow DOM, HTML5 imports, etc.

But a lot of people, I've noticed, fall into two categories of developer.

On one hand some people are perfectly fine to grab something awesome like Polymer project, which we're going to talk about.

And that framework is basically web components plus some sugar and some things like modelled reviews, and it's really cool.

And they don't really care too much about what a really basic native implementation might look like.

But then I have other people who say to me, well no I don't want that.

I need to understand how it would work in a native implementation.

Like with just some bare bones.

Like 10 lines of code or less.

So the idea with these examples was that I could code up something short and sweet in a browser that does have the implementations in order to show how they work.

So Chrome Canary is the one that has the most support for these things right now.

But as we go through the presentation you'll see that other browsers are slowly catching up.

So what we're going to do is we're going to do something kind of like the thing that we were doing before.

We've got more cats to choose from this time.

So it says at the top here, what cats do you find lovely? Do you want to shout some out.

We've got like nine whole cats here.

Which one looks good to you? You like number six? It's got three cats.

That's a pretty good choice.

Seven? You haven't even seen seven yet.

You're just shutting out numbers now.

OK, let's pick three of them.

We've got six, seven, and nine.

And let me-- how do I do this in Chrome again? All right, let's look at the development tools.

All right, is that big enough? You guys can definitely see that? OK.

So let's take a look inside of my example one div.

It's going to highlight, of course, in Chrome as I go over these things.

Let's look at the unordered list of cats.

It looks pretty normal, right? Kind of like the markup that we looked at.

Nothing out of the ordinary there.

If we scroll down here and we click the choose cats button, however, something magical happens.

Suddenly there are only three cats.

And also this thing called document fragment appears.

And this here, my friends, is Shadow DOM.

What's happened here is you can see that the original host elements children, all these list elements, are still there.

But what we've told the Shadow DOM is please only select the cats that we've selected.

I have a little bit of JavaScript behind the scenes that adds these classes so that I can use the selectors later, and stuff like that.

You don't really need to know too much about that.

But the important thing is that we've inserted the Shadow Tree and it's rendering has replaced the rendering of its host.

All right, so that's the first example.

So a few things about these Shadow Trees.

There is a very interesting CSS rule that's specific to the context here of Shadow DOM.

When you use this at host rule for CSS from inside of a Shadow Tree this effectively allows you to reach outside the soft encapsulated boundary that I've been talking about and say, hey, I would like to style the parent-- or, pardon me, the host element that the Shadow Tree is contained in.

So in this case that would actually be the unordered list.

So, actually, if we applied the CSS back here, display block, some padding, and border.

We would get something kind of like this.

The awesome cats are, and we would get a purple border around it.

And so there are also some other cool things have been introduced at least since a year ago when I was first talking about this material.

There's been some interesting pseudo elements to allow us to give-- to have more styling control and more selection control.

So, for example, there is content.

And if you've been following the evolution of the Shadow DOM spec-- It's actually a spec that's very much in flux right now.

If you compare the editors draft with the current working draft they're very different in a lot of ways.

And one of them is that if you look at the working draft it'll have a distributed sort of thing, but actually it's moving towards this content here.

And so what this will do is this will take all of the elements that are descendants of an element that is distributed at an insertion point-- so at those content tags we were talking about.

So, for example, the one on the bottom there should select all of the list items that have the class awesome at a particular content insertion point.

So that's actually pretty cool.

The next one is part.

Now part I really like, because it essentially allows you to create your own custom pseudo selectors, in a sense.

So if we have a-- pardon me.

If we have a div and we assign it to a variable component and then we do something similar to what we did in the last example and we create a Shadow Root on component and then assign it to Root and then we also create another DIV.

Like let's imagine a situation where we are creating our ideal music player kind of widget.

We want some element that's going to be a control so we create another div there.

By setting the property on control of pseudo and giving it the string of control, and then appending that to the Shadow Root, and then of course we assign-- we pend that stuff all to the DOM.

We can actually do something like this.

We can say component and then reach in, looking for the part that we happen to have assigned the pseud of control to.

So that actually gives you a lot of power actually, because from the parent style sheet you can reach in-- and that's you traversing that boundary again-- you can reach in and style things inside of your Shadow DOM Tree.

And if this looks familiar it should because using browser prefix pseudo elements like this we've been styling things on the HTML video element, and the range slider for quite some time to try and get around the native default styles.

So this will give you a lot of control over those details there.

So Shadow DOM Browser Support, the part that everybody really cares about.

Firefox, soon.

We don't actually have it yet.

But we have some of the other features, I promise you.

And actually a short while ago we had the Mozilla Summit in Brussels and I was very fortunate to grab a bunch of people at Mozilla together.

Some who are people that are spec maintainers and writers and some people who are actually platform implanters discuss like, OK, what's going on with some of these specs? And OK, why haven't we implemented these features? Because people really seem to want them.

And so we got together and a general hoorah was had that, yes, we should be working on this.

And so I made sure I'm CC'd on all the bugs to do with web components now.

To know when, and if, they got implemented so I can light a fire under someone's butt.

Because when I'm actually out there talking about just Firefox OS people actually want to build Firefox OS apps using these technologies.

It's not just limited to desktop.

And it's not just limited to the existing context that we're used to, but actually this new platform.

People are already looking for these things.

And so I understand not just my own enthusiasm for them, but that other developers want them as well.

So I'd like to push for that.

And Chrome actually has had this in Chrome Stable for a while.

In order to see the Shadow Trees you still have to go into the developer tools and turn on show Shadow DOM, but it's there and stable.

And it's there for you to use.

Internet Explorer? Don't know.

If anybody watches this, or as in the audience, and knows someone that I can talk to at Microsoft about this I am still totally in the dark to do with Internet Explorer.

Now you may notice that I'm omitting Opera.

Opera is now using the same rendering engine as Chrome, which is blink.

So should work just fine over there.

And I'm omitting Safari, because they kind of fall into the same category as IE.

Like, I have no idea what they're doing and they are kind of a closed black box.

I don't really know who we could ask there.

If somebody else knows that please tell me, because I would love to be able to communicate this information to developers.

And Safari, being that it's web kit, theoretically has the ability to expose this stuff to developers.

And I don't really know why they haven't yet.

I mean it seems to be the way forward.

Maybe they're waiting for the spec to firm up.

I don't really know.

So HTML templates, they look a little something like this.

So we've got some more cats, because that's going to be a recurring theme here.

And what a template is is it's essentially a piece of inert markup.

And so what happens when the browser encounters a template is it will be passed but not rendered.

It's not rendered and it's not alive, as they say, until it's injected into the DOM later.

So what we can do is something like this.

We can grab some element, let's just call it host in this case, and again give it a Shadow Tree.

And then all we have to do is append the content of that template to it to bring that live.

And then the rendering of that templates content in the Shadow Tree will replace whatever was in the host.

So let's actually go back to the demo again.

All right.

So my second demo here.

Let's append some cats using a template.

So if we go all the way to the bottom of my demo there's actually a template here.

And you'll notice that Chrome is quite clever.

Chrome-- So the template tag, which I was going to get to in a moment, is actually implemented in Firefox as well.

But because we don't have Shadow DOM support yet we don't quite get the same document fragment and the boundary of encapsulation that we would get here in Chrome.

Chrome is actually doing it the way that I would expect, and that's that there's a document fragment which contains all the stuff in the template.

I would want that to be encapsulated, et cetera, et cetera.

But anyway, here's a template that I've just appended on the bottom my document.

If people have used like handle bars before and normally will use script tag this is essentially client side templating that's designed to replace that.

We don't need to do those hacks anymore it's going to be built right into the browser, which I think is kind of a relief.

So what's actually going to go on here is up in example two I have the div-- It's an empty div called future caps because there's no caps there yet.

And if I click this button append cats-- Bam.

I got another div.

And there is my document fragment with my cats, which if you look inside the very bottom here in the document fragment-- Oh, it's gone now.

In the document fragment the style will actually have dash blue just to verify that it's actually the template that I was using.

So that is simple use of HTML templates.

And now the cool thing about HTML templates is that-- Oh, you know what? I actually got this one wrong.

Chrome does have-- Oh, no, sorry. style scoped.

So you may have noticed in the last example that I was using style scoped.

This is a particular attribute that will make it so that if you declare some style within an element the style should only apply to the children of its parent or host element .

So the style should only apply to whatever is inside that template tag.

And what I was going to say here is as far as I know style scoped is only implemented in Firefox.

It has been since I think 22.

Chrome, I don't think so.

There are Chrome people here that could correct me on this if it has been recently.

And IE, again, I have no idea.

As for HTML templates Firefox has support for this, Chroma has support for this, and you're starting to see a pattern here.

Internet Explorer, I'm sorry, I don't know.

So the next thing that we're going to run into is HTML imports.

So we all know how to include style sheets in our document.

Wouldn't it be pretty awesome if we could include our templates and markup the same way using something like this? Well thankfully people that are writing W3C Specs and figuring out what fantastic browser features we should ship also thought that too.

So now we can do something like this.

I can include some HDL HTML and it's basically like-- if you've programmed other languages it's like pound include for the web.

It's very much like that.

And so if we go back over to my demo here we're going to view the source of-- this is an external document to my demo.

And it's just another template.

And I've given it a different ID.

It's import cat's template.

And the difference is really that there are some different paths and that the border here is green instead of blue.

So that when it gets appended to the DOM you don't think I'm making things up.

But if you go back over here at the very, very top you can see in the head that I've got import cats there.

Ha ha.

Just right underneath my style sheet.

No funny business.

And then if I click Import cats-- Ka-blamo, there's more cats.

So it's as simple as that.

And the JavaScript I've got going on here is very heavily commented.

The idea is that this is not the most elegant piece of JavaScript, but rather it's supposed to be used as a teaching tool.

Like I've got all my variables on different lines.

I'm not using Strict mode.

I wanted something really quick and dirty that could give someone an overview of, oh, this is all it is.

So if you want to help me with this, or you have additions or ideas, please help me.

Like I said, I coded it in kind of like a post fever dream kind of haze.

So any input is going to be great.

But that's essentially HTML imports.

They're very really quite simple.

And that was me going to the demo already.

And so, yeah.

Browser support.

Firefox, soon.

Again we don't have anything for HTML imports.

Chrome has it but it's behind flags.

You have to go into-- I guess it's about flags, or Chrome flags, and it's under HTML imports.

And it's pretty easy to find.

And IE, no.

So now let's talk a little bit about custom elements, which if you've used something like angular already, or if you are familiar with the Polymer project, or if you've been following web components, you definitely know about this already.

I think that angular as a framework has definitely gotten the most attention for extending the DOM, which is very much an idea that's been borrowed from web components.

So custom elements.

Custom elements can be used kind of like this.

And we'll look at another way that can be used in just a moment.

But essentially custom elements are allowing you to create your own DOM elements, or extend existing ones.

So you might do something like this-- Oh I have a typo here.

This should not be X it should be my widget.

So just pretend that that says My Widget and that I didn't do that.

So what we're going to do is this document register function, which we'll talk about in a moment and it's implementations status in browsers.

Are we're going to register something called My Widget.

And then I'm going to append a child and new My Widget.

And it will create a new custom element for me.

And the interesting thing about these widgets as you create them is that their default prototype is the HTML element prototype unless you say otherwise.

And so what I wanted to make clear is that actually this top line here is essentially functionally equivalent to what's going on here.

If you just omit this it will automatically-- or should automatically just be like, OK, you're going to be an HTML document.

So custom tags versus type extensions.

Now there's a couple ways that you can actually create a custom element.

This one here you can actually do document, create element My Widget once you've actually registered it with the document, or you can new My Widget.

But the other way is actually just to do this top one here.

Or you can actually do this bottom one here, which actually last time I gave a talk on this I talked a little bit about marking things as is.

But I've actually come to really appreciate the top approach a lot better.

And the difference here is that the top one is using a local name.

We would call this actually custom tags.

The bottom one where it's using the is attribute for custom elements is essentially what we would call a type extension.

And one of the questions I had last time I talked about the stuff was, hey, so after I've instantiated my element and it's there in the DOM what happens if I change the is attribute? Nothing happens.

Turns out that's a terrible idea and if it were to have consequences it would be kind of crazy.

So that actually can't be changed after the fact.

If you were to change it it would, and should, do nothing.

So one of the interesting questions that came up is what happens if the browser encounters one of these custom elements before the JavaScript that registers it has been run? That's a very interesting question.

So the way that the browser is supposed to deal with this, according to the spec, is that it gives it a pseudo class of unresolved.

And then when that element has been correctly upgraded by the browser into its custom element status that pseudo class is removed.

So this is in consideration of what we all may know about already, the flash of unstyled content.

So if your page starts rendering and for some reason your JavaScript gets blocked in some way and that registration of your element is not there yet.

Then those elements just will not show up if you tell them to.

So here's some CSS that could possibly use to deal with this.

You've got My Widget unresolved, opacity zero.

And then when that pseudo element is gone then you transition it in and it's visible again.

Similar to the kind of stuff that you do a lot of the time when you're dealing with web fonts and the time it takes to load those.

So browser support for document register.

This was like a the more you know moment for me.

You know that start thing-- About the last day or so.

Because as I was putting together this talk I actually learned that document register is available in Firefox behind flags.

And it's also available in Chrome behind flags.

I actually went looking for it in Chrome under the suspicion that it was available behind a flag, but actually it's under one called experimental JavaScript something.

I'll have to get back to you on that.

And then Firefox you actually have to set a preference somewhere.

I actually only found that out this afternoon.

I was like, oh, that was super non-obvious.

But those things are already in browsers and they're under experimental flags, which means that hopefully they'll be progressing to be in more stable versions and be accessible for the everyday developer and ready for production.

And Internet Explorer, no.

So more on custom tags shortly, because we're going to talk about libraries that make use of custom tags.

And really the templates and the Shadow DOM which is the glue and the encapsulation, all of that stuff is really, really there, in my opinion, to make things like custom tags.

I want to be able to give my widgets an awesome local name.

Have all, or most, of the logic pertaining to them all in one place in the styles and stuff like that.

This is the fantasy world that Angelina lives in.

This is what gets me to sleep at night, that this could possibly be a reality.

One of the things I wanted to mention was the element element that we talked about maybe last year has sort of taken a nap because of some problems.

That particular thing that you may have seen in the spec before has been removed from the spec.

And I was considering maybe going into some detail about why the element element was removed, but I wasn't sure that was going to be really exciting for everybody here who doesn't necessarily care about all the spec stuff.

So it's been a roof from the spec, but that doesn't mean the custom elements are gone.

Obviously you've seen a imperative way that we can register them, and use them.

And people are using things like angular and Polymer no problems and also X-Tags.

So I think we're OK for now.

And maybe that'll be something to come back to.

So obligatory mention, when it comes to web components, is decorators.

Every single presentation that I come across always omits decorators.

And I totally omit decorators too, because this is a browser feature that exists in the web components explainer but does not have its own specification.

You know the specification writers been focusing on-- what I think rightly so-- are some of the more important features things like shadow DOM, templates, imports etc.

And this has been side stepped.

It's an interesting idea.

But I'm going to go over it because I do get people asking me a little bit about it.

Because it's only in the explainer I should warn you that any questions about decorators I might just be like, hmm, don't know.

Because there is really not very much information in it.

Or I can show you exactly which list to direct your comments to.

So, for example, we define a decorator something like this.

We've got a tag called decorator.

We give it an ID, and inside that decorator you see something very familiar.

You see that there's a template tag and within there we've got some content points.

So you're looking at this and wondering like, OK, great.

What's it for? A decorator is a way of specifying and applying presentational markup.

So whereas custom elements give you a encapsulated widget that can have state and other properties that are really helpful to you in designing interactive application.

Decorators are just there for the pretty.

That's it.

So they use a lot of the same features but the end outcome is not something that has any state.

So when a decorator is applied to a host element you can see the same thing would happen here, it's going to say, hey, the child of my host element that has the summary, the selector summary, I'd like to insert that content here.

And I'd like to insert all the rest of the content here.

Something that I didn't mention earlier is that if you do have a content insertion point and you haven't selected something specifically, just all the children, all the children of the host element will go in there.

So that's a way to specify what goes where.

And so apparently this is how decorators are to be applied.

Details opened with square brackets-- and this is in CSF now, to be clear-- decorators, although HTML seeming markup, are applied via CSS.

And what we do is use this decorator property here and assign it a URL that we give an ID to.

I know it's kind of weird.

I've had mixed feelings about this, because on one hand I feel like mixing CSS and using it to apply HTML kind of like rustles my jimmies.

But at the same time someone made the argument-- that was that funny, eh? It does rustle my jimmies.

because I just feel like, you know, CSS, presentation, and then market-- but someone did make the argument the other day that, well, CSS is there to specify presentation and if you're specifying presentational markup doesn't it belong there? And I'm like, OK, maybe.

So this is still a little bit weird to me, but this is what's in the explainer so far.

And then what this would happen is when things actually get rendered you'd end up with something like this.

You'd end up with details open.

And open would be the decorator being applied.

And then you can see that summary was inserted here and then an unordered list kind of like this here.

So if we go back and we take a look at the original markup we can see that we're creating a link with that content there.

And that there should be an arrow next to where summary appears.

And then there's a content.

And if we look at this here we see that it actually inserts an unordered list.

And it should render something kind of like this.

So maybe you have an unordered list and you can use decorators to give it all this presentational markup without having to add extra stuff to the DOM.

So this is just a happy little chart that I actually-- I actually took this decorator's example, directly from the explainer and this chart directly from the explainer that sort of gives you a little overview of what decorators are to be used for and what custom elements are to be used for.

Because the major differences are that decorators are a stateless production and custom elements are actually like a proper stateful DOM object.

So there's some important differences there.

Because when I first heard about this a year ago I was kind of confused.

I was like, well why would I need two versions of custom elements? Decorators kind of sound like those.

But actually after learning more about it I came to understand their relevance.

Right, so now the exciting stuff.

I introduced the state of things being implemented-- Oh, and the reason why there is no slide for implementation here I hope should be obvious, because no spec no implementation.

But now we want to talk about the exciting stuff, right? Like polyfills, and libraries, and frameworks that make it possible to actually play with this stuff beyond just being able to go into Chrome Canary and turn on some flags and be like, woo-hoo this is great.

But we're all practical web developers.

And we want to be able to do practical stuff with these things.

I would like to be building my applications with these technologies.

So there's a few different libraries and things to consider.

So last year when I gave a talk at JSConf EU I talked about how Dimitri Glaskov, one of the spec writers, had come up with a pollyfill that I was using actually in that demo when I was live coding and showing how Shadow DOM works.

But that has been superseded by the work done on the Polymer project.

There are a lot of people on that project who have done some excellent work polyfilling so that it's a cross browser compatible.

And we're going to talk about Polymer in just a little bit, but if you want to use a polyfill just go use theirs.

And actually more to the point, X-Tags and Brick, both Mozilla projects.

X-Tags originally had its-- X-Tags was an implementation-- or is an implementation of custom elements, had it's own polyfills.

But actually now Polymer and textiles are sharing the same pollyfills used by Polymer.

And the idea here is in the spirit of open source we should be collaborating.

And the idea is that if we're using the same polyfills-- I mean same bugs for both libraries kind of thing.

Fix them in one place.

So Mozilla and Google are trying to collaborate, of course, and make sure this is an easy experience for developers.

We don't want things to be broken in seven different ways when you're trying to get on board with this stuff.

So one of the libraries-- and the one that I like because it's actually quite minimal, and not just because it's a Mozilla thing.

I liked it before I started Mozilla, just as a disclaimer-- Is I like X-Tags and Brick a lot because it's not an opinionated framework.

Essentially X-Tags polyfills custom elements and Brick, which was recently introduced.

Brick is just a set of widgets.

It's basically repository of widgets that are built on top of X-Tags.

So if you want like a date picker-- If you want an app bar-- And Brick is very much tailored towards mobile application development.

When it comes to Firefox OS we get developers asking us for more tooling.

And they want to know what frameworks we think works best, but actually we're trying to be as agnostic as possible.

Because that's just sort of how we do at Mozilla.

So we decided to develop Brick because it's not a full featureful framework but it does give people these building blocks to rapidly prototype applications .

And that's really what it seems like a lot of people are looking for.

So if I pop over here to-- I wanted to go over here and show you.

So this is actually the X-Tag's website at xtags.org.

This will just give you a little bit of a background.

This is the core of what's in Brick.

So xtags.org is where you

can find the X-Tag core if you don't want to use any of the Brick components.

And it's cross-platform compatible, which is pretty fantastic.

And, as I mentioned, it's using the same polyfill that Polymer is using.

They're sharing the same stuff behind the scenes.

And this is actually the Brick website.

And I decided to show the date picker widget as an example.

But all you necessarily need to do here is include the state picker markup and it allows you to set certain properties, and stuff like that.

And essentially you get something like this.

So it's a really nice date picker and it's all just totally hidden away for you in there.

And actually the documentation for Brick is actually pretty good.

It tells you how to do a lot of different things using polyfill, listening for date changes.

And so Brick is actually pretty fantastic.

One of things I like about Brick-- as a library-- that they do that a lot other places don't, is they allow you to build your own bundle.

Which I think more and more libraries should let you do.

Because I don't just want to click once and have everything.

I totally want to choose what I want for lunch.

I don't necessarily want the whole buffet.

So you can actually decide which of these components that you would like to use there.

So that's X-Tag and Brick.

But if we go back to the presentation for a second it's actually very simple to use.

All you got to do is include-- ha-ha! Some Brick CSS, which will-- if you've selected some Brick components there will be some CSS.

And the philosophy for Brick has always been, don't provide pretty CSS just provide the foundational, structural CSS so that things don't look totally like crap.

Because like you say, we're trying to be a little bit unopinionated here.

And then we've got the JavaScript which takes care of registering your elements for you automatically.

So that all you need to do is go bam! I want a date picker right there.

All the hard work is actually done for you.

So then there's the Polymer project which is actually pretty fantastic.

So the Polymer project-- Like if X-Tags is just a library that gives you some foundation and the polyfill for custom elements.

And brick is like a set of literally bricks, building blocks.

And one of the major differences between these brick building blocks and the kinds of things you can build with Polymers.

Polymers kind like web components plus a lot of sugar.

They provide extra, extra features kind of like model driven views, which if you're familiar with the two way binding that happens with things like ember and angular, you find modeled driven views to be very comfortable.

And things like pointer events and-- Pardon me.

And things like that.

So it's a really it's like web components with sugar.

And it's very simple to use, much like Brick.

And so I would actually say that one of the main differences between Brick and Polymer is that Brick does not have two way bindings like Polymer does, or angular does, or anything like that.

It does not have any opinion on how you pass your data between your model and your view, etc.

Where as Polymer is actually-- you're signing up to participate with a framework.

You don't necessarily have to use all of the features.

That's definitely true.

You can take the polyfills and just use those.

But to get the most out of it it's been structured in such a way that you get all of this nice stuff.

And it's actually become quite popular for doing such a good job at that.

And so I mean similarly you'd do something like this.

You'd load Polymer-- And unlike X-Tags where the JavaScript takes care of all the registration stuff for you, you actually need to import a template here.

Whereas you don't necessarily need to do that all the time for X-Tags.

And then you can declare a component by its tag similarly just like that.

Bam.

This is actually taken right from the Polymer website.

I feel like I should say that so that I'm not like, you know-- but, yeah.

That's from there.

And something to consider though when considering all of these frameworks is that Polymer is 168k.

I took Polymer minified and it was 168k-- this is from last night-- for reference, angular, and other popular framework, which does let you extend elements, 81k.

X Tag, 63k.

Now another difference between X-Tags and Polymer is X-Tags actually does not have full Shadow DOM support in it.

The maintainers of X-Tags, just because Shadow DOM is changing so much and hasn't been fully implemented like all the browsers-- They're kind of eh about what they want to do about it.

So it's been left out.

So Polymer is supporting everything.

And they've got model driven views, and they've got pointer events, and so it's a big.

And the reason why it's so big is that's the price of compatibility.

And being able to-- pardon me.

Being able to support all of these things back to IE9.

So if it's big and that's scary, I know.

But I still think you should play with this stuff anyway.

And, in the future, in my ideal situation these things will all get smaller.

As more and more of the browsers actually implement features these should get smaller and smaller.

In fact, in an ideal world a lot of the features that these share in common should become standard.

And eventually some of these things may not even exist.

And maybe that's good because their common use patterns and we should standardize them.

I don't know.

Just an idea.

So an obligatory mention is actually angular directives.

Angular has been doing stuff that's kind of like web components already.

In fact, both Angular and Ember, if you read their docs, talk about how they are very much inspired and influenced by the specifications of web components even if they don't necessarily use all the technologies yet because they're just not ready.

So you'll see like as the second example here you can create a custom element any number of these ways here.

But the second one is very close, right? Like that's basically what we're doing in the spec.

I think most people-- I think a lot of people I know with Angular are probably doing this third one.

Because they're practical web developers and they've got to be compatible with IE.

But if you look at how directives are set up it's very similar to how you would register a custom element.

And so that's an incredible amount of foresight for the designers of this library, because that's going to make transitioning into using document register fairly simple really.

So that there's not a lot of work that developers have to do in order to transition their applications.

And then obligatory mention is Ember Components.

I don't know too much about Ember.

But someone did point out to me, like the spot in the docs where Ember had said, yes, we are trying to be on board with web components.

And they have some capsulated component like things as well.

So that's a number of really popular frameworks that are all using these design patterns.

So why isn't the stuff implemented in every major browser yet? Well so it's tricky, right? Because it's a balance really.

We know-- working in a browser vendor I've come to understand that we know that developers want these features but it's a balance of time and resources.

And it's very difficult for browser vendors to go ahead and implement stuff that's not necessarily all that confident in its specification yet.

Because I know that it's sometimes really easy for us to just hack together a project and then iterate on it.

But when it comes to browser vendors the implications of that are quite profound.

They change the platform that allows us to shape the web.

And we've also got limited time, and resources, and money.

We can't necessarily pull people off of a project to work on stuff like that.

So what you need to understand is just be patient, because the more and more you guys get behind this and the more and more you create frameworks and give feedback to the document-- or Feedback to the specifications that this is what you want.

I assure you that browser vendors are listening.

And I know that, at least with Mozilla especially, we are going to be pushing for that.

I would like to give another talk like this in a year and be able to say, yes, a lot of the major rendering engines out there now support this stuff.

And it will be happy.

And there will be cheers.

And then we'll go have drinks.

And it'll be awesome.

So one thing I want to mention is I was talking about specifications.

The reason why I give this talk is because I have a weird perverse need to go read through all this dry stuff.

And not everybody does so I like to give these talks because I kind of feel like I'm acting as sort of like a translator.

Because I know people are curious to know what's coming, people who really want to stay on the bleeding edge.

But not everybody wants to read through the specification documents.

You've got to understand that they're not written for you.

They're not written as user manuals.

They're written for the implementers of the platform to tell them exactly what algorithms so that we have interoperability between different platforms.

So that you guys don't have to go and fix all sorts of cross-platform bugs.

And so the extensible web manifesto is a group of people that have all signed on with the idea that we want to tighten the feedback loop between developers and spec writers.

And so if you identify some patterns in development we want you to come and give feedback.

Or start prototyping out a specification of a feature that you would like to see.

Keep in mind that if you do do that though what you want to do is be able to prove your use cases though.

You don't just want to show up and be like, hey, hey I've got like cool feature X. No, you've

got to actually show this is something that a lot of developers are already doing in the wild in order for people to take you seriously, and with merit.

Because, as I mentioned, implementing these things in browsers takes time and money.

And that's not something that we can take lightly.

OK, so before I go, something awesome.

So as for things that are really cool that have been built with web components-- where did I put this here-- this thing.

OK maybe I've got to refresh this here so that it re sizes.

Or maybe it's not responsive we'll find out.

Nope.

(a little bit broken at 10)24.

Sorry, sorry.

So what this is-- This is Mozilla's app maker.

This is a tool that started off as a toy built using web components and Brick type components and essentially it's a drag and drop app creator.

And this is actually pretty fascinating because what I can do is I can add all sorts of widgets and then what I can do is I can create more views.

I can add another card.

There we go, go back to widgets.

And where's that fireworks one? That one's pretty awesome.

I'm going to do fireworks.

Add like a button going on there.

Aw, the fireworks one is kind of hard to see.

But if I click that usually it will fire the fireworks.

So I recommend flathead.herokuapp.com

and I think we actually have an official Mozilla URL for it now.

But this is pre-alpha.

View it something that's not 1024 by 768 and play with it.

So this was developed because someone wanted a side project with web components.

And now it's turned into actually what we're going to use as a tool for people to build mobile applications with, or at least prototype them.

Because if I click this publish button up here-- which hopefully I can get to, nope-- anyway the Publish button will actually give me an install URL.

And if I visit that install URL on a Firefox OS device I can actually install that application and test it right away.

The feature that I'm pushing for, of course, is the ability to be able to export code.

Because once I get a little bit far with prototyping my application, of course I'm going to want to be able to have more control over the code.

I don't want a complete whizzy wig editor.

I think that's a bad rabbit hole to go down.

But I do think that's actually really promising.

Because when we have developers coming from paradigms like IOS and they want to start developing for the web and they're familiar with things like Interface Builder I'd love to throw them at something like that.

And it's also really cool that it was built with web components.

So I'm going to post the slides online but I've collected for you my favorite resources for web components.

And so it's got the explainer, it's got Mozilla's app maker, X-Tags, Brick, Polymer Project, Shadow DOM, visualizer.

The bottom five are done by Eric Bidelman, who's done tons of really awesome writing.

If you read those last four articles on Shadow DOM web components you'll be more of an expert than I am, I think.

And so there's some really great resources all in one place for you.

So that's really it Fronteers.

Thanks a lot, and yeah.

[APPLAUSE] (paul) Who is that back there? (angela) don't know.

It's just some guy.

(paul) That's awesome.

I love it.

Mustache.

(angela) sparkles and stuff.

(paul) And sparkles.

Awesome.

That was great.

There was actually a few inquiries about accessibility.

(angela) Right.

(paul) So I was wondering if you can answer what the state of the accessibility is in the context of web components, brick, and all that.

(angela) so my understanding when it comes to accessibility for things like Shadow DOM, right? Where you're comparing the Render Tree to the Host Tree.

Is that the browser-- pardon me.

Screen reader should be able to crawl the Render Tree so the-- I always forget how to pronounce this, Wai-aria.

W-A-I dash ria, specification stuff should have no problems.

This was actually a really big concern for me too.

I had a lot of people asking questions about that.

(paul) Cool.

That's good.

This is actually something that I've been wondering about myself.

How can we keep the number of file downloads to a minimum with a lot of web components? (angela) what people are doing right now is they're concatenating templates onto their one main document.

And until I feel confident that HTML imports have been worked out sufficiently to mitigate that sort of stuff that's probably what I'll do.

I like the idea of a HTML imports, but it's kind of a rabbit hole because you can have an HTML import and then inside that HTML import you can import something else.

And then guess what? From inside that import you can import something else.

Now I don't think that any reasonable developer would want to do that, but-- yeah, if you want to load in 10 widgets that's the overhead of 10 HTP requests and I don't want that in my applications.

(paul) Yeah, I've seen-- I think one of the developers on the Polymer project worked-- created a tool called Vulcanizer, which is designed for this use case of squashing everything down to a single resource.

(angela) Yeah.

(paul) And even Addy Osmani did a combination of Yeomen plus Vulcanizer to kind of work that out.

(angela) Yeah (paul) I think that's-- finding a performing way of delivering these is something that everyone wants to figure out soon.

(angela) That's been my go to recommendation is, if I have a number of templates that I want to grab and just cash and have around for later then I would love to have some sort of like logic for deferring it.

Like if they're not crucial that would be fantastic.

And even if I do differ it and I have a bunch of them I'd probably want to quash them all into one file for one request.

(paul) Yeah.

Yeah.

Does appending many templates into a document have any impact on the rendering time or rendering performance? (angela) I have no idea.

(paul) Actually I got this question and I was like-- I tested it out.

(angela) Did you test it out? (paul) Yeah.

(angela) Oh well you tell me then.

(paul) Yes, OK, I will.

It doesn't.

(angela) It doesn't? (paul) No.

(angela) Oh, sweet.

(paul) Yeah.

So the template tag is hidden.

It's invisible.

And it's also inert.

And the inert basically means the browser ignores-- you know, when you throw it into the DOM the browser ignores everything that's inside of it, right? It just treats it like the script, script type equals-- (angela) Handlebars, or whatever it is.

(paul) And so it's just straight up ignored.

And I tried it out basically injecting a template tag into a DOM there's no additional layout cause whatsoever.

(angela) That's really interesting.

I actually would have thought otherwise.

Wow, that's-- (paul) Yeah, so it's a bit like-- sometimes you're like, well if the browser is smart enough it would figure out.

And about half the time it's like, no, browsers a dumb.

Then half the time you're like, oh, they did it right.

(angela) All right, I like that.

(paul) And this time it's good.

So we're good.

(steve) [INAUDIBLE] (paul) What? They do what? (steve) [INAUDIBLE] (paul) Ah.

Steve Souders points out they do block rendering if you reference them from JavaScript.

Definitely like a link roll web component it's going to block.

Yeah, sounds-- we need like a big guide-- performance guide on kind of what-- (angela) Yeah, well I mean this all this stuff is so new, right? Like I get a lot of questions about performance and about accessibility.

Those are actually probably the two main areas I think that probably need more documentation and stuff written, but all this stuff is so new.

(paul) Yeah.

Last question, what are jimmies? And how do they get rustled? (angela) I don't have that animated GIF.

I don't know.

It's a phrase that means like getting worked up over something.

(paul) Yeah.

Seems like-- (angela) Jimmies are rustled.

(paul) My jimmies all rustled up.

(angela) Yeah, exactly.

See? You know what I mean.

One person in the audience cracked up.

They knew what I meant.

(paul) All right.

I like it.

All right, thank you Angelina.

(angela) Great.

Thanks for having me, you guys.