The Working Draft podcast is usually in German, but this episode is in English. It was recorded in a casual way by a bunch of people soaking up the sun sitting outside the venue at Beyond Tellerrand. Initially that was PPK and Chris, but then I barged in half way through. Good fun …if you’re into nerdy discussions about browsers, standards, and the web. And the sound quality isn’t too bad, considering the circumstances under which this was recorded.
Dave explains the thinking behind his responsive table pattern I linked to a while back. He’s at pains to point out that you should always make sure a pre-made pattern is right for you instead of just deploying it no-questions-asked:
Using prefabricated, road tested solutions from Apple’s Human Interface Guidelines, Google’s Material Design, Twitter’s Bootstrap, and Brad Frost’s Responsive Patterns is always a good place to start, but don’t settle there. My biggest advice would be to turn off the 27” display and use your sites and projects on your phone, there’s lots of low hanging fruit that could give way to new patterns, tailor-suited to your content.
Remy looks at the closing gap between native and web. Things are looking pretty damn good for the web, with certain caveats:
The web is the long game. It will always make progress. Free access to both consumers and producers is a core principle. Security is also a core principle, and sometimes at the costs of ease to the developer (but if it were easy it wouldn’t be fun, right?).
That’s why there’ll always be some other technology that’s ahead of the web in terms of features, but those features give the web something to aim for:
Flash was the plugin that was ahead of the web for a long time, it was the only way to play video for heavens sake!
Whereas before we needed polyfills like PhoneGap (whose very reason for existing is to make itself obsolete), now with progressive web apps, we’re proving the philosophy behind PhoneGap:
If the web doesn’t do something today it’s not because it can’t, or won’t, but rather it is because we haven’t gotten around to implementing that capability yet.
The markup here (with proprietary inline attributes for styling) is a terrible idea but the demo that accompanies is great at showing how flexbox works …I just wish it didn’t try to abstract away the CSS. This is so close to being a really good learning tool for flexbox.
A really interesting proposal for more logic constructs in CSS: when/else conditions. At first glance, this looks like it would complicate the language (and one of the most powerful features of CSS is its simplicity), but when you dig a bit deeper you realise that there’s nothing new enabled by this extra syntax—it actually simplifies what’s already possible.
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.
Hmmm …I think Jeffrey might have just given me my new job title.
Issue 596729 - chromium - Do not show the app banner unless the Manifest has a display set to standalone or fullscreen - Monorail
I am shocked and disgusted by this arbitrary decision by the Chrome team. If your Progressive Web App doesn’t set its manifest to obscure its URL, you get punished by missing out on the add to home screen prompt.
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.
Download it now and watch this space for more titles around building inclusive web apps, collaboration, and maintaining privacy and security.
Did I mention that it’s free?
Here’s a nice little pattern from Dave—showing data tables one column at a time on smaller screens.
There’s a lot I disagree with here. I don’t think this pattern library process is very elegant or scalable, and it certainly wouldn’t work for me.
But I’m still linking to it. Why? Because I think it’s absolutely wonderful that people share their processes like this. It doesn’t matter one whit whether or not it would work for me.
Frontend development may have gotten a lot more complicated, but the simple premise of sharing what you’ve learned hasn’t.
I couldn’t agree more!
If you don’t comment your CSS, you’ll confuse other people looking at your code, and, more embarrassingly, you’ll confuse future you. If you do comment CSS, everybody will be less confused, and things will be accidentally broken less often. You will be popular and generally well-liked, and people will remember to send you cards on your birthday. Comment more.
Some good advice here on how to write better comments in CSS.
Here’s the video of the talk I just gave at the Beyond Tellerrand conference in Düsseldorf: Resilience.
Rachel and Drew have been beta-testing Mark’s Fractal project for organising a library of components for Perch’s interface. Sounds like it’s working out very, very well indeed!
Some smart thoughts on web fonts.
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).
Infinite Scrolling, Pagination Or “Load More” Buttons? Usability Findings In eCommerce – Smashing Magazine
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:
- The gospel fallacy
- The Luddite fallacy
- The scale fallacy
- The chocolate fireguard fallacy
- The pull request fallacy
- The ‘made at Facebook’ fallacy
- The Bob the Builder fallacy
- The real world fallacy
- The Daphne and Celeste fallacy
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