Tags: naming

19

sparkline

Tuesday, August 29th, 2017

Problem space

Adam Wathan wrote an article recently called CSS Utility Classes and “Separation of Concerns”. In it, he documents his journey through different ways of thinking about CSS. A lot of it is really familiar.

Phase 1: “Semantic” CSS

Ah, yes! If you’ve been in the game for a while then this will be familiar to you. The days when we used to strive to keep our class names to a minimum and use names that described the content. But, as Adam points out:

My markup wasn’t concerned with styling decisions, but my CSS was very concerned with my markup structure.

Phase 2: Decoupling styles from structure

This is the work pioneered by Nicole with OOCSS, and followed later by methodologies like BEM and SMACSS.

This felt like a huge improvement to me. My markup was still “semantic” and didn’t contain any styling decisions, and now my CSS felt decoupled from my markup structure, with the added bonus of avoiding unnecessary selector specificity.

Amen!

But then Adam talks about the issues when you have two visually similar components that are semantically very different. He shows a few possible solutions and asks this excellent question:

For the project you’re working on, what would be more valuable: restyleable HTML, or reusable CSS?

For many projects reusable CSS is the goal. But not all projects. On the Code For America project, the HTML needed to be as clean as possible, even if that meant more brittle CSS.

Phase 3: Content-agnostic CSS components

Naming things is hard:

The more a component does, or the more specific a component is, the harder it is to reuse.

Adam offers some good advice on naming things for maximum reusability. It’s all good stuff, and this would be the point at which I would stop. At this point there’s a nice balance between reusability, readability, and semantic meaning.

But Adam goes further…

Phase 4: Content-agnostic components + utility classes

Okay. The occasional utility class (for alignment and clearing) can be very handy. This is definitely the point to stop though, right?

Phase 5: Utility-first CSS

Oh God, no!

Once this clicked for me, it wasn’t long before I had built out a whole suite of utility classes for common visual tweaks I needed, things like:

  • Text sizes, colors, and weights
  • Border colors, widths, and positions
  • Background colors
  • Flexbox utilities
  • Padding and margin helpers

If one drink feels good, then ten drinks must be better, right?

At this point there is no benefit to even having an external stylesheet. You may as well use inline styles. Ah, but Adam has anticipated this and counters with this difference between inline styles and having utility classes for everything:

You can’t just pick any value want; you have to choose from a curated list.

Right. But that isn’t a technical solution, it’s a cultural one. You could just as easily have a curated list of allowed inline style properties and values. If you are in an environment where people won’t simply create a new utility class every time they want to style something, then you are also in an environment where people won’t create new inline style combinations every time they want to style something.

I think Adam has hit on something important here, but it’s not about utility classes. His suggestion of “utility-first CSS” will only work if the vocabulary is strictly adhered to. For that to work, everyone touching the code needs to understand the system and respect the boundaries of it. That understanding and respect is far, far more important than any particular way of structuring HTML and CSS. No technical solution can replace that sort of agreement …not even slapping !important on every declaration to make them immutable.

I very much appreciate the efforts that people have put into coming up with great naming systems and methodologies, even the ones I don’t necessarily agree with. They’re all aiming to make that overlap of HTML and CSS less painful. But the really hard problem is where people overlap.

Tuesday, June 27th, 2017

Progressing the web

Frances has written up some of the history behind her minting of the term “progressive web app”. She points out that accuracy is secondary to marketing:

I keep seeing folks (developers) getting all smart-ass saying they should have been PW “Sites” not “Apps” but I just want to put on the record that it doesn’t matter. The name isn’t for you and worrying about it is distraction from just building things that work better for everyone. The name is for your boss, for your investor, for your marketeer.

Personally, I think “progressive web app” is a pretty good phrase—two out of three words in it are spot on. I really like the word “progressive”, with its echoes of progressive enhancement. I really, really like the word “web”. But, yeah, I’m one of those smart-asses who points out that the “app” part isn’t great.

That’s not just me being a pedant (or, it’s not only me being a pedant). I’ve seen people who were genuinely put off investigating the technologies behind progressive web apps because of the naming.

Here’s an article with the spot-on title Progressive Web Apps — The Next Step In Responsive Web Design:

Late last week, Smashing Magazine, one of the largest and most influential online publications for web design, posted on Facebook that their website was “now running as a Progressive Web App.”

