Tags: shadow

11

sparkline

Web Components: The Long Game – Infrequently Noted

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.

Shadow DOM: fast and encapsulated styles – Monica Dinculescu

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.

Out of the (Drop)Shadows | Scott Jensen Design

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.

Namespaces - daverupert.com

Sometimes our job titles and distinctions feel like the plastic grass in a sushi bento; flimsy and only there for decoration.

Shadow DOM v1: self-contained web components | Web Fundamentals - Google Developers

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

A simple HTML5 Progress bar | Charlotte Jackson, Front-end developer

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!

Using Encapsulation for Semantic Markup on CSS-Tricks

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.

On the styling of forms by Bruce Lawson

Bruce takes a look at the tricky issue of styling native form controls. Help us, Shadow DOM, you’re our only hope!

Shadow is now Adobe Edge Inspect | Adobe Edge Inspect Team Blog

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 Shadow | preview mobile web - Adobe Labs

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.

Demo: CSS drop-shadows without images – Nicolas Gallagher

Some nice drop-shadow effects. Generated content is the key.