Here’s what we’ve published this week:

✻ An Interview with Libby Nicholaou: Libby runs Adobe’s Creative Residency program which allows designers to work on their passion projects for a year. A dream, right?
 
✻ Taking AMP for a Spin: David Attard converts an existing website to Google’s new AMP standard. Example test result:

1.1s, 2.3Mb, 14 requests → 0.9s, 1.18Mb, 5 requests

✻ An Interview with Una Kravets: Una is a front-end developer and designer whose work we admire. Sarah Drasner transcribed a conversation with her about her contributions to open source projects and work/life balance.

✻ Should you have default styles for `table`?: Chris picks apart how you might go about answering this question for different projects. If you do (i.e. table { }) you can just drop in tables anywhere and they'll look good, but are there repercussions?

✻ The Current State of Telephone Links: the history and current state of telephone links is not as straightforward as you might think. Geoff reveals why.

 

What we’ve been reading, listening and watching


Trent Walton on the difficulty with classifying components properly:

A couple of years ago, Paravel was kicking off a fairly large-scale design system project utilizing Pattern Lab. It served as a great proof of concept, but the team struggled to map components to an atomic classification, which made collaboration within the project difficult. We’d pause to re-calculate proper classification before talking about a component. This struggle with atomic classification also made difficult the task of explaining elements of the project to stakeholders, who then became preoccupied with making the metaphor work when we really needed to be talking about resources for next steps.

Nathan Curtis has some thoughts on how his thinking has evolved on the subject, including:

Sure, HTML is made of elements (P, LI, BUTTON, INPUT). But the line between what’s an element versus what’s a component is subjective. It’s annoying to constantly debate.
 

In other news around the web


From the archives: unnecessary words

Technical writing is tricky for many reasons, and we think there are many words that are best avoided, such as: obviously, basically, simply, of course, clearly...These words get in the way of describing a problem by boosting our egos or by making others look small. Spotting them in our work is sometimes tricky but very much worth the effort.

 

What have you learnt this week?

Chris Coyier: I have a crazy specific one for you this week. I'm messing around with a new design for CSS-Tricks. I'm thinking of a small fixed position header on large screens where I use mix-blend-mode to have it overlap the content in an interesting way. But as soon as I applied that, it entirely disappeared! So I made a reduced test case (duh) and the problem wasn't happening, so I started trimming away things one by one to figure out what it was. Turns out, best I can tell, it was that I was hiding elements with the ol' kick-off-the-page technique:

.screen-reader {
  position: absolute;
  top: -9999px;
  left: -9999px;
}

So I reported it. Just to Chromium Bugs, since it doesn't seem to be a problem in other browsers. I probably should have been using a smarter visually hidden class anyway.



Until next month!
Team CSS-Tricks

 
Copyright © *|CURRENT_YEAR|* *|LIST:COMPANY|*, All rights reserved.
*|IFNOT:ARCHIVE_PAGE|* *|LIST:DESCRIPTION|*

Our mailing address is:
*|HTML:LIST_ADDRESS_HTML|* *|END:IF|*

Want to change how you receive these emails?
You can update your preferences or unsubscribe from this list

*|IF:REWARDS|* *|HTML:REWARDS|* *|END:IF|*