The Media Object
How it's done today (using BEM syntax):
**
**
…
…
**Notice how div.Media-body serves no semantic purpose. It's a container elements that is purely presentational.
Solving those problems just requires a little memorization or Googling.
These aren't actually "hard" problems.
Hint, it's not these…
…it's 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.
Yes, they are.
In my experience, any attempt to style markup through selectors alone is inevitably going to fail.
Selectors that target HTML tags will always be vulnerable to future changes. Instead, your selectors should target classes.
Without thoughtful conventions, you end up with this:
Are all these classes needed? What do they do? If I remove one of them will everything break? WTF is going on? #FML
Good CSS consists of selectors that match exactly the elements you want without accidentally matching the elements you don't. All while not being overly verbose or repetitive, being resilient to change, and adaptable to any and all future design requirements.
In other words, writing good CSS means you need magical powers and the ability to predict the future.
In all seriousness, the people who are good at CSS recognize its shortcomings and approach new problems with those shortcomings in mind.
Methodologies like BEM, SMACSS, and OOCSS are invaluable tools for writing CSS today.
The real question isn't "how do I write good CSS?" its "how should we change CSS to make it harder to screw up?"
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 give us both of these.
Shadow DOM gives us real style scoping and encapsulation. We can add elements to the page that won't be affected by the existing CSS, and we can write style rules that won't affect the rest of the page.
Shadow DOM also allows us hide presentational elements from end users. Effectively creating a private and public API.
Shadow DOM is a subtree of DOM nodes that you can create on any HTML element.
The shadow subtree is ultimately rendered onto the page with the main DOM tree, but unlike the main DOM tree, shadow nodes can only be modified or styled from within.
In short, shadow nodes are private.
The main DOM:
The element's shadow DOM:
How it's done today (using BEM syntax):
…
**Notice how div.Media-body serves no semantic purpose. It's a container elements that is purely presentational.
The main DOM:
…
Shadow DOM:
…
~~The <author-card> imports the <media-object> and composes it within its own shadow DOM.
<flex-line> and <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 uses <flex-line> in its shadow DOM to build the classic "Holy Grail" layout.
Composed tree:
Sometimes CSS doesn't do exactly what you want, so you have to resort to hacks.
With shadow DOM, you can keep these hacks out of sight, where they belong.
Flex grid broken | Flex grid fixedCheck out polymer-project.org as well as chromestatus.com. Both are built entirely with Web Components using Polymer.
With the webcomponents.js polyfills you can get most of these features in all modern browsers (IE 10+).
Though some features (like full style encapsulation) cannot be polyfilled, and so keep that in mind.
Yes, the selectors ::shadow and /deep/ allow you to do this.
But as a general rule, you shouldn't ever do this. Well designed elements should make themselves sufficiently extensible.
To quote the open/closed principle:
Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.
The shadow DOM is your private API and the main DOM is your public API. Implementation details belong in the shadow DOM.
Also, dynamic content should go in the main DOM whenever possible. As a rule, Web Components should be static, bundleable, and cacheable.
Yes. Screen readers see the rendered tree in the same way that you see it (visually) when using your browser.
Since Web Components are just HTML, you can use ARIA roles and attributes just as you can today.
As with any emerging technology, test it on the devices you need to support.