Honestly, I didn’t think much of it. Progressive Web Apps are for the hardcore web application developers creating the next online cloud-based Photoshop (complicated stuff), right? I scrolled on and went about my day.

And here’s someone feeling the cognitive dissonance of turning a website into a progressive web app, even though that’s exactly the right thing to do:

My personal website is a collection of static HTML files and is also a progressive web app. Transforming it into a progressive web app felt a bit weird in the beginning because it’s not an actual application but I wanted to be one of the cool kids, and PWAs still offer a lot of additional improvements.

Still, it could well be that these are the exceptions and that most people are not being discouraged by the “app” phrasing. I certainly hope that there aren’t more people out there thinking “well, progressive web apps aren’t for me because I’m building a content site.”

In short, the name might not be perfect but it’s pretty damn good.

What I find more troubling is the grouping of unrelated technologies under the “progressive web app” banner. If Google devrel events were anything to go by, you’d be forgiven for thinking that progressive web apps have something to do with AMP or Polymer (they don’t). One of the great things about progressive web apps is that they are agnostic to tech stacks. Still, I totally get why Googlers would want to use the opportunity to point to their other projects.

Far more troubling is the entanglement of the term “progressive web app” with the architectural choice of “single page app”. I’m not the only one who’s worried about this.

Here’s the most egregious example: an article on Hacker Noon called Before You Build a PWA You Need a SPA.

No! Not true! Literally any website can be a progressive web app:

That last step can be tricky if you’re new to service workers, but it’s not unsurmountable. It’s certainly a lot easier than completely rearchitecting your existing website to be a JavaScript-driven single page app.

Alas, I think that many of the initial poster-children for progressive web apps gave the impression that you had to make a completely separate app/site at a different URL. It was like a return to the bad old days of m. sites for mobile. The Washington Post’s progressive web app (currently offline) went so far as to turn away traffic from the “wrong” browsers. This is despite the fact that the very first item in the list of criteria for a progressive web app is:

Responsive: to fit any form factor

Now, I absolutely understand that the immediate priority is to demonstrate that a progressive web app can compete with a native mobile app in terms of features (and trounce it in terms of installation friction). But I’m worried that in our rush to match what native apps can do, we may end up ditching the very features that make the web a universally-accessible medium. Killing URLs simply because native apps don’t have URLs is a classic example of throwing the baby out with the bath water:

Up until now I’ve been a big fan of Progressive Web Apps. I understood them to be combining the best of the web (responsiveness, linkability) with the best of native (installable, connectivity independent). Now I see that balance shifting towards the native end of the scale at the expense of the web’s best features. I’d love to see that balance restored with a little less emphasis on the “Apps” and a little more emphasis on the “Web.” Now that would be progressive.

If the goal of the web is just to compete with native, then we’ve set the bar way too low.

So if you’ve been wary of investing the technologies behind progressive web apps because you’re “just” building a website, please try to see past the name. As Frances says:

It’s marketing, just like HTML5 had very little to do with actual HTML. PWAs are just a bunch of technologies with a zingy-new brandname.

Literally any website can—and should—be a progressive web app. Don’t let anyone tell you otherwise.

I was at an event last year where I heard Chris Heilmann say that you shouldn’t make your blog into a progressive web app. I couldn’t believe what I was hearing. He repeats that message in this video chat:

When somebody, for example, turns their blog into a PWA, I don’t see the point. I don’t want to have that icon on my homepage. This doesn’t make any sense to me.

Excuse me!? Just because you don’t want to have someone’s icon on your home screen, that person shouldn’t be using state-of-the-art technologies!? Excuse my French, but Fuck. That. Shit!

Our imaginations have become so limited by what native mobile apps currently do that we can’t see past merely imitating the status quo like a sad cargo cult.

I don’t want the web to equal native; I want the web to surpass it. I, for one, would prefer a reality where my home screen isn’t filled with the icons of startups and companies that have fulfilled the criteria of the gatekeepers. But a home screen filled with the faces of people who didn’t have to ask anyone’s permission to publish? That’s what I want!

Like Frances says:

Remember, this is for everyone.

Monday, June 26th, 2017

Naming Progressive Web Apps | fberriman

AMP is a symptom that someone, somewhere, thinks the web is failing so badly (so slow, so unresponsive) for a portion of the world that they want to take all the content and package it back up in a sterile, un-webby, branded box. That makes me so sad. PWAs, to me, are a potential treatment.

