Tags: element

34

sparkline

Sunday, January 14th, 2018

Meet the New Dialog Element

Move over, JavaScript alerts; HTML dialogs are here.

Saturday, January 6th, 2018

A Sliding Nightmare: Understanding the Range Input | CSS-Tricks

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.

Tuesday, November 28th, 2017

i is=”the walrus”

In which Brian takes a long winding route through an explanation of why the is attribute for custom elements is dead before he demonstrates the correct way to use web components:

<!-- instead of writing this -->
<input type="radio" is="x-radio">

<!-- you write this -->
<x-radio>
<input type="radio">
</x-radio>

Sadly, none of the showcase examples I’ve seen for web components do this.

Monday, October 2nd, 2017

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.

Thursday, August 24th, 2017

Mapping in HTML – a proposal for a new element – Terence Eden’s Blog

I quite like this proposal for geo element in HTML, especially that it has a fallback built in (like video). I’m guessing the next step is to file an issue and create a web component to demonstrate how this could work.

That brings up another question: what do you name a custom element that you’d like to eventually become part of the spec? You can’t simply name it geo because you have to include a hyphen. geo-polyfill? geo-proposal? or polyfill-geo? proposal-geo?

Monday, June 12th, 2017

An intro to web components with otters – Monica Dinculescu

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).

Tuesday, May 2nd, 2017

Creating a pattern library in Sketch, Roobottom.com

A smart approach to creating patterns as symbols in Sketch. Sounds like diligence and vigilance is required to make it work, but then, that’s true of any pattern library.

Friday, February 17th, 2017

The average web page from top twenty Google results

Ever wondered what the most commonly used HTML elements are?

Thursday, November 10th, 2016

Custom Elements: an ecosystem still being worked out - Tales of a Developer Advocate

Really, really smart thinking from Paul here, musing on the power relationship between the creators of custom elements and the users of custom elements.

Sunday, November 6th, 2016

Create a MarkDown tag - JSFiddle

This is nice example of a web component that degrades gracefully—if custom elements aren’t supported, you still get the markdown content, just not converted to HTML.

<ah-markdown>
## Render some markdown!
</ah-markdown>

Tuesday, November 1st, 2016

Mutating the active element - ally.js

Rodney has done some great research into how different browsers respond to a focusable element becoming inactive (by being made disabled, hidden, or removed).

Wednesday, August 24th, 2016

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

Wednesday, August 3rd, 2016

Extensible web components

Adam Onishi has written up his thoughts on web components and progressive enhancements, following on from a discussion we were having on Slack. He shares a lot of the same frustrations as I do.

Two years ago, I said:

I have conflicting feelings about Web Components. I am simultaneously very excited and very nervous.

I still feel that way. In theory, web components are very exciting. In practice, web components are very worrying. The worrying aspect comes from the treatment of backwards compatibility.

It all comes down to the way custom elements work. When you make up a custom element, it’s basically a span.

<fancy-select></fancy-select>

Then, using JavaScript with ShadowDOM, templates, and the other specs that together make up the web components ecosystem, you turn that inert span-like element into something all-singing and dancing. That’s great if the browser supports those technologies, and the JavaScript executes successfully. But if either of those conditions aren’t met, what you’re left with is basically a span.

One of the proposed ways around this was to allow custom elements to extend existing elements (not just spans). The proposed syntax for this was an is attribute.

<select is="fancy-select">...</select>

Browser makers responded to this by saying “Nah, that’s too hard.”

To be honest, I had pretty much given up on the is functionality ever seeing the light of day, but Monica has rekindled my hope:

Still, I’m not holding my breath for this kind of declarative extensibility landing in browsers any time soon. Instead, a JavaScript-based way of extending existing existing elements is currently the only way of piggybacking on all the accessible behavioural goodies you get with native elements.

class FancySelect extends HTMLSelectElement

But this imperative approach fails completely if custom elements aren’t supported, or if the JavaScript fails to execute. Now you’re back to having spans.

The presentation on web components at the Progressive Web Apps Dev Summit referred to this JavaScript-based extensibility as “progressively enhancing what’s already available”, which is a bit of a stretch, given how completely it falls apart in older browsers. It was kind of a weird talk, to be honest. After fifteen minutes of talking about creating elements entirely from scratch, there was a minute or two devoted to the is attribute and extending existing elements …before carrying as though those two minutes never happened.

But even without any means of extending existing elements, it should still be possible to define custom elements that have some kind of fallback in non-supporting browsers:

<fancy-select>
 <select>...</select>
</fancy-select>

In that situation, you at least get a regular ol’ select element in older browsers (or in modern browsers before the JavaScript kicks in and uplifts the custom element).

Adam has a great example of this in his post:

