Tag: time

“Just in Time” CSS

I believe acss.io is the first usage of “Atomic CSS” where the point of it is to be a compiler. You write CSS like this:

<div class="C(#fff) P(20px)">   text </div>

And it will generate CSS like:

.C(#333) {   color: #333; } .P(20px) {   padding: 20px; }

(Or something like that.)

The point is that it only generates the CSS that you actually need, because you asked for it, and no more. The result is far less CSS than you’d see in an average stylesheet.

That complication process is what has come to be known as “Just in Time” CSS.

The popular Tailwind framework supports it. It kind of flips the mental model of Tailwind on its head, to me. Rather than providing a huge pile of CSS utility classes to use — then “purging” what is unused — it only creates what it needs to begin with.

I’d say “Just in Time” is a concept that is catching on. I just saw Assembler CSS and it leans into it big time. Rather than classes, you do stuff like:

<div x-style="grid; gap:1rem; grid-rows:1; grid-cols:1; sm|grid-cols:3">   <button x-style="^button:red">Submit</button> </div>

I’m pretty torn on this stuff. Some part of me likes how you can get styling done without ever leaving your templates. And I especially like the extremely minimal CSS output since CSS is a blocking resource. Another part of me doesn’t like that it’s a limited abstraction of CSS itself, so you’re at the mercy of the tool to support things that CSS can do natively. It also makes HTML a bit harder to look at — although I certainly got over that with JSX inline event handlers and such.

The post “Just in Time” CSS appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.



Of Course We Can Make a CSS-Only Clock That Tells the Current Time!

Let’s build a fully functioning and settable “analog” clock with CSS custom properties and the calc() function. Then we’ll convert it into a “digital” clock as well. All this with no JavaScript!

Here’s a quick look at the clocks we’ll make:

Brushing up on the calc() function

CSS preprocessors teased us forever with the ability to calculate numerical CSS values. The problem with pre-processors is that they lack knowledge of the context after the CSS code has compiled. This is why it’s impossible to say you want your element width to be 100% of the container minus 50 pixels. This produces an error in a preprocessor:

width: 100% - 50px; // error: Incompatible units: 'px' and '%'

Preprocessors, as their name suggests, preprocess your instructions, but their output is still just plain old CSS which is why they can’t reconcile different units in your arithmetic operations. Ana has gone into great detail on the conflicts between Sass and CSS features.

The good news is that native CSS calculations are not only possible, but we can even combine different units, like pixels and percentages with the calc() function:

width: calc(100% - 50px);

calc() can be used anywhere a length, frequency, angle, time, percentage, number, or integer is allowed. Check out the CSS Guide to CSS Functions for a complete overview.

What makes this even more powerful is the fact that you can combine calc() with CSS custom properties—something preprocessors are unable to handle.

The hands of the clock

Image of a round clock with a light grey background. The hours hand is dark blue pointed at 2, the minutes are light blue pointed at 9 and the seconds are yellow and pointed at 2.

Let’s lay out the foundations first with a few custom properties and the animation definition for the hands of the analog clock:

:root {   --second: 1s;   --minute: calc(var(--second) * 60);   --hour: calc(var(--minute) * 60); } @keyframes rotate {   from { transform: rotate(0); }   to { transform: rotate(1turn); } }

Everything starts in the root context with the --second custom property where we defined that a second should be, well, one second (1s). All future values and timings will be derived from this.

This property is essentially the heart of our clock and controls how fast or slow all of the clock’s hands go. Setting --second to 1s makes the clock match real-life time but we could make it go at half speed by setting it to 2s, or even 100 times faster by setting it to 10ms.

The first property we are calculating is the --minute hand, which we want equal to 60 times one second. We can reference the value from the --second property and multiply it by 60 with the help of calc() :

--minute: calc(var(--second) * 60);

The --hour hand property is defined using the exact same principle but multiplied by the --minute hand value:

--hour: calc(var(--minute) * 60);

We want all three hands on the clock to rotate from 0 to 360 degrees—around the shape of the clock face! The difference between the three animations is how long it takes each to go all the way around. Instead of using 360deg as our full-circle value, we can use the perfectly valid CSS value of 1turn.

@keyframes rotate {   from { transform: rotate(0); }   to { transform: rotate(1turn); } }

These @keyframes simply tell the browser to turn the element around once during the animation. We have defined an animation named rotate and it is now ready to be assigned to the clock’s second hand:

.second.hand {   animation: rotate steps(60) var(--minute) infinite; }

We’re using the animation shorthand property to define the details of the animation. We added the name of the animation (rotate), how long we want the animation to run (var(--minute), or 60 seconds) and how many times to run it (infinite, meaning it never stops running). steps(60) is the animation timing function which tells the browser to perform the 1-turn animation in 60 equal steps. This way, the seconds hand ticks at each second rather than rotating smoothly along the circle.

While we are discussing CSS animations, we can define an animation delay (animation-delay) if we want the animation to start later, and we can change whether the animation should play forwards or backwards using animation-direction. We can even pause and restart the animations with animation-play-state.

The animation on the minute and hour hands will work very much like on the second hand. The difference is that multiple steps are unnecessary here—these hands can rotate in a smooth, linear fashion.

The minute hand takes one hour to complete one full turn, so:

.minute.hand {   animation: rotate linear var(--hour) infinite; }

On the other hand (pun intended) the hour hand takes twelve hours to go around the clock. We don’t have a separate custom property for this amount of time, like --half-day, so we will multiply --hour by twelve:

.hour.hand {   animation: rotate linear calc(var(--hour) * 12) infinite; }

You probably get the idea of how the hands of the clock work by now. But it would not be a complete example if we didn’t actually build the clock.

The clock face

So far, we’ve only looked at the CSS aspect of the clock. We also need some HTML for all that to work. Here’s what I’m using:

<main>   <div class="clock">     <div class="second hand"></div>     <div class="minute hand"></div>     <div class="hour hand"></div>   </div> </main>

Let’s see what we have to do to style our clock:

.clock {   width: 300px;   height: 300px;   border-radius: 50%;   background-color: var(--grey);   margin: 0 auto;   position: relative; }

We made the clock 300px tall and wide, made the background color grey (using a custom property, --grey, we can define later) and turned it into a circle with a 50% border radius.

There are three hands on the clock. Let’s first move these to the center of the clock face with absolute positioning:

.hand {   position: absolute;   left: 50%;   top: 50%; }

Notice the name of this class (.hands) because all three hands use it for their base styles. That’s important because any changes to this class are applied to all three hands.

Let’s define the hand dimensions and color things up:

.hand {   position: absolute;   left: 50%;   top: 50%;   width: 10px;   height: 150px;   background-color: var(--blue); }

The hands are now all in place:

A round clock with just one light blue hand pointing directly at 6.

Getting proper rotation

Let’s hold off celebrating just a moment. We have a few issues and they might not be obvious when the clock hands are this thin. What if we change them to be 100px wide:

A round clock with a light grey background. The light blue hand is thick and still pointed at 6, but

We can now see that if an element is positioned 50% from the left, it is aligned to the center of the parent element—but that’s not exactly what we need. To fix this, the left coordinate needs to be 50%, minus half the width of the hand, which is 50px in our case:

Grey circle with a red vertical line bisecting it in the center. Two red arrows are on the clock, one labeled 50% pointing at the red line and another labeled negative 50 pixels pointing away from the red line.

Working with multiple different measurements is a breeze for the calc() function:

.hand {   position: absolute;   left: calc(50% - 50px);   top: 50%;   width: 100px;   height: 150px;   background-color: var(--grey); }

This fixes our initial positioning, however, if we try to rotate the element we can see that the transform origin, which is the pivot point of the rotation, is at the center of the element:

Grey circle showing a blue rectangle on top rotated counter-clockwise.

We can use the transform-origin property to change the rotation origin point to be at the center of the x-axis and at the top on the y-axis:

.hand {   position: absolute;   left: calc(50% - 50px);   top: 50%;   width: 100px;   height: 150px;   background-color: var(--grey);   transform-origin: center 0; }

This is great, but not perfect because our pixel values for the clock hands are hardcoded. What if we want our hands to have different widths and heights, and scale with the actual size of the clock? Yes, you guessed right: we need a few CSS custom properties!

.second {   --width: 5px;   --height: 140px;   --color: var(--yellow); } .minute {   --width: 10px;   --height: 90px;   --color: var(--blue); } .hour {   --width: 10px;   --height: 50px;   --color: var(--dark-blue); }

With this, we’ve defined custom properties for the individual hands. What’s interesting here is that we gave these properties the same names: --width, --height, and --color. How is it possible that we gave them different values but they don’t overwrite each other? And which value will I get back if I call var(--width), var(--height) or var(--color)?

Let’s look at the hour hand:

<div class="hour hand"></div>

We assigned new custom properties to the .hour class and they are locally scoped to the element, which includes the element and all its children. This means any CSS style applied to the element—or its children accessing the custom properties—will see and use the specific values that were set within their own scope. So if you call var(--width) inside the hour hand element or any ancestor elements inside that, the value returned from our example above is 10px. This also means that if we try using any of these properties outside these elements—for example inside the body element—they are inaccessible to those elements outside the scope.

Moving on to the hands for seconds and minutes, we enter a different scope. That means the custom properties can be redefined with different values.

.second {   --width: 5px;   --height: 140px;   --color: var(--yellow); } .minute {   --width: 10px;   --height: 90px;   --color: var(--blue); } .hour {   --width: 10px;   --height: 50px;   --color: var(--dark-blue); } .hand {   position: absolute;   top: 50%;   left: calc(50% - var(--width) / 2);   width: var(--width);   height: var(--height);   background-color: var(--color);   transform-origin: center 0; }

The great thing about this is that the .hand class (which we assigned to all three hand elements) can reference these properties for the calculations and declarations. And each hand will receive its own properties from its own scope. In a way, we’re personalizing the .hand class for each element to avoid unnecessary repetition in our code.

Our clock is up and running and all hands are moving at the correct speed:

The finished clock. Grey background, with minutes and hours pointing to 6 and seconds pointing to 7.

We could stop here but let me suggest a few improvements. The hands on the clock start at 6 o’clock, but we could set their initial positions to 12 o’clock by rotating the clock 180 degrees. Let’s add this line to the .clock class:

.clock {   /* same as before */   transform: rotate(180deg); }

The hands might look nice with rounded edges:

.hand {   /* same as before */   border-radius: calc(var(--width) / 2); }

Our clock looks and works great! And all hands start from 12 o’clock, exactly how we want it!

Setting the clock

Even with all these awesome features, the clock is unusable as it fails terribly at telling the actual time. However, there are some hard limitations to what we can do about this. It’s simply not possible to access the local time with HTML and CSS to automatically set our clock. But we can prepare it for manual setup.

We can set the clock to start at a certain hour and minute and if we run the HTML at exactly that time it will keep the time accurately afterwards. This is basically how you set a real-world clock, so I think this is an acceptable solution. 😅

Let’s add the time we want to start the clock as custom properties inside the .clock class:

.clock {   --setTimeHour: 16;   --setTimeMinute: 20;   /* same as before */ }

The current time for me as I write is coming up to 16:20 (or 4:20) so the clock will be set to that time. All I need to do is refresh the page at 16:20 and it will keep the time accurately.

OK, but… how can we set the time to these positions and rotate the hands if a CSS animation is already controlling the rotation?

Ideally, we want to rotate and set the hands of the clock to a specific position when the animation starts at the very beginning. Say you want to set the hour hand to 90 degrees so it starts at 3:00 pm and initialize the rotation animation from this position:

/* this will not work */ .hour.hand {   transform: rotate(90deg);   animation: rotate linear var(--hour) infinite; }

Well, unfortunately, this will not work because the transform is immediately overridden by the animation, as it modifies the very same transform property. So, no matter what we set this to, it will go back to 0 degrees where the first keyframe of the animation starts.

We can set the rotation of the hand independently from the animation. For example, we could wrap the hand into an extra element. This extra parent element, the “setter,” would be responsible for setting the initial position, then the hand element inside could animate from 0 to 360 degrees independently. The starting 0-degree position would then be relative to what we set the parent setter element to.

This would work but luckily there’s a better option! Let me amaze you! 🪄✨✨

The animation-delay property is what we usually use to start the animation with some predefined delay.

The trick is to use a negative value, which starts the animation immediately, but from a specific point in the animation timeline!

To start 10 seconds into the animation:

animation-delay: -10s;

In case of the hour and minute hands, the actual value we need for the delay is calculated from the --setTimeHour and --setTimeMinute properties. To help with the calculation, let’s create two new properties with the amount of time shifting we need:

  • The hour hand needs to be the hour we want to set the clock, multiplied by an hour.
  • The minute hand shifts the minute we want to set the clock multiplied by a minute.
--setTimeHour: 16; --setTimeMinute: 20; --timeShiftHour: calc(var(--setTimeHour) * var(--hour)); --timeShiftMinute: calc(var(--setTimeMinute) * var(--minute));

These new properties contain the exact amount of time we need for the animation-delay property to set our clock. Let’s add these to our animation definitions:

.second.hand {   animation: rotate steps(60) var(--minute) infinite; } .minute.hand {   animation: rotate linear var(--hour) infinite;   animation-delay: calc(var(--timeShiftMinute) * -1); } .hour.hand {   animation: rotate linear calc(var(--hour) * 12) infinite;   animation-delay: calc(var(--timeShiftHour) * -1); }

Notice how we multiplied these values by -1 to convert them to a negative number.

We have almost reached perfection with this, but there’s a slight issue: if we set the number of minutes to 30, for example, the hour hand needs to already be halfway through to the next hour. An even worse situation would be to set the minutes to 59 and the hour hand is still at the beginning of the hour.

fix this, all we need to do is add the minute shift and the hour shift values together for the hour hand:

.hour.hand {   animation: rotate linear calc(var(--hour) * 12) infinite;   animation-delay: calc(     (var(--timeShiftHour) + var(--timeShiftMinute)) * -1   ); }

And I think with this we have fixed everything. Let’s admire our beautiful, pure CSS, settable, analog clock:

Let’s go digital

In principle, an analog and a digital clock both use the same calculations, the difference being the visual representation of the calculations.

Clock with a rectangular light grey background with the numeric time reading 14 45 18 in 24-hour format.

Here’s my idea: we can create a digital clock by setting up tall, vertical columns of numbers and animate these instead of rotating the clock hands. Removing the overflow mask from the final version of the clock container reveals the trick:

The new HTML markup needs to contain all the numbers for all three sections of the clock from 00 to 59 on the second and minute sections and 00 to 23 on the hour section:

<main>   <div class="clock">     <div class="hour section">       <ul>         <li>00</li>         <li>01</li>         <!-- etc. -->         <li>22</li>         <li>23</li>       </ul>     </div>     <div class="minute section">       <ul>         <li>00</li>         <li>01</li>         <!-- etc. -->         <li>58</li>         <li>59</li>       </ul>     </div>     <div class="second section">       <ul>         <li>00</li>         <li>01</li>         <!-- etc. -->         <li>58</li>         <li>59</li>       </ul>     </div>   </div>  </main>

To make these numbers line up, we need to write some CSS, but to get started with the styling we can copy over the custom properties from the :root scope of the analog clock straight away, as time is universal:

:root {   --second: 1s;   --minute: calc(var(--second) * 60);   --hour: calc(var(--minute) * 60); }

The outermost wrapper element, the .clock, still has the very same custom properties for setting the initial time. All that’s changed is that it becomes a flexbox container:

.clock {   --setTimeHour: 14;   --setTimeMinute: 01;   --timeShiftHour: calc(var(--setTimeHour) * var(--hour));   --timeShiftMinute: calc(var(--setTimeMinute) * var(--minute));    width: 150px;   height: 50px;   background-color: var(--grey);   margin: 0 auto;   position: relative;   display: flex; }

The three unordered lists and the list items inside them that hold the numbers don’t need any special treatment. The numbers will stack on top of each other if their horizontal space is limited. Let’s just make sure that there is no list styling to prevent bullet points and that we center things for consistent placement:

.section > ul {   list-style: none;   margin: 0;   padding: 0; } .section > ul > li {   width: 50px;   height: 50px;   font-size: 32px;   text-align: center;   padding-top: 2px; }

The layout is done!

Outside each unordered list is a <div> with a .section class. This is the element that wraps each section, so we can use it as a mask to hide the numbers that fall outside the visible area of the clock:

.section {   position: relative;   width: calc(100% / 3);   overflow: hidden; }

The structure of the clock is done and the rails are now ready to be animated.

Animating the digital clock

The basic idea behind the whole animation is that the three strips of numbers can be moved up and down within their masks to show different numbers from 0 to 59 for seconds and minutes, and 0 to 23 for hours (for a 24-hour format).

We can do this by changing the translateY transition function in CSS for the individual strips of numbers from 0 to -100%. This is because 100% on the y-axis represents the height of the whole strip. A value of 0% will show the first number, and 100% will show the last number of the current strip.

Previously, our animation was based on rotating a hand from 0 to 360 degrees. We now have a different animation that moves the number strips from 0 to -100% on the y-axis:

@keyframes tick {   from { transform: translateY(0); }   to { transform: translateY(-100%); } }

Applying this animation to the seconds number strip can be done the same way as the analog clock. The only difference is the selector and the name of the animation that’s referenced:

.second > ul {   animation: tick steps(60) var(--minute) infinite; }

With the step(60) setting, the animation ticks between numbers like we did for the second hand on the analog clock. We could change this to ease and then the numbers would smoothly slide up and down as if they were on a ribbon of paper.

Assigning the new tick animation to the minute and hour sections is just as straightforward:

.minute > ul {   animation: tick steps(60) var(--hour) infinite;   animation-delay: calc(var(--timeShiftMinute) * -1); } .hour > ul {   animation: tick steps(24) calc(24 * var(--hour)) infinite;   animation-delay: calc(var(--timeShiftHour) * -1); }

Again, the declarations are very similar, what’s different this time is the selector, the timing function, and the animation name.

The clock now ticks and keeps the correct time:

Time reading 14 1 10 in 24-hour format.

One more detail: The blinking colon (:)

Again we could stop here and call it a day. But there’s one last thing we can do to make our digital clock a little more realistic: make the colon separator between the minutes and seconds blink as each second passes.

We could add these colons in the HTML but they are not part of the content. We want them to be an enhancement to the appearance and style of the clock, so CSS is the right place to store this content. That’s what the content property is for and we can use it on the ::after pseudo-elements for the minutes and hours:

.minute::after, .hour::after {   content: ":";   margin-left: 2px;   position: absolute;   top: 6px;   left: 44px;   font-size: 24px; }

That was easy! But how can we make the seconds colon blink too? We want it animated so we need to define a new animation? There are many ways to achieve this but I thought we should change the content property this time to demonstrate that, quite unexpectedly, it is possible to change its value during an animation:

@keyframes blink {   from { content: ":"; }   to { content: ""; } }

Animating the content property is not going to work in every browser, so you could just change that to opacity or visibility as a safe option…

The final step is to assign the blink animation to the pseudo-element of the minute section:

.minute::after {   animation: blink var(--second) infinite; }

And with that, we are all done! The digital clock keeps the time accurately and we even managed to add a blinking separator between the numbers.

Book: All you need is HTML and CSS

This is just one example project from my new book, All you need is HTML and CSS. It’s available on Amazon in both the U.S and U.K.

If you are just getting started with web development, the ideas in the book will help you level up and build interactive, animated web interfaces without touching any JavaScript.

If you are a seasoned JavaScript developer, the book is a good reminder that many things can be built with HTML and CSS alone, especially now that we have a lot more powerful CSS tools and features, like the ones we covered in this article. There are many examples in the book pushing the limits including interactive carousels, accordions, calculating, counting, advanced input validation, state management, dismissible modal windows, and reacting to mouse and keyboard inputs. There’s even a fully working star rating widget and a shopping basket.

Thanks for spending the time to build clocks with me!

The post Of Course We Can Make a CSS-Only Clock That Tells the Current Time! appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.


, , , , ,

Exploring color-contrast() for the first time.

I saw in the release notes for Safari Technical Preview 122 that it has support for a color-contrast() function in CSS. Safari is first out of the gate here. As far as I know, no other browser supports this yet and I have no idea when stable Safari will ship it, or if any other browser ever will. But! It’s a very good idea! Any native tool to get us to ship more accessible interfaces (of which color contrast is a part) is cool by me. So let’s attempt to get it to work.

Anybody can download Safari Technical Preview, so I did that.

I had to ask around about this, but just because this is a pre-release browser, it doesn’t mean all these features are active by default. Just as Chrome Canary has feature flags you have to turn on, so does Safari Technical Preview. So, I had to flip it on like this:

The release notes don’t have any information about how to actually use color-contrast(), but fortunately web searching turns up a spec (it’s part of Color Module 5), and MDN has a page for it with very basic syntax information.

This is how I understand it:

That example above is a little silly, because it will always return white — that has the most contrast with black. This function actually gets useful when one or more of those color values is dynamic, meaning very likely it is a CSS custom property.

The function returns a color, so the top use-case, I would guess, is going to be setting a color based on a dynamic background. So…

section {   background: var(--bg);   color: color-contrast(var(--bg), white, black); }

Now we can toss any color at all at --bg and we’ll either get white or black text, depending on what has the most contrast:

That’s extremely cool, even in the most basic use case.

Here’s a demo from Dave where he’s not just setting the text color in the parent, but the color of links as well, and the links have a different set of colors to choose from. Play with the HSL sliders (in Safari Technology Preview, of course) to see it work.

Just picking two colors that have enough contrast is easy enough (although you’d be surprised how often it’s screwed up by even those of us with good intentions). But oh wow does it get complicated quick with different situations, let alone having a bunch of color variations, or god forbid, arbitrary combinations.

Here’s a video of me playing with Dave’s tester so you can see how the colors update at different places.

The post Exploring color-contrast() for the first time. appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.


, , ,

Splitting Time Between Product and Engineering Efforts

At each company I’ve worked, we have had a split between time spent on Product initiatives and Engineering work. The percentages always changed, sometimes 70% Product, 30% Engineering, sometimes as much as a 50/50 split. The impetus is to make sure that Engineering spends a portion of their time building new features, but also ensures we can do “our own” work such as address technical debt, upgrade systems, and document our code.

The trouble is, it’s one thing to say this at the outset, and another to make it a reality. There are some reasons that I’ve seen this model fail, not because people don’t understand in theory that it’s valuable, but because in practice, there are some common pitfalls that you have to think through. We’ll cover some of these scenarios from the perspective of an Engineering leader so that we can address a good path forward.

The issues

Some of the pointers below are reactions and planning based on what can go wrong, so let’s talk first about the challenges you can encounter if this isn’t set up right.

  • Product may have conflicts, either with the work itself or the time involved. This can strain the relationship between Product and Engineering. If they are caught by surprise, you can potentially find the boundaries of your work getting more restrictive.
  • Your engineers might not understand what’s expected of them. Parallelization of efforts can be hard to do, so building a good process can provide clarity.
  • Maintenance path should be clear: Are you planning on making a giant system upgrade? This may affect other teams over time and if you’re not clear about eventual ownership, it could come back to haunt you. 👻

As nice as it is to have some freedom in your engineering time, communication, planning, and clear expectations can help make sure that you avoid any of the issues outlined above.

A group of people working
Photo by Akson on Unsplash


Once you figure out what problem you would like to tackle, it’s critical to write up a small one-sheeter that you can share with stakeholders on the nature of the work, the amount of time it’s going to take, and why it’s important.

If it’s a large project, you can also scope those pieces down into GitHub/GitLab/Jira issues, and add a label for the type of work that it is. This is great because you can use whatever project management system you already use to elevate the amount of work and expectations weekly. It’s good to keep the dialogue open with your Product partners on scope and the nature of the work so they aren’t surprised by other work getting done. This will largely vary by the culture of the team and organization.

This can help provide clarity for your Engineers, too. If they understand the nature of the work and what’s expected of them, it’s easier for them to tackle the small issues that make up a whole.

You may find that it makes less sense from a focus perspective to have every engineer split time across product and engineering projects. They may instead prefer to split the work up between themselves: three people on product work for a few weeks, one person on engineering work. There are also times where everyone does need to be involved so that they have equal institutional knowledge (migrations can be like this, depending on what it is). Your mileage may vary based on the size of the team, the amount of product work, and the type of project. 

Communication helps here, too — if you’re not sure what the right path is, it can help to have a small brainstorm as a group on how you want to get this done. Just be sure you also align everyone with why the project is important as you do so.

Types of projects

There are many types of projects that you can create in your Engineering team time, and each has slightly different approaches from what I’ve seen, so let’s go over each one of them.

Tech debt

Let’s address technical debt first because that’s one of the most common pieces of work that can unlock your team. For every feature you write, if Engineering effort is slowed, you’re not only losing time in terms of product development, you’re also losing money in terms of engineering time in salary.

A bit of technical debt is natural, particularly at smaller companies where it makes more fiscal sense to move quickly, but there are some points where tech debt becomes crippling for development and releases, and makes a codebase unstable. Sometimes it needs to be done immediately to make sure all your engineers can work efficiently, and sometimes it’s gradual.

In a lot of cases, the technical debt pieces are things you learn you need by a bottoms-up approach: the devs that are closest to working with the system will know best what day-to-day technical debt exists than Engineering Managers (EMs) typically will. The challenge as an EM is to notice larger patterns, like when many folks complain of the same thing, rather than one dev who may have a strong opinion. Asking around before you start this type of project can help — poll people on how much time they think they’re wasting in a given week vs the prospect of an alternative.

Sometimes technical debt is a matter of a large amount of refactor. I’ve seen this go best when people are up front on what kind of pull requests (PR) are necessary. Do you need to update the CSS in a million spots? Or convert old class components to hooks? You probably don’t want one huge PR for all of it, but it doesn’t make sense to break this work per-component either. Work together as a team on how much each PR will hold and what is expected of the review so you don’t create a “review hole” while the work is being done.

Two people looking at some code
Photo by heylagostechie on Unsplash

Innovative projects

A lot of companies will do hack week/innovation week projects where devs can work on some feature related to the company’s product untethered. It’s a great time for exploration, and I’ve seen some powerful features added to well-known applications this way. It’s also incredibly energizing for the team to see an idea of their own come to fruition.

The trouble with doing these kinds of projects in the split engineering time is that you can, at times, make the Product team feel a little slighted. Why? Well, think of things from their perspective. Their job is to put forth these features, plan carefully with stakeholders, put together roadmaps (often based on company metrics and research), and get on the Engineering schedule, usually working with a project manager. If you spend half your time working on unplanned features, you can potentially fork an existing plan for a project, go against some of the known research they have, or simply slow down the process to get a core make-it-or-break it feature they need.

The way I’ve seen this play out well is when the EM communicates up front with Product. Consider this a partnership: if Product says that a particular feature doesn’t make sense, they likely have a good reason for thinking so. If you can both hear each other out, there is likely a path forward where you both agree. 

It’s good to address their fears, too. Are they concerned that there won’t be enough time for product work? Ask your team directly how many weeks at half time they think it might take (with the expectations that things might shift once they dig in). Make it clear to everyone that you don’t expect it to be done at a break-neck pace.

Ultimately, communication is key. Ideally, these are small projects that won’t derail anything that can be done in parallel to the regular work. My suggestion is to try it with something very small first to see what bumps in the road there might be, and also build trust with Product that you’ll still get your work done and not “go rogue.”

The final piece of this is to figure out who is responsible for metrics, outcomes, and when things don’t go well. Part of the reason Product gets to decide direction is because they’re on the hook when it fails. Make sure you’re clear that as an Engineering leader, you’re taking responsibility for outcomes, both the good and the bad to maintain a good relationship.

Slow, ongoing work

This is probably the most clear-cut of any of the types of projects and will likely get the least amount of pushback from anyone. Examples of this type of work is internal documentation, tooling (if you don’t have a dedicated tools team), or small bits of maintenance.

The communication needed here is a little different from other projects, as it’s not necessarily going to be one constrained project that you ship, but rather an iterative process. Take documentation as an example: I would suggest building time for internal documentation into any feature process. 

For instance, let’s say you created a new feature that allows teams to collaborate. Not everyone across the company may know that you created a microservice for this feature that any team can use, and what parameters are expected, or how to add functionality down the road. Internal docs can be the difference between the service being used, as well as your team being asked to pair with someone every time someone needs to use it. Or worse: them trying to hack around and figure it out on their own, creating a mess of something that could have been worked on quicker and more efficiently.

Unlike the innovation projects, slow, ongoing work is typically not something folks really crave doing, so setting a process and expectations up straightaway works best. Internal documentation is a sometimes hidden but very important part of a well-functioning team. It helps with onboarding, getting everyone on the same page about system architecture, and can even help devs really solidify what they built and think through how they’re solving it.

Two women talking about something on a computer screen
Photo by Christina @ wocintechchat.com on Unsplash


Migrations are handled a little differently than some other types of projects because it likely affects everyone. There is no one right way to do this, and will also largely depend on what type of migration it is — framework to framework, breaking down a monolith, and migrating to a different build process or server all may have different approaches. Due to the fact that each one of these is likely an article of its own, let’s go through some high level options that apply to the organization of them.

  • My first suggestion is to do as much research as possible up front on whatever type of migration you’re doing. There’s no way to know everything, but you don’t want to get part-way through a process to find out something critical. This is also helpful information to share with stakeholders.
  • Are there internal debates about what direction your company should head in? Timebox a unit of time to work through the problem and make sure you have a clear decision-maker at the end. A lot of tech problems don’t have one “true” solution, so having one owner make the decision and everyone else disagree and commit can help. But you also want to give a moment for folks to have their voices heard about what gives them pause, even if they are in disagreement — they might be thinking of something you’re not.
  • Document a migration plan, both at a high level and then work through the impact on each team. This is also a great time to explain to Product why this work is important: is your codebase becoming old and can no longer play well with other libraries and tools? Did a new build process come out that could save your engineers time in a release process? Help them understand why the work is critical.
  • Be clear about maintenance and ownership. If one team migrates a build process that then causes issues for another, who’s fixing things to unblock that team? You should decide this before it happens.
  • Some migration paths allow you do things slowly over time, or team by team, or do a lot of the work up front. However, there is usually a time when it’s going to be critical and all hands on deck are needed. Unlike some of the other work that can be parallelized, you may have to work something out with Product where all other feature work is stalled for a little bit while you get the new system in place. If you work closely with them, you may find that there are times in the season where you naturally have more of a customer lull, and it could give you the breathing room you need to get this done. I’d suggest that if they’re willing to let you take Engineering time to 100% for a little while, you return the favor; and once the platform is stable, dedicate 100% of the team’s time to Product work.


This final step might seem optional, but it’s a big deal in my opinion. Your team just pulled off something incredible: they parallelized efforts, they were good partners to Product, they got something done for the Engineering org at large. It’s crucial to celebrate the work like you would a launch.

The team needs to know you value this work because it’s often thankless, but very impactful. It can also build trust to know that if something hairy comes up in the future, that it does actually help their career path as well. Celebrating with your team what you accomplished costs very little, and has great cultural impacts.

The post Splitting Time Between Product and Engineering Efforts appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.


, , , , ,

Time for Next-Gen Codecs to Dethrone JPEG

AVIF has been getting a lot of tech press, but Jon Sneyers is hot on JPEG XL (which makes sense as he’s the “chair of the JPEG XL ad hoc group in the JPEG Committee”). According to Jon’s comparison, JPEG XL comes out on top on everything, except low fidelity compression, and offers progressive rendering which none of the other next-gen codecs do. But WebP (not to be confused with the upcoming WebP2!) has something of a leg up now that it has support across all the major browsers.

There is a whole ecosystem around image formats that is way wider than websites, of course, and I’m sure that plays a big role in what ends up on websites. What format do you get when you make screenshots on your system? What does your digital camera export? What does your favorite design software export? Then, once people have images, does the website-making software you use support them? I think of how WordPress rejects SVG unless you force it; I just tried uploading an AVIF for this post and it won’t take that, either.

I also think of the UX of new formats, like when I have a .avif file on my desktop, my macOS computer doesn’t know what to make of it. It’s just a blank white document with no preview. The image ecosystem as a whole moves slower than the web. Inertia, as Jon puts it, is a good framing, but hopefully can be overcome:

Let’s just hope that the new codecs will win the battle, which is mostly one that’s against inertia and the “ease” of the status quo. Ultimately, unless JPEG remains a dominant force, regardless of which new codec will prevail, we’ll reap the benefits of stronger compression, higher image fidelity, and color accuracy, which translate to more captivating, faster-loading images.

I’d bet that image codecs evolve as long as displaying images on screens is a thing. There is no endgame. The blog post I’m linking to from Jon is on the Cloudinary blog, and I gotta give it to them: Cloudinary — and services like it — are a solution here. They provide a system where I don’t have to care about image formats all that much. I upload whatever I have (ideally: big and high-quality) and they can serve the best possible format, size, and quality for the situation. That job, to me, is just too damn hard to do manually, let alone stay on top of long-term.

I see JPEG 2000 is still hanging out, but whatever happened to JPEG XR? It wasn’t that long ago we talked about serving that, even with <source>. Was that just mostly an IE thing that died with IE?

Direct Link to ArticlePermalink

The post Time for Next-Gen Codecs to Dethrone JPEG appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.


, , , ,

PSA: It’s That Time to Update the Copyright Year on Your Site

Every year about this time I see articles going around reminding people how to update the copyright on their websites. Usually somewhere in the footer. You know, a line like:

© Copyright 2007-2019 CSS-Tricks

I am very absolutely not a lawyer, but this is how I understand it:

  • You don’t actually need that if your goal is copyrighting blog posts. Blog posts are copyrighted (in the United States) the second you publish them, with or without a copyright notice. You just can’t sue anybody over infringement unless you register the copyright.
  • People say it may “defer” infringements (but I don’t buy it).
  • People say it may win you greater settlements should you sue and win (but I wouldn’t even know where to begin fact-checking that).

Personally, I usually don’t bother with it, but don’t take that advice. I feel like it’s usually included for a bit of swagger like, “lookie how long we’ve been around.” In that same tune, if you’re doing it, it makes a lot of sense to keep it up to date because having the incorrect or an outdated date definitely makes your site look stale.

So, sure, rock your <?php echo date("Y"); ?> or whatever you need to do to keep it up to date. Just be careful: I just saw a site going around that recommended an inline JavaScript document.write() technique. That’s probably not the worst thing in the world since it’s just injecting a string, but it’s usually something to avoid for various reasons, and I’d way rather see you do it server-side or pre-rendered.

The post PSA: It’s That Time to Update the Copyright Year on Your Site appeared first on CSS-Tricks.


, , , , ,

Save Big on An Event Apart for a Limited Time!

(This is a sponsored post.)

If you could get one gift from your boss this holiday season, what would you want it to be? You know, other than the usual mouse pad, picture frame or, my favorite, the ol’ coffee mug and Starbucks card combo.

What if you were to receive something, hmm, more substantial? Like something that keeps giving three days instead of one. Or something that levels up your front-end chops. Or something that lets you network with your peers and gain invaluable experience by learning from the brightest minds in the biz?

Yes, all of that would be awesome — nay — epic! And, yes, you can get all of that together with one ticket to An Event Apart.

There truly is no better gift for front-enders. It’s a break from the desk into a three-day haven of learning about the most important movements in web development and design from the folks who are leading the way. Seriously, just check out the lineup for the Washington D.C. installment.

This is where we’d normally share a special coupon code that scores you a $ 100 discount and gives us credit for sending you there. You can totally do that by entering AEACP at checkout. We rely on sponsorships around here and supporting our sponsors keeps this boat moving.

But! An Event Apart are feeling extra generous this season and offering a discount of $ 200 off any two- or three-day pass to any of their 2020 events. That includes stops in D.C., Seattle, Boston, Minneapolis, Orlando and San Francisco!

OK, so what’s that code? You’re just gonna have to watch out on Twitter, Facebook or their mailing list on Friday, December 13, to get it.

Learn More

Direct Link to ArticlePermalink

The post Save Big on An Event Apart for a Limited Time! appeared first on CSS-Tricks.


, , , ,

Save Big on An Event Apart for a Limited Time!

(This is a sponsored post.)

If you could get one gift from your boss this holiday season, what would you want it to be? You know, other than the usual mouse pad, picture frame or, my favorite, the ol’ coffee mug and Starbucks card combo.

What if you were to receive something, hmm, more substantial? Like something that keeps giving three days instead of one. Or something that levels up your front-end chops. Or something that lets you network with your peers and gain invaluable experience by learning from the brightest minds in the biz?

Yes, all of that would be awesome — nay — epic! And, yes, you can get all of that together with one ticket to An Event Apart.

There truly is no better gift for front-enders. It’s a break from the desk into a three-day haven of learning about the most important movements in web development and design from the folks who are leading the way. Seriously, just check out the lineup for the Washington D.C. installment.

This is where we’d normally share a special coupon code that scores you a $ 100 discount and gives us credit for sending you there. You can totally do that by entering AEACP at checkout. We rely on sponsorships around here and supporting our sponsors keeps this boat moving.

But! An Event Apart are feeling extra generous this season and offering a discount of $ 200 off any two- or three-day pass to any of their 2020 events. That includes stops in D.C., Seattle, Boston, Minneapolis, Orlando and San Francisco!

OK, so what’s that code? You’re just gonna have to watch out on Twitter, Facebook or their mailing list on Friday, December 13, to get it.

Learn More

Direct Link to ArticlePermalink

The post Save Big on An Event Apart for a Limited Time! appeared first on CSS-Tricks.


, , , ,

What happens when you open a new install of browsers for the 1st time?

Interesting research from Jonathan Sampson, where he watches the network requests a browser makes the very first time you launch it on a fresh install, and otherwise do nothing. This gives you a little insight into what kind of information that browser wants to collect and disseminate.

This was all shared as tweets, but I’m linking to an unrolled thread if there’s one available:

Looks like Brave is the cleanest and the most questionable is… Opera?

Direct Link to ArticlePermalink

The post What happens when you open a new install of browsers for the 1st time? appeared first on CSS-Tricks.


, , , ,

That Time I Tried Browsing the Web Without CSS

CSS is what gives every website its design. Websites sure aren’t very fun and friendly without it! I’ve read about somebody going a week without JavaScript and how the experience resulted in websites that were faster, though certain aspects of them would not function as expected.

But CSS. Turning off CSS while browsing the web wouldn’t exactly make the web far less usable… right? Or, like JavaScript, would some features not work as expected? Out of curiosity, I decided to give it a whirl and rip the CSS flesh off the HTML skeleton while browsing a few sites.

Why, you might ask? Are there any non-masochistic reasons for turning off CSS? Heydon Pickering once tweeted that disabling CSS is a good way to check some accessibility standards:

  1. Common elements like headings, lists, and form controls are semantic and still look good.
  2. A visual hierarchy is still established with default styles.
  3. The content can still be read in a logical order.
  4. Images still exist as <img> tags rather than getting lost as CSS backgrounds.

A WebAIM survey from 2018 reported that 12.5% of users who rely on any sort of assisted technology browse the web with custom stylesheets, which can include doing away with every CSS declaration across a site. And, if we’re talking about slow internet connections, ditching CSS could be one way to consume content faster. There’s also the chance that CSS is disabled for reasons outside our immediate control, like when a server has hiccups of fails to load assets.

As an experiment, I used five websites and a web app without CSS, and this post will cover my experiences. It wound up being a rather eye-opening adventure for me personally, but has also informed me professionally as a developer in ways I hope you’ll see as well.

But first, here’s how to disable CSS

You’re absolutely welcome to live vicariously through me in the form of this post. But for those of you who are feeling up to the task and want to experience a style-less web, here’s how to disable CSS in various browsers:

  • Chrome: There’s actually no setting in Chrome to disable CSS, so we have to resort to an extension, like disable-HTML.
  • Firefox: View > Page Style > No Style
  • Safari: Safari > Preferences... > Show Develop menu in menu bar. Then go to the Develop dropdown and select the “Disable Styles” option.
  • Opera: Like Chrome, we need an extension, and Web Developer fits the bill.
  • Internet Explorer 11: View > Style > No style

I couldn’t find a documented way to disable CSS in Edge, but we can remove CSS from it and any other browser programmatically via the CSS Object Model API in the DevTools console:

var d = document;  for (var s in S = d.styleSheets)     S[s].disabled = true;  for (var i in I = d.querySelectorAll("[style]"))     I[i].style = "";

The first loop disables all external and internal styles (in <link> and <style>), and the second eliminates any inline styles. The caveat here, however, is that elements can still dynamically be given new inline styles. To instantly erase them, the best workaround is adding a timer. Something like this:

(f = function(){     // Remove CSS     ...      setTimeout(f, 20); })();

Alternatively, there are text-only browsers — such as the ancient Lynx — but expect to be living without video, images (including SVGs), and JavaScript.

Through the style-less looking glass…

For each site I surfed without CSS — Amazon, DuckDuckGo, GitHub, Stack Overflow, Wikipedia and contrast checker called Hex Naw — I’ll share my first impressions and put some suggestions out there that might help with the experience.

Get ready, because things might get a bit… appalling. 😱

Website 1: Amazon.com
The Amazon.com homepage with and without CSS
The Amazon.com homepage with CSS (left) and without CSS (right).

There’s no real need for an introduction here. Not only is Amazon a household staple for so many of us, it also powers a huge chunk of the web, thanks to their ubiquitous Amazon Web Services platform.

There’s a vast number of things going on here, so I’ll explore the style-less stuff that gets in my path while finding a product and pretending to purchase it.

The Amazon.com results for a “mac mini” search query
The Amazon.com results for a “mac mini” search query.

On the homepage, I immediately see a sprite sheet used by the site. It’s really in place of where the logo could be, thus making it tough to know whether or not those images are intended to be there. Each sprite contains multiple versions of the logo, and even if I could see the “Amazon” word mark in it, it’s surprisingly that it’s not the global home link. If you’re curious where the home link really is, it’s this structure of spans where the logo is served up as background image… in CSS:

<a href="/ref=nav_logo" class="nav-logo-link" aria-label="Amazon" tabindex="6">   <span class="nav-sprite nav-logo-base"></span>   <span class="nav-sprite nav-logo-ext"></span>   <span class="nav-sprite nav-logo-locale"></span> </a>

The next problem that arises is that the “Skip to main content” link doesn’t look like a typical skip link, yet it works like one. It turns out to be an <a> element without an href, and JavaScript (yes, I did leave that enabled) is used to mimic anchor functionality.

When I start a search, I have to look further below the “Get started” link to see the suggestions. Under the “Your Lists” and “Your Account” items, it becomes difficult to tell the links apart. They appear all strung together as if they were one super long mega link. I believe it would have been more effective to use a semantic unordered list in this scenario to maintain a sense of hierarchy.

Under all those search suggestions, however, the account and navigation links are easier to read since they’re separated by some space.

Interestingly, the carousel lower down the page is still somewhat functional. If I click the “Previous page” or “Next page” options, the order of the images is changed. However, hopping between those options required me to scroll.

A split view of the carousel on the amazon.com homepage. First is initial state, second shows previous page on top, and third shows next page on top.
The carousel appears with its pages stack on top of another. The previous or next page shows up on top.

Skipping down a bit further, there’s an advertisement element. It contains an “Ad feedback” string that looks static just like what we saw with the “Skip to main content” link earlier. Well, I clicked it anyway and it revealed a form for sharing feedback on the advertisement relevance.

Blue curvy arrow showing destination to ad feedback form when clicking Ad Feedback text under ad
To make the call to action clearer, “Ad feedback” should be a link or button.

You may have missed it, but there’s a blank button above the two groups of form labels and the radios buttons are out of place. The structure is confusing because I don’t know which labels belong to which radio buttons. I mean, I guess I could assume that the first label goes with the first radio input, but that’s exactly what it is: a guess.

What’s also confusing is that there are Submit buttons between the “Close Window,” “Cancel,” and “Send Feedback” options at the bottom of the form. If I press any of these, I’m taken back to the ad. Now, suppose I were blind and using a screen reader to navigate this same part, even with the presence of CSS. I would be told “Submit, button” for two of the buttons and would therefore have zero clue what to do without guessing. It’s another good reminder about the importance of semantics when handling markup (button labels in this case) and being mindful of how much reliance is placed on JavaScript to override web defaults.

Doing a search — let’s say for “Mac Minis” — I can still access and understand the product ratings since they are displayed as text (instead of the tooltips they are otherwise) in place of stars. This is a good example of using a solid textual fallback when an image is used as visual content, but is served as a background image in CSS.

Messy results page displaying sponsored products on top of normal products
The page required me to scroll a while to get to the actual search results. Notice that ginormous overlay of a sponsored product.

Having chosen the Mac Mini with Intel Core i3, I’m greeted by other Mac products above the product I’ve selected and have to navigate beyond them to select the quantity I want to purchase.

Part of product page showing Amazon Prime membership info
The product page displays Amazon Prime membership info slapped between the quantity selection and purchase buttons.

Scroll down, and an “Add to Cart” button is displayed next to a label bearing the same content. That’s redundant and probably unnecessary since a <button> element is capable of holding its own label:

<button>Add to Cart</button>

Next up, we have an offer for an Amazon Prime membership. That’s all fine and dandy, but notice that it’s inserted between the product I’m purchasing and the “Buy Now” button. I have a really hard time knowing whether clicking “Buy Now” is going to add the Mac Mini to checkout, or whether I’m purchasing Amazon Prime instead.

I also wanted to play around a bit, so I tried removing the Mac Mini from my cart once I figured out how to add it. It took me like ten seconds to locate the cart so I could edit it. Turns out it was directly next to “Proceed to checkout (1 item)” link but rams right up alongside it so it all looks like a single link.

Part of shopping cart page showing a Mac Mini added, Cart and Proceed to Checkout links together, and gift card offer with cost after deduction

Overall, it wasn’t difficult to find a product. On the other hand, the path to checkout became more of a headache as I proceeded. There was some poor semantic- and accessibility-related practices that caused confusion, and important buttons and links became more difficult to find.

👍 What the Site Does Well 💡 What the Site Can Improve
Carousels are functional even without styling. The logo relies on a background image, obscuring the path back home.
The content hierarchy is still generally helpful for knowing where we are on a page. Many links and anchors rely on JavaScript and do not appear to be interactive.
The order of elements remains roughly in tact. Links often bump up against each other or are placed outside where they would be relevant.
Great use of fallbacks for product rating that rely on background images. Button labels are either misleading or repetitive.
Form elements fail to align themselves properly.
There’s a rough journey to check out.
Website 2: DuckDuckGo
The DuckDuckGo homepage with and without CSS
The DuckDuckGo homepage with CSS (left) and without CSS (right).

Have you used DuckDuckGo before? I assume many folks reading CSS-Tricks have, but for those who may be hearing of it for the first time, it’s an alternative to Google search with an emphasis on user privacy.

So, getting started with this is a little misleading because the DuckDuckGo homepage is super simple. Not much can go wrong there, right? Well, it’s a little more involved than that since we’re dealing with search results, content hierarchy and relevance once we get into making search queries.

Top of DuckDuckGo homepage

Right off the bat, what I’m greeted with is a lot more content than I would have expected for such a simple lander. At it’s not totally clear what website this is by scanning the website. The first mention of the product name is the fourth item in the first unordered list and it’s a call to action to “Spread DuckDuckGo.” The logo is totally missing, which obviously means it’s used as a background… in CSS.

Speaking of that unordered list, I assume what I’m seeing belongs in the header, and there’s no skip navigation. We have a triple arrow icon (is that a mobile menu or a menu to hide the least important items, or something else?), followed by privacy-related content, social media links, something that looks like one link but is actually two links for “About DuckDuckGo” and “Learn More.”

Finally, toward the very bottom is where the primary use case for the site actually comes up: the search bar. I assume the “S” label means “Search” and the “X” label is shorthand to clear the search field.

Alright, onto performing a search. It’s super cool that I can still see auto-suggestions and use the up and down arrow keys to highlight each one. Clearing the field though, the suggestions don’t disappear until after I refresh the page.

Performing a search and checking out the auto-suggestions
Performing a search and checking out the auto-suggestions.

Everything in the Settings menu are items in a list including what should be headings — “Settings,” “Privacy Essentials,” “Why Privacy,” “Who We Are,” and “Keep in Touch.” These are very likely part of a mobile men if CSS was enabled, perhaps triggered by that triple arrow link thing at the top. In that menu, I see four blank bullet points between “Settings” and “More Themes.”

Orange arrows pointing to run-on links, unclear button labels, and empty list items
The DuckDuckGo homepage exposed a few glaring usability issues right off the bat.

Coming here as a new user, I have no idea what those empty list items are, but the bullets I highlighted in the screenshot above are actually the theme buttons. To clarify the intent, some fallback text would be helpful, and these should be radio or normal buttons instead of list items (considering their functionality).

Every block of content with an “X” — including the “Settings” — cannot be dismissed; however, clicking the “X” above an image of a hiker image does cause a chunk of content to clear off the screen — thanks to JavaScript still being enabled. What I really find awkward is the redundant numeration in the ordered list under “Switch to DuckDuckGo…” We see this:

1. 1We don’t store your personal info 2. 2We don’t follow you around with ads 3. 3We don’t track you. Ever.

Looks like some mixed use case of semantic markup with some other way to display list item numbers.

Clicking each X to find that only the third has functionality
The third “X” down has functionality.

There’s a colossal amount of white space under the hiker image until the first <h1> element. Assuming they’re either links or buttons, clicking every instance of “Add DuckDuckGo to [browser]” does nothing. Each section’s illustration causes some unnecessary horizontal scrolling, which is a common issue we’ll see in the other sites we look at.

Scrolling through white space between hiker image and first-level heading
Scrolling through white space between hiker image and first-level heading. Wheee!

After those sections, there’s a blank box and I have no idea what it is.

A blank box at the bottom of the page
A blank box that appears to have no purpose.

I cracked open DevTools and it turns out to be a <body> element in an <iframe> that holds only JavaScript for something related to POST requests. It might as well be one of those elements we should leave alone.

Following that, I see two repeated instances of “Set as Default Search Engine” wrapped around a “Set as Homepage” section.

Instructions in Safari to set the search engine as your default or your homepage
The instructions in Safari to set the search engine as your default or your homepage. Instructions may differ from one browser to another.

These must have been the instructions that popped up when I clicked the “Add DuckDuckGo…” actions, but it shows the impact hiding and showing content can have when we’re dealing with straight markup. Instead of repeating content, the corresponding links or buttons should point to one instance. That would cut the redundancy here.

OK, time to finally get into search. The first thing I see in the search results is an empty box with an instruction to ignore the box. Okey-dokey then.

Orange arrow pointing at a tiny box on the search results page saying “Sure, OK.”
DuckDuckGo wants me to ignore a box.

Moving on, did you see that DuckDuckGo link? That must be the logo, and I wonder why this was not on the homepage. Seems like low-hanging fruit for improvement.

The search bar still functions normally with the exception of the “S” and “X” buttons that have swapped places from where they were on the homepage.

Onto the search results. I could easily distinguish one result from another. What I found quite unnecessary, yet funny, is that the “Your browser indicates if you’ve visited this link” messaging that’s located at the end of each page title. That would be super annoying from a screen reading perspective. Imagine hearing that repeated at the end of every page title. That messaging is there to be displayed alongside checkmarks that contain tooltips that hold that messaging. But, with CSS disabled, well, no checkmarks and no tooltips. As a result, all I get is an extra long heading.

Comparison of search results page with and without CSS. Extra text appears next to titles in the non-CSS version.
Search results on DuckDuckGo are still well structured with CSS disabled, but notice the messaging that is appended to each result title.

The navigation bar that is normally displayed as tabs to filter by different types of results (e.g. Images) seems to do nothing at this point because it’s hard to tell that they are filters without styling. But if I click on the Images filter, the image results are actually loaded lower down onto the page, piled right on top of the Web results, and the page becomes mega long as a result. Oh, and you might think that scrolling all the way back up (and it’s a long way up) then clicking another filter, say Videos, would replace the images, but that simply inserts video thumbnail images below the images making an already mega long page a super mega long page. Imagine the page weight of all those assets!

Well, you don’t have to. According to DevTools, images alone account for 831 requests and a total weight of 23.7 MB. Hefty!

Orange outline box encircling feedback on requests and total image weight in DevTools
The real kicker is that it’s not immediately clear that all those images have loaded visually.

The last couple of items are worth noting. Clicking the “Send feedback” link apparently does nothing. Maybe that triggered a modal with CSS? And, although the “All Regions” link does not resemble a link and I could’ve easily ignored it, I was curious enough to click it and was taken to an anchor point of a list of countries. The last two links just made their corresponding contents appear under the list country options.

Blue arrow showing destination to list of regions after clicking All Regions
The “All Regions” option is secretly acting as an anchor.

There’s a lot going on here and there are clearly opportunities for improvement. For example, there are calls to action that display as normal text that should be either be links or buttons instead. Also, we’d think the performance of a site would get better with CSS disabled, but all those loaded assets in the search results are prohibitive. That said, the search experience isn’t painful at all… that is, unless you’re digging into images or videos while doing it.

👍 What the Site Does Well 💡 What the Site Can Improve
Search is consistent and works with or without CSS. A “skip” link for would help with keyboard browsing.
The content hierarchy makes content easy to read and search results a clean experience. Non-link items in the “Settings” menu should be headings for separate unordered lists so there is a clear hierarchy for how the options are grouped.
Good use of a homepage link at the top of the search results page. Some content is either duplicated or repeated because the site relies on conditionally showing and hiding content.
Make sure that all calls to action render as links instead of plain text.
Use a fallback solution to filter the types of search results to prevent items stacking and help control hefty page weight.
Website 3: GitHub
The GitHub homepage with and without CSS
The GitHub homepage with CSS (left) and without CSS (right).

Hey, here’s a site many of us are well familiar with! Well, many of us are used to being logged into it all the time, but I’m going to surf it while logged out.

Already, there’s a skip link (yay). There’s also a mobile navigation icon that I expect will do nothing, and am proven right when I try.

Wide gap after Why GitHub? dropdown
That big gap of white? It’s an SVG icon with a white fill, according to DevTools.

Between some of the navigation items, there are unnecessarily giant gaps. If you click on these, they still function as dropdown menus. They are <details> and <summary> elements… but something feels semantically wrong. It is nice that the menu items are actually unordered list items and that native browser functionality can still take place by using a semantic way to expand content. But that SVG icon messes with me.

Before typing anything into the field, I see three instances of “Search All GitHub” and “Jump to” links. I have no idea which to click, but if I do a search, the keyword shows up in the third group.

Orange outline boxes around groups of search links
There is no clear connection between the search input and the three groups of links.

Everything else on the homepage seems fine except for a number of overly large images horizontally overflowing the window.

Scrolling down to see large images overflowing the browser window
Scrolling down to see large images overflowing the browser window.

Let’s go back to the search bar and navigate to any repo we can find. Right under the Search button, we have two nearly identical secondary navigation bars that return the repository counts, code, commits, and other meta. Without looking at the source, I have no clue what the purpose is for having two of these.

Search results for a “javascript tips” query.
Search results for a “javascript tips” query.

Repository pages still have an easy-to-follow structure and a logical hierarchy for the most part. While logged out and having my cache cleared before coming, the “Dismiss” button for the “Join GitHub today” block still performs as I’d expect. Like we saw earlier on Amazon, the tag links are difficult to tell apart because they run together as a single line.

A repository page in a logged out state.

The next two buttons — “JavaScript” and “New Pull Request” — don’t seem to do anything when I click them. I’d imagine the pull request button should be disabled while viewing as a guest since, unless it’s intended to take a user to a log in screen first… but even that doesn’t feel right. Turns out that the button is indeed disabled when CSS is active, though. Then the rest of the page is fairly easy to understand.

If you’re here mainly for managing, contributing to, or checking out repositories, you won’t face a whole lot of friction since the hierarchy plays out well. You’ll experience pretty much the same elsewhere, whether you’re looking at pull requests, issues, or individual files. Most of the hurdles live in less prominent pages on the site.

👍 What the Site Does Well 💡 What the Site Can Improve
The hierarchy and structure of many pages are really easy to follow and make logical sense. Use the height and width attributes on <img> elements and SVGs to prevent them from blowing up.
Most of the SVG icons embedded on the page are appropriately sized. Watch for empty list items.
Nice use of a skip link in the header. Ensure that button labels use full words.
Make sure links have whitespace or line breaks between them to prevent run-ons.
Website 4: Hex Naw
The Hex Naw tool with and without CSS
The Hex Naw homepage with CSS (left) and without CSS (right).

This next site is an online tool I use often to check color contrasts for accessibility. And for a site that is so big on color, there’ s probably a lot happening here with CSS, so it should get interesting.

There’s immediately a large amount of space above the navigation and no skip links. The hamburger and close buttons for the mobile layout and “X” buttons next to each color to test are oversized.

Scrolling to find missing skip links and excessive space above the navigtion
We’re missing skip links and there is excessive space above the navigation.

Oh, and check out this giant gap between the “Test Colors” button and the next section of content.

Scrolling to show large gap between Test Colors button and “yeah” and “naw” counters
It would be nice to close this gap so the “yeah” and “naw” counters are visible in the test.

One of the many nice features of this site is a checkbox that allows you to see only the colors that passed the test, rather than viewing all of the tested colors. Unfortunately, that button does nothing with CSS disabled. However, I can still see which colors work and get the definitions for contrast ratio, large text, and small text directly in the result table.

Test result section showing “Show passing colors” checked, legend for C, L, and S letters, table of results, and feedback for all failed colors

Hiding and showing the terms is probably what the button does with CSS. The bummer is that I won’t know the purpose of those single letters (e.g. S and R) after the table headers. It’s also both ironic and confusing to see that message for all failing colors after the table because, well, there are passing colors in this list. What could be done is have hide it by default but conditionally inject it later if all the colors in a single test fail.

Pulling out DevTools, it turns out some of the white space at the top is the Hex Naw logo as a SVG file. The space above that is associated with other SVG symbols used for the page. By using a default color of black for the logo, this would help reduce some of the space. I made that quick change in DevTools and it makes a noticeable difference.

Hex Naw logo colored black and highlighted in DevTools
The size of the mobile menu and “X” icons can easily be reduced and be proportional to their viewBox attributes.
The menu and X icons given a width and height of 44 pixels using the attributes
Here’s one way to reduce the size of the mobile menu and “X” icons.

The second gap of space is caused by an SVG loader that appears while calculating color contrasts. This could be helped by specifying a much smaller, yet proportional, width and height exactly like the mobile menu and “X” icons.

SVG loader icon resized to 25px by 25px
I was able to reveal and resize the SVG loader icon in DevTools.

Adding an initial width and height to each SVG would definitely reduce the need to scroll. This is also what we can do to fix the gaps we saw in GitHub’s navigation as well.

Ultimately, Hex Naw remains pretty useful without CSS. I can still test colors, get passing and failing color results, and navigate around the page. It’s just too bad I wasn’t able to work with actual colors and had to work around those extra large SVG icons.

👍 What the Site Does Well 💡 What the Site Can Improve
The site maintains good content hierarchy throughout the site. SVGs should be use a fallback fill color and use the height and width attributes.
All of the elements are written semantically. Feedback for all failing colors could be dynamically added and removed to prevent awkward messaging.
The tests themselves function properly with the exception of being able to show or hide information. Consider an alternative way to display color for the values being tested, like table cells with the background color attribute.
Website 5: Stack Overflow
The Stack Overflow homepage with and without CSS
The Stack Overflow homepage with CSS (left) and without CSS (right).

Like GitHub, Stack Overflow is one of those resources that many (if not most) of us keep in our back pocket because it helps find whether someone has already asked a development question and the answers to them.

On the page to ask a question, I see a bunch of blank bullet points above the main <textarea> element. I have no idea why those empty list items are there. I don’t see any of the formatting buttons either, but after messing around a bit, I found that they happen to be nothing more than blank list items. Perhaps fallback text or an SVG icon for each item would help identify what these are and do. They should be turned into real buttons as well.

It’s also still possible to get a list of similar questions while entering text into the title field. Every works here as expected, which is nice. Although, it is strange that the vote counts for each suggested question appears twice, once above the title as a link and again next to the title without being linked.

The “Ask a Question” page showing blank bullets and questions that may already have an answer. Strong tag tooltip is displayed for one of the bullets.
The “Ask a Question” page has a little awkward formatting, but the overall functionality is in tact and the page is relatively easy to navigate.

One of the key elements we all look for when landing on a Stack Overflow question page is that big green checkmark that indicates the correct answer out of all the submitted answers. But with CSS turned off, it’s hard to tell which answer was accepted because each answer in the list has a black checkmark. Even if the accepted answer is always at the top, there’s still no alternative or fallback indication without having to interact with the page. Additionally, there’s no indication if you have already up voted or down voted the question or any of the answers.

Answered question with black checkmarks next to an accepted answer and other answers
The question (left) next to the list of provided answers (right). We lose a lot of hierarchy when styles are taken away.

To sum up my experience on Stack Overflow, I was able to accomplish what I normally come to the site for: finding answers to a programming problem. That said, there were indeed a few opportunities for improvement and this site is a prime example of how design often relies on color to indicate hierarchy or value on a page, which was sorely missing from the question pages in this experiment.

👍 What the Site Does Well 💡 What the Site Can Improve
Almost every element is written semantically. Use clear controls to identify editing tools while asking or answering questions.
SVG icons use the width and height attributes. Consider a visual icon to distinguish the accepted answer from any other answers to a question.
Lists of answers are clear and easy to scan. Consider a different method to indicate an up vote or a down vote besides color alone.
Website 6: Wikipedia
The Wikipedia homepage with and without CSS
The Wikipedia homepage with CSS (left) and without CSS (right).

Wikipedia, the web’s primary point of reference! It’s an online staple and one of its appealing qualities is a sort of lack of design. This should make for an interesting test.

A few links down, we have a skip navigation option for the real navigation and search. The homepage header containing the globe image maintains its two column layout, and you may have guessed why: this is a table layout. While it may not be a usability issue, we know it isn’t semantic to rely on tables to create a layout. That was a relic of the way past when we didn’t have floats, flexbox, grid or any other way to handle content placement. That said, there are no noticeable usability issues or confusing elements on the page.

Let’s move on to what many of us spend the most time on in Wikipedia: an article entry. This is often the entry point to Wikipedia, especially for those of us that start by typing something into a search engine, then click on the Wikipedia search result.

Top of Wikipedia article
Notice how similar the style-less page is to the styled page, even though it becomes a single column.

The bottom line is that this page is still extremely usable and hierarchical with CSS disabled. The layout goes down to a single column, but the content still flows in a logical order and even maintains bits of styling, thanks again to a reliance on tables and inline table properties.

One issue I bumped up against is the navigation. There is a “Jump to navigation” link in the header which indeed drops me down to the navigation when I click it. In case you’re wondering, the navigation is contained in the footer, which is the reason for needing to jump to it.

Navigation menu with stranded checkboxes above “Variants” and “More”
Navigation menu with stranded checkboxes above “Variants” and “More.”

There are seemingly random checkboxes above a couple of the navigation headings (specifically for “Variants” and “More”) and they appear to serve no purpose, although the checkbox above “More” becomes displays at a certain viewport width when CSS is enabled.

There actually is one odd thing in the navigation, and it’s a label-less button between the “In other projects” and “Languages” headings.

Part of navigation showing blank button with “Language settings” tooltip and some of the languages
Hovering over the button provides a hint that it’s for language settings, but the button should at least have a title to make that clear up front.

Clicking that button, I’m still able to access the language settings, and it mostly works as expected. For example, the layout maintains a tabbed layout which is super functional.

The CSS-less possibility of switching back and forth between Display and Input tabs

In the Display tab, however, the “Language” and “Fonts” buttons do nothing. They probably are tabs as well, but at least I can see what they offer. Beside those buttons are two empty select menus that do absolutely nothing (the first one does become populated with ComicNeue, OpenDyslexic, and System font options when you check the checkbox). Looking at the “Input” tab, the writing language buttons still happen to function as tabs. I’m still able to select options other than English, Spanish, and Chinese.

Blue arrow pointing out the jump to a list of languages at the top of the page when pressing the [...] button
Pressing the […] button takes me to a list of languages at the top of the page.

The articles aren’t difficult to read at all without CSS and that’s because nearly every element is semantically correct and follows a consistent document hierarchy. One thing I did wonder was where the “Show/Hide” button that’s normally in the table of contents went. It turns out to be a lone checkbox, and the label is fake — it uses the content property on a pseudo-element in CSS to display the label.

Another issue in articles is that you have to spend time hunting images down when previewing them. Normally, clicking an image in the article sidebar will trigger a full-screen modal that contains a carousel of images. Without CSS, that carousel is gone and, in its place, is the image with a row of unlabeled buttons above it. That’s a bummer, but would be perfectly OK if the carousel wasn’t all the way down the page, opposite of where the clicked image is at the top of the page without an ability to jump down to it.

Orange arrow pointing to blank buttons above carousel, which are the controls
The image carousel is no longer contained in a modal, but at the end of the page.

I’d be careless if I didn’t mention that the Wikipedia logo was nowhere to be found on the article! It’s not even a white SVG on white. The link contains actually nothing:

<a class="mw-wiki-logo" href="/wiki/Main_Page" title="Visit the main page"></a>

Thankfully, the “Main page” link under “Navigation” is the another way back home without pressing the browser Back button. But, still feels odd to have no branding on the page when it does such a great job of it on the homepage.

Wikipedia’s HTML issues exist mostly in features I expect to be less often used rather than articles. They never hampered my reading experience in the long run.

👍 What the Site Does Well 💡 What the Site Can Improve
The site maintains a clean structure and hierarchy. The logo placement could be moved (or added, in some cases) to the top of the page without a CSS background image.
Skip links are used effectively for search and navigation. Buttons should include labels.
The article content is semantic and easy to read. The image carousel on pages could load where the trigger occurs and use proper button labels for the controls.

Ways to make CSS-less a better experience

CSS is a key component to the modern web. As we’ve seen up to this point, there are a number of sites that become next to un-unusable without it — and we’re counting some of the most recognizable and used sites in that mix. What we’ve seen is that, at best, the primary purpose for a site can still be accomplished, but there are hurdles along the way. Things like:

  • missing or semantically incorrect skip links
  • links that run together
  • oversized images that require additional scrolling
  • empty elements, like list items and button labels

Let’s see if we can compile these into a sort of list of best practices to consider for situations where CSS might be disabled or even unavailable.

Include a skip navigation link at the top of the document

Having a hidden link to skip the navigation is a must. Notice how most of the sites we looked at contained navigation links directly in the header. With CSS turned off, those navigations became long lists of links that would be so hard to tab or scroll through for any user. Having a link to skip that would make that experience much better.

The most basic HTML example I’ve seen is an anchor link that targets an ID where the main content begins.

<a href="#main">Skip to main content</a> <!-- etc. --> <main id="main"></main>

And, of course, we can throw a class name on that link to hide it visually so it is not displayed in the UI but still available for both keyboard users and when CSS happens to be off.

.skip-navigation {   border: 0;   clip: rect(1px, 1px, 1px, 1px);   overflow: hidden;   padding: 0;   position: absolute;   height: 1px;   width: 1px; }  /* Bonus points for adding :focus styles */
Leave whitespaces where they make sense

Another pain point we saw in a few cases were text links running together. Whether it was in the navigation, tags, or other linked up meta, we often saw links that were “glued together” in such a way that several individual links appeared to be one giant link. That’s either the result of hand-coding the links like that or an automated build task that compresses HTML and removes whitespaces in the process. Either way, the HTML winds up like this:

<a href="#">CSS</a><a href="#">JavaScript</a><a href="#">Python</a><a href="#">Swift</a>

We can keep the freedom to use spaces or line breaks though, even with CSS disabled. One idea is to lean on flexbox for positioning list elements when CSS is enabled. When CSS is disabled, the list items should stack vertically and display as list items by default.

If the items are tags and should still be separated, then traditional spacing methods like margins and padding are still great and we can rely on natural line breaks in the HTML to help with the style-less formatting. For example, here are line breaks in the HTML used to separate items, flexbox to remove spaces, then styled up in CSS to re-separated the items:

See the Pen
Handling Links in HTML Separated by Spaces or Line Breaks
by Jon Kantner (@jkantner)
on CodePen.

Use width and height attributes liberally

The biggest nuisance in this experiment may have been images exploding on the screen to the point that they dominate the content, take up an inordinate amount of space, and result in a hefty amount of scrolling for all users.

The fix here is rather straightforward because we have HTML attributes waiting for us to define them. Both images and SVG have methods for explicitly defining their width and height.

<img src="/path/to-image.jpg" width="40" height="40" />  <svg width="40px" height="40px" viewBox="0 0 200 200">   <polygon points="80,0 120,0 120,80 200,80 200,120 120,120 120,200 80,200 80,120 0,120 0,80 80,80" /> </svg>
Prepare SVGs for a white background

Many of the large gaps on the sites we looked at looked like empty space, but they were really white SVGs that blew up to full size and blended into the white background.

So, yes, using the proper width and height attributes is a good idea to prevent monstrous icons, but we can also do something about that white-on-white situation. Using properties like fill and fill-rule as attributes will work here.

<!-- Icon will be red by default --> <svg viewBox="-241 243 16 16" width="100px" fill="#ff0000">   <path d="M-229.2,244c-1.7,0-3.1,1.4-3.8,2.8c-0.7-1.4-2.1-2.8-3.8-2.8c-2.3,0-4.2,1.9-4.2,4.2c0,4.7,4.8,6,8,10.6  c3.1-4.6,8-6.1,8-10.6C-225,245.9-226.9,244-229.2,244L-229.2,244z"/> </svg>
/* ...and it’s still red when CSS is enabled */ svg {   fill: #ff0000; }

See the Pen
Define SVG Width Attribute
by Geoff Graham (@geoffgraham)
on CodePen.

Label those buttons!

Lastly, if buttons are initially empty, they need to have visible fallback content. If they use a background image and a title for what the do, use a span containing the title text then add aria-hidden="true" so it doesn’t sound like the screen reader is reading the button label twice (e.g. VoiceOver says, “Add button Add” instead).

<button class="btn-icon" title="Add">   <span class="btn-label" aria-hidden="true">Add</span> </button>

Then the CSS can be something like this:

.btn-icon {   background: url(path/to/icon.svg) 0 0 / 100% 100%;   height: 40px;   width: 40px; }  .btn-label {   display: block;   overflow: hidden;   height: 0; }

If there are <li> elements acting as buttons, they can remain, but they should be static, and the contents should be placed in a button.

Now, if the icon is an SVG, we can ensure the title tooltip can still be seen by using aria-labelledby and assigning the id to the title.

<button>   <svg width="40px" height="40px" viewBox="0 0 200 200" aria-labelledby="btn-title">     <title id="btn-title">Add</title>     <polygon points="80,0 120,0 120,80 200,80 200,120 120,120 120,200 80,200 80,120 0,120 0,80 80,80" />   </svg> </button>


It can be easy to either forget or be afraid to check how a site appears when CSS isn’t available to make the UI look as good as intended. After a brief tour of the Non-CSS Web™, we saw just how important CSS is to the overall design and experience of sites, both small and large.

And, like any tool we have in our set, leaning too heavily on CSS to handle the functionality and behavior of elements can lead to poor experiences when it’s not around to do its magic. We’ve seen the same be true of sites that lean too heavily on JavaScript. This isn’t to say that we should not use them and rely on them, but to remember that they are not bulletproof on their own and need proper fallbacks to ensure an optimal experience is still available with or without our tooling.

Seen in that light, CSS is really a layer of progressive enhancement. The hierarchy, form controls, and other elements should also remain intact under their user agent styles. The look and feel, while important, is second when it comes to making sure elements are functional at their core.

The post That Time I Tried Browsing the Web Without CSS appeared first on CSS-Tricks.


, , ,