Posted on

Reimagine Atomic CSS

I’m not the biggest fan of Atomic CSS myself. I don’t like all the classes. I like to express my styles in CSS because I find CSS… good. But I appreciate that a lot of people seem to like it, and it does have some clear advantages, like the fact that the generated stylesheet is generally smaller than hand-rolled CSS authored other ways—plus, the available classes are like guardrails that ensure more consistent usage in a design system.

I also appreciate that innovation is happening in this space. It seems to have gone from:

Here’s a billion classes you can use, but hey, at least the CSS is still fairly small and won’t change!

To:

Yes, that, but we’re going to strip away the ones you aren’t using.

And now:

We’re going to generate the stylesheet on the fly based on what you do use.

Anthony Fu breaks down this history nicely in “Reimagine Atomic CSS” where he then throws his hat in the ring taking things one step further with UnoCSS. I can’t say I fully understand it all, but it looks like it can do anything that its predecessors can do but more, largely via rule configurations. It’s also fast (based on vite), and I’m always a fan of fast tools—especially where the goal is a tightly authored feedback loop.

It looks rather complex to me and seems to have limited integrations. I’m not a fan of the bit that turns styles into arbitrary HTML attributes. If they were, like, JSX props, that’s fine. But I think HTML attributes that go all the way to the DOM are dangerous and should be data-* scoped.

At the same time, I always like it when people think through problems and share their thought processes for solving them like Anthony has done here. Plus, there is a playground and that’s fun.

To Shared Link — Permalink on CSS-Tricks

The post Reimagine Atomic CSS appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.

Posted on

Responsive Styling Using Attribute Selectors

One of the challenges we face when implementing class-based atomic styling is that it often depends on a specific breakpoint for context.

<div class="span-12"></div> <!-- we want this for small screens  -->
<div class="span-6"></div>  <!-- we want this for medium screens -->
<div class="span-4"></div>  <!-- we want this for large screens  -->

It’s common to use a prefix to target each breakpoint:

<div class="sm-span-12 md-span-6 lg-span-4"></div>

This works well until we start adding multiple classes. That’s when it becomes difficult to keep a track what relates to what and where to add, remove. or change stuff.

<div class="
  sm-span-12 
  md-span-6 
  lg-span-4 
  sm-font-size-xl 
  md-font-size-xl 
  lg-font-size-xl 
  md-font-weight-500 
  lg-font-weight-700">
</div>

We can try to make it more readable by re-grouping:

<div class="
  sm-span-12 
  sm-font-size-xl 


  md-span-6 
  md-font-size-xl 
  md-font-weight-500 


  lg-span-4 
  lg-font-size-xl 
  lg-font-weight-700">
</div>

We can add funky separators (invalid class names will be ignored):

<div class="
  [
   sm-span-12 
   sm-font-size-xl 
  ],[
   md-span-6 
   md-font-size-xl 
   md-font-weight-500 
  ],[
   lg-span-4 
   lg-font-size-xl 
   lg-font-weight-700
  ]">
</div>

But this still feels messy and hard to grasp, at least to me.

We can get a better overview and avoid implementation prefixes by grouping attribute selectors instead of actual classes:

<div 
  data-sm="span-12 font-size-lg"
  data-md="span-6 font-size-xl font-weight-500"
  data-lg="span-4 font-size-xl font-weight-700"
>
</div>

These aren’t lost of classes but a whitespace-separated list of attributes we can select using [attribute~="value"], where ~= requires the exact word to be found in the attribute value in order to match.

@media (min-width: 0) {
 [data-sm~="span-1"] { /*...*/ }              
 [data-sm~="span-2"] { /*...*/ }   
 /* etc. */ 
}
@media (min-width: 30rem) {
 [data-md~="span-1"] { /*...*/ }   
 [data-md~="span-2"] { /*...*/ }   
 /* etc. */   
}
@media (min-width: 60rem) {
 [data-lg~="span-1"] { /*...*/ }   
 [data-lg~="span-2"] { /*...*/ }   
 /* etc. */   
}

It may be a bit odd-looking but I think translating atomic classes to  attributes is fairly straightforward (e.g. .sm-span-1 becomes [data-sm~="span-1"]). Plus, attribute selectors have the same specificity as classes, so we lose nothing there. And, unlike classes, attributes can be written without escaping special characters, like /+.:?.

That’s all! Again, this is merely an idea that aims to make switching declarations in media queries easier to write, read and manage. It’s definitely not a proposal to do away with classes or anything like that.

The post Responsive Styling Using Attribute Selectors appeared first on CSS-Tricks.

Posted on

Java Concurrency: AtomicReference

Java.util.concurrent.atomic.AtomicReference is a class designed to update variables in a thread-safe way. Why do we need the class AtomicReference? Why can we not simply use a volatile variable? And how can we use it correctly?

Why AtomicReference?

For the tool I am writing, I need to detect if an object was called from multiple threads. I use the following immutable class for this: