Scope Proposal & Explainer
This detailed proposal from Miriam for scoping CSS is well worth reading—it makes a lot of sense to me.
This detailed proposal from Miriam for scoping CSS is well worth reading—it makes a lot of sense to me.
I’m very taken with Github’s tab-container element—this is exactly how I think web components should be designed!
Sit down and listen to a story from uncle Ethan.
I’ve often said that the goal of a good library should be to make itself redundant. jQuery is the poster child for that, and this article points to web components as the way to standardise what’s already happening in JavaScript frameworks:
Remember when
document.querySelector
first got wide browser support and started to end jQuery’s ubiquity? It finally gave us a way to do natively what jQuery had been providing for years: easy selection of DOM elements. I believe the same is about to happen to frontend frameworks like Angular and React.
The article goes on to give a good technical overview of custom elements, templates, and the Shadow DOM, but I was surprised to see it making reference to the is
syntax for extending existing HTML elements—I’m pretty sure that that is, sadly, dead in the water.
A time capsule for the long now. Laser-etched ceramic tablets in an Austrian salt mine carry memories of our civilisation in three categories: news editorials, scientific works, and personal stories.
You can contribute a personal story, your favorite poem, or newspaper articles which describe our problems, visions or our daily life.
Tokens that mark the location of the site are also being distributed across the planet.
A good explanation of web components, complete with some code examples.
Web Components are not a single technology. Instead, they are series of browser standards defined by the W3C allowing developers to build components in a way the browser can natively understand. These standards include:
- HTML Templates and Slots – Reusable HTML markup with entry points for user-specific markup
- Shadow DOM – DOM encapsulation for markup and styles
- Custom Elements – Defining named custom HTML elements with specific behaviour
A quick guide to all the font-variant-...
stuff in CSS.
One of the things we’d hoped to enable via Web Components was a return to ctrl-r web development. At some level of complexity and scale we all need tools to help cope with code size, application structure, and more. But the tender, loving maintainance of babel and webpack and NPM configurations that represents a huge part of “front end development” today seems…punitive. None of this should be necessary when developing one (or a few) components and composing things shouldn’t be this hard. The sophistication of the tools needs to get back to being proportional with the complexity of the problem at hand.
I completely agree with Alex here. But that’s also why I was surprised and disheartened when I linked to Monica’s excellent introduction to web components that a package manager seemed to be a minimum requirement.
Monica explains how Shadow DOM could be the perfect answer for scoping CSS:
We didn’t have style encapsulation, so we started naming things “the right way” with BEM, so that we didn’t accidentally stomp over each other’s styles. We wanted to be able to author CSS from inside a JavaScript component, so we started using CSS-in-JS. We needed all these tools, because “the platform” (read: the browsers that be) wasn’t there, and building these tools showed that there was a need to move forward. For style encapsulation, Shadow DOM is the platform moving forward.
Although, in a way, Shadow DOM is also another flavour of CSS-in-JS:
Before you complain that using a Shadow DOM and Web Components means that it absolutely requires JavaScript: this is true.
Dave explains how Jekyll Includes are starting to convert him to web components. The encapsulation is nice and neat. And he answers the inevitable “but why not use React?” question:
Writing HTML that contains JavaScript, not JavaScript that contains HTML, feels good to me.
The key feature for me is that this approach doesn’t have to depend on JavaScript in the browser:
I like that Web Components are an entirely client-side technology but can be rendered server-side in existing tech stacks whether it’s Jekyll, Rails, or even some Enterprise Java system.
A really great introduction to web components by Monica. But I couldn’t help but be disheartened by this:
Web components tend to have dependencies on other web components, so you need a package manager to herd all them cats.
For me, this kind of interdependence lessens the standalone nature of web components—it just doesn’t feel quite so encapsulated to me. I know that this can be solved with build tools, but now you’ve got two problems (and one more dependency).
Prompted by the way Craig is handling the shutdown of hi.co, Glenn Fleishman takes a look at other digital preservation efforts and talk to Laura Welcher at the Long Now Foundation.
A time capsule is bottled optimism. It makes material the belief that human beings will survive long enough to retrieve and decode artifacts of the distant past.
Smart thinking from Harry here on a common issue when it comes to naming and styling. As he points out, the solution is not technical, but lies in how you form your mental model:
The design issue here is solved by subtly inverting the problem.
On 18 May 2010, the Planets (Preservation and Long-term Access through Networked Services) Project deposited a time capsule in the vaults of datacenter, Swiss Fort Knox, in Saanen, Switzerland. It contained the decoding information for five digital file formats on media ranging from paper, microfilm and floppy discs to CDs, DVDs and USB sticks.