I Wanted To Type a Number | Filament Group, Inc., Boston, MA
Choosing the right input type for your form field.
Archive: August, 2016
82
| 5th | 10th | 15th | 20th | 25th | 30th | ||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 12am | |||||||||||||||||||||||||||||||
| 4am | |||||||||||||||||||||||||||||||
| 8am | |||||||||||||||||||||||||||||||
| 12pm | |||||||||||||||||||||||||||||||
| 4pm | |||||||||||||||||||||||||||||||
| 8pm |
Wednesday, August 31st, 2016
The web is not print and other stories
Rachel takes a look back at twenty years of building on the web. Her conclusion: we’ve internalised constraints that are no longer relevant, and that’s holding us back from exploring new design possibilities:
Somehow the tables have turned. As the web moves on, as we get CSS that gives us the ability to implement designs impossible a few years ago, the web looks more and more like something we could have build with rudimentary CSS for layout. We’ve settled on our constraints and we are staying there, defined by not being print.
Aria-Controls is Poop | HeydonWorks
I wrote a while back about how I switched from using a button to using a link for progressive disclosure patterns. That looks like it was a good move—if I use a button, I’d need to use aria-controls and, as Heydon outlines here, the screen reader support is pants.
Create awesome styles- Nucleus - Living style guide generator
Another style guide generator that parses comments in CSS.
Tuesday, August 30th, 2016
The Improbable, Bold History of Space Concept Art – How We Get To Next
A brief history of space concept art—Norman Rockwell, Chesney Bonestell, Robert McCall, Pat Rawlings, David Meltzer …all the classics.
Indicating offline | justmarkup
Some interesting interface ideas here for informing users when a service worker is doing its magic.
In the future users may expect a site to work offline after visiting again, but until this happens, I think it is a good idea to let the users know about this feature.
Passing Away In Pixels – The Interconnected
Justin has been thinking about how we ensure our digital legacy survives our passing.
Monday, August 29th, 2016
transceiver.frequency
Hypnotic.
The Long, Remarkable History of the GIF
The history of the GIF—a tale of licensing, compression, and standards.
How we made the RioRun progressive web app | Info | The Guardian
The devs at The Guardian walk through the process of building a progressive web app for the Olympics. There were some gotchas with the life cycle of service workers, but the pay-off was worth it:
Once you get there though, it’s quite magical when you load the page on a phone, switch it to airplane mode, reload, and continue using the app as though nothing was wrong.
MarkApp: Building apps with HTML
Here’s an interesting collection from Lea: small JavaScript libraries that do their configuration declaratively via HTML, rather than in JavaScript.
Thursday, August 25th, 2016
Mozilla Open Design – branding without walls
Mozilla are updating their brand identity and they’re doing it in the open. A brave, but fascinating move.
It’s Daphne.
The rise and fall of the Gopher protocol | MinnPost
A deep dive into the history of Gopher. For a while there, it looked like it was going to be bigger than the World Wide Web.
This article is filled with timely details:
The programmers were young guys, mostly in their 20s and, like McCahill, mostly huge Nirvana fans. Paul Lindner, a coding wunderkind from northern Minnesota who was dubbed the Gopher Dude for his evangelism, had long metal-head hair and signed Gopher emails with lyrics like “You have to spit to see the shine” from Babes in Toyland. Early Gopher servers were named Mudhoney, Danzig, and Anthrax.
Ah, Babes In Toyland! It’s like the soundtrack to my time in art college in the early 90s. I remember one of the best gigs ever being a triple bill of The Sultans Of Ping, Babes In Toyland, and Theraphy? at Sir Henrys in Cork.
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
Psiu Puxa Wallpapers
Yummy wallpapers for your desktop, tablet, and phone, from NASA and ESA.
SPACEPLAN
I thoroughly enjoyed playing this game. On the face of it, it seems like little more than a cow-clicker, but the way that the plot and the gameplay unfolds is really delightful.
This feels like the kind of game that would only work on the web—keep it in a browser tab in the background, revisiting occasionally throughout the day.
Marking up help text in forms
Zoe asked a question on Twitter recently:
#a11y folks: Is it still best to put form field instruction/help text inside the <label>, or is aria-describedby sufficient nowadays?
— Zoe M. Gillenwater (@zomigi) August 18, 2016
‘Sfunny—I had been pondering this exact question. In fact, I threw a CodePen together a couple of weeks ago.
Visually, both examples look the same; there’s a label, then a form field, then some extra text (in this case, a validation message).
The first example puts the validation message in an em element inside the label text itself, so I know it won’t be missed by a screen reader—I think I first learned this technique from Derek many years ago.
<div class="first error example">
<label for="firstemail">Email
<em class="message">must include the @ symbol</em>
</label>
<input type="email" id="firstemail" placeholder="e.g. you@example.com">
</div>
The second example puts the validation message after the form field, but uses aria-describedby to explicitly associate that message with the form field—this means the message should be read after the form field.
<div class="second error example">
<label for="secondemail">Email</label>
<input type="email" id="secondemail" placeholder="e.g. you@example.com" aria-describedby="seconderror">
<em class="message" id="seconderror">must include the @ symbol</em>
</div>
In both cases, the validation message won’t be missed by screen readers, although there’s a slight difference in the order in which things get read out. In the first example we get:
- Label text,
- Validation message,
- Form field.
And in the second example we get:
- Label text,
- Form field,
- Validation message.
In this particular example, the ordering in the second example more closely matches the visual representation, although I’m not sure how much of a factor that should be in choosing between the options.
Anyway, I was wondering whether one of these two options is “better” or “worse” than the other. I suspect that there isn’t a hard and fast answer.
Official Google Webmaster Central Blog: Helping users easily access content on mobile
Two pieces of good news from Google:
- 85% of websites qualify as mobile-friendly, so there’s no longer a need to explicitly label them as such in search results.
- Google will down-rank sites that have annoying pop-overs demanding you download an app or sign up to an email newsletter when you’re trying to read the damn page.
Why The Longplay Face | Collection
I giggled at quite of few of these mashups.
Empire of the Air: The Imperial Airship Service
The first in a series of articles looking at the history of British airships a century ago …just in time for the revival.
Tuesday, August 23rd, 2016
This week’s @asyncjs is looking mighty fine.
https://asyncjs.com/twofer-games-and-bots/
Go, @gablaxian, go!
Writing Less Damn Code | HeydonWorks
I’m in complete agreement with Heydon here:
But it turns out the only surefire way to make performant Web Stuff is also to just write less. Minify? Okay. Compress? Well, yeah. Cache? Sounds technical. Flat out refuse to code something or include someone else’s code in the first place? Now you’re talking.
Just like the “mobile first” mindset, if you demand that everything must justify its existence, you end up with a better experience for everyone:
My favorite thing about aiming to have less stuff is this: you finish up with only the stuff you really need — only the stuff your user actually wants. Massive hero image of some dude drinking a latte? Lose it. Social media buttons which pull in a bunch of third-party code while simultaneously wrecking your page design? Give them the boot. That JavaScript thingy that hijacks the user’s right mouse button to reveal a custom modal? Ice moon prison.
Hypothesis: if you really insist on using a pull quote online, you should apply aria-hidden=”true”.
Why do pull quotes exist on the web?
There you are reading an article when suddenly it’s interrupted by a big piece of text that’s repeating something you just read in the previous paragraph. Or it’s interrupted by a big piece of text that’s spoiling a sentence that you are about to read in subsequent paragraphs.
There you are reading an article when suddenly it’s interrupted by a big piece of text that’s repeating something you just read in the previous paragraph.
To be honest, I find pull quotes pretty annoying in printed magazines too, but I can at least see the justification for them there: if you’re flipping through a magazine, they act as eye-catching inducements to stop and read (in much the same way that good photography does or illustration does). But once you’re actually reading an article, they’re incredibly frustrating.
You either end up learning to blot them out completely, or you end up reading the same sentence twice.
You either end up learning to blot them out completely, or you end up reading the same sentence twice. Blotting them out is easier said than done on a small-screen device. At least on a large screen, pull quotes can be shunted off to the side, but on handheld devices, pull quotes really make no sense at all.
Are pull quotes online an example of a skeuomorph? “An object or feature which imitates the design of a similar artefact made from another material.”
I think they might simply be an example of unexamined assumptions. The default assumption is that pull quotes on the web are fine, because everyone else is doing pull quotes on the web. But has anybody ever stopped to ask why? It was this same spiral of unexamined assumptions that led to the web drowning in a sea of splash pages in the early 2000s.
I think they might simply be an example of unexamined assumptions.
I’m genuinely curious to hear the design justification for pull quotes on the web (particularly on mobile), because as a reader, I can give plenty of reasons for their removal.
Alas, tomorrow evening’s Brighton Homebrew Website Club is cancelled—apologies, my fellow website tinkerers.
Using Feature Queries in CSS ★ Mozilla Hacks – the Web developer blog
A thorough explanation of @supports from Jen, with plenty of smart strategies for using it in your CSS today.
If it weren’t for retargeting, we might not have ad blocking
The more I reflect on the current practices of the online advertising industry, the more I think that ad-blocking is a moral imperative.
10K Apart
The 10K competition—spiritual successor to Stewart Butterfield’s 5K.org—is back. This time there’s no escape clause with web fonts or jQuery. You can lazy-load in more content after the initial 10K payload …but whatever you’re building needs to be usable in that first 10K.
Give it a go. There’s nothing like having a constraint to really get the creative juices flowing.
What is React?
I’m in a similar position to Remy:
I don’t use React. I don’t really gravitate towards larger frameworks, only because my daily work doesn’t require it, and I’m personally more interested in the lower level techniques and parts of the web and JavaScript.
But, like Remy, I’m interested in knowing what are the ideas and techniques embedded within large frameworks that will end up making their way into the web stack:
What I want to know is: what should I be taking away from React into my own continued evolution as a web developer?
There are some good responses in the comments.
gmetais/sw-delta: An incremental cache for the web
Here’s an interesting use of service workers: figure out the difference (the delta) between the currently-cached version of a file, and the version on the network, and then grab only the bits that have changed. It requires some configuration on the server side (to send back the diff) but it’s an interesting approach that could be worth keeping an eye on.
Download Blisk - a browser for web developers
A browser aimed specifically at web developers. It’s got some nice features around mobile device emulation.
Tuesday, August 16th, 2016
Sick of being sick.
Monday, August 15th, 2016
Day four of man flu. Bored now.
My Olympics coverage choices are dressage and boxing. Neither appeals by themselves, but combined…
Sunday, August 14th, 2016
Watching WarGames and wondering if it’s the only Hollywood movie (so far) where machine learning saves the day.
Saturday, August 13th, 2016
Thursday, August 11th, 2016
Scored a Darwin coin today.
Wednesday, August 10th, 2016
Hacking at Homebrew Website Club Brighton.
Formspree
There’s this really common use-case I’ve seen at Codebar and Homebrew Website Club, where someone is making a static site, but they just want a contact form that sends data via email. This looks like a handy third-party service to do just that. No registration required: it’s all done via the value of the action attribute in the opening form tag:
action="https://formspree.io/your@email.com"
Daily oyster.
Tuesday, August 9th, 2016
Speaking Most Clearly When Not Speaking At All - Zeldman on Web & Interaction Design
I’ve always loved Jeffrey’s writing.
Popped into @brightsausco, where an episode of Hardcore History was playing. Had a nice chat about Dan Carlin …and I got sausages.
The History of the URL: Path, Fragment, Query, and Auth - Eager Blog
Another dive into the archives of the www-talk mailing list. This time there are some gems about the origins of the input element, triggered by the old isindex element.
Start Building Accessible Web Applications Today - Course by @marcysutton @eggheadio
A great series of short videos from Marcy on web accessibility.
Daily oyster.
Refactoring CSS Without Losing Your Mind // Speaker Deck
A talk from Harry on the whys and hows of refactoring CSS. He mentions the all: initial declaration, which I don’t think I’ve come across before.
Monday, August 8th, 2016
Summer salads.
Exploring web technologies
Last week, I had two really enjoyable experiences discussing completely opposite ends of the web technology stack.
Tuesday is Codebar day here in Brighton. Clearleft hosted it at 68 Middle Street last week. I really, really enjoy coaching at Codebar. I particularly like teaching the absolute basics of HTML and CSS. There’s something so rewarding about seeing the “a-ha!” moments when concepts click with people. I also love answering the inevitable questions that arise, like “why is it like that?”, or “how do I do this?”
Thursday was devoted to the opposite end of the spectrum. I ran a workshop at Clearleft with some developers from one of our clients. The whole day was dedicated to exploring and evaluating up-and-coming web technologies. Basically, it was a chance to geek out about all the stuff I’ve been linking to or writing about. During the workshop I ended up making a lot of use of my tagging system here on adactio.com:
- My thoughts on web components,
- Links to resources on web components,
- My posts on implementing service workers,
- Lots and lots of links to handy service worker resources,
- Links relating to performance,
- A whole bunch of accessibility links, and
- Everything I’ve linked to regarding progressive web apps.
Web components and service workers ended up at the top of the list of technologies to tackle, which was fortuitous, given my recent thoughts on comparing the two:
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?”
Those two questions turned out to be a good framework for the whole workshop. The question of how to evaluate technologies is something I’ve been thinking about a lot lately. I’m pretty sure it will be what my next conference talk is going to be all about.
You can read more about the structure of the workshop over on the Clearleft site. I’m looking forward to running it again sometime. But I’m equally looking forward to getting back to the basics at the next Codebar.
Can’t code, won’t code - cracking the secret of gender imbalance in STEM
Adult training represents a way into coding for millions of women who never learnt when they were younger. Meetups such as those run by organisations such as Women Who Code and Codebar can introduce women to the collaborative, problem-solving world of programming.
The day Herbie came to visit @Clearleft.
Creating An Accessible Modal Dialog
In the same vein as Hugo’s script, Ire walks through the steps involved in making an accessible modal window. Seeing all the thinking and code required for this really highlights the need for a way of making the document in the background inert.
“Researching Design Systems,” an article by Dan Mall
Dan has been researching the history of design systems, annotating as he goes.
Stuff I wish I’d known sooner about service workers
Some helpful “gotchas” that could save you some frustration if you’re starting out with service workers.
Progressive Enhancement for JavaScript App Developers | De Voorhoede
Build JS apps responsibly - cover your basics, render strategically and enhance into true apps.
Sunday, August 7th, 2016
sw-toolbox
If you’re going to dip your toes into the world of service workers, this handy library from the Chrome team is a good place to start.
The Future of Browser History — Free Code Camp
I’ve been thinking about this a lot lately. It feels like a user’s browser history is an incredibly rich seam of valuable information just waiting to be presented in a more interesting way.
The History of Email - Eager Blog
The ancestors of the Internet were kind enough to give us a communication standard which is free, transparent, and standardized. It would be a shame to see the tech communication landscape move further and further into the world of locked gardens and proprietary schemas.
The Forgotten Kaleidoscope Craze in Victorian England | Atlas Obscura
A wonderful investigation of a culture-shifting mobile device: the kaleidoscope. A classic Gibsonian example of the street finding its own uses for technology, this story comes complete with moral panics about the effects of augmenting reality with handheld devices.
(I’m assuming the title wasn’t written by the author—this piece deals almost exclusively with pre-Victorian England.)
Saturday, August 6th, 2016
Dropping into the Summer Homebrew Website Club gathering at The Marwood.
Sampling the Session IPA from Beercraft.
CSS Writing Mode
Some nifty layout tricks using the writing-mode property in CSS.
Service worker meeting notes - JakeArchibald.com
Jake has written up the notes from the most recent gathering to discuss service workers. If you have any feedback on any of the proposed changes or additions to the spec, please add them. This proposal is the biggie:
We’re considering allowing the browser to run multiple concurrent instances of a service worker.
Official Google Webmaster Central Blog: AMP your content - A Preview of AMP’ed results in Search
Google’s search results now include AMP pages in the regular list of results (not just in a carousel). They’re marked with a little grey lightning bolt next to the word AMP.
The experience of opening of those results is certainly fast, but feels a little weird—like you haven’t really gone to the website yet, but instead that you’re still tethered to the search results page.
Clicking on a link within an AMP spawns a new window, which reinforces the idea of the web as something separate to AMP (much as they still like to claim that AMP is “a subset of HTML”—at this point, it really, really isn’t).
React Isomorphic Demo
It is possible to use React without relying completely on client-side JavaScript to render all your content—though it’s certainly not the default way most tutorials teach React. This ongoing tutorial aims to redress that imbalance.
Besides the main benefit of server rendering giving faster page loads, it also enables large amounts of the site to run without JavaScript. There are many reasons why you would want this, but my personal reasons are that it allows you to completely drop support JavaScript in older browsers, but still have the site function.
25 years ago the world changed forever | W3C Blog
On August 6th, 1991, Tim Berners-Lee sent a message to alt.hypertext newsgroup announcing his WorldWideWeb project.
Friday, August 5th, 2016
Prioritising topics for discussion.
Inline SVG spriting and currentColor | Charlotte Jackson, Front-end developer
The currentColor value in CSS comes in very handy when you’ve got an SVG sprite and you want icons to inherit their colour from the surrounding text.
Homebrew Website Clubbers of Brighton—a whole day at Marwood tomorrow
https://indieweb.org/events/2016-08-06-homebrew-website-club-sprint
Alex Langley’s Tech Chat Episode 14 - Has digital technology changed everything or has it changed nothing? on Huffduffer
Myself and Lizzie were on a local radio show, having a wide-ranging chat about technology, commenting on recent news stories. It was fun.
ServiceWorker: A Basic Guide to BackgroundSync
A nice introduction to using Service Workers to enable syncing in the background: when the user is offline, tasks get queued up and then when the user is back online, those tasks execute.
Thursday, August 4th, 2016
It’s drinks o’clock in Brighton.
Wednesday, August 3rd, 2016
Horizontal lines around centered content
Here’s another clever CSS technique. It uses flexbox to add horizontal lines either side of centred content.
CSS only scroll indicator
This is witchcraft. I’ve been deconstructing the CSS to figure out how this works and it’s really clever.
(Hint: try commenting out some of the CSS and see what happens.)
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:
@adactio I will go to every standards meeting until I get it done, because otherwise we are hosed for <form> and web components.
— Monica Dinosaurescu (@notwaldorf) June 16, 2016
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.
Google’s AMP Project delivers on its promise of good performance: this message appeared blazingly quickly…
Tuesday, August 2nd, 2016
I get such a kick out of teaching HTML and CSS from scratch during @CodebarBrighton. It’s always invigorating and inspiring.
Battery Status readout as a privacy risk
The security research that went into improving the spec for the Battery Status API. This is why it’s so important that the web holds itself to high standard.
Even most unlikely mechanisms bring unexpected consequences from privacy point of views. That’s why it is necessary to analyze new features, standards, designs, architectures - and products with a privacy angle. This careful process will yield results, decrease the number of issues, abuses and unwelcome surprizes.
Hidden Expectations - daverupert.com
Over the years I’ve come to realize that most difficult part of making websites isn’t the code, it’s the “hidden expectations”, the unseen aspects I didn’t know were my responsibility when I started: Accessibility, Security, Performance, and Empathy.
Monday, August 1st, 2016
Writing conference talks is hard.
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.
Thinking and linking.