DEV Community: Lars-Erik Bruce

Use anchors, not buttons, for navigation!

Lars-Erik Bruce — Tue, 25 Feb 2025 15:02:56 +0000

As the web enthusiast that I am, I do prefer that links who takes me to different pages or sites actually use an anchor, and not a button. That is, that in the DOM-tree, it is coded as an a-tag with an href-attribute. By all means - attach an event listener, and do your magic if you must, but please avoid using a button instead of an anchor.

The reasons for using an anchor are plentiful: Screen readers will know that it is a link, which takes you places, and not a button, that only emits actions. You can right click the link, and open it in a separate tab or window. You can hover over the link, and see where it takes you. But recently I experienced even another good reason, that I haven't contemplated earlier!

We had a page that became irresponsible due to a javascript bug: A React component was re-rendered in infinity, due to some malicious state update inside a useEffect. The page was merely a navigational page, with lots of buttons for navigation. The buttons was deemed useless, due to the bug. But: If we had used anchors instead of buttons, the page would still have been working just fine! The bug would still be there, of course, but our end users wouldn’t even know that the page was buggy.

Of course, I fixed the re-rendering bug as well. But before I did so, I confirmed that using links worked, despite the bug being present. And I guess the morality of the story is, that even when javascript runs amok, and kills most of the interactivity and dynamic behaviour on the page, completely normal, good old anchors, still works as a charm!

So no need breaking the web with navigational buttons!

Name your APIs carefully!

Lars-Erik Bruce — Tue, 29 Oct 2024 10:15:40 +0000

The content of thoughts are words and concepts. The more precise your vocabulary is, the more precise are your thoughts.

Misleading or wrong names on fields, variable names, endpoints, will make your thoughts about your own code less precise. This is the most important in APIs meant to be consumed by several programmers.

If you find that something in your API could be named more precise, I find that it will be better for all parts if you deprecate this at once, and introduce the more precise name.

GlobalErrorHandler: Catch the errors that falls through ErrorBoundary's fingers!

Lars-Erik Bruce — Mon, 21 Oct 2024 10:56:54 +0000

ErrorBoundary is a magnificent tool to capture errors thrown from React components. You can provide custom error messages according to the nature and placement of the error itself. But not all errors thrown are handled by the ErrorBoundary! What do you do with those?

When considering both async errors and errors throw from outside of React, the ErrorBoundary fall short. To mitigate this, I have in my applications created what I call an GlobalErrorHandler. A functional component that simply A) Pop up an error dialog, telling the user that something went wrong, B) Logs the error to the server, so we can investigate and find solutions.

The idea is simple. We want one GlobalErrorHandler in the root of our application. This handler should only handle errors not caught by the ErrorBoundary. What more, it should be easily dismissed by the user, and we should assume that the application still is usable (to some degree).

So the strategy is this: The GlobalErrorHandler doesn't do anything at all, except rendering its children (i.e. the rest of the application), by default. But, it sets up two event listeners, listening for all error and unhandledrejection events in the browser. Then it examines the error, and see if it has already been handled by any ErrorBoundaries. Finally, if that isn't the case, it pops up a Dialog, telling the user that something went wrong somewhere, and lets the user dismiss the dialog and continue using the application.

Has the error already been handled

Before pestering end users with unnecessary dialogs ON TOP OF the handling done by ErrorBoundary, we first have to start with asking the error: Have you been handled already? My solution to this, is to introduce a new field on the error-object isHandledByBoundary. This is set to true within ErrorBoundary:

  componentDidCatch(error: Error, errorInfo: ErrorInfo) {
    (error as any).isHandledByBoundary = true;
    ....
  }

With this in place in all ErrorBoundary-components (and other machinery that handles uncaught errors), we are ready to start defining our GlobalErrorHandler.

The bare skeleton

Then we can build the skeleton of our GlobalErrorHandler. It straightforwardly render its children, and it also renders an "ErrorDialog" defined elsewhere. (If you want to share this component across applications, the ErrorDialog could be a prop instead.)


import { useState, useEffect, ReactNode } from 'react';
import { ErrorDialog } from '../Components/ErrorDialog';

