This is a great tutorial—I just love the interactive parts that really help make things click.
Greg has done a lot of research into developer frustrations with customising form controls.
My current thinking in this space, and I know some folks will find this controversial, but I think we should completely standardize in-page form controls with no limitations on their styling capabilities. What do I mean by in-page controls? I am referring to any form control or component that is rendered within the content process. This standardization would include the sub-parts and their related states and how these are exposed (probably through CSS psuedo classes or HTML attributes). This will enable the shadow-dom to be encapsulated while providing web developers with a consistent experience to adjust to match their brand and needs of their site/application.
document.querySelectorfirst 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.
Bringing gradients back, baby!
This is going to be a handy reference to keep on hand whenever you want a button to actually look like a button.
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
Ana goes into exhaustive detail on all the differences in the shadow DOM and styling of
input type="range" across browsers.
I’m totally fine with browsers providing different styling for complex UI elements like this, but I wish they’d at least provide a consistent internal structure and therefore a consistent way of over-riding the default styles. Maybe then people wouldn’t be so quick to abandon native elements like this in favour building their own UI components from scratch—the kind of over-engineering that inevitably ends up being under-engineered.
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:
Although, in a way, Shadow DOM is also another flavour of CSS-in-JS:
Can an opinionated flat design still have depth and truly be free of drop shadows?
Scott proposes a technique that mimics atmospheric perspective—y’know, when things in the distance look hazier than things in the foreground.
The fact is, we are surrounded by a world that is full of depth, and very little of it is defined by shadow. If we are going to replace drop shadows in our visual UI metaphors, we should look at other options that create depth in the world around us.
Sometimes our job titles and distinctions feel like the plastic grass in a sushi bento; flimsy and only there for decoration.
An in-depth look at the current Shadow DOM spec. It’s well-written but I don’t think this will really click with me until I start playing around with it for myself.
It’s good to see that the examples have some thought given to fallback content.
There’s also a corresponding tutorial on custom elements
I love this little markup pattern: simple, accessible and elegant …with some quirky CSS gotchas around styling non-standard prefixed pseudo-elements. They came from the Shadow DOM …dun dun DUN!
I really hope that this is the kind of usage we’ll see for web components: enhancements for the browsers that support them without a good ol’ fashioned fallback for older browsers.
Bruce takes a look at the tricky issue of styling native form controls. Help us, Shadow DOM, you’re our only hope!
Oh, dear. Adobe Shadow gets a new name and a hefty price tag. Yesterday it was free. Today it is $119.88 per year. It’s useful but it’s not that useful.
So, lazy web, who’s working on an open-source alternative?
Adobe have launched their version of Weinre, the tool that allows you to refresh and debug iOS and Android browser views from your desktop computer.
Some nice drop-shadow effects. Generated content is the key.