Hidden little details that make a big difference for screen readers.
A website is only as beautiful as the underlying markup.
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.
Mark has dumped his brains!
Seriously, there is a lot of thought that has gone into this, and it’s just the beginning: Mark recounts the experience that Clearleft has had with delivering pattern libraries, laying the groundwork for releasing the library-generating tool that he has been building.
Watch this space.
Adrian runs through the history of well-crafted websites:
- 1990s: Dynamic websites
- 2002: All-CSS layouts
- 2003: Nice URLs
- 2005: Ajax
- 2009: Custom web fonts
- 2010: Responsive web design
I think he’s absolutely right with his crystal ball too:
What’s a big hint that a site is crafted by forward-looking web developers? I’d say it’s service workers, the most interesting thing happening in web development.
But leaving trends aside, Adrian reminds us:
Some things never go out of style. None of the following is tied to a particular time or event, but each is a sign a website was made by people who care about their craft:
- Semantic markup
- Following accessibility standards
Ted has snuck a blog post out from behind Apple’s wall of silence, and it’s good news: WebKit is not going to use vendor prefixes for new features.
Here’s a well put-together collection of common patterns that are now much easier thanks to flexbox.
This could be a handy replacement for some Google Charts images of graphs. It uses SVG and is responsive by default.
I bet it wouldn’t be too tricky to use this to make some sparklines.
If you want to keep up to date with all the coolest stuff landing in CSS, I recommend bookmarking this ever-changing page.
As well as compèring the event, Chris took the time to make notes at the Clarity conference, dedicated to all things patterny.
This looks like it could be a very nifty tool to have at your disposal while coding. I like that it’s editor-agnostic.
I quite like this step-by-step interface for a form, all cleverly handled with the
:focus pseudo-class. I’d want to refine some of the usability issues before using it in production, but the progressive disclosure is nice.
Here’s a clever way to get text centred when it’s short, but left-aligned when it wraps.
Two (similar) patterns for responsive navigation that don’t involve sweeping everything behind a hamburger icon.
When I’ve experimented with auto-overflowing horizontal patterns like this, I’ve found that a judiciously-placed box shadow can give a nice affordance.
Everything you ever wanted to know about CSS pseudo-classes (and pseudo-elements).
While many challenges remain, the good news is … it’s progressive. Developers can already see the benefits by sprinkling in these technologies to their existing websites and proceed to build on them as browsers and operating systems increase support.
Well, this is rather wonderful! A one-stop-shop for exploring UI patterns on CodePen …this is going to be time sink.
Here’s an interesting proposal from ppk: use
requestAnimationFrame to gauge how performant a browser in behaving and then enhance accordingly.
Rachel compares two CSS layout modules; Grid and Flexbox. This distinction is crucial:
Flexbox is essentially for laying out items in a single dimension – in a row OR a column. Grid is for layout of items in two dimensions – rows AND columns.
You know that front-end pattern libraries have hit the mainstream when the Nielsen Norman Group get in on the action.
As ever, I’m not sure their sweeping generalisations can be applied to every project, but their checklist approach makes for a good starting point.
Some good thoughts in here about writing scalable CSS …although the finger-pointing at sites (that are shipping at scale) reminds me a bit of that quote by copywriter Paul Butterworth: “Where the heck were you when the page was blank?”
Vitaly calls them dirty tricks but this is a handy collection of front-end development techniques. They’re not really dirty …just slightly soiled.
Minimum viable Service Worker tutorial. Copy, paste, and don’t ask questions.
Well, I’m convinced.
Remy sums up the psychological end goal of progressive apps (HTTPS + Service Worker + manifest JSON file) prompting an add to home screen action:
This high bar of entry will create a new mental model for our users.
If I add this app to my home screen, it will work when I open it.
It’s a shame that this charge to turbo-boast the perception of the web on mobile is a bit one-sided: I would love to see Apple follow Google’s lead here. But if Android succeed in their goal, then I think iOS will have to follow suit just to compete.
I don’t care about Opera Mini (I’m not its Product Manager). In the same way, I don’t care about walking sticks, wheelchairs, mobility scooters or guide dogs. But I care deeply about people who use enabling technologies — and Opera Mini is an enabling technology. It allows people on feature phones, low-powered smartphones, people in low-bandwidth areas, people with very small data plans, people who are roaming (you?) connect to the web.
Just recently on a Clearleft project, some of us were discussing whether there was a reason not to use
rems instead of
ems for media queries. Apart from one older browser implementation difference, we couldn’t come up with much.
Some in-depth research here supports the use of
em values for media queries. Very good to know.
Some solid sensible advice on optimising performance.
I hadn’t heard of the
save-data header. This article shows how you can use a Service Worker to sniff for it and serve up smaller assets, but I’m guessing you could also sniff for it from the server.
Paul is digging deep into flexbox and finding it particularly useful for internationalisation …but there are still some gotchas.
Here’s a bit of convergent evolution: Hugo’s script is similar to what I wrote about recently.
He also raises a point that Kevin mentioned:
I would like to investigate on the
summaryelements as they are basically a native implementation for content toggles.
For some reason
details never got much browser love, even though it’s clearly paving a well-trodden cowpath.
Enduring CSS (not int the sense of “put up with” but in the sense of “long-lasting”) is a new book by Ben Frain all about writing and maintaining modular reusable CSS.
You can read the whole thing for free online or buy an eBook.
A lovely outlook on designing with progressive enhancement:
There will always be users coming from places you didn’t expect, using devices you didn’t test for.
Making web apps? Care about SEO? Here’s Google’s advice:
Use feature detection & progressive enhancement techniques to make your content available to all users.
This is really, really clever. You can’t use generated content (
: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
In this extract from his forthcoming book, Richard looks at when to use
ems, when to use
rems …and when to use
ch (no, me neither).
A good side-by-side comparison of loading techniques, with some clear advice. But pay attention to this note:
While the debate over “Load more” versus infinite scrolling versus pagination has been debated for years, the product loading method shouldn’t be the first thing that most e-commerce vendors spend their development resources on.
If you’re going to override or reimplement something that already exists, do some research on what the existing thing does first. You cannot possibly craft a good replacement without understanding the original.
Remember that for all the power the web affords you, the control is still ultimately in end user’s hands.
The full text of Adam’s excellent talk at EnhanceConf.
The videos from EnhanceConf are started to go up already. Stefan’s talk really struck me—all the talks were great but this one had the most unexpected insight for me. It really clarifies a lot of ideas that I’ve been trying to articulate, but which Stefan crystalises by taking the long-zoom view.
A very lightweight script for toggling the appearance of elements in an accessible way.
There is one truism that has been constant throughout my career on the web, and it’s this: naming things is hard.
Trent talks about the strategies out there for naming things. He makes specific mention of Atomic Design, which as Brad is always at pains to point out, is just one way of naming things: atoms, molecules, organisms, etc.
In some situations, having that pre-made vocabulary is perfect. In other situations, I’ve seen it cause all sorts of problems. It all depends on the project and the people.
Personally, I like the vocabulary to emerge from the domain knowledge of the people on the project. Building a newspaper website? Use journalism-related terms. Making a website about bicycles? Use bike-related terms.
The problem is that performance is a feature that is not on anyone’s product roadmap.
For whatever reason, the fact that it correlates directly to bounce rate, time on site, pages-per-visit etc. has not struck home with many product owners.
Most websites, certainly in the publishing industry where I have worked for a good part of my career, see those metrics as core KPIs. So you would think that anything that improved them would get prioritised. But no.
Ignacio asked me some questions. I was happy to answer them.
A pattern library of Walmart’s front-end code.
A wonderfully thoughtful piece on typography, Jan Tschichold and the web. This really resonated with me:
It’s only been over the past year or so in which I’ve recognised myself as a ‘Web designer’ with a capital W, as I now believe that something happens to information and technology, and even typography itself, when people pass through these interconnected networks and interact with hypertext.
It’s for these reasons that I don’t believe in “digital design” or “designing for screens” and it’s why I’m often attracted to one particular side of this spectrum.
Robin proposes three “principles, suggestions, outlines, or rather things-that-I-ought-to-be nervous-about when setting text on the web”:
- We must prioritise the text over the font, or semantics over style.
- We ought to use and/or make tools that reveal the consequences of typographic decisions.
- We should acknowledge that web typography is only as strong as its weakest point.
There’s an in-depth look at applying progressive enhancement to web type, and every single link in the resources section at the end is worth investigating.
Oh, and of course it’s beautifully typeset.
Linting CSS seems like a very good idea, especially if you’re not the only one writing the CSS. This guide is going to come in very handy when I give it a try.
A comprehensive overview of
rel="preload" which looks very useful indeed …I just wish it wasn’t (like “nofollow”) a nonsensical value for the
rel attribute: a resource can’t have a relationship of “preload” to the linking document.
This looks like it could be quite a handy (and relatively lightweight) script for attaching events—like animations—to an item’s visibility, so the events only trigger when the item is scrolled into view.
Well, this pretty much sums up the front-end team at Clearleft:
I’ve often said that at Clearleft, development is always in the service of design. And like Brad, I often find myself defining that work by what it isn’t:
They understand UX principles and best practices, but may not spend their time conducting research, creating flows, and planning scenarios
They have a keen eye for aesthetics, but may not spend their time pouring over font pairings, comparing color palettes, or creating illustrations and icons.
They understand the importance of backend development, but may not spend their time writing backend logic, spinning up servers, load testing, etc.
Y’know, all too often we’re caught up in the latest techniques and technologies. It’s easy to forget that there are people out there trying to learn this whole web thing from scratch. That’s why I think blog posts like this are so, so important!
Based on her experience teaching CSS at Codebar, Charlotte describes how she explains margins. Sounds simple, right? But is that because we’ve internalised this kind of thing? When was the last time we really thought about the basic building blocks of making websites?
Anyway, this is by far the best explanation of margin shorthand properties that I’ve seen.
More of this kind of thing, please!
I’ve seen the exact problem that Rachel describes here—flexbox only applied to direct children, meaning the markup would have to be adjusted.
display: contents looks like a nifty solution.
We tend to use a variant of BEM in our CSS at Clearleft. Glad to see that when we’ve hit these issues, we’ve taken the same approach.
This is a really good primer on all the pieces that make up the Houdini approach to CSS—giving authors access to low-level APIs for rendering.
As is often repeated here, it’s still early days and caution is advised, but it’s still a good idea to wrap your head around what’s coming down the standards pipe.
There’s even more specs in Houdini’s list of drafts, but the future of those is rather uncertain and they are not much more than a placeholder for an idea at this point. Examples include custom overflow behaviors, CSS syntax extension API, extension of native scroll behavior and similar ambitious things that allow you to screw up your web app even worse than ever before. Rejoice!
Microsoft are officially on board with implementing Service Workers in Edge:
Roadmap Priority: High — We intend to begin development soon.
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.
You can do anything with CSS these days.
Lyza has written an excellent deep dive into Service Workers, complete with code.
I’m really chuffed that she gave me a shout-out to my exhortation:
So if you decide to play around with Service Workers, please, please share your experience.
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!
A great description of a solid architectural approach to building on the web (and not just for accessibility either).
Adrian documents how he’s using Service Workers on Soundslice. I could imagine doing something similar for The Session.
A very handy tool for figuring out breakpoints for responsive images.
Upload an image in its largest size, play around with the settings, and then generate the breakpoints, the markup, and the resized images for each breakpoint.
A nifty tool from Brad to help calculate and allocate performance budgets. Click around and edit the numbers.
A complete list of HTML elements, past and present. They’re all hyperlinked to the relevant specs.
Some of the explanations get a little ranty, but Heydon’s collection of observed fallacies rings true:
I’ve definitely had the Luddite fallacy and the scale fallacy thrown in my face as QEDs.
The ‘made at Facebook’ fallacy is pretty much identical to what I’ve been calling the fallacy of assumed competency: copying something that large corporation X is doing just because large corporation X is doing it.
A nicely documented pattern library.
A clever technique by Emil to implement the “float label” pattern using CSS. It all hinges on browsers supporting the
:placeholder-shown pseudo-class which, alas, is not universal.
I was hoping that maybe
@supports could come to the rescue (so that a better fallback could be crafted), but that tests for properties and values, not selectors. Damn!
I was just helping out with some debugging at work and it reminded me of this great talk/post by Remy:
- Replicate: see the bug
- Isolate: understand the bug
- Eliminate: fix the bug
A response to a rant I linked to recently.
I couldn’t agree more. The tools have evolved and we now have frameworks and practices that allow us to render from the server and use the same code to render on the client, progressively enhancing from a solid robust base.
The problem is that I don’t see a willingness from developers to embrace this way of thinking. Instead I see it dismissed as being unrealistic or more expensive.
Still, it always takes time for behaviour to change so maybe things will only get better. I certainly hope so.
A great piece by Christian on taking a responsible, customer-focused approach to building on the web.
You don’t have to support old browsers and terrible setups. But you are not allowed to block them out. It is a simple matter of giving a usable interface to end users. A button that does nothing when you click it is not a good experience. Test if the functionality is available, then create or show the button.
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.
A lightweight alternative to Modernizr. It doesn’t add classes to your markup so it’s up to what you do with the results of any test.
It’s perfect for cutting the mustard on a case-by-case basis.
The proxy browser Opera Mini is one of the most popular mobile browsers in the world, and rightly so. Ire Aderinokun has put together a handy collection—based on caniuse.com data—of all the features that are unavailable or only partially available in that browser. The point here is not to avoid using these features, but to make sure you’ve got a solid fallback in place:
This isn’t about bashing the problem, but figuring out the solution.
We have some new
font keywords that are basically shortcuts to using the system fonts on a device. This article explains the details.
I somehow missed this when it was first published last Summer: a collection of twelve obscure CSS knowledge grenades.
You learn something new every day. I just learned twelve somethings.
I think that “Do we want to support users without JS?” is the wrong question. Progressive enhancement has benefits that reach far beyond that user group.
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 nice self-contained script for animating items into view as the document scrolls.
(I’m very confused by the tagline for ScrollReveal—”Easy scroll animations for web and mobile browsers”—eh? Mobile browsers are web browsers …”web” is not a synonym for “desktop”.)
Brad follows up with his thoughts on Dan’s article, emphasising the importance of a developer’s role in not just slavishly recreating what’s in a static comp, but seeing through to the underlying pattern beneath:
It’s so incredibly crucial to treat development as a key part of the design process.
A really terrific article from Dan on building pattern libraries. In summary:
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,)