type Props = {
  children: ReactNode;
};

export function GlobalErrorHandler({ children }: Props) {
  const [error, setError] = useState<Error | string | null>(null);
  const [isDialogOpen, setDialogOpen] = useState(false);

  useEffect(() => {
    ....
  }, []);

  function handleCloseDialog() {
    setDialogOpen(false);
    setError(null);
  }

  return (
    <>
      {children}

      {isDialogOpen && error && (
        <ErrorDialog
          actionName="Unhandled error"
          error={error}
          loggFeilmelding={true}
          onClose={handleCloseDialog}
        />
      )}
    </>
  );
}

The only thing we are lacking now, are the error handling itself, defined within useEffect.

Handling the errors

All the code in this section should be located within the useEffect function!

First we define handleWindowError. This is to be delivered to the error event-handler on the window-object. Nothing mysterious here, but witness that the error event also contains information about source, line number and col number. Which might be valuable to collect.

Usually this information is also found within the error object, but I need to make more empirical investigations into this. Perhaps we always should keep the line and col numbers as reported by the error-event? In that case, we could also have a state for this within GlobalErrorHandler (and make sure this is sent when logging the error).

   function handleWindowError(
      message: string | Event,
      source?: string,
      lineno?: number,
      colno?: number,
      error?: Error
    ) {
      if (error && (error as any).isHandledByBoundary) {
        return true;
      }

      const errorMessage = error
        ? error
        : `Error: ${message} at ${source}:${lineno}:${colno}`;
      setError(errorMessage);
      setDialogOpen(true);
      return true;
    }

We will also define the handleUnhandledRejection handler. This is for errors that are raised within promises, but where we forgot to write a .catch()-clause.

    function handleUnhandledRejection(event: PromiseRejectionEvent) {
      setError(`Unhandled promise rejection: ${event.reason}`);
      setDialogOpen(true);
    }

Then all we need to do, is to setup the listeners, and remove the listeners whenever GlobalErrorHandler is not rendered anymore:


    window.addEventListener('error', handleWindowError);
    window.addEventListener('unhandledrejection', handleUnhandledRejection);

    return () => {
      window.removeEventListener('error', handleWindowError);
      window.removeEventListener(
        'unhandledrejection',
        handleUnhandledRejection
      );
    };

The return statements is, of course, where we return out of the function we are feeding useEffect. This ensures that we are starting to listen on events and handle them when the component renders, and stop when the component is not rendered any more.

Thus we have a GlobalEventHandler, to handle those pesky errors in our React-application that are either thrown from asynchronous sources, or thrown from outside of the React components!

AHA-programming, an analogy

Lars-Erik Bruce — Fri, 11 Oct 2024 07:25:24 +0000

DRY code is like a desert, useful code is miles apart.

WET code is like the ocean, you are drowning in code.

AHA code is like as if the old Greek philosophers woke up from the dead, and started programming.

If you have no clue what I'm on about, read this post about AHA-programming by Kent C. Dodds.

You probably don't need a monorepo

Lars-Erik Bruce — Mon, 26 Aug 2024 09:32:37 +0000

If you have several npm packages inside the same "monorepo", you and your users would probably be better off if this was one big coherent package instead.

A lot of bookkeeping and administrative tasks just disappear.
Three shaking removes unused code either way.
Unhealthy dependencies between each package is impossible, because everything is just one single dependency.

Instead of "monorepo", consider a monolith instead. That is, one huge application. It solves the same "issues", but with a lot less administration between the teams sharing the components.

Just the Code!

Lars-Erik Bruce — Thu, 30 May 2024 07:14:58 +0000

I have written two GPTs to help me write code. They are both called "Just the Code". They are instructed to just answer with the code, and keep the explanations to the minimum, when helping you code an application.

Both are geared towards browser applications, one for vanilla Javascript and one for React + TypeScript. Give them both a go!

Since free users of ChatGPT now also are able to use GPTs, everyone are now able to test out these code helpers. So be sure to check it out!

As an example, here is an implementation of snake Just the Code wrote in vanilla Javascript.

Why you should always set responsive mode to 320px when checking "mobile layout" on your web pages