Thursday, June 22nd, 2017

Code clarity - Anthony Ricaud

Breaking down programming tasks into smaller chunks …and naming things.

I’ll take a piece of paper and write the function names I’m going to implement. Or I’ll do it directly in my code editor, with real functions or comments.

It allows you to focus on one problem at a time. When you’re writing those function names, you are thinking about what the code should be doing. When you’re implementing the functions, you are thinking about how the code should do it.

Sunday, June 18th, 2017

Microformats : Meaningful HTML

A great one-page intro to microformats (h-card in particular), complete with a parser that exports JSON. Bookmark this for future reference.

Monday, March 20th, 2017

Designing Systems, Part 3: Components and Composition / Paul Robert Lloyd

Paul finishes up his excellent three part series by getting down to the brass tacks of designing and building components on the web …and in cities. His closing provocation has echoes of Heydon’s rallying cry.

If you missed the other parts of this series, they are:

  1. Theory, Practice, and the Unfortunate In-between,
  2. Layers of Longevity, and
  3. Components and Composition

Tuesday, January 3rd, 2017

Kiss My Classname - Zeldman on Web & Interaction Design

I understand how bloated and non-reusable code can get when a dozen people who don’t talk to each other work on it over a period of years. I don’t believe the problem is the principle of semantic markup or the cascade in CSS. I believe the problem is a dozen people working on something without talking to each other.

Thursday, November 10th, 2016

From Pages to Patterns – Charlotte Jackson - btconfBER2016 on Vimeo

The video of Charlotte’s excellent pattern library talk that she presented yesterday in Berlin.

Monday, October 10th, 2016

Taking Pattern Libraries To The Next Level – Smashing Magazine

Here’s an epic brain dump by Vitaly on the challenges of putting together a pattern library and then maintaining it.

Sacrificing consistency for usability is fine. A slightly open-ended, inconsistent but heavily used pattern library is better than a perfectly consistent pattern library that is never used.

Monday, September 26th, 2016

Museum of Wi-Fi

The Museum of Wi-Fi exists to preserve these vestiges of our neighbourhood battlefields.

Some are brilliantly smart, some are just purely gross. They all belong in the museum.

Thursday, May 26th, 2016

Semantic CSS - Snook.ca

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.

Wednesday, March 2nd, 2016

Atomic Classification | Trent Walton

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.

Most importantly, make the naming process a collaborative exercise, as outlined by Alla and Charlotte.

Monday, February 8th, 2016

Battling BEM – 5 common problems and how to avoid them

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.

Wednesday, January 6th, 2016

“Content & Display Patterns,” an article by Dan Mall

A really terrific article from Dan on building pattern libraries. In summary:

  1. Naming things is hard,
  2. 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,)

Friday, July 3rd, 2015

Contextual Styling: UI Components, Nesting, and Implementation Detail by Harry Roberts

Smart thinking from Harry here on a common issue when it comes to naming and styling. As he points out, the solution is not technical, but lies in how you form your mental model:

The design issue here is solved by subtly inverting the problem.

Saturday, May 30th, 2015

100 words 069

I made mention already of an exercise that myself and Charlotte came up with to help developers to think in terms of granular components: using a humble pair of scissors to cut up screenshots or mockups into their constituent parts.

Recently we repeated and added to this exercise. Once the groups of components are gathered together—buttons, form elements, icons, whatever—we go through each group. Everyone writes on a post-it what name they would give this component—button, formField, icon, etc. Then everyone slaps down their post-it notes at the same time. See any overlap? That’s your class name.

Friday, October 31st, 2014

How URL started as UDI — a brief conversation with @timberners_lee @W3C #TPAC - Tantek

Tantek shares a fascinating history lesson from Tim Berners-Lee on how the IETF had him change his original nomenclature of UDI—Universal Document Identifier—to what we now use today: URL—Uniform Resource Locator.

Wednesday, December 19th, 2012

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.

Thursday, February 2nd, 2012

» Of Grids, Class Names, Responsiveness, and Lifecycles Bits Pushed Around

The thought process behind trying to abstract class names that are used for layout in responsive designs (and can therefore refer to different widths depending on the context). Here, the author settles on letters. In the past, I’ve approached the same kind of abstraction by using latinised names.