Philip Walton / @philwalton
For a long time Web Components were primarily a Google effort, but now all browser vendors are on board.
Web Components will likely work natively in all browsers sometime in 2016.
When I submitted this talk proposal, Chrome had a native implementation of all the Web Component features.
But in order to reach consensus, the spec had to change.
That means, unfortunately, no browsers currently implement the latest standards.
createShadowRoot()method has been renamed to
<content select>element has been renamed to
<slot name>, and the
::shadow) have been removed.
I actually think CSS Developers have the most reason to care!
Hint, it's not these…
Selectors are globals. It's hard to write predictable code when any rule you write could potentially conflict with another rule you didn't know existed.
Writing bad selectors today will likely cripple your ability to makes changes to the front-end in the future.
Selectors that cast a wide net increase the chances of unintended matches.
And for whatever reason, people who write CSS like to live dangerously!
This is not a joke. This actually happened.
Maybe you're using a naming convention, or a linter, or something else that ensure your specificity is low and you're only targeting classes…
Are all these classes needed? What do they do? If I remove one of them will everything break? WTF is going on?
If selectors that depend the markup structure is bad, and if markup full of implementation details is bad, how should we be writing CSS?
The problem isn't that our CSS is bad, the problem is it's operating on far too much DOM.
The real question isn't "how do I write good CSS?" It's:
If I could change anything about HTML and CSS to make these problems easier to solve, what would it be?
As it turns out, Web Components gives us all of these.
Why should we change CSS? Aren't these problems already solved by:
But there are some key differences between the current solutions and Web Components:
Sold yet? Ok, let's dive in!
What is it, and how can I get me some?
Shadow DOM is a subtree of DOM nodes that you can create on any HTML element.
The shadow DOM subtree gets merged into the main DOM, but unlike the main DOM tree, shadow nodes can't be styled from outside.
In short, shadow nodes are private.
HTMLElement and then get registered on the document for use as a specific HTML tag.
Custom elements typically create a shadow root in their
createdCallback lifecycle method.
HTML Imports are a way to package up a custom element and any of its dependencies into a single file.
Other custom elements (or the main document) can then "import" the imports before using them.
Template are inert bits of DOM. By "inert" I mean their contents aren't processed by the browser.
Templates are typically used to define a reusable bit of DOM that can be cloned and assign to another DOM node.
super-element.html component definition:
Shadow DOM uses the
<content> element to define insertion points. The insertion points house the main DOM.
The main DOM:
Most software development techniques for modularity and code reuse center around two principles.
Inheritance generally establishes an is-a relationship.
The extending component will typically:
createdCallbackto create the base shadow root.
Composition generally establishes a has-a relationship.
The composing component will typically:
Composition usually involves building a complex element from simpler elements, or "base" elements.
The media object is a classic OOCSS base element.
Base elements typically define layout and positioning while leaving color and ornamentation unspecified.
<flex-grid> are very presentational, so you might not want to have them appear in your main document source.
Luckily, you don't have to.
The next example composes
<flex-line> in its shadow DOM to build the classic "Holy Grail" layout.
The main DOM:
The shadow DOM:
<profile-card-gallery>element, built using:
The main DOM:
The shadow DOM:
<profile-card-gallery> component uses CSS custom properties to pass style data to the
<flex-grid> element inside its shadow DOM.
Custom properties replace the shadow piercing combinators as the de facto way to style third-party components.
In some cases, it's unreasonable to create custom properties for all the possible CSS properties someone may want to style.
@apply rule allows component authors to opt-in to letting users of their component add any styles they want.
Custom properties work very well as a way to pass data through the shadow boundary in a way that a component can opt-in to receiving.
In addition to custom properties, a future spec will likely define custom pseudo-elements for more direct third-party styling.
Defining custom pseudo-elements in the Shadow DOM:
Referencing custom pseudo-elements in external CSS:
In many cases, a component will need to depend on a set of styles that don't make sense as individual Web Components.
To include those styles, add their contents to a style tag in the element's Shadow DOM.
All CSS rules are global and they often conflict with other rules in unexpected ways.
Managing the global nature of CSS at scale usually involves littering the HTML with implementation details.
Abstracting away these implementation details often requires complex build processes or templating systems that raise the barrier to entry for new developers.
And they do so at the platform level, so the barrier to entry remains low.
Verbose naming conventions will go away; they'll no longer be necessary.
CSS files will become smaller, self-contained style declarations that do one thing and one thing only.
Components will be styled by composing and extending existing styles.
Third-party component theming will be opt-in.
You can already use most Web Components features (with the exception of Shadow DOM) via the webcomponents.js polyfill.
I predict Shadow DOM will be available in all browsers within one year from today.
Start (or continue) thinking about your site design in terms of reusable components.
Use a methodology like BEM, SMACSS, or OOCSS, which will make the transition very natural.
The web platform will continue to work as it does today, long into the future. If Web Components aren't the best solution to your problem, feel free to use another solution.
Speaking for myself, I can't wait for a world in which Web Components, ES6 modules, and HTTP2 are all fully supported everywhere.
The future is bright!