Lars-Erik Bruce — Tue, 07 May 2024 07:38:49 +0000

In this day and age, you would seldom come across a smart phone with 320px width. So, why would you spend time checking your web sites or web applications against 320px window width? As it turns out, there are actually a handfull of good reasons to simulate a device width of 320px during web development!

WCAG Reflow Compliance

Lets take the most important point first. According to the Web Content Accessibility Guidelines (WCAG), content must reflow on the screen so users can scroll vertically without having to scroll horizontally. This rule states that the minimum screen size must be either 320 CSS pixels or 1280 CSS pixels at 400% zoom.

If you calculate 1280 / 4, you quickly discover that these are exactly the same size requirements. So when I develop web pages and web applications, I always ensure everything looks fine, and there are no horizontal scroll, at 320px, to stay WCAG compliant.

Also make sure that if you intend for the page to scroll horizontally (instead of vertically), the WCAG requirement is then to support a screen height as small as 256 CSS pixels.

But even if you don't consider WCAG compliance of importance, there are still other good reasons to always check against 320px width!

Detecting Overflow Issues

If you use 320px for testing, you will immediately identify overflow issues. If your layout does not cause horizontal scrolling at 320px during testing, you can be quite confident that this is true in production as well, for wider screen sizes!

Cross-Device Compatibility

If you test the smallest size first, you are more likely to find potential issues that could affect larger sizes as well. If everything is readable, all touch interactions works flawless, and the design still doesn't look cramped at 320px, then you are certain to have no such issues with a larger screen size.

Crow epistemology: Have as few items as possible on each page

In general, you want your audience to find what they are searching after as soon as possible. The best way to be certain that your web application isn't crowded with buttons and functionality, is to make the web page behave nice on a small 320px screen. You should see the most important information without any scrolling, and also be able to navigate further into the major sections within your application with ease. If this is manageable at 320px, you have a clean and clear page.

If you find this difficult on a 320px screen, then new users not accustomed to your application will also find it difficult to navigate and find what they are looking for when using a big screen.

Conclusion

Even though no one would ever use a small phone with only 320px screen width these days, setting the responsive width in your browser to 320 pixels when developing can make you confident that you are making a page that can be used with ease by everyone.

this.savedUrl.startsWith is not a function

Lars-Erik Bruce — Tue, 16 Apr 2024 15:13:24 +0000

For years we had this dreaded error in our logs: "this.savedUrl.startsWith is not a function". Heaps of time has been spent trying to debug this, along with it's cousins "url.startsWith is not a function." and "url.match is not a function.". Here is the story about how I finally uncovered the causes of this bug, and how I fixed it.

A search for "this.savedUrl.startsWith is not a function" did not yield a single search result. But we had a lot of these in our logs. How could it be that we where the only one affected?

I could not, for the life of me, find "this.savedUrl.startsWith" anywhere in our codebase. The bug, it seemed, weren't ours. And I didn't feel I had anything to go by. At least the stack trace agreed: It claimed that the line of code with the error was outside of any script-file: It claimed the error was on the first line in the index.html file, or in a place called "@user-script:12:1:390" or something similar.

Trying to debugging this, I enhanced our logging, and began collecting the User Agent for every log message. This gave some interesting insights:

"url.match is not a function." all come from the iOS snapchat browser
"this.savedUrl.startsWith is not a function." all come from Chrome on iOS

I also noticed from the stack trace, that it had something to do with calls to XMLHttpRequest.prototype.open, so I assumed there must have been som non-standard implementation of this method.

What I assumed next, was that we somehow managed to send undefined instead of a string as URL somewhere. But this didn't make sense either: Our application worked for most of the cases, only these peculiar edge cases seemed to cause trouble.

But either way, the issue was only on iOS devices. I did not have any iOS device for debugging, and the company didn't have any test devices available. So I noted that a developer with an iPhone should take over these bug ticket, and kept developing new features instead of worrying about this old bug.

But months went by, without anyone picking up the thread. We regularly had end users complaining about not being able to use our web application, and we still saw these error messages in the logs. So I started investigating some more. I got the bright idea that, instead of searching for the full error message "this.savedUrl.startsWith is not a function", what about only searching for "this.savedUrl.startsWith" instead?

