 Welcome to the future of HTML and CSS. So let's go ahead and get started. Let me tell you just a little bit about myself. My name is Preston So. I'm a software engineer at Time Inc. and I've been working with Drupal for about seven years with a couple of breaks. I am happy to answer any questions with the contact info above if you would like to contact me. So here is sort of the broad outline of what I'd like to cover today. The first thing I'd like to talk about is where are we now? Where are HTML and CSS now? And why talk about HTML and CSS in the first place? As opposed to, say, Drupal. And then I'll talk a little bit about what the rendering engine landscape looks like currently and how that might impact the future developments of HTML and CSS. Then I'll be talking a lot about what sorts of new and cutting edge features have made it into the CSS standard into the drafts and are currently in flux. And then I'll talk just a little bit. I want to give a very broad and basic introduction to the main ideas behind web components and talk just a little bit about what that might have in store in terms of CSS and also what sorts of implications that might have for Drupal. Finally, I'd like to end with just a little bit of a summary about where things are headed and think about HTML and CSS in the long run. And rather than a sort of simple Q&A just because a lot of these ideas that I'm talking about are in flux, I'd like to entertain the possibility of having a sort of open discussion about what people think about this kind of stuff, what people think about the larger concepts and where things are headed. First thing I'll talk about is where are we now? A brief retrospective and talking about where web standards are headed as a general rule. So HTML and CSS have matured considerably since they were first begun as standards. We remember table-based layouts from the 1990s. We remember non-semantic clear fixes and box model hacks. I'm sure that many of you were around then and maybe you still are coding for IE6. I don't know, but if you are, I'm very sorry for you. And also since the browser wars, we've also moved past this very clunky handling of JavaScript to very good handling of JavaScript and also browser support for a great variety of different features. So this is just a brief timeline that just gives you an idea of what standards came about when in terms of publication by the consortium. And as you can see, HTML5 came out in 2008, which is pretty late when you think about it. But when you think about the fact that just five years ago, that's when the beginnings of responsive web design were coming about. That's when CSS was just becoming involved with transitions and a lot of these new effects that we've been seeing, things have really moved fast in the last five years. And same thing with CSS. CSS has obviously been around for a long time and we of course have a lot of possibilities that have grown as a result of this split between structure and presentation. But why talk about HTML and CSS in the first place? After all, a lot of sessions that we see at conferences and a lot of the things that people talk about these days are preprocessors and frameworks and ways to make our lives easier when we're coding HTML and CSS. Well, the reason why is because it's essential to stick with the basics sometimes. The fundamentals are where the most meaningful change is gonna happen and that's where that change happens is gonna have a huge impact on all of the abstractions that we're working with. So if you're talking about less or SAS or stylus, all those things are gonna be impacted by what the CSS working group at the consortium is producing and also how those preprocessors are able to respond to new CSS standards. So just talking about very, very simply HTML and CSS, we know about Hamel, we know about SAS and less and what we'll be talking about is sort of what's at the bottom obviously. And why talk about CSS over say SAS or less? Well, SAS and less are basically what's called syntactic sugar. They're not replacements for CSS but they are ways to make writing CSS much easier. And what this means is that although I don't expect this to happen, CSS could outpace or even supersede some of the elements that are in place in less than SAS and I'll talk a little bit about that and the implications of that in a little bit. So pure CSS will always be a purist's paradise and as we all know, preprocessors like SAS and less are very ideal for efficiency and low overhead getting started quickly on a project. But when it comes to really getting down to the very fine details you got to, you know, obviously CSS. So moving forward here and I do also want to bring in a little bit about the history of HTML and CSS because of how fast things have moved in the last couple of years in the front end it's always important to take stock of where we are and how far we've come. And as I mentioned earlier, this was a lot of the new work that has been done and a lot of the improvements that have been made to the front end wouldn't be possible without the web standards movement. And the web standards movement was a response to the browser bars of the 90s. And one very interesting question that Zeldman, who you may know as sort of the forefather of the web standards movement, is web design dead. And this was a blog post that he posted at the beginning of this year asking whether or not the idea of an HTML and CSS guru, someone who really knows their way in and out of the browser, someone who knows what to do when they're coming across a lot of cross-browser compatibility issues, are those sorts of jobs no longer available? And I think the answer is yes. But right now what's interesting is that we're facing sort of another series of wars in the browser space, except between these rendering engines that are actually trying to race and move as quickly as possible against one another to implement the new features that they want to see. And as a result, we've seen the web standards movement sort of die out. And that's been shifted over to a lot of other projects, such as the email standards movement and so on and so forth. But as Jeff Croft wrote, the goal of the web standards movement was for it not to have to exist. And that's a very important point, I think. Once web standards made the web safe for design content experience, the web's capabilities, and thus the work required to create certain kinds of websites started becoming more and more complex. This is where we start introducing ideas that, you know, the front end is not just HTML and CSS anymore. It's also about JavaScript, it's also about jQuery, it's also about knowing all of these other languages and ideas that were really not in play before, or at least were not very well supported before. So what does the rendering landscape, the rendering engine landscape look like today? Or the browser engine landscape? Well, as you may know, quite recently, Chrome decided to create a fork of WebKit. So this is what the current landscape looks like. Chrome and Opera are currently using the Blink rendering engine, i.e. is using Trident, Firefox is using Gecko, and Safari is using WebKit. So what is Blink? What are WebKit and Blink exactly? Well, KHTML, you know, you may know this better as the conqueror browser, was the basis of WebKit. And Blink is basically a fork of WebKit that is currently serving as the engine for Chrome and Opera. And, you know, Blink's sort of idea in doing this is that more options in rendering engines will lead to more innovation in a healthier Web ecosystem. And this is something that, you know, might be a little bit controversial because, you know, if you stick with a smaller number of rendering engines and, you know, keep going at that pace, maybe things will be a little bit less fragmented. And Blink has made it very clear that their sort of dual tenets for whether or not to move a feature forward is a compatibility risk with other features and versus moving the Web forward. So the question is, will the Web become more fragmented? Will we have a bunch of rendering engines and, you know, there's not going to be any random reason between them? Well, you know, I don't think so because we learned from our mistakes the first time around. And, you know, that's something that we are still trying to learn to this day. But what about vendor prefixes? Well, as we know, the browser bars and also the advent of Netscape and all of those things led to a great deal of non-stated markup that entered the Web space, including things like the filter property that IE had. Vendor prefixes were originally a way for browsers to test emerging properties without impacting compatibility. But, you know, vendor prefixes are kind of ugly-looking. You know, it's not really that great to have a hyphen at the beginning of a line that doesn't look so great. And also, when you have inconsistencies between the way that browsers are implementing features and you come out with this. And, you know, Flexbox is one of those issues where you had sort of a legacy way of doing things, an older standard that was being implemented and then, of course, the syntax changed. So, another example right here, as you can see. So, Aaron Gustafson said that, you know, vendor prefixes look kind of like box model hacks or other CSS hacks. They just look kind of hacky. You know, even though you might not agree with that, you do have to admit that they do add to file size and aren't really that pretty look at. They avoid clashes with future features, which is one advantage. And they do add sort of a needed flexibility. But if standards change, rendering engines can theoretically adapt to those changes, but they can also just fall back onto the prefix without any sort of consequence. So, one example of this was in 2009, actually, when the CSS Working Group, and this is a while ago, I know, that vendors were considering an implementation of the WebKit prefix because, you know, the other prefixes, Moz, were not getting enough usage. But this led to a sort of, you know, discussion within the Working Group saying that, well, you know, we should only adopt other prefixes when the standard has been adopted. So, that was a very important step. So, relatively recently, Mozilla and Chrome have both stopped adopting vendor prefixes. They're choosing the ship on prefix features as soon as they have matured. So, Chrome, for example, ships on prefix features, and there's often an exposed option if you want to use that feature. So, what does the future of vendor prefixes look like? Well, with the recent moves by Chrome and Mozilla, I would say that they're dead but not quite extinct because you still see them in a lot of CSS everywhere. And, again, you know, you've got your auto prefixes that you're using for your CSS preprocessing. So, let me talk about, you know, let me talk for a little while about what sorts of advancements in CSS we've been seeing. This is going to be, I'm going to delve into sort of mostly things that have happened in the last six months or so. There are a couple of things that might be a bit of review, and I know that many of you probably have worked with a lot of this stuff before. So, please bear with me. So, CSS is constantly undergoing a lot of change. And, as a result of this constant change, CSS has been split into distinct modules that are being developed independently, allowing rendering engines to follow their own schedule when it comes to these features. So, for example, I'd like to just jump right in and talk about CSS selectors. And you've probably seen this before already just because it is already in a great deal of style sheets and the matches of any pseudo-class essentially makes your markup more efficient by allowing your selectors to be a little bit less clunky. Then we've got attribute selectors without case sensitivity. So, this is a pretty big one. You know, as, you know, generally speaking, at least the way that I learned, you know, class naming and so on and so forth was stick with lower case. But, obviously, there is a possibility that you have people who are using a different case. So, this little... this allows you to basically select an attribute... an attribute's value, excuse me, without any sort of case sensitivity, so it can be any value. Then there's support for bidirectionality as well. That's new in CSS selectors. So, for instance, if you have left to right text or right to left text, you can select for those. And another very important change as well is the laying pseudo-class, which allows you to target individual languages. So, in this example, for instance, if you're using a font that's more well suited for Russian, then you can select for that based on what language the content is in. And then, of course, you know, CSS is also always improving accessibility, and this is something that I'll delve into a little bit as well later on. But speech rendering is a very important topic. And one of the things that these pseudo-classes allow you to do is that if you have an active reading going on, if you have an active text-to-speech reading going on, then you can use highlighting or CSS to style the paragraph that is currently being read or the element that is currently being read. So you could even have it based on the word. If you really want to get down to sort of the finest level of the elements, you can do so with that CSS. And same thing with past and future. And then, of course, I've been seeing this a lot, actually, lately, which is styling based on a link's destination, using local link and any link pseudo-classes to change the style. And you've got reference combinators as well, which is basically if you have a selector and you want to use a selector that is related to that selector. So for instance, this code example right here is styling the input for whom, I guess, the label is hovered. And you can also use the not pseudo-class to prevent that as well. And then this is something new as well. Before this new technique, there was really no way to select a parent based on its children. That's been one major disadvantage of CSS that's been really well documented. There's just no way without JavaScript to accurately select a parent based on its contents. And so, originally, this markup actually was a dollar sign instead of an exclamation point. And then they switched to the exclamation point and now there's this confusion of, well, is this like the not operator or what is it? So there's currently a lot of discussion going on about whether or not this is the right approach, because I think what they were going for here is to sort of map it to making it look like the important declaration. But as we know, it's pretty confusing for people new to CSS to see this. And so what are some of the things that this selection allows us to do? Well, it potentially allows us to style based on, to get rid of some of the body classes that we have, for instance, in certain themes where you have your layout and you have to indicate to the theme, for instance, that you have a sidebar on the right side. Well, what you can do is you can select based on the parent that contains a sidebar right and apply a right margin or apply a left margin or whatever you need to do to make that work. Another thing that has been very interesting lately is the corner shape and corners properties. So, as we know, we can make rounded corners with border radius, but did you know that you can also actually make different shapes with those as well? It doesn't have to necessarily be a rounded corner. Well, we've got several options for corner shapes, and you can see those there. And currently in discussion is Cubic Bezier, which would allow you to do a lot of custom creation of shapes that would work with corners. And then what if you want to... So, this is a pretty big concern, which is how do you only render part of a border? And this has been something that people have always... people have used pseudo elements for this, people have used some sort of the column before, column after to do this. Well, now what you can do is you can limit the borders that you are using to, for example, the sides, only the middle 50% of those sides, or you can, for instance, do it with just the corners. And this is if you have a border radius already present. So you can do just 10 pixels into the sides from the corners and the entire corner. And then, of course, we've got the ability to clip the border, and this is a really interesting property because this allows you to basically take a border and put it into basically arbitrary pieces that will be... that have different... that will render or not. So, for instance, this first declaration here, border clip, 20 pixels, one FR. So that FR is actually a fraction unit, which means that it is taking the remainder of whatever is not already declared and applying that. So, as you can see, we've got... the first part will be visible, and the third part will not be in the first... and the third part will be. So this alternates back and forth. And what you can see is that border clip... what this will do is this will apply on all sides of the element... sorry, on all corners of the element, it will apply a little sort of L that will be 20 pixels long. So... and of course, the one FR states that anything that's outside of that sort of 20-pixel threshold will not be rendered. So that border will actually not be there. And then, of course, you know, if you are looking for a sort of footnote style that you might find at the bottom of a book page, you can also clip and use that to create an incomplete length for a border. So I'd like to talk a little about CSS Flexbox. I'm sure that many of you have already seen this before, but Flexbox is one of those things that, you know, it's something that's definitely really, really good to cover. And basically what the Flexbox module does is it allows you to lay elements out when their sizes are arbitrary. You don't know what their sizes are, you don't know what they could be. So the end-of-flow based layouts might be here. And so Chris Coye actually wrote a very good tutorial for this that I'm linking to at the end of this presentation that talks about some of the benefits. And one of those is that it's direction agnostic. You don't need to necessarily have a certain way of doing things for left to right or right to left. It doesn't really matter. So here's what it looks like, display flex, instead of display block or display inline block, what have you. And then of course display inline flex. And so basically what happens is that we have a parent element that contains several children that are arbitrarily sized, and we need to lay them out in a flexible box. And so what we need to do is we need to declare what sorts of properties that container has. So for instance, flow, sorry, flex direction indicates, well, do you want it to be horizontal or do you want it to be vertically oriented? And in this case, the default value is row, which is simply left to right or right to left if you're using a right to left language. Similarly, flex wrap determines, well, should these elements wrap when it gets to the point where they're too big to fit in the horizontal or vertical space that you have allotted for these elements. And finally, flex flow is just a shorthand for those. So this is just a diagram that shows you basically what the implications of these values are. As you can see, row goes left to right, column goes down, and then of course there's row reverse and column reverse, which can get very, very confusing once you're working with right to left versus left to right languages. And then wrap, once there are too many elements to fit on that row, then it'll wrap onto the next row. And then similarly, wrap reverse also reverses the direction so that while your first row might have been left to right, wrap reverse will reverse that order. And then we've got more properties, which are more about sort of how are we going to align flex items, what are called flex items, how are we going to arrange those within what's called the flex container. So in this case, we have the justify content and align items properties. And basically what they do is they allow you to take the entire piece, all of the children of that parent and put them in a specific arrangement within your flex box. So for instance, flex start puts it at the start of the flex box and flex end puts it at the end. Now if you're using a different orientation, then you want to make sure to account for that as well. Similarly, we've got center and we've got space between, which distributes all of the elements so that they're at the extremes as opposed to in the center. And space around actually provides a little bit of space for that edge so that there's a bit of space separating the edge of the flex box from the items inside. Now align items is basically what are the, it's on the cross axis. So what's the alignment of the items when it comes to the actual, where the items actually are? So in this case, align items flex start moves all of the flex items to the top of the flex container. Flex end moves them all down to the bottom of the flex container. And then you can see similarly we've got center and we've got stretch. And another value that you can actually use for light items is baseline, which basically takes the baseline of the text within the flex items and aligns those items to that baseline. So basically there's a little more you can do, which is how can we, instead of just aligning all the items, why don't we take the items as a unit and align them appropriately? So for example, you have aligned content, which takes all the items and moves them to the top flex end to something similar where it moves all the items down to the bottom and stretch does what you see here. Now for the flex items themselves, what sorts of properties are available there? Well, we've got the ability to determine the sequential order in which these items will be laid out. So the order property tells you, well, where do you want this to appear in relation to the other items? So if I, for example, have this child, for instance, had the property order with a value of 2, then it would appear after this particular child that you're seeing here. If it had a number that was lower, it would appear prior. It would be rendered prior. And similarly, flex grow and flex shrink are properties that allow you to actually manipulate the size of this item in relation to other items. And this is what's really great about Flexbox, is that you really don't need to know the size of the elements. This is really not important because what flex grow does is it actually allows you to assign a multiplier to the size of the element. And you can, you know, so for example, if I put a 2 in flex grow, it's going to take up double the size of what the default flex item size is. So the way that you define this sort of default flex item size is by using flex basis. And flex basis defines a width or height, depending on your orientation, that allows the flex item to be rendered appropriately and size appropriately. And then similarly, you can use exceptional values here for aligned self, which basically takes an arbitrary item, the item that you have chosen, for instance, this particular child, and aligns only that single child based on how you want it to be aligned. And of course, with any good set of CSS properties, there is a shorthand. So you can do flex colon, and that will apply to your flex items. And the shorthand for the flex container is flex flow. So now let's move on to some practical implications of this. Well, centering, for instance, is a total cinch. If you want to take any arbitrarily wide, arbitrarily high child of an element and put it in the center of an arbitrarily high, arbitrarily wide container, then this is easy peasy. All you got to do is declare display flex and margin auto. And that does exactly what you need it to do. Of course, flexbox support in browsers is not necessarily 100%. So we might need to stick with things like 50%, 50%, and that kind of stuff for a little while longer. And this is another very interesting one, so multi-column layout. This is actually part of a larger debate that's going on in the working group right now about the difference between fragmentation of markup and sort of unifying this markup. So CSS multi-column layout is very similar in a lot of ways to CSS regions. And CSS regions is a module that basically allows you to spill content into another area. So you have content in one element and you want to spill that into another content. For those of you familiar with things like tools like InDesign, for instance, we'll know exactly how that works when you have to spill something onto another page or spill something onto another column. But in this case, what we're dealing with here is instead of doing that, instead of fragmenting content, we're actually just applying this to the entire content so that there's no sort of... There's not necessarily any arbitrary spilling that you're determining going on. So in this case, we have a column count for how many columns there are and there's a shorthand for that as well. Then we have column gap, which determines the space between the columns and we have column rule, which determines the borderline between those rules. And this is just a general thing you can use. And then we have the break properties as well. So break before, break after. Let's say that you have a paragraph at the top of your content or somewhere in your content and you want it to always appear at the top of the column. Well, what you can always do is you can put break before and you can put break before always to make it... No matter what happens, or you can do break after... Sorry, break before column. To target the columns. So as you can see, this is very useful for book layout as well. And as we know, many, many more books have started to be styled and rendered using CSS. So this is absolutely essential for us. And then, of course, we have column fill, which basically prevents too much work from being done. It basically prevents too much weight in one column so you can have a very balanced set of columns that was very hard to do before. And, of course, column span, which is very similar to the spanning in tables, which allows you to fill out the entirety of the columns. So next, I'll talk a little bit about CSS shapes. So CSS shapes is really interesting. It's a natural step ahead from CSS masking, which allows the creation of paths that basically hide arbitrary portions of images. In this case, we're actually cutting the image. We're actually taking the image and cutting out parts. So, for instance, if you have a PNG that you're using and you want to make that into a shape, you can refer to that using the URL and then apply this shape image threshold property, which is actually an opacity value. So what this is saying right now is, first of all, I'm going to take this image that I've got and I'm going to find all the places in this image that have an opacity of one. I'm going to cut out everything that doesn't have that opacity, and then that's going to be my shape. So what we can do is we can actually, instead of having to work too hard to figure this out, we can also do arbitrary shapes. And this is something that is very impressive as well. One other thing I want to talk about just very quickly is there's new units in CSS, and one of them is VW. No, it's not Volkswagen. It is viewport width or viewport height. So as you can see, nowadays, as it gets more important to be responsive, you can now style, you can now determine the size of a particular element based on the overall viewport. So if you wanted to have, for instance, a header, or a heading, I'm sorry, that stretches across the entire viewport, or maybe is twice the viewport or half the viewport, that's very easy to do now. You don't have to do any sort of crazy calculations for that. So now I'll move on a little bit to sort of the mediest part of this, which is CSS variables. So very recently, probably in the last few months, CSS variables has become a much more important topic. And we know about how we're using variables in less than SAS, for instance, but why don't we go ahead and include them in the standard? Well, there's a lot of debate about this, and part of it is that at its core, CSS meant to be a purely presentational language or delve a little bit more into the programming space. And I'll talk a little bit more about that in a bit as well. So, for instance, here's a typical CSS file that has some variables, and then we apply those variables. What happens is that... I'm sorry, I'm missing a slide here. Okay, well, I think that... Okay, anyway, bear with me one second. So you can also apply custom properties, and I'll shift back to variables in a little bit. So one of the things that you can do is to actually assign these custom properties as variables, essentially. And these variables are only going to have scope within whichever declaration block you put them in. So, for instance, these two properties here, these two custom properties, which can be invoked as variables, are declared and they only have scope within those particular blocks. And so, how do we use those? Well, we use the var in CSS to go ahead and use those. So, now another... And of course, we can use things like CALC to actually work with those variables and actually change them in native CSS. Now, we're not looking at SCSS right now, we're looking at CSS right now. So, for instance, what you can do is you can have a lot of interaction going on between these various... between this huge variety of variables that you might have constructed in your CSS. Another thing you can do, actually, which is actually a huge step, which I think is gonna be... If it does actually go through all the way and become a recommendation by the consortium, would be very interesting, which is a fallback for variables. So that... Sorry, for properties that... No, I'm sorry, for variable values. So, if you have a border width, for instance, that is using the variable known as wide, well, if that's not set, you can just go back to this two-pixel fallback. And, you know, obviously what you can do with that is you can apply calculations based on that, for instance, here, which may or may not be what you want. So, these fallbacks can be very useful for interacting with CSS variables. Wow, I didn't realize that we're running out of time. Okay, so basically what we want to do, though, is, you know, let's say that we have a variable that's just an arbitrary number and we want to apply it to a unit so that we've got a unit that we can use. Well, there's not really a sort of really simple way to do this yet, so what we're doing is we're applying one unit of that unit and multiplying that by the number. So if you have an arbitrary number that's a unitless number and you want that to be applied to a unit, then you can use CALC for that. So, CSS Variables is currently available in Firefox 31. The use of variables in CSS and not in a preprocessor, it's gradually confirming this notion that CSS is really moving in a sort of more programming-oriented direction. We're already talking about functions in CSS, we're talking about variables in CSS, what else is there? So, the question then becomes, well, once CSS Variables actually does become a thing, our preprocessed variable is still useful. Then there's also CSS Extensions and this is something that has a very huge impact on the way that we would be able to interact with our CSS. So, basically using at-rule, custom selector, and you call it something using colon hyphen hyphen, and hyphen hyphen is a... was chosen because, you know, basically they... hyphen hyphen is never going to be used for anything else. So, it's now being used for variables. It's a little wacky, but it works. And so, you know, to the right, you've got all of those selectors that are going to fall into that custom selector, and now you can manipulate that custom selec... and style that custom selector as you see fit and, of course, go down into the children as well. So, this is another... you know, this is yet another proposal that really adopts the sort of functionality that we've been seeing from a CSS preprocessor. And it's very interesting to see, you know, things that are very, sort of, already out there in the wild available to do in SAS and less being adopted in the... or not adopted, but certainly being proposed in the CSS standard. Great. So, next, I'd like to move a little bit into HTML and talk just a little bit about Web Components. It'll be a very, sort of, basic introduction to Web Components, mostly because I do want to get to the end of the slides, and I know that we're pressed for time. So, what exactly are Web Components? Well, Web Components are... are potentially going to change the way that we're going to interact with a DOM. And the reason why is because there's actually a second DOM, so we'll talk about it shortly. So, Web Components permit the building of reusable widgets that are self-contained, which means that if you have, you know, for example, if you're using very modular CSS that you want to be able to apply anywhere, and you have some other styles and scripts that might be affecting those particular class names or identifiers, then Web Components actually allows you to take those out and remove them from being... being affected. So, the Shadow DOM is how basically Web Components, individual Web Components are able to be self-contained and unaffected by external styles of script. So, I'll talk about the Shadow DOM at length right now. So, basically, the Shadow DOM is a second DOM tree that defines another hierarchy while the first DOM tree is still preserved. So, this is actually, so, you know, now we're talking about this duality between in the dark and in the light. In the dark, and no, this is not Game of Thrones. In the dark is, you know, basically something that's in the Shadow DOM. In the light is something that's actually exposed to the DOM in the light, which means that it's always present and always able to be interacted with. So, a little bit of terminology, just first of all, Shadow Roots are nodes that are associated with the Shadow Hosts, which are elements outside of the Shadow DOM. So, Shadow Hosts are pieces of our elements that are entirely outside of the Shadow DOM. But as a child, underneath those elements appears the Shadow DOM. So, the Shadow Root is rendered instead of the Shadow Host and using JavaScript yields the Shadow Host. Let me just show you a practical example right now. So, this is not the, you know, not the most sort of bulletproof example, but let's just say that we're designing a box or, let's say, a button or something that's going to be used on an e-commerce website. And we've got this texture that says, buy it for $2. But, you know, really honestly, maybe, and, you know, this is debatable whether or not this falls into a question of semantics, but let's just assume, for the sake of argument, that this white text is the only semantically available text that we want to interact with. So, you know, for instance, we've got our style sheet, let's say, you know, for now, let's just put it in a style tag and we've got, you know, several divs that we can interact with. Well, what we actually want it to look like is not this huge, you know, div soup that has a lot of the stuff that we don't necessarily need. All we want is this. We just want a very quick and clear dollar amount or, let's say, euro amount. So, let's go ahead and put these unnecessary elements that we don't need into the shadow DOM, encapsulating it so that this sort of thing will actually never happen. So, here's what we do. And this is actually an idea that's relatively similar, as you'll see, to the way that we build a theme in Drupal. So, you know, we create a template that's going to house all of the code that we're encapsulating. Basically, we're taking that code that was the sort of meat that we had before and we're putting it into the shadow DOM. So, you put the style within that template, you put all of your stuff, and then, of course, you want to use a content element that's going to show that content of the element that you are, that you are hoping to show. So, here's a continuation. And, you know, the content element will be made up of material from the shadow host. So, how do we interact with this in JavaScript? Well, we've got a... We need to create several... I'm sorry. We need to create a shadow root. And that's the first thing that you can see here. We're assigning a variable, myShadow, and we're creating a shadow root that's going to... that we're going to interact with. And then we create a template that is going to have... the information that's in the shadow. So, we're going to take that template, and we're going to actually apply it to the DOM dynamically, so that this code is not actually appearing in the DOM that is original. It's actually appearing later because we're applying it, we're appending it as... through JavaScript. So, you know, let's say, for instance, that we need to localize that text. Instead of saying, buy it for, we need to, let's say, translate it into Spanish. Well, you know, that's actually something that's very easy because we can just change that text in the template, and it renders as it should. So, as you can see, this sort of decoupling of the content versus the... versus the actual templating material is something that we're very familiar with as, let's say, a theme or as a site builder. This is very similar conceptually to how these things work in Drupal theming. So, now let's say we want to create a custom element. Well, you know, we want to go ahead and, you know, take this buy it for text and make it into a buy it for element. And what we want to do is we want to use an element's prototype. Here, we're just using the sort of lowest level HTML element prototype to build this new element that we're going to be able to interact with. And as you can see, the result of this code is going to be that we can use this custom element to go ahead and render our content. And then we can also extend pre-existing elements. So, you know, if you want to take a button or a div or whatever, you know, you can go ahead and access that element's prototype and assign that to the document in such a way that you can extend these elements that are exist. And you would use the is attribute to actually show that that's taking place. And so what this does is that you can, you know, take a bunch of elements that you might have and interact with them in a lot of novel ways. So, that's great. Well, okay, you know, Web Components is not a new idea. It's been around for about a year or two. You know, and, you know, we've got a lot of information out there about that stuff. But what happens when we need to style in between the light and the dark? What happens when we need to interact with, let's say, the shadow DOM from, you know, using CSS that's outside of it, or access, let's say, the shadow host from CSS that's inside the shadow DOM? Well, the way that we do that is with CSS scoping. You know, these selectors right here are actually going to allow you to traverse that gap and to go back and forth. So, for instance, this first one here is the shadow host. And let's say, you know, for the sake of argument. So these examples, this example is taking place within the shadow tree, within the shadow DOM. You know, and please recall that the shadow host is actually outside of that shadow DOM and cannot necessarily be accessed. Well, we've got our colon host which is going to match to the shadow host. And then if we want to, you know, if we do want to specify it further, we can. And then host context is, you know, any sort of ancestor that's outside of the shadow tree. And then, you know, that's, you know, selecting basically from the dark into the light. Now, how do we select from the dark, from the light into the dark? Well, you know, we can use colon, colon shadow for that. So CSS scoping is still very much in its infancy. There's a lot of debate still going on, just like a lot of this material that I've just covered. And there's a lot of sort of flux that's happening with these ideas. But CSS scoping is one that has a huge impact on the way that we're able to interact with web components and the shadow DOM. And it should be very interesting for, you know, all of our projects to come. So I'd like to move a little bit now into sort of bringing this all together and talking just very broadly about some of these ideas that I've just discussed. You know, what does the future hold for HTML and CSS? You know, what does it look like in Drupal and in the web overall? Well, you know, a lot of these things that I've been talking about may not even make it to the final standard that the consortium is going to come out with. But, you know, it's still useful to talk about because a lot of these things are going to influence the way that Drupal changes in the next few years, five years, 10 years, what have you. And it's important for us to stay at the forefront of those advancements. So the first thing I want to say is that, you know, well, you know, CSS was always meant to be a very presentationally focused language. It was always meant to be something that was purely, you know, declarations of style, purely property value, purely, you know, that. And then we've got these new introductions of various, you know, functions and variables that we've been seeing, you know, things like, you know, calc and things like CSS variables. And, you know, this could be potentially risky because, you know, we have always worked with this dichotomy of, well, we're using CSS processors to do these really awesome programmatic things that we can't do with normal CSS. And, you know, that's sort of the point. That was really sort of, in a lot of ways, a lot of the point of a preprocessor was how do we actually do that? So where does CSS stop being a purely presentation language? And, again, you know, Web Components, they use JavaScript and, you know, a shadow DOM to construct elements on the page and render them. Well, you know, obviously we need to stay focused on what are the potential hazards for accessibility and progressive enhancement. And, but there's a lot of potential for Web Components from a theming perspective. And I'm sure that there'll be a lot, there has been and will be a lot of discussion about, about ways to leverage that. So, you know, these are just some, some questions that I had about this and, you know, just wanted to, you know, maybe have a bit of an open discussion and see what people think because I'm, you know, I'm certainly not an expert on this stuff. You know, I'm not going to call myself, you know, a sort of complete CSS expert just because, you know, I've, you know, there's a lot of people in this room that have a lot of knowledge. So, you know, let's learn from that. So with that in mind, here are some useful resources. I'm going to put this in a PDF of the slides that I'll go ahead and put on the website as well there. And some very useful tutorials and articles that are also very interesting reading for people who are interested in some of the larger debates about this kind of stuff and what's happening in HTML and CSS, sorry, in the CSS standard and also in ways that working with HTML are changing. So that's it. Thank you very much. Let me just end with a couple of notes. I'm currently working for a great company, Timing, and I just want to note that we are always looking for Drupal talent. And if you're interested in talking about Timing and interested in what sort of work we do, please feel free to come and talk to me. I'll have a bunch of stickers over here somewhere for you to pick up. And please don't forget to review this session. I know that I'll definitely find your feedback useful and I know that the conference organizers will as well. And with that, thank you very much.