Web Components and Model Driven Views by Alex Russell
[0:47] I'll give you a for instance. One of the things that we're hitting right now with some stuff I'm going to show you in a bit is performance issues around mutation events. Who knows what mutation events are? OK, I'm sorry for your loss. Mutation events for those of you who didn't raise your hand are the spec that's been around probably since the early 2000s that allows you to add an arbitrary listener for any time anything in the DOM changes. Sounds pretty awesome, right? You can make some really high fidelity synchronous abstractions with mutation events. That's good stuff.
[1:21] They sound like a panacea, right? You want to build some framework that's going to attach itself to every new element that comes into the DOM that matches a particular selector. Well, just listen on that change, and then go create a DOM, find that element, and then go make your change. Well, yes and no, because the more you do this, the more synchronous it is... Let's say I'm adding a bunch of elements. Now I have to run this code every single time. It winds up being aspect-oriented advice on every synchronous operation in your DOM, and it can really screw you.
[4:02] So we don't want there to be technical lock in, we don't to have any runtime risk. We don't want it to be too slow to actually use. We don't want to find ourselves on the wrong side of business or economics. We want our feature to survive, so if that we start to use it or rely heavily on it, we can trust it. It's worth asking, who are these things good for and why?
[4:23] Markup is good for developers, and it's good for publishers and users. This is sort of like the grand triumvirate. If it's good for developers, if it's good for publishers, and it's good for users, it's probably good for you. Then we look at CSS and CSS is good for designers and it's good for developers. CSS can help users, it can sort of by the by help users, it helps you structure your stuff better, but it's not like a first-order user visible feature. It doesn't deliver mean value to users all of the time.
[5:28] I want to bring up, as maybe my example of the Platonic ideal of a new web feature, the humble anchor tag. The humble anchor tag is all that and a bucket of chips. So the humble anchor tag gives us the ability to define relationships. These aren't strong relationships, they're not as heavily defined, but they are relationships. The text inside my anchor means something with regards to the thing that I put on the outside. It probably means something in context to the other text around it. It relies on the browser to give you default UI. I can configure it through that other aspect, right? I can go to CSS and I can configure all of those roles and states around anchor tags. I can style it using selectors.
[6:44] The odds are that you would end up with a very finely tuned solution to your specific problem. You wouldn't come up with a link tag. You would not come up with an anchor. This is not what you would end up with, because this doesn't mean exactly what you were going to say. If I want to open this in a new window well, now I have to configure it. I have to come up with some other thing. Well, I would have just written a little bit of code to just open up in a new window, right?
[7:04] I would not have made all of these nicely layered configuration and relationships hang off of what's really a pretty rough semantic here. This doesn't mean very much. This is how the entire web works. Right? This is what Google sees. This is how we express all of our intent, but it doesn't mean a lot.
[7:23] We want a lot of things out of new features, and it's worth asking, "Who are they going to be good for?" Right? So ubiquity is really good for us as developers, it reduces a lot of our risk. Performance is great for us as developers, but it's primarily useful for users and publishers. They're not going to adopt stuff unless it works well.
[7:42] We want high level semantics, which are good for users, developers, and publishers. So if I have a high level semantic, it means that, well, we can all sort of get along, where I can kind of agree. I can say that this thing is an anchor and it means something both to Google and it means something to my page too. We're all getting value out of that. Declare it as configuration, lowers the bar to entry for a lot of features, and then extensibility gives us this big out.
[9:09] OK. We decided that what we want are things that look a lot like the anchor tag. We know now that when we go and we add a new feature to the web platform, we want it to be available everywhere. We don't want to really have to go through this process of sort like, figuring it out. "Can I actually step there, am I going to fall through?" We want the browser to give us this default UI. There's a good default something that you can provide for free, something that I don't have to send down the wire, do it. Just put it there for me by default.
[9:40] We want it to describe relationships between content. New features, semantics aren't just there to sort of help us feel good about having said something. They're there to express relationships between the sets of things that we're putting in our document. I think this an important and often lost point. We spend a lot of time talking about how many angels fit on the head of a div, but the role of semantics is to express the relationships between things in our document. They have to mean something to the systems that are going to consume them, but they only work really well when they also mean something to users.
[10:11] The anchor tag is perfect here, because it means something to the user. It gives us something that the user can do, it expresses our relationship, and it lets the browser handle most of the default for us for free. This is where all new features sort of want to be.
[10:25] How do we get there? I think this is the important question. This is the Chrome adoption curve from Ars Technica from August, I believe. The end of August. So what we're looking at here is Chrome 13 eating into Chrome 12, which was eating into Chrome 11, Chrome 10. The steepness of these lines is actually changing because they're only sampling once a month. These lines would be roughly about the same angle if they were sampling more frequently. How good is it that you're watching browser replacement rates that are affected by the sampling size at once a month? You're getting sampling rate error.
[11:00] But this is one of the things that can help us move things forward. If we think about the web evolving, we didn't get the anchor tag, we didn't iFrames working correctly everywhere, we didn't get the frameSet working everywhere. We didn't get form elements working everywhere. We didn't get most of the stuff that we take for granted today, CSS working everywhere, without a couple of revisions. It takes browsers time to implement stuff. We have to get it out to users, now users have to start using it, and then we have to look at our deployed population and go, "OK, now I can use this feature, I can target this feature."
[11:32] So as developers, this is the sort of things we thrive on. The faster that this crank turns, the more chances we get to see new features enter the market that we can start to target. "OK, well, this is good."
[11:43] Chrome's a relatively sizable chunk of your user base, probably. New sites specifically are seeing large percentages of users using Firefox and Chrome. We're moving pretty fast here, right? This is awesome. We're replacing ourselves once every six weeks, more or less.
[11:58] This is Firefox, all right? We're starting to see that the slope is going significantly steeper as Firefox is pushing more updates more quickly, which is amazing. We're starting to see at the 4.0 to 5.0 transition, they're seeing the same sort of sampling rate error. That line is getting jaggy because they're updating so fast that once a month is no longer quick enough to really get a sense for the curve.
[12:22] This is good, but we've got this hard core now of 3.6 users that are sort of left, and they're a significant percentage of the world's browser users. OK, I don't mean to depress you before lunch, but yeah, that's not getting any steeper, is it? I mean like, we could sample once every six months and it'd get exactly the same curve, which is really depressing.
[12:45] IE6 looks sort of intractable, IE7, IE8. I keep joking IE8 is the new IE6, and Paul Irish put it more, I think, generically when he said, IEn is the new IE6. Because what we're seeing here is that we don't really have this crank turning fast, right? If I have to pay attention to this portion of the market, and almost all of us do, right? We're looking at a crank that's turning really, really slowly. We can't start to take advantage of the new stuff, not really anyway. We can't start to really lean on it. We can't get to that Platonic ideal of a new feature without that feature being everywhere, right?
[13:26] The first thing we wanted was ubiquity. Isn't that the promise of the web, is that we'll have stuff and we'll have it everywhere, and we won't have to work hard to get it? That's the promise of the web. So we're going to have a hard time getting to our Platonic ideal if this is the world that we're living in, for new features anyway.
[13:42] So Microsoft is trying to help. They've put together the IE6 countdown, and as we saw IE6 is getting better in terms of market share, nine percent. I don't mean to bash on IE6, it's absolutely the best browser that was released in 1998, hands down, no doubt. You'll have to fight me on this if you think otherwise, because you're wrong. IE6 was fricking amazing. It was some amazing engineering. But this is what we're looking at, right? So we're looking at those replacement rates, and IE8 is going to be tied to Windows XP. So wow, 30 percent worldwide.
[14:21] Every new person who picks up IE8 today is part of the problem. They are already part of the problem. Same with IE9, right? How are IE9 users going to get IE10 faster? It's not clear. We talked about IE10 a lot yesterday. Some of the presentations, the great presentation on CSS talked a lot about what's coming in IE10. Well, when are we going to be able to get IE9 out of the world so that we can start to use IE10?
[14:48] Looking forward, IE9 yeah. 3.2 percent, well that's the 32 IE8 99 percent... Oh my goodness. All right. We should be clear. We've seen this pattern before. We know what stalled evolution looks like. This is not a new thing for us. We saw it when we were trying to kill NetScape 4. When NetScape four was at 100 percent, more or less... Sorry, NetScape was about at 100 percent with NetScape 3, it took a long time for us to get NetScape three and four out of the world.
[15:21] Once we had a significantly better set of browsers that could displace them, it took a very long time to get them out in the ecosystem so we could start to take advantage of new stuff because we want those new features to have that property of ubiquity.
[15:32] So what do we do? This is not a new story, but it's helpful to think it through and say, "What are we going to do in response to a market failure?" Which is what this is.
[15:45] I was going through some old slide discs of mine last night and I was shocked to this slide that, I think, we put together in 2008 before I joined Google. This show the timeline of IE releases, sort of early to more modern.
[16:01] From 1995, from IE 1.0, to 2001, which was the golden master release for IE 6.0 for Windows, we saw something like seven or eight releases in the span of five years. And their adoption rates were incredible, in part because the market didn't existed before and it was just expanding like mad. But their replacement rates were incredible too. Now we're in a more stagnant period here.
[16:27] So what did we do? It worth asking the question, "What did we do?" because this is going to push what we should do and how we should think about what we do next, because plan A is always a fast evolving platform. The faster we turn the crank, the more generations we get in to any particular set of time, the more chances we have to test more features and the more chances we have to make new features available. Which means we get to figure out, "Are they good or are they bad?" and make them Platonic ideal of ubiquity.
[16:56] So plan B, unfortunately, is something we've come to rely very heavily on which are frameworks and compilers. I'm not saying that frameworks and compilers are bad. God knows I've done my bit. But we should acknowledge that plan B is always going to be these sorts of fallback systems. It's not like we're going to be able to stop thinking about browsers that aren't flushing out of the ecosystem quickly.
[17:19] Look at mobile. We've got versions of Android that are still 1.6 sitting out there. A lot of them may be getting over the year updates, but it might be awhile. Now admittedly, that story is a lot better. A lot of those users got those phones less than a year ago and they'll swap them out in about another year. So two year timeframe, worse case, that's pretty darn good. But at the same time, we'd like to go a lot faster.
[17:43] The Chrome world gets us up to date in about six weeks. A new feature in six weeks and gets us up to date in two weeks. So that's where we want to be, and we've got this set of structural drags that keep us from actually getting there.
[17:55] So how should we think about how we're going to get stuff into the web without doing this? This is a diagram that came out with a proposal from the search team at Google about two years ago for AJAX Search where the idea was that you would run a headless version of a browser on your server. And then you would serve that up when Google comes to you with a Googlebot so that they would be able to send you a hash fragment and you would be able to send back the stuff that you were going to render anyway.
[18:26] Like, really? That's a little nuts, right? Seriously, that's a little nuts.
[18:32] The set of people that are going to be able to do this versus putting some files in a directory is small. Let's just acknowledge that upfront. So we do have company strategies. I spent a bunch of time during the last couple of years working on something called Chrome Frame. This is maybe one out. It's a plug-in for IE that makes it look like Chrome to you.
[18:54] So that's maybe one way that you can be self serve about getting yourself out of this and get everybody into that quickly updating population. If you can pull that population up to the front of the pack, maybe you could start using new features faster. Maybe that's one way that we can start to get the process of progress moving faster for us.
[19:13] The other ways that we have are also all what I would call "hacks", but I don't mean that in a derogatory term. They're brilliant and beautiful things that we can do to make life better for us right now. The set of things that we can do include widget frameworks. And widget frameworks -- I have done my share of damage here too -- come with a lot of liabilities.
[19:35] Let's be honest. They're the sorts of things that you use when the semantic that you're trying to express is so far away from what HTML natively has a semantic for, that you're willing to go and be completely self served for it. Taking on for yourself accessibility, UI, UX, internationalization, localization, performance, theme ability; all of this stuff is mostly taken care of for you by HTML.
[20:25] Then you have the problem, of course, of once that thing is in your page, you've got your calendar widget in your page, there you go merrily querying the DOM with jQuery and you come along some TR, some TD. Oh, balls.
[20:37] That doesn't actually mean what you think it does because you don't own that node. That node is owned by the component. That element is owned by a parallel tree of components. A set of things that is being built out of DOM, but exposes all of it's guts to DOM. So you wind up in this place where now you have to be mutually distrustful as well. You can't trust yourself to just go, "Use the DOM as it was."
[20:58] It's no longer the contained mode hierarchy that you expected. It's a proxy for a shadow tree over here, another tree that's got fewer things in it which manages small sections of the DOM which means interoperability suffers a lot.
[21:52] So we're going to get ourselves out of Hawk. The question is, how are going to do it? Can we rely on that fast evolution cycle to deliver new stuff to us sooner? Or when we get stuck, do we have to do this?
[22:22] This is from Bruce's example yesterday where Opera took a survey of the most common class names that were being used widely on the web in order to inform the HTML5 semantic construction process. And things like microformats, and things like Schema.org and microdata are all part of the same evolutionary process. They turn into a slang that we all wind up using one way or the other. This is actually a really rough slang.
[22:51] Do you think that all of the people who use the word "footer" inside of their CSS classes meant exactly the same thing with it? I don't think so. If you are using microformats, you're probably a lot closer to the same semantic meaning. But it's like anchor, you don't mean exactly the same thing all the time. You mean sort of something close to the same thing.
[23:09] So what we wind up with this large and growing body of things that we assume that we have to carry along with us. Think about jQuery. Think about the tool kit that you're using. You're probably pulling that along with you into every project. You're assuming it. It's part of the web as far as you're concerned. It's interceding on your behalf to the platform.
[23:27] Do you have some basic structural CSS that you carry around with you all the time? It's part of the web as far as you're concerned. It's part of the browser. It's part of your development experience of the browser. So we wind up with these small languages, these small ad hoc languages that do things for us that the browser isn't doing for us.
[24:24] So we wind up with this unspoken tension between deep pragmatism and the Platonic ideal of where we would like to be. But we don't have a really good model for thinking about it.
[25:04] What made that evolutionary step possible for going from broad use of known class names, not even agreed upon, just the same class names all over the web to new elements in HTML5? The fact that we can see them. We can go and we can search the web. We can find out what declaratively people were using. And we can go, "Oh, right this is what everybody wants."
[25:40] So when you talk to people who work from a browser, I think we should all stop being a little bit guilty and start being a little bit angry. Because what it means for you to be carrying this stuff around, to be using this sort of slang day to day, is that the browser isn't giving you what you need. The tools are not evolving quickly enough to get you where you want to be.
[26:01] Part of that is that that ecosystem isn't moving quickly enough. Maybe we're not turning the crank fast enough, we're not getting enough generations on; talk to your Microsoft rep or use Chrome Frame.
[26:11] Part of it is that we can't trust ourselves and we can't trust the standards process because browsers don't feel like they can ship stuff quickly enough.
[26:35] OK. It's worth remembering too that when we want stuff out of the web, we need to be willing to pay for it a little bit. We've said that there's this slang that we're using and we feel guilty about it, but if a new feature comes along and we want to start using it, what does it mean to start using it? Using it when and where? In which circumstances?
[26:57] So we wind up with all of this advice about how to use fallback content, how to use degradable markup, how to use these new semantics along with the old semantics so we don't feel quite so guilty.
[27:07] I'd like to advocate that we should stop doing that a little bit. Not that we shouldn't provide fallback semantics, but in a lot of cases we wind up with these unsemantic equivalents where if I'm using a new element type that didn't have an example in HTML4 or didn't have some easy allegory what you're going to end up with is something that looks like a DIV. It's going to be an unsemantic pile of block or inline block, or whatever it's going to be from a CSS perspective.
[27:40] That's OK, because you mean something to the future and there's going to be a lot more future than there is past, I hope. So it's all right for you to start taking advantage of things that aren't everywhere yet.
[27:51] We can start to put down a little bit of our guilt, a little bit of our self-flagellation and start to take advantage of new stuff. Because when we do we're also putting in a vote for the future. What we do defines what users are going to do. If we say, "You need a newer browser in order to view this site," it's not saying, "Best viewed in Netscape 4," it's saying, "Best viewed in the future." Hopefully we want that in our operable future. So it's not saying no.
[28:51] Bruce also, yesterday, said that heuristics are rubbish because they're ambiguous. I think, if I'm being charitable, what he might have meant was that it's difficult for a browser to parse a document and figure out what you mean about a particular element and do something about it when you're using heuristics, when you're using stuff like microformats.
[29:48] What is it exactly you mean to click on that link? What does it mean? It's a really complex question to answer. It means that we're going to start a new HTTP transaction. OK. But what are we going to do with the current document? What is a document? What does it mean to navigate? Shared session state?
[30:30] Today, we just put this in a web page and assume that it means something good for the user. We have this shared vocabulary of, "What is a URL?" It's a parsable thing. We have an ontology for what a URL is, right? It's actually something with a grammar, and we can go figure out, "Well, what are you going to do when you click on that link about that URL?" That's up to the browser, but it's up to this mediated process that out of view of our content.
[31:21] Language is built this way. Language is built by not actually understanding what the other person means, but sharing a bunch of ambiguous things that you can sort of get by with in the cultural milieu. They give you this ability to go from one idea to the next without really getting bogged down in them until you really want to.
[31:38] We shouldn't expect the web to be any different. The web gives us some nice fundamental data types. It gives us text, it gives us URLs, it gives us dates, ranges, emails, a lot of these are new, but selecting text area. But what do these things actually mean for my application? They only mean something in context, most of the time, and that's true of regular language as well. When I put these things together in a form and I say <Input type=text name="name"> I give some email address, email, whatever. This means something heuristically to a browser, because it's going to try to auto-fill that form for you.
[32:15] Heuristics aren't how we break the web; heuristics are how we make language. It's how we collectively make language. I'd like to suggest that that's how we're going to make change in our language as well, because we need more observable ways to share loose meaning to feed the process of progress.
[32:53] So if we can be declarative about our slang, we can start to make it observable, which means that we can go see what everyone else is doing. We can hear the slang everybody else is using, and we can sort of converge on a vocabulary. Then it becomes the browser's job to go blast that vocabulary for us, to give us a good version of that. Something that we can feel less guilty about because it's got a standard, because it's implemented everywhere if we're turning the crank fast enough.
[33:19] We want to feed this process of progress. I think we get stuck in a place where we consider HTML5, we're done. And I agree with Hixie in some sense about HTML being a living standard. I think what he's getting at here -- and he'll correct me if I'm wrong -- is that if we consider there to be a point in time where a thing is done... we do need checkpoints. We absolutely need checkpoints. But if we consider there to be a point in time when things are done, we stop thinking about what it means to evolve to the next point.
[33:48] We consider these things to be point events, and we're frustrated that we don't have them yet, and then we're frustrated that we don't have the new thing yet. But we're not really thinking about what it means to be living in this uncomfortable tension, which is the default. We've always had this uncomfortable tension between new features and old browsers. We've always had this uncomfortable tension between slang and the blessed language. That's just how life goes. It's not bad, it's good! It's how we evolve! If we stopped having slang, we'd be Latin, we'd be dead. No one speaks Latin, right? Does anyone here speak Latin? OK. I bet two Latin speakers probably can't speak to each other unless they went to the same school.
[35:10] I think because people take the idea of markup very seriously, but we should stop doing that. Markup is serious when it's serious, but until then, it's just slang. We make up slang all of the time. It's OK to make up slang. It's OK to ask the browser to intercede on our behalf when we're using slang. It's slang that gives us this process of progress.
[35:31] All right, so this is Bruce's list of popular class names from a couple years back. We want this. We absolutely want this, and we want this for the things that we're trying to say in our applications so that we can make our own semantics observable. He asked the question yesterday and I think it's puissant, "Are the semantics we have the semantics we need?"
[36:31] What if the DOM was extensible? It's worth asking the question. I know this is where the pitchforks are going to come out, so please keep them packed for just a second. What if we could make our extensions observable to crawlers? What if we could create new semantics that were observable to crawlers, like microformats, like schema.org?
[37:15] What if the things we're trying to say frequently about the stuff that we're rendering wasn't just sort of like spitting a string into the DOM? What if we could go discover that too? What if the browser was handing out ponies?
[37:27] All right. So I work on a browser and we're handing out ponies. The first pony we're handing out is Scoped CSS. Tab, I think, talked recently about this yesterday, but Scoped CSS, it's a spec that's been pretty widely accepted already. What we're looking at here is a small example where we've got an image selector, and that image puts a black border on every image that it can see, but it's only going to select inside of that outer div. That image at the bottom is not going to be affected by it at all, because only the rules that are defined inside of that style, those rules will only apply inside of the current element. They'll start matching from that parent element.
[38:11] It's a nice way of saying... of getting ourselves out of the problem that you often have with CSS where you write a naïve selector, something that looks really simple, and you put it in a small test document and you start iterating on your little component or your little piece of UI, works great. Then you put it into a big document and you've blown somebody else's stuff up. As Nicole Sullivan will tell you, you will end with this place where you're putting important, not all the selectors, which is not really where you want to be.
[38:41] Scoped CSS is something that we're working on today, we've got an implementation, it's great. It's going to get us out of some of this stuff. This is pony number one. The second part, and this where we get back to this question of evolvable semantics, giving our hacks some meaning, putting ourselves back into the declarative side of things.
[39:00] This is a web component. Web components are some new work that we're doing to make the DOM extensible. Think of it this way. What is a button, like the button element? The button element is actually a really high level thing. It maps to an OS level button. It has built-in states. It has active hover. It's got the ability to render sub-content. It's got all of this really sophisticated behavior. If you were trying to build a button in Canvas, you'd write a lot of code to do it, but we can just write it out as a button element.
[39:32] Now, we want to suppose that if the DOM is a high-level representation of retained mode components, then we should be able to put our own high level retain mode components in the DOM too, so that I can just treat the DOM as my lingua franca. I can just come in with jQuery and find my custom elements, as opposed to going through this parallel tree over there.
[40:54] This is the part where you're going to come at me with pitchforks. There's this x-comment. What we're implicitly saying here is that the browser didn't have a semantic for this. I wanted to say something that was so far away from what the browser could actually give me the ability to say for myself that I wanted to cobble up a new one. Now there's no difference here between this and the div. You're going to tell me, "You shouldn't do that, because you should not be able to extend HTML."
[41:17] Well, first, I can't add a new element type that doesn't have this x- prefix. It's not a name space, but we are going to say that if you have extensions, they have to look like extensions so that you know you're using an extension so that when the new stuff comes along, you're not going to be conflicting with real HTML.
[41:32] But when you're inventing new stuff to say what you mean, you need to be able to say what you mean. Putting it in some class, inventing a new language in some attribute versus using the tag name, I'm sorry, but that's just a little bit of lying to yourself. If you're using a class name to mean that this thing is actually something different and you're not using the tag name directly, you're just sort of hiding from yourself. You're actually imbuing this thing with semantic identity, but trying to pretend like you're not.
[41:57] Let's not do that. Let's stop the lying to ourselves. Let's build ourselves an out so that we can have discoverable, shared, ambiguous, beautifully ambiguous, but beautifully shared, declarative meaning.
[42:08] OK, so you know how I was talking about that problem with a calendar widget? Where you might build a calendar widget, and then you're going to spill your guts out to the entire world because you have all of these little tables, divs, whatever? You naively query through the DOM, you find them, you start to script them, not realizing that somebody else had ownership over it? They were the ones who were controlling it, they styled it, so you style it means that it blows up, something like that? Because they are reading back style or something? Or you're going to blow up their event handler, which means that it's going to end up in some nasty, disgusting state?
[43:05] Well, I want to do that trick for my own components. So Shadow DOM is an idea that was taken from XPL, and please don't use the word XPL with the web component model, because they're very different, but this is an idea that was taken from XPL and we're using it all of the time in browsers today, but we want to give you access to it so that you can create something similar.
[43:22] So that if you have a visual representation, you want to be able to construct that with HTML and CSS, because it's incredibly productive, but you know that it's not the semantic that you're trying to express. It shouldn't bleed out into your page. You shouldn't be able to have to sort of like, spill your guts to any Johnny-come-lately who's walking the DOM in order to just get some visual rendering of the semantic that your element describes.
[43:42] So Shadow DOM gives us a way to do this. What we're doing here is we're saying, "Please make a public shadow property," this is by convention, not by fiat. This is the part that you have to do, you say "New shadow root this," and you can only do this once for any element. Now, most elements in your document won't already have had a shadow created. You'll get an exception if you try to do this a second time, but there's only one shadow per element, and you can script it. It's like a document fragment. You can add new stuff to it. You can take a pen child, and it'll be part of the visible UI of your element.
[44:13] OK, so that's pretty cool. So every time I create a new comment element, I will create some, in my build UI function, some new UI for that comment that scripts that Shadow DOM, and it's not going to be visible to the public document. That's awesome.
[44:26] OK, so I've got Shadow DOM. I've got Scoped CSS. I've got web components. Now I want to put something, so I've got this thing that's got the Shadow DOM, it's this visual representation of my element. Now I want to append child. What happens? OK. This is where the content element comes into place. The content element up there says, "When you append child, you put it here." Poke yourself through the Shadow DOM back into the light DOM. It's like a wormhole, right? There's this visual stuff around me, but if I script it, all I see the outer element, and then the stuff inside. You know, pay no attention to the gigantic, awesome UI that I've put around my actual children.
[45:06] So how does that work? It works sort of like this. I've got my component element. It looks like an element, it is an element in the DOM. I have two childred -- Child A and child B. Child A actually lives inside the content when I append child, but there's all of this other visual UI, the "child..." That's all visual UI stuff that's going to be living in the shadow. So when I script it, I see component element and child A and child B. From the inside, I can look at the shadow, and I can start to script it, and I can change my visuals in reaction to something, but I don't have to bleed all of that implementation detail to the outside world.
[45:38] OK, I've got ten minutes left. I'm going to short out my Q&A time a little bit, and we're going to go through some demos. This is a little bit of a Franken-build with Chrome. It's using some patches that we've put together for WebKit and for Chrome to help make this component system down here at the bottom where the comments were... So cute!
[46:02] All right, I've added a new comment here to my thing. Let's see if I look at the Web Inspector, what do I get... Oh wow, OK, that's cool. X-comment, can you all see that? All right. X-comment, and that's only got the children for that text. All right.
[46:22] If I come back here and I look at it visually, my comment here has this avatar, and it's got this formatting around it. Huh. OK, that's a component. Let's see how it works. So, we've got this template here and it's just a native element at this point. We'll see it again in a second. But it's got some scope style. Right? I've got some scope style, cool. It's got this content element and then I'm going to define this comment class just the way I did in my example here, right?
[46:56] I'm going to make an element, I'm going to give it a shadow root and my build UI, I just build up some stuff. I copy this template in and, basically, when I append child, it goes into this content, right? So, that's not visible in the DOM that I'm seeing. So, if I come back through here, now my components or my UI on to the semantics. So, I can see in my console document.query selector all, next-comment slick. I've got two of them, right?
[47:32] So, what we're looking at now is that we just extended the semantic. We extended the semantic with a thing we were actually trying to say and we improved our interoperability because I can put these x-comments on any document and not blow up when somebody comes through and tries to script it. They're just going to see the UI that I exposed.
[47:51] They're going to see the semantic that I've exposed. And when a Web crawler and it sees an x-comment in the code, well, it's not going to be semantic in a way that HTML is semantic. Well, maybe because it's all probabilistically semantic. HTML doesn't mean stuff, right? Back to our anchoring sample, HTML doesn't mean stuff unless we all agree that it means stuff, and it's that widespread agreement, that widespread use that imbues it with meaning. OK. So, that's the components and what do you think?
Alex: [48:25] All right. Quickly before I run out of time, I'll talk a little bit about model driven views. So, you know how we talked earlier about those form types? Those form types are a set of prebuilt semantics that we have for HTML, things that we know how to say, but those form element types in forms, give us some structure representation of the relationship between those pieces of data. But, that's sort of hard to extract and if we try to put all of our programming into forms, we quickly end up in a pretty terrible place because they don't express all of the UI we'd like. [48:57] They do a great job but they're not extensible, right, so we want some sensibility. And then we wind up having this thing where we shipped on template systems in class. I know we have backbone or spine and we pull those down and we use those in conjunction with, maybe, a snapshot of some JSON, right, and then we try to build some markup or we try to upgrade some markup that was there before.
[49:16] What if instead, we were just expressing the data that we wanted in the DOM itself, right, because you could think about that form and it's got that visual tree, right, it's got that sort of shadow tree of the UI that it's building, but it's also got that semantic tree. I go through the DOM and I can see the model that's there, right? I can see the values of those input elements. And they're sort of living on the elements themselves. They're sort of in parallel, but they wind up sort of getting conjoined in HTML today because HTML is very confused. It is model. It is view. It is relationship, all in one thing.
[49:47] So, what if instead, we could directly inside the DOM tease that version out and talk about a model that's implicit on every element in the document and it's inherited through the document like CSS is. So, that's what we're doing here. I'm setting the document's model, the body's model to something which just comes through this Model.get which is, unfortunately, a little bit magic.
[50:13] But, what we're putting in there is just the JSON object, right? There's nothing special about this. But, now, when we mutate this JSON object, or when we mutate the model, we're going to see live updates because what we're doing here is we're stamping this out once and then we can change it later. So, I'm going to give you a quick example of this. Right. So, this is the same recursive template working here. This is something we'll call model driven views.
[50:36] But, what we're seeing here is the same recursive template, and what we do is we just smack the data directly in, right? So, now, we've got the DOM managing our templating and our data binding for us. We don't have to go build a system and send it on the wire ourselves. This is pretty good.
[50:53] OK. The design goes here, although we want unified templating and data binding because they're two aspects of the exact same thing. Templating is data binding as a one-shot deal. Data binding is the upgraded version of templating. You shouldn't have to think of them as separate things. You're taking some data, you're generating a view. And we want to only update the parts of the view that actually change when we update some data.
[51:15] And we want to make it sure that you can plug in your own persistence layer so that when you update some portion of your model, it gets written back to your back-end, your local storage, whatever it is in the same way that hormones do this for you. Cool.
[51:28] I want to talk about this, but we will say that we're looking at a declarative version of this so that you can have the search engine be savvy about finding your data in addition to just finding your programmatic implementation of this because, again, if it's declarative, we can see it, and we want to expose things to be declarative and HTML's data too.
[51:48] So, let's look quickly at what it means to look at our little example here. So, now we've got hierarchical comments. Awesome, we've got threads. So, how did this happen? So, what we've got here is we've got our comments class, right. What we've done is we've just said instead of putting that stuff in the document like I did over here, right, if I look here, I've got my x-comment here which declares that first comment.
[52:20] Now, it's just using the default text, but that's not really very satisfying. I want to separate our model and our view out a little bit. So, let's go back to the other one and look at what we're doing here. Instead, I put in this JSON object which could have come off the wire. It could have come from someplace else. It's just hierarchical JSON, right. Like, this is just the thing that I was going to be serving out out of my database. Cool.
[52:39] But, in order to generate that view, I just use a template in a document and it gets automatically generated for me. Now, when I go and I want to update things, I don't put any x-comment in my document, I modify the model. Let's look at that. Last post, all right. It was there. It's immediately done, but I didn't add x-comment. What I did instead was to put a new object into my model. Right?
[53:08] Now, we've got data binding and model driven views, all managed by the Web platform itself. What do you think? Do you want it?