I’ve been thinking of a gallery component lately, where you’d have a custom element, say <o-gallery> for want of a better example, and simply populate it with images you want to display, with custom elements and shadow DOM you can add all the rest, controls/layout etc. Markup would be something like:

<o-gallery>
 <img src="">
 <img src="">
 <img src="">
</o-gallery>

If none of the extra stuff loads, what do we get? Well you get 3 images on the page. You still get the content, but just none of the fancy interactivity.

Yes! This, in my opinion, is how we should be approaching the design of web components. This is what gets me excited about web components.

Then I look at pretty much all the examples of web components out there and my nervousness kicks in. Hardly any of them spare a thought for backwards-compatibility. Take a look, for example, at the entire contents of the body element for the Polymer Shop demo site:

<shop-app unresolved="">SHOP</shop-app>

This seems really odd to me, because I don’t think it’s a good way to “sell” a technology.

Compare service workers to web components.

First of all, ask the question “who benefits from this technology?” In the case of service workers, it’s the end users. They get faster websites that handle network failure better. In the case of web components, there are no direct end-user benefits. Web components exist to make developers lives easier. That’s absolutely fine, but any developer convenience gained by the use of web components can’t come at the expense of the user—that price is too high.

The next question we usually ask when we’re evaluating a technology is “how well does it work?” Personally, I think it’s just as important to ask “how well does it fail?”

Service workers work well and fail well. If a browser supports service workers, the user gets all the benefits. If a browser doesn’t support service workers, the user get the same experience they would have always had.

Web components (will) work well, but fail badly. If a browser supports web components, the user gets the experience that the developer has crafted using these new technologies. If a browser doesn’t support web components, the user gets …probably nothing. It depends on how the web components have been designed.

It’s so much easier to get excited about implementing service workers. You’ve literally got nothing to lose and everything to gain. That’s not the case with web components. Or at least not with the way they are currently being sold.

See, this is why I think it’s so important to put some effort into designing web components that have some kind of fallback. Those web components will work well and fail well.

Look at the way new elements are designed for HTML. Think of complex additions like canvas, audio, video, and picture. Each one has been designed with backwards-compatibility in mind—there’s always a way to provide fallback content.

Web components give us developers the same power that, up until now, only belonged to browser makers. Web components also give us developers the same responsibilities as browser makers. We should take that responsibility seriously.

Web components are supposed to be the poster child for The Extensible Web Manifesto. I’m all for an extensible web. But the way that web components are currently being built looks more like an endorsement of The Replaceable Web Manifesto. I’m not okay with a replaceable web.

Here’s hoping that my concerns won’t be dismissed as “piffle and tosh” again by the very people who should be thinking about these issues.

Monday, August 1st, 2016

Web Components and progressive enhancement - Adam Onishi

Adam and I share the same hopes and frustrations with web components. They can be written in a resilient, layered way that allows for progressive enhancement, but just about every example out there demonstrates a “my way or the highway” approach to using them.

We were chatting about this in the Design Systems slack channel, and it helped clarify some of my thoughts. I’ll try to poop out a blog post about this soon.

Tuesday, July 26th, 2016

shawnbot/custom-elements: All about HTML Custom Elements

A good introduction to custom elements, one piece of the web components stack.

That said, when using custom elements—or anything involving JavaScript, for that matter—you should always design experiences for progressive enhancement, and plan for the possibility that JavaScript isn’t enabled or available.

Hmmm …that’s kind of hard when JavaScript is required to make custom elements work at all.

Tuesday, July 12th, 2016

The Search For The Holy Grail: How I Ended Up With Element Queries, And How You Can Use Them Today – Smashing Magazine

An attempt to crack the element query nut. It relies on executing JavaScript at runtime so it doesn’t feel production-ready to me unless you’re already relying on JavaScript to render or style your content. Still, there’s a lot of good thinking has gone into the syntax—it’s worth investigating for that reason alone.

Thursday, March 10th, 2016

Jon Aizlewood | Visual inventories for agile design

Jon outlines his technique for keeping “the 30,000 foot” view when patterns are coalescing during a project.

See also: Andy P.’s experience of working with Jon this way.

Wednesday, March 9th, 2016

Styling Broken Images

This is really, really clever. You can’t use generated content (:before and :after) on replaced content. The img element is replaced content …but only when the image actually loads. So if the image fails to load, you can apply specific fallback styles (using :before and :after).

Tuesday, January 26th, 2016

The elements of HTML

A complete list of HTML elements, past and present. They’re all hyperlinked to the relevant specs.

Friday, August 21st, 2015

CSS element() function - Vincent De Oliveira

Fire up Firefox and try out these demos: the CSS element value is pretty impressive (although there are currently some serious performance issues).

To put it simply, this function renders any part of a website as a live image. A. Live. Image!