Snook has been on a roll lately, sharing lots of great insights into front-end development. This is a particularly astute post about that perennial issue of naming things.
A typically superb article by Aaron. Here, he breaks down a resilient approach to building for the web by examining the multiple ways you could add a button to a page. There’s a larger lesson here too:
We don’t control where our web-based products go or how our users access them. All we can do is imagine as many less-than-perfect scenarios as possible and do our best to ensure our creations will continue to do what they’re supposed to do. One of the easiest ways to do that is to be aware of and limit our dependencies.
Hidden little details that make a big difference for screen readers.
A website is only as beautiful as the underlying markup.
A glanceable one-stop-shop for how today’s browsers are dealing with today’s accessibility features. Then you can dive deeper into each one.
A pattern library of Walmart’s front-end code.
Three very easy to implement additions to scrollable areas of your web pages:
role="region", and an
Ooh, I really like this idea! Pointing to your Service Worker the same way you point to your style sheet makes a lot of sense to me.
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!
Use the right element for the job.
- Does the Control Take Me to Another Page? Use an Anchor.
- Does the Control Change Something on the Current Page? Use a Button.
- Does the Control Submit Form Fields? Use a Submit.
A complete list of HTML elements, past and present. They’re all hyperlinked to the relevant specs.
A nicely documented pattern library.
A linkbaity title for a ranty post. But it’s justified.
My point is that from an architectural perspective, most single page apps are the result of making the wrong choices and missing important opportunities.
Well, this is timely! Just today I was having a really good natter with Charlotte about using checkboxes, specifically sending multiple values to the server:
You’ll notice that the
namegiven to each of these checkbox
inputelements is the same: “reservation-requested-device”. The square brackets (“”) at the end of the
nameare the magic bit that allows the values of each chosen “reservation-requested-device” checkbox to be submitted as the value of “reservation-requested-device”.
See, I wasn’t sure whether that was just a PHP thing (the only server-side input-handling I’ve had much experience of) or whether it was a more general way of sending multiple values.
Update: It seems that the square brackets are indeed a PHP thing. Multiple values will be sent in any case. See this test case.
A really terrific article from Dan on building pattern libraries. In summary:
- Naming things is hard,
- Separation of content and presentation is A Good Thing.
There are some really good insights here into getting just the right level of abstraction for a component—not too tightly tied to a specific visual display, but also not too tightly tied to a specific kind of content type:
When thinking about patterns, content strategists are primarily thinking about Content patterns, designers are primarily thinking about Display patterns, and front-end developers are responsible for bringing the two together.
(And it’s great to see Charlotte’s excellent article get a shout-out in the “Related reading” section at the end,)
Marco gives a run-down of the basics of getting accessibility right on the web. Nothing here is particularly onerous but you’d surprised how often developers get this wrong (or simply aren’t aware of it).
He finishes with a plea to avoid unnecessary complexity:
It really isn’t hard to get the basics of accessibility right on the web …and yet those basics are often neglected.
Here’s a handy shortlist to run through, HIKE:
- H stands for headings and semantic markup.
- I stands for images and labels.
- K stands for keyboard navigation.
- E asks for you to ACT with a little extra love for custom components and more.
(ACT = ARIA, Colour Contrast, Text Size)
Written in 2001, this history of the web takes in CERN, hypertext, the ARPANET, SGML, and lots more.
This is a wonderful, wonderful look back at the state of hypertext in the run-up to the creation of the World Wide Web.
My jaw may have dropped when I saw the GML markup.
Now I’m going to read part two.
The best ARIA role is the one you don’t need to use.
This looks like a great resource for anyone setting out to learn how to make websites.
The A-Z of HTML, with an example for each and every element. Comprehensive and impressive.
A new presentation from the wonderfully curmudgeonly Steven Pemberton, the Nosferatu of the web. Ignore the clickbaity title.
This part really, really resonated with me:
The web is the way now that we distribute information. We will need the web pages we create now to be readable in 100 years time, just as we can still read 100-year-old books.
This is such an incredibly useful resource by Steve and Léonie: documenting how multiple screen readers handle each and every element in HTML.
It’s a work in progress, but it’s definitely one to remember the next time you’re thinking “I wonder how screen readers treat this markup…”
I’m so proud of Charlotte right now: last week she gave a conference talk and today she has an article published in A List Apart. Superb work on both fronts!
She does a great job of talking through a collaborative exercise to help teams move from thinking in pages to thinking in patterns.
The sad history of
I wish I could share in the closing optimism:
Now imagine the future where Web Components are supported natively, and someone else is allowed to write a <better-input>, an element that is a real, encapsulated DOM element, and not just a div soup. Imagine using this <better-input> that isn’t implemented differently in each browser, that looks the same everywhere, and that probably also knows how to bake you a cherry pie.
But I all I can think is:
Now imagine the future where Web Components are supported natively, and everyone is allowed to write a million variations of <my-idea-of-a-better-input>, an element that is an inaccessible div soup under the hood.
An alternate version of AMP HTML that works in more parsers and user agents.
The AMP project have “A new approach to web performance” making your website dependent on Google. The Be Nice AMP Project follow the old approach: Make your site fast following best practice guidelines and be independent of Google.
A nice combination of style guide and pattern library, with plenty of documentation.
This is a deep, deep dive into responsive images and I can only follow about half of it, but there are some really useful suggestions in here (I particularly like the ideas for swapping out images for print).
An in-depth look at where web components stand today, together with some very good questions about where they might be heading tomorrow.
Here’s a really nifty use of the
:checked behaviour pattern that Charlotte has been writing about—an interface for choosing a note from a piano keyboard. Under the hood, it’s a series of radio buttons and labels.
I like this nice straightforward approach. Instead of jumping into the complexities of the final interactive component, Chris starts with the basics and layers on the complexity one step at a time, thereby creating a more robust solution.
If I had one small change to suggest, maybe
aria-label might work better than offscreen text for the controls …as documented by Heydon.
A superb piece by Ross Penman on the importance of being true to the spirit of the web.
Github’s pattern library.
As always, it’s great to see how other organisations are tackling modular reusable front-end code (though I can’t imagine why anyone other than Github would ever want to use it in production).
Lea wasn’t happy with the lack of styling and extensibility of the datalist element, so she rolled her own lightweight autocomplete/type-ahead widget, and she’s sharing it with the world.
The Web is the printing press of our times; an amazing piece of technology facilitating a free and wide-scale dissipation of our thoughts and ideas. And all of it is based on this near 20-year old, yet timeless idea of the Hyper Text Markup Language.
I just noticed that I’m mentioned in the acknowledgements of this most handy of W3C documents. This pleases me disproportionately.
With all my talk about extending existing elements instead of making new ones, I was reminded of one of my favourite examples of custom elements in action: Github’s extensions of the
I completely share Bruce’s concern about the year-zero thinking that’s accompanying a lot of the web components marketing:
Snarking aside, why do so few people talk about extending existing HTML elements with web components? Why’s all the talk about brand new custom elements? I don’t know.
I’m a fan of web components. But I’m increasingly worried about the messaging surrounding them.
A history lesson and a love letter to the early web, taking in HTML, Photoshop, and the web standards movement.
Those were long years, the years of drop-shadows. Everything was jumping just slightly off the screen. For a stretch it seemed that drop-shadows and thin vertical columns of text would define the web. That was before we learned that the web is really a medium to display slideshows, as many slideshows as possible, with banner ads.
This strikes me as an eminently sensible idea by Emil: using the picture element to begin providing WebP alternatives to JPG.
Of course, picture-supporting browsers will have to adjust their decision-making algorithm to support this pattern.
Paul Ford’s potted history of web standards, delivered in his own inimitable style.
Reading through the standards, which are dry as can be, you might imagine that standardization is a polite, almost academic process, where wonks calmly debate topics like semicolon placement. This is not the case.
A great primer on using
picture. I think I’ll be referring back to this a lot.
Following on from that post of Jason’s I linked to, Chris also emphasises that, for most use cases, you probably only need to use srcset (and maybe sizes), but not the picture element with explicit sources.
It’s really, really great that people are writing about this, because it can be quite a confusing topic to wrap your head around at first.
Léonie gives a great, clear description of how screen readers switch modes as they traverse the DOM snapshot.
Jason points out that the picture element might not be needed for most responsive image use cases; the srcset and sizes attributes will probably be enough—that’s what I’m doing for the photos on my site.
Remember when I was talking about refactoring the markup for Code for America? Well, it turns out that Heydon Pickering is way ahead of me.
He talks about the viewpoint of a writer (named Victoria) who wants to be able to write in Markdown, or HTML, or a textarea, without having to add classes to everything. That’s going to mean more complex CSS, but it turns out that you can do a lot of complex things in CSS without using class selectors.
There are slides.
Some very handy techniques for working with right-to-left text.
This (literally) charts the evolution of HTML, tracking which elements have been added and which have been removed.
A lovely little tale of empowerment through HTML and CSS.
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.
A look at how the website for An Event Apart is using the picture and Picturefill …featuring Jessica as the cover girl.
A truly wonderful piece by Mandy detailing why and how she writes, edits, and publishes on her own website:
No one owns this domain but me, and no one but me can take it down. I will not wake up one morning to discover that my service has been “sunsetted” and I have some days or weeks to export my data (if I have that at all). These URLs will never break.
A great article by Susan on getting started with creating a styleguide for any project.
I’ve seen firsthand how style guides save development time, make communication regarding your front end smoother, and keep both code and design consistent throughout the site.
Funny because it’s true:
The thing I regret the most is how my class addiction affected my relationship with HTML.
A great post from Anna on the front-end styleguides she’s worked on for A List Apart and Code for America. ‘Twas a pleasure working with her on the Code for America project.
A-mer-ica! Fuck yeah!
A fascinating look at the early history of HTML, tracing its roots from the dialect of SGML used at CERN.
Another front-end style guide for the collection. This time it’s from A List Apart. Lovely stuff!
A nice bit of markup archeology, tracing the early development of HTML from its unspecced roots to the first drafts.
I recognise some of the extinct elements from the line-mode browser hack days at CERN e.g. HP1, HP2, ISINDEX, etc.
A fascinating snapshot from 1995, arguing for the growing power of HTML instead of the siren song of proprietary formats.
I’m very happy that this is still available to read online 18 years later.
The authors of the Extensible Web Manifesto explain the thinking behind their …uh… thinking.
Alex starts with a bit of a rant about the phrase “semantic HTML”, which should really just be “well-written HTML, but there then follows some excellent thoughts on the emergence of meaning and the process of standardising on vocabularies.
Hot on the heels of the Mailchimp styleguide, here’s the collection of patterns used by Mapbox. I’m not keen on some of their markup choices, but again, it’s great to see organisations publicly documenting this stuff.
The definition of the cite element (and the blockquote element) has been changed for the better in HTML5 …at least in the W3C version anyway.
A love letter to HTML, prompted by the line-mode browser hack event at CERN.
Once you get past the cheesy intro music, there are some gems from Robert Cailliau in here.
Jason provides some instruction in using the correct quotation marks online.
Go, Dan, go!
The semantics of the cite element are up for discussion again. Bruce, like myself, still thinks that we should be allowed to mark up names with the cite element (as per HTML 4), and also that cite elements should be allowed inside blockquotes to indicate the source of the quote.
Let’s pave that cowpath.
A very, very clever hack to provide fallback images to browsers that don’t support SVG. Smart.
A very handy starting point for creating a front-end style guide.
I kind of love the interaction design of this site.
A terrific case study in progressive enhancement: starting with a good ol’ form that works for everybody and then adding on features like Ajax, SVG, the History API …the sky’s the limit.
This is wonderful stuff! I’m a big fan of the
datalist element but I hadn’t realised how it could be combined with
input types like
Here are some nice patterns that Paul uses for starting points in his own projects.
Related to my rant on links that aren’t actually links: buttons that aren’t actually buttons.
You’re probably doing each of these already but just in case your’e not, Andy has listed six quick wins you can get from HTML5.
Bruce takes a look at the tricky issue of styling native form controls. Help us, Shadow DOM, you’re our only hope!
A good explanation of HTML5’s sectioning content and outline algorithm.
Bruce sits down for a chat with Hixie. This is a good insight into the past and present process behind HTML.
Here’s a treasure trove of web history: an archive of the www-talk list dating back to 1991. Watch as HTML gets hammered out by a small group of early implementors: Tim Berners-Lee, Dave Raggett, Marc Andreessen, Dan Connolly…
Why you should say HTML classes, CSS class selectors, or CSS pseudo-classes, but not CSS classes - Tantek
I love that Tantek is as pedantic as I am …although I don’t think “pedantic” is exactly the right word.
Tantek has put together a wiki page to document the arguments for and against adding a new “main” element to HTML.
A handy step-by-step guide to scraping HTML to get data out. Useful for services (—cough—Twitter—cough—) that keep changing the rules of their API use.
Less wireframing, more prototyping.
Bruce’s thoughts on the proposed inclusion of a “content” or “maincontent” element in HTML5.
Personally, I don’t think there’s much point in adding a new element when there’s an existing attribute (role=”main”) that does exactly the same thing.
Also, I don’t see much point in adding an element that can only be used once and only once in a document. However, if a “content” or “maincontent” element could be used inside any sectioning content (section, article, nav, aside), then I could see it being far more useful.
A really great markup and CSS pattern for “content first, navigation second” from Aaron.