Sunday, October 14th, 2018
Thursday, October 11th, 2018
Some sensible answers to this question here…
…of which, exactly zero mention end users.
Wednesday, October 10th, 2018
Tuesday, October 9th, 2018
Design has disrupted taxis in a massive, almost unprecedented way. But good design doesn’t merely aim to disrupt—it should set out to actually build viable solutions. Designers shouldn’t look at a problem and say, “What we’re going to do is just fuck it up and see what happens.” That’s a dereliction of duty.
A new impressionistic documentary about Space City.
Monday, October 8th, 2018
The hits keep on comin’ from Clearleft. This time, it’s Danielle with an absolutely brilliant and thoughtful piece on the perils of gaps and overlaps in pattern libraries, design systems and organisations.
This is such a revealing lens to view these things through! Once you’re introduced to it, it’s hard to “un-see” problems in terms of gaps and overlaps in categorisation. And even once the problems are visible, you still need to solve them in the right way:
Recognising the gaps and overlaps is only half the battle. If we apply tools to a people problem, we will only end up moving the problem somewhere else.
Some issues can be solved with better tools or better processes. In most of our workplaces, we tend to reach for tools and processes by default, because they feel easier to implement. But as often as not, it’s not a technology problem. It’s a people problem. And the solution actually involves communication skills, or effective dialogue.
That last part dovetails nicely with Jerlyn’s equally great piece.
The fascinating results of Brad’s survey.
Personally, I’m not a fan of nesting. I feel it obfuscates more than helps. And it makes searching for a specific selector tricky.
That said, Danielle feels quite strongly that nesting is the way to go, so on Clearleft projects, that’s how we write Sass + BEM.
A profile of Mark Graham and the team at the Internet Archive.
Saturday, October 6th, 2018
An nth-letter selector in CSS
Variable fonts are a very exciting and powerful new addition to the toolbox of web design. They was very much at the centre of discussion at this year’s Ampersand conference.
A lot of the demonstrations of the power of variable fonts are showing how it can be used to make letter-by-letter adjustments. The Ampersand website itself does this with the logo. See also: the brilliant demos by Mandy. It’s getting to the point where logotypes can be sculpted and adjusted just-so using CSS and raw text—no images required.
I find this to be thrilling, but there’s a fly in the ointment. In order to style something in CSS, you need a selector to target it. If you’re going to style individual letters, you need to wrap each one in an HTML element so that you can then select it in CSS.
For the Ampersand logo, we had to wrap each letter in a
But if the whole point of using HTML is that the content is accessible, copyable, and pastable, isn’t a bit of a shame that we then compromise the markup—and the accessibility—by wrapping individual letters in presentational tags?
What if there were an
::nth-letter selector in CSS?
There’s some prior art here. We’ve already got
::first-letter (and now the
initial-letter property or whatever it ends up being called). If we can target the first letter in a piece of text, why not the second, or third, or nth?
It raises some questions. What constitutes a letter? Would it be better if we talked about
::nth-character, and so on?
Even then, there are some tricksy things to figure out. What’s the third character in this piece of markup?
Is it “C”, becuase that’s the third character regardless of nesting? Or is it “E”, becuase techically that’s the third character token that’s a direct child of the parent element?
I imagine that implementing
::nth-character) would be quite complex so there would probably be very little appetite for it from browser makers. But it doesn’t seem as problematic as some selectors we’ve already got.
Think about it. The browser has to first calculate how many characters are in the first line of an element (like, say, a paragraph). Having figured that out, the browser can then apply the styles declared in the
::first-line selector. But those styles may involve font sizing updates that changes the number of characters in the first line. Paradox!
(Technically, only a subset of CSS of properties can be applied to
::first-line, but that subset includes
font-size so the paradox remains.)
I checked to see if
::first-line was included in one of my favourite documents: Incomplete List of Mistakes in the Design of CSS. It isn’t.
So compared to the logic-bending paradoxes of
::nth-letter selector would be relatively straightforward. But that in itself isn’t a good enough reason for it to exist. As the CSS Working Group FAQs say:
The fact that we’ve made one mistake isn’t an argument for repeating the mistake.
Now, I know that browser makers would like us to figure out how proposed CSS features should work by polyfilling a solution with Houdini. But would that work for a selector? I don’t know much about Houdini so I asked Una. She pointed me to a proposal by Greg and Tab for a full-on parser in Houdini. But that’s a loooong way off. Until then, we must petition our case to the browser gods.
This is not a new suggestion.
While I’m talking about CSS, I would also like to have
::nth-word(n), any thoughts?
Of all of these “new” selectors,
::nth-letteris likely the most useful.
In 2012, Bram linked to a blog post (now unavailable) from Adobe indicating that they were working on
::nth-letter for Webkit. That was the last anyone’s seen of this elusive pseudo-element.
In 2013, Chris (again) included
::nth-letter in his wishlist for CSS. So say we all.
Friday, October 5th, 2018
I know I’m biased because I work with Jerlyn, but I think this in-depth piece by her is really something! She suveys the design system landscape and proposes some lo-fi governance ideas based around good old-fashioned dialogue.
Developing a design system takes collaboration between the makers of the design systems and the different users of the system. It’s a continual process that doesn’t have to require a huge investment in new departments or massive restructuring.
It can start small.
Thursday, October 4th, 2018
I like the robustness that comes with declarative languages. I also like the power that comes with imperative languages. Best of all, I like having the choice.
audio elements, for example. If you want, you can embed a video or audio file into a web page using a straightforward declaration in HTML.
<audio src="..." controls><!-- fallback goes here --></audio>
Client-side form validation is another good example. For most us, the HTML attributes—
type, etc.—are probably enough most of the time.
<input type="email" required />
<input type="geolocation" />
(And just in case you’re thinking of the fallback—which would be for the
input element to be rendered as though its
type value were
text—and you think it’s ludicrous to expect users with non-supporting browsers to enter latitude and longitude coordinates by hand, I direct your attention to
input type="color": in non-supporting browsers, it’s rendered as
input type="text" and users are expected to enter colour values by hand.)
Anyway, that’s just one example. Like I said, it’s not that I’m in favour of declarative solutions instead of imperative ones; I strongly favour the choice offered by providing declarative solutions as well as imperative ones.
cache APIs, for example. But I think we should be careful that it doesn’t become the only way of exposing new browser features. I think that, wherever possible, the design pattern of exposing new features declaratively and imperatively offers the best of the both worlds—ease of use for the simple use cases, and power for the more complex use cases.
A very thoughtful post by Rachel…
It’ll never catch on.
Wednesday, October 3rd, 2018
Tuesday, October 2nd, 2018
When you’re struggling to write something that sounds clear and sounds human (two of the essential basics of a good blog post, I’d argue), just use the words normal people would use.