And what I found surprised me: The only place I could find this string, was some forks of the iOS implementation of Chrome. So I got ahold of another developer who had an iPhone with Chrome, and got him to log into the application. But everything worked as expected. But then I started to investigate the code around "this.savedUrl.startsWith", and saw this was code for translating the page with Google translate!

/**
 * Redefine XMLHttpRequest's send to call into the browser if it matches the
 * predefined translate security origin.
 * Only redefines once because this script may be injected multiple times.
 */
if (typeof(XMLHttpRequest.prototype.realSend) == 'undefined') {
  XMLHttpRequest.prototype.realSend = XMLHttpRequest.prototype.send;
  XMLHttpRequest.prototype.send = function(body) {
    // If this is a translate request, save this xhr and proxy the request to
    // the browser. Else, pass it through to the original implementation.
    // |securityOrigin| is predefined by translate_script.cc.
    if (this.savedUrl.startsWith(securityOrigin)) {
      const length = __gCrWeb.translate['xhrs'].push(this);
      __gCrWeb.message.invokeOnHost({
          'command': 'translate.sendrequest',
          'method': this.savedMethod,
          'url': this.savedUrl,
          'body': body,
          'requestID': length - 1});
    } else {
      this.realSend(body);
    }
  };
}

I asked my colleague to turn on automatic translation in his Chrome-for-iOS browser, and there it was! The bug appeared! The whole page crashed and became unusable, if it tried to translate the page during pageload.

After a while, with devtools in Safari, we figured out how to get a breakpoint inside the specific chrome javascript. And sure enough, the url was not a string. It was an array!

So my assumption that the URL must have been undefined, was wrong. It was an array! And in hindsight this makes sense: If the url was undefined, the error message would have been something completely different, namely: "Uncaught TypeError: Cannot read properties of undefined (reading 'startsWith')".

I felt a bit bad about this: My "undefined" hunch was so wrong, and perhaps I would have solved the bug months ago if I just kept my head straight. But either way, I now know that the URL we tried to fetch was an array, and not a string. Why?

If we only had used TypeScript instead of JavaScript, I guess this bug would never have existed in the first place.

By some reasons, a developer decided many many years ago, when first implementing this application, to send in an array to axios.get with a single element consisting of the URL, instead of the URL itself. Somehow XMLHttpRequest (and Axios) handles this correctly. But plugins and browsers who intercepts all traffic going through XMLHttpRequest, wasn't quite prepared that we serve an array, instead of a string, to axios.get...

More digging into the history of the code, I saw that initially the code looked something like this:

axios.get(['/api/', page].join('/'))

but in a commit it was rewritten to

axios.get(['/api/' + page])

And this has, ever since, caused issues for the iOS snapchat browser, Chrome on iOS that translates pages automatically and also browsers with adblock-plugins. If we only had used TypeScript instead of JavaScript, I guess this bug would never have existed in the first place.

Don't feed async functions to express handlers

Lars-Erik Bruce — Thu, 18 Jan 2024 13:20:01 +0000

Express does not support async handlers. I have witnessed an application who restarted every time the async function threw an error. This was on Node 16.

When we updated to Node 20, the whole application froze instead. After too many hours with debugging, I uncovered that the issue was async functions in express.

Running express on node 20, we weren't able to even see anyhing in the log. With node 16, the application crashed, with this error message:

node:internal/process/promises:279
triggerUncaughtException(err, true /* fromPromise */);
^
[UnhandledPromiseRejection: This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason "AxiosError: Request failed with status code 400".] {
code: 'ERR_UNHANDLED_REJECTION'
}

So what happened was that inside an express route async function, we did a subsequent call to another API with Axios, that failed with a status code 400. But since express doesn't support async functions, it couldn't catch the error and handle it.

How to fix it? Call your async function as a promise!

Let's say you have the following route defined:

app.get('/api/some/endpoint', someAsyncHandler);

You can here write an inplace wrapper for the async handler:

