Toucaan CSS Framework Blog

Breaking Down CSS.

2024-01-15T00:00:00.000Z

Raise your hands if you love the notched iPhones and Google Pixel. 🙋‍♀️🙋‍♂️

Okay. Not many hands went up there, but I am sure, as a web developer or designer, you wouldn't you like some extra real estate for your app? A beautiful edge-to-edge "bezel less" display—well, almost—makes the notch not appear as a quirk for most users.

At least to me, the notch hasn't been an issue so far. I mean in portrait orientation.

As long as I am surfing the web in portrait mode, most websites look okay and work great, and the notched bezel doesn't appear on my list of nits to fret about.

It is the landscape mode, however, where the notch pokes me in the eye.

Take a look at The Dev Blog site, for example:

You will immediately notice that the header ends abruptly on both ends in a broken floating way. My designer's soul feels this is a bug in the layout.

However, what's worse is that the layout breaks even when the width of the header element is specified 100%. Yes, this is one of those weird instances of implementation where things don't work as expected by the end-user or follow the spec. Does setting 100% width on the screen no longer mean 100% of the screen anymore?

Is 100% width restricted to a "safe area"?

While I rarely read The Dev Blog with my phone in landscape orientation, the situation is worse for YouTube. A thick red header broken at the edges looks horrible. And most of the time, I view videos on my phone in landscape orientation.

This bug bothers me more on YouTube because videos are generally best viewed in fullscreen and landscape mode. And every time a video ends, this glaring header bug in blood red color shows itself at the top of the page. I wouldn't blame YouTube for missing out on this issue because they did set the width to 100% on their css. It's the implementation of iOS Safari that doesn't meet the specs on the notched phones.

A Solution

TBF, Apple adds an extra blank gutter area on both sides of the webpage to avoid content getting obscured by the notch. The area between the gutters is called the safe area as mentioned earlier in the post.

Given that Apple has forced this change despite its failing spec and the general assumptions about how widths work in css, now the question is how to handle the notch correctly for your website. And can we do it without hacks or tricks like testing for the safe area margin?

Update: August 15, 2023

The latest iPhones come with an island instead of a notch. I don't particularly like having a hard black blot floating around my apps or websites, but this is Apple and Apple's design language lately. As small voiceless developers, we can only adapt our designs around the notch or away from the island and continue to give it our best shot.

Update: March 9, 2020

The meta tag for the notched phones isn't enough anymore. Apple now recommends using a @supports(padding:max(0px)) { env() } query detection to fix the notched environment for your website on iOS Safari (iPhones). I hate them for doing this, but this is the only way to tackle the notch on the newest iPhones.

Also, the notch cannot be fiddled with on the iOS Google Chrome browser or the iOS Firefox browser at the time of this update.

Update: April 17, 2018

Google has announced that Pixel 3 and 4 will carry a notch like the new iPhones. The following blog post explains a simple technique to handle the notch in landscape mode gracefully. No javascript or css hacks are required for this technique to work, so shine away, you crazy diamond!

Enter Viewport-Fit Meta Tag!

A simple fix to use all the extra space around the notch is to set the new viewport-fit property like so:

<meta name='viewport' content='initial-scale=1, viewport-fit=cover'>

The meta tag above will do the trick and restore the relationship between 100% element width and 100% screen width as per specification.

@supports(padding:max(0px)) {
    body, header, footer {
        padding-left: min(0vmin, env(safe-area-inset-left));
        padding-right: min(0vmin, env(safe-area-inset-right));
    }
}

This query will allow your layout to access the areas behind the notch. Next, to ensure your content doesn't go under the notch either, you can use a container class like so:

.content {
  padding: 20px;
  padding-left: env(safe-area-inset-left); /* Apply safe area */
  padding-right: env(safe-area-inset-right);
}

/*** There are four safe-area padding options:
*
*   padding: env(safe-area-inset-top)
*           env(safe-area-inset-right)
*           env(safe-area-inset-bottom)
*           env(safe-area-inset-left);
****/

There are four options to handle viewing on all four sides of the phone.

By resetting all four safe-area paddings, one can guarantee a safe area for content no matter how the user holds their phone to view content.

A Better Solution

The safe-area padding insets resolve the issue at hand for the most part. Still, I recommend not using these unique non-standard properties (or hacks if you allow me) explicitly created for the non-rectangular viewport. It is both excess and unmaintainable.

There's a much simpler solution to avoid the content clash with the notch using simple and standards-compliant css properties. We'll use ordinary width definitions per single responsive @media-query, like so:

/* scss snippet */
@media only screen and (orientation: portrait) {
    body {
        .shrink {
            width: 95%;
        }
    }
}
@media only screen and (orientation: landscape) {
    body {
        .shrink {
            width: 90%;      /* Shrink slightly to avoid the notch. */
        }
    }
}
.center {
    text-align: center;
    margin: 0 auto;
}

That's it. You don't have to use env(safe-area-insets) to arrive at the desired layout and happily maintain just one code for all mobile phones, regardless of whether they are notched. In your HTML, apply the css class .shrink on the

container element to make it work across all devices and all viewports for your users. Just one rule to rule it all!

<header>
    
<header>
<main class=" shrink center">
    
main>
<footer>
    
footer>

I prefer this approach because it helps avoid using non-standard properties (safe-area-insets) for a goal achievable with just standard css. On Toucaan, we've adopted this approach as the default.

Several other solutions are floating around the web using JavaScript, but I do not recommend those. CSS is best suited for solving this layout nit.

The Notched Phone.

2023-08-15T00:00:00.000Z

This article was originally featured on the The Bubblin Blog. It has since been updated and migrated to the Toucaan blog because it is relevant here.

Raise your hands if you love the notched iPhones and Google Pixel. 🙋‍♀️🙋‍♂️

At least to me, the notch hasn't been an issue so far. I mean in portrait orientation.

As long as I am surfing the web in portrait mode, most websites look okay and work great, and the notched bezel doesn't appear on my list of nits to fret about.

It is the landscape mode, however, where the notch pokes me in the eye.

Take a look at The Dev Blog site, for example:

You will immediately notice that the header ends abruptly on both ends in a broken floating way. My designer's soul feels this is a bug in the layout.

Is 100% width restricted to a "safe area"?

A Solution

Update: August 15, 2023

Update: March 9, 2020

Also, the notch cannot be fiddled with on the iOS Google Chrome browser or the iOS Firefox browser at the time of this update.

Update: April 17, 2018

Enter Viewport-Fit Meta Tag!

A simple fix to use all the extra space around the notch is to set the new viewport-fit property like so:

<meta name='viewport' content='initial-scale=1, viewport-fit=cover'>

The meta tag above will do the trick and restore the relationship between 100% element width and 100% screen width as per specification.

@supports(padding:max(0px)) {
    body, header, footer {
        padding-left: min(0vmin, env(safe-area-inset-left));
        padding-right: min(0vmin, env(safe-area-inset-right));
    }
}

This query will allow your layout to access the areas behind the notch. Next, to ensure your content doesn't go under the notch either, you can use a container class like so:

.content {
  padding: 20px;
  padding-left: env(safe-area-inset-left); /* Apply safe area */
  padding-right: env(safe-area-inset-right);
}

/*** There are four safe-area padding options:
*
*   padding: env(safe-area-inset-top)
*           env(safe-area-inset-right)
*           env(safe-area-inset-bottom)
*           env(safe-area-inset-left);
****/

There are four options to handle viewing on all four sides of the phone.

By resetting all four safe-area paddings, one can guarantee a safe area for content no matter how the user holds their phone to view content.

A Better Solution

/* scss snippet */
@media only screen and (orientation: portrait) {
    body {
        .shrink {
            width: 95%;
        }
    }
}
@media only screen and (orientation: landscape) {
    body {
        .shrink {
            width: 90%;      /* Shrink slightly to avoid the notch. */
        }
    }
}
.center {
    text-align: center;
    margin: 0 auto;
}

container element to make it work across all devices and all viewports for your users. Just one rule to rule it all!

<header>
    
<header>
<main class=" shrink center">
    
main>
<footer>
    
footer>

I prefer this approach because it helps avoid using non-standard properties (safe-area-insets) for a goal achievable with just standard css. On Toucaan, we've adopted this approach as the default.

Several other solutions are floating around the web using JavaScript, but I do not recommend those. CSS is best suited for solving this layout nit.

The Inch CSS Unit.

2023-07-15T00:00:00.000Z

This article was originally featured on the The Bubblin Blog. It has since been updated and migrated to the Toucaan blog because it is relevant here.

The Standards Way

Have you ever tried using the INCH css unit, i.e., in, in your web designs? No?

Well, let's do it today. 🏁

I propose the following bit of code:

/* Somewhere inside the  element of your page, add the following: */

@import url('path/to/portrait.css') only screen and (orientation: portrait);
@import url('path/to/landscape.css') only screen and (orientation: landscape);

The css above will prioritize and import the desired stylesheet according to the orientation of the viewport. Then on the portrait (or landscape) css, we'll put the inch unit (in) to use like so:

/* portrait.css */
@media only screen and (max-width: 2in) {
    /*  Style the smartwatch or tiny viewports with < 2" width. */
}
@media only screen and (min-width: 2.000000000001in) and (max-width: 4in) {
    /* Smartphones and phablets are usually < 4" in width.*/
}
@media only screen and (min-width: 4.000000000001in) and (max-width: 8in) {
    /* Tablets in portrait mode, perhaps…*/
}
/* and so on…*/

Do you like what you see?

Wouldn't writing meaningful breakpoints like this be better?

Doesn't the code above just read beautifully? Using breakpoints according to the physical size of the medium? Huh, who could have thought of that?

I think referring to layouts by their physical size is only natural. It would also make it easier for developers and designers to communicate and reference UI with non-developer audiences.

An inch-wide button. A footlong header. 🤠

I know, you must be thinking—but does it even work? Can we use physical inches on css like this?

Well, the answer is both yes and no.

The --inch Utility Variable

Checkout the documentation on the --inch.

Note the in unit (css inch) used in the width-based media query above is already offered by vendors as part of the specification. So yes, using in units like this is valid css. That's for the yes part.

However, even though the code above is valid css and it "works" at the breakpoints specified predictably, the measurement doesn't scale the way we expect it to.

Props if you have already spotted the bug in the code above!

A Brief Context

There has been an embarrassing and lingering issue with the web's equivalent of the inch since the early days. The problem stems from how vendors implemented (or could implement) the correlation between an absolute imperial or standard unit like the inch or centimeters and the number of pixels it takes to achieve that physical length.

In other words, css doesn't really know how much an inch is.

Even modern browsers have this issue. A css inch, i.e., 1in does not equal a real physical inch you and I know of and use regularly. Therefore, specifying width: 1in; on your stylesheet doesn't mean the element painted on the DOM will be an inch-wide. Depending on the device, it would likely be shorter (or otherwise) than an inch in width.

A css inch (in) is something else altogether. It varies from device to device and has no reliable value despite the requirement. According to the specification, a css inch, i.e., 1in, equals 96px (or 72px for the Mac) or 2.54cm. This mapping between pixels and inches was set (hard-coded) some 30 years ago based on the resolution of existing hardware then.

If we were to believe the original implementation, an Apple Watch would be four inches wide according to css. 384px / 96px ≈ 4in. But we all know this is false. An Apple Watch is just under an inch in width, even though its pixel resolution is close to the resolution of the original iPhone.

A Time Capsule

The last commit establishing the relationship between an inch and pixels, i.e., to 96px (or 72px on the Mac), was pushed in the early 1980s, during the age of CRT monitors. We're literally in a time capsule here! Can you imagine how long this bug has denied us the opportunity to use physical units for digital layouts? Almost four decades! 🔥

The browser doesn't know how much an inch is in absolute terms. It never tests for the actual size of the pixel rendered on the viewport.

A 2011 Update of CSS Standards

"In the past, CSS required that implementations display absolute units correctly, even on computer screens. But as the number of incorrect implementations outnumbered the correct ones, and the situation didn't seem to improve, CSS abandoned that requirement in 2011. Currently, absolute units must work correctly only on printed output and on high-resolution devices." Reference.

Yet, the committee did not define "high resolution" in its last update. Since low-end printers resolve at a minimum of 300 dpi, and high-end screens are close to 200 dpi in resolution today, the cut-off is probably somewhere in between.

The note concluded with the following recommendation from the committee:

"…if you are designing for print, use physical units (in/mm), but if you are designing for the online medium, use px, em, or percentages."

But this was in 2011. More than a decade ago.

What about now? Has anything changed in 2023?

The New Way of The CSS Variables

Let's use one of the finest frontiers of modern-day css, CSS Custom Properties or CSS Variables to teach some standard units to the browser.

The good thing is that the browsers already know a little about it; we only have to bring them up to speed. Let's declare a variable --inch at the :root, like so:

:root {
  --inch: 96px;
}

We start with the in to px mapping per the specs above.

But I am writing this article on a 15" Retina Macbook Pro (2017). Since a retina(😬) display packs more pixels per inch than 96, the css inch, i.e., width: 1in on my computer, is shorter than the absolute measure.

To add support for retina displays:

:root {
  --inch: 96px;
}
@media (resolution: 192dpi) and (-webkit-device-pixel-ratio: 2) {
  :root {
    --inch: 130px; /* Tested using a physical ruler [^1] */
  }
}

Now the --inch utility variable specified on our layout will scale correctly. And it would do so on all the 20 million odd MBPs with the same hardware at best/default resolution. Yay! 🥳

We now have a better --inch: pixels mapping for a machine like mine.

Notice that by using an inch: pixel mapping, we inform the browser about how much an inch is in absolute terms here. We can continue to add hardware-specific --inch: pixels mappings for different mediums and combine those mappings with our existing knowledge of media queries to extend and refine further support.