app.get('/api/some/endpoint', function someAsyncHandlerWrapper(req, res) {
  someAsyncHandler(req, res).catch(function errorHandler(error) {
    logger('Failed to handle this API endpoint.', e.message);
    res.sendStatus(500);
  }
});

So, use the async function as a promise (since async/await is just syntactic sugar for promises either way), and send a response code of 500 back to the client!

5 killer tricks to make your React Design System Component highly reusable! (You won't believe the Bonus trick!)

Lars-Erik Bruce — Wed, 10 Jan 2024 13:28:50 +0000

You have just made your perfect Component for the company's design system, and are ready to ship it out in your Component Library. But, are the developers depending on it as excited as you? No, because they know, with their new Component follows restraints in the form of a straight jacket and a trip to the nearest mental hospital!

Why? Because the Jira asked for a rainbow component with custom colors, and odd behavior, which makes perfect business sense from their point of view, but that you "forgot" to think about in your crazy laboratory while cooking up new components!

Don't fret! Let me tell you what features you should always include, so developers won't send you ugly thoughts and karma while they are crying themselves into sleep at night.

Lets start with a made-up component. Scenario: You want to style a FormComponent in accordance with the design system sketches. Let's say you came up with the following:

export function FormComponent({ prefix, value, onChange }) {
  return (
    <div className={css.fsComponent}>
      <div className={css.fsComponentHeader}>{prefix}</div>
      <input
        className={css.fsComponentInput}
        type="text"
        value={value}
        onChange={onChange}
      />
    </div>
  );
}

It does exactly what is asked for, a simple input element with a prefix (and of course, your beautiful CSS styling). But how can we make this component both easier and more flexible to use?

1. Utilize PropTypes or TypeScript for type safety!

Before we do anything else, we should add types to our component, so that developers using it gets a clear idea how it can be used automatically through their code editor:

type Props = {
  prefix: string;
  value: string;
  onChange: (event: React.ChangeEvent<HTMLInputElement>) => void;
};

export function FormComponent({ prefix, value, onChange }: Props) {
  return (
    <div className={css.fsComponent}>
      <div className={css.fsComponentHeader}>{prefix}</div>
      <input
        className={css.fsComponentInput}
        type="text"
        value={value}
        onChange={onChange}
      />
    </div>
  );
}

But, it looks like we adopted the mentality of restraining our developers in our types! What if the Jira calls for a flag icon in the input prefix?!

2. Use React.ReactNode as type for children and other props for jsx-arguments

Don't impose strict rules about what is allowed for the compositional props, like children (or prefix in our example) . We never know how our Components are going to be used in advance.

If we want to render props straight into the JSX-tree, we should never enforce the developers to send a string. Or an element for that sake! Sometimes, I just want to use a string as a child, but I have to put it inside a span, because the component requires an element! :-(

type Props = {
  prefix: React.ReactNode;
  value: string;
  onChange: (event: React.ChangeEvent<HTMLInputElement>) => void;
};

React.ReactNode allows for null, undefined, string, number and all variants of React elements!

3. Always include all props from the proper DOM-element

Never limit the users of your component for what already exists in the DOM API! This not only allows the users of the component to customize your component with style or className when needed (which I'm sure you dread), it also gives them access to literally hundreds of other attributes from the DOM API!

type Props = {
  prefix: React.ReactNode;
  value: string;
  onChange: (event: React.ChangeEvent<HTMLInputElement>) => void;
} & React.HTMLAttributes<HTMLDivElement>;

export function FormComponent({ prefix, value, onChange, ...props }: Props) {
  return (
    <div {...props} className={css.fsComponent + ' ' + (props.className || '')}>
      ...
    </div>
  );
}

You can use the React.HTMLAttributes to easily add all DOM attributes as properties to your component. Remember to send in the HTMLElement that you use as a wrapper element (HTMLDivElement if it is a div, etc).

4. Propagate `ref` with `forwardRef`

If you include a way for the developer to refer to your component, they are allowed to do basic stuff like managing focus, measure dimensions and positions and even integrate with third party DOM libraries!

type Props = {
  prefix: React.ReactNode;
  value: string;
  ref?: React.ForwardedRef<HTMLDivElement>;
  inputRef?: React.ForwardedRef<HTMLInputElement>;
  onChange: (event: React.ChangeEvent<HTMLInputElement>) => void;
} & React.HTMLAttributes<HTMLDivElement>;

export function FormComponent({
  prefix,
  value,
  onChange,
  ref,
  inputRef,
  ...props
}: Props) {
  return (
    <div
      {...props}
      className={css.fsComponent + ' ' + (props.className || '')}
      ref={ref}
    >
      <div className={css.fsComponentHeader}>{prefix}</div>
      <input
        ref={inputRef}
        className={css.fsComponentInput}
        type="text"
        value={value}
        onChange={onChange}
      />
    </div>
  );
}

You don't have to provide a ref for every HTML tag you use in the components JSX. But the container element should have one, and also some pivotal elements, like input elements, could benefit from this.

This way, the developers using your component can speak directly with the elements DOM API with ease, when needed.

5. Support both controlled and uncontrolled modes

Don't decide how developers should use your component. Support both controlled and uncontrolled modes. Right now, we have a controlled component. By turning it into a component that can be used both controlled and uncontrolled, we empower the users of our Component.

export function FormComponent({
  prefix,
  value,
  ref,
  onChange,
  inputRef,
  ...props
}: Props) {
  const [internalValue, setInternalValue] = useState(value);

  useEffect(() => {
    // Update value if it is used as a controlled component
    if (onChange === undefined) {
      setInternalValue(value);
    }
  }, [value, onChange]);

  return (
    <div
      {...props}
      className={css.fsComponent + ' ' + (props.className || '')}
      ref={ref}
    >
      <div className={css.fsComponentHeader}>{prefix}</div>
      <input
        ref={inputRef}
        className={css.fsComponentInput}
        type="text"
        value={onChange === undefined ? internalValue : value}
        onChange={(e) => {
          if (onChange) {
            onChange(e);
          } else {
            setInternalValue(e.target.value);
          }
        }}
      />
    </div>
  );
}

Bonus 6! Keep functionality out of your design style library!

If your component library is meant to enforce a style guide, or a design pattern, why not let the users of the component library worry about the logic and only implement the styling? Then you also have a lot less of bug testing to worry about (I'm certain you will find bugs in the above example, for instance). What about just this:


type Props = {
  prefix: React.ReactNode;
  children: React.ReactNode;
  ref?: React.ForwardedRef<HTMLDivElement>;
} & React.HTMLAttributes<HTMLDivElement>;

export function FormComponent({ prefix, children, ref, ...props }: Props) {
  return (
    <div
      {...props}
      className={css.fsComponent + ' ' + (props.className || '')}
      ref={ref}
    >
      <div className={css.fsComponentHeader}>{prefix}</div>
      <div className={css.fsComponentInputContainer}>{children}</div>
    </div>
  );
}

Style it up assuming that {children} is an input-element, state this clearly in the documentation, and let the developers deal with it if they feel they need something else. Then the design system only deals with the looks and feel of the application, while the application code deals with the functionality:

<FormElement prefix={<Icon svgPath={keyIconPath} />}>
  <input type="password" value={password} onChange={(e) => setPassword(e.target.value)} />
</FormElement>

CSS in Stylesheets

Lars-Erik Bruce — Wed, 03 Jan 2024 09:18:13 +0000

What if we wrote the CSS rules in separate files, provided to the browsers as a form of "style sheets"?

Instead of transpiling SASS, writing CSS in our Javascript or fill our HTML or templates with class-names that describes the style we want, here is a novel idea: What if we provided pure simple text files to the browser, explaining how we would like our web applications and documents to be styled?

There seems to be many benefits of providing CSS in text files like these:

1. Improved performance

Faster loading times

Pure CSS files are lightweight and it turns out, the browsers can work out their contents and apply the style much faster than competing methods. This again, makes sure the loading times are much faster.

Also, the CSS doesn't even have to load, before the page is started rendering. The browser can apply styles whenever new style sheets are ready loaded.

Cache efficiency

Browsers can cache pure text files, which means that once a user has visited your web page, his browser doesn't have to download the CSS file again until next time you have changed the sites appearance.

2. Improved maintainance

Simplified debugging

When the CSS are located in separate files, it is easier to locate and fix styling issues. Especially when we write the style sheets ourselves, instead of relying on transpilation. When we isolate CSS from JS and HTML, we reduce complexity and make debugging a more straightforward process.

Version control friendly

Writing the styles in pure text files, we can track, reverse and collaborate our style sheets with ease in git.

3. Enhanced flexibility and scalability

Reusability

CSS in text files can be reused across multiple pages. CSS written for a specific style class, can be reused for multiple components. This saves time, and ensures consistency in design.

Scalability

Having CSS in separate text files makes it easier to organize our styles. We can split the styles into different "sheets" (text files) and manage them independently.

There are many ways we could divide the CSS files. We could use one for each component we make, one for each screen in our application, or heck, for smaller projects we could even make do with one single CSS file for the entire web site.

In conclusion

Instead of the tried and tested approaches like "utility first" style classes like Tailwind, "css-in-js" frameworks, transpiled super CSS like SASS or Less, we could try something novel: Write plain CSS in plain text files. I think this would be an important and beneficial practice for modern web development. By understanding and implementing these principles, developers can create more efficient, maintainable and flexible web pages and web applications.

A px is not a pixel, long live the px!

Lars-Erik Bruce — Mon, 27 Nov 2023 16:32:06 +0000

One of the lessons you need to have conquered, before becoming the ultimate CSS maestro, is embracing the fact that a css px is not the same as a screen resolution pixel. In CSS a px is a unit of measurement that is supposed to represent "one dot on the screen". Though, it is not always that 1px is made up of a single screen pixel. Actually, in these "high resolution" days, seeing a CSS pixel actually align with screen pixels are quite rare. How can this be?

One of the problems, is that screen resolution keeps getting larger, and if we insisted on letting 1px equal a screen pixel, web pages would become unreadable and ridiculously small on high resolution monitors.

One CSS pixel is defined as the visual angle of one pixel on a device with a pixel density of 96 DPI (dots per inch) and a distance from the reader of an arm's length. Therefore we can also call a CSS pixel for "the visual angle unit". This definition is designed to make web content appear at a similar size across different devices.

"The absolute length units are fixed in relation to each other and anchored to some physical measurement. They are mainly useful when the output environment is known. The absolute units consist of the physical units (in, cm, mm, pt, pc, Q) and the visual angle unit (pixel unit) (px)." - CSS Values and Units Module Level 4 (w3C).

Furthermore, the CSS specification defines a pixel to be exactly 1/96th of a CSS inch, while 1cm is defined as 96px/2.54 ( since one inch is 2.54 centimeters).

What can we learn from this? CSS pixel as the canonical unit!

All this means that, when it comes to all CSS units of absolute length (cm, mm, Q, in, pc, pt and px), they are all reduced to a px value. This means that you really don't need any other absolute length units than px!

It can sure be helpful to know that an inch is always 96 CSS pixels, or that a centimeter is always around 37.8 CSS pixels, as a guide to how many pixels you need. But in the end, in the style sheet, you are probably better off just specifying all absolute sizes in pixels.

What about relative length units?

Many of the relative length units are also anchored to pixels, but you have to do the anchoring yourself. For instance, 1em is the same as the font-size in the element. So if the font-size is set to 14px for an element, then 1em is identical to 14px. 1rem is the same as the font-size in the root-element.

This means that, in the end, if you specify all sizes with px instead of these relative units, the screen will look identical. The upside of having used these relative units, comes when you change the font-size, and witness everything else adjust its sizes accordingly.

I would argue, none-the-less, that in most cases setting the sizes with the px unit is enough here as well, either way. If you maintain an application that rarely change design/font-sizes, it is rare that you need this automatic adjustment, and if you use px as unit you have more control over the actual final sizes in your style.

From an Universal Design perspective, you think you might need these relative units after all. So that the user might change their default font size in their browser settings. From empirical experience, it looks like most people who need a larger text either use browser/OS zoom, or reduce the screen resolution on their devices.

So I'd say, go px all the way!