For example:

@media only screen and (min-width: 320px) {
  /* Small screen, non-retina */
}

@media only screen and (-webkit-min-device-pixel-ratio: 2) and (min-width: 320px), 
only screen and (min--moz-device-pixel-ratio: 2)      and (min-width: 320px),
only screen and (min-device-pixel-ratio: 2) and (min-width: 320px),
only screen and (min-resolution: 192dpi) and (min-width: 320px),
only screen and (min-resolution: 2dppx)  and (min-width: 320px) { 
  /* Small retina screen that overrides the mapping above */
}

/* and so on…*/

That's it.

With css custom properties, we can easily supply the necessary hardware-specific mappings to the browser and then use physical inches to do our layouts. It not only scales well but is also so much more readable.

Given that css is all about finding a compromise to serve the maximum number of users, we can start, at least consider, using standard units for web design within an acceptable margin of error. Perhaps we may even reconcile the trade of print design and digital someday!

I created a tiny Utility Variable called --inch that supports several commonly available devices. Feel free to submit PR to add new mappings if your hardware+browser combination isn't already included.

:::warn Disclaimer Now it's time to state the obvious: As far as disclaimers can go, I must explicitly state here that this article and its accompanying library is an exploratory exercise. It is probably not fit for use in production yet. :::

[^1] I tested it using a 5th Grade Ruler. 🥳

Design Websites for The Apple Watch

2023-06-30T00:00:00.000Z

This article was originally featured on the The Bubblin Blog. It has since been updated and migrated over to the Toucaan blog because it is relevant here.

One of the capabilities of Toucaan is prioritizing and delivering the most intrinsically suitable stylesheet for a smartwatch. Toucaan uses a css router to accomplish this.

Let's look at what it takes to design a website (or web app) for the tiniest viewport on the web—the Apple Watch.

The Watch & The Browser

If measured in device resolution, the Apple Watch is similar to a mobile phone. A petite Apple Watch (the fifth generation and upwards) resolves to about 324 x 394 pixels. About as much as the first-generation iPhone.

However, the physical size of the watch is only 40mm—approximately 1.57 inches along the diagonal. Not only is the physical size of the wristwatch small, the time spent glancing through its screen is usually shorter too. Meaning we're dealing with both small physical size and short attention span.

Secondly, the viewable or the "light up" area on the watch is only about 1.18" x 1.25". It is also slightly obscured by the rounded bezel around the viewport, depending on the viewing angle and distance from the viewer's eye.

Mobile first Smartwatch first.

There are many important things to consider before designing websites for a watch. Chances are that your existing web app or website is responsively designed and is already compatible with the smartwatch. By default, Apple scales down every website to render it in the best possible way.

WatchOS will scale down content by a factor of 0.49 to ensure every responsively designed page fits the tiny form factor without introducing the horizontal scroll. This default behavior guarantees the existing mobile website to "work" on the watch browser correctly with no extra configuration required from the end user.

However, even mobile UI is usually too complex for the smartwatch. It is better to reduce and optimize your application for the watch separately. Deliver an experience that belongs to the smartwatch instead.

Below are a few tips & potential issues to bear in mind while designing for the Apple Watch.

Practice Extreme Minimalism

The first thing to internalize about an Apple Watch is to admit that showing nothing is better than something. Practice extreme minimalism while designing for smartwatch users.

More generally:

Display only the most relevant information to the user for which they will raise their hand for a few seconds.
If the content is text-heavy, left align the content and HTML elements.
Group the UX visually at the center of the screen to help users take action quickly.
Use the entire width and height available of the viewport.
Design for no more than two outcomes wherever possible.
Use native elements of the browser. For example, avoid building a javascript component for a hamburger menu with twenty different options. You might want to keep javascript to a minimum as well.
Use aria-labels to help watchOS pick up the correct interface for the end user. The Apple Watch supports several form elements, including the number type (type= "tel"), the date type (type=" date"), and the select input (

Toucaan CSS Framework Blog

Breaking Down CSS.

A Solution​

Enter Viewport-Fit Meta Tag!​

A Better Solution​

The Notched Phone.

A Solution​

Enter Viewport-Fit Meta Tag!​

A Better Solution​

The Inch CSS Unit.

The Standards Way

A Brief Context​

The New Way of The CSS Variables

Design Websites for The Apple Watch

The Watch & The Browser​

Mobile first Smartwatch first.​

Practice Extreme Minimalism​

A Solution

Enter Viewport-Fit Meta Tag!

A Better Solution

A Solution

Enter Viewport-Fit Meta Tag!

A Better Solution

A Brief Context

The Watch & The Browser

Mobile first Smartwatch first.

Practice Extreme Minimalism