Forem: Marvin Danig

Toucaan—Baseline CSS 🎼

Marvin Danig — Tue, 12 Nov 2019 01:21:12 +0000

This is the second chapter on my series on Rethinking CSS Frameworks with Toucaan.

❥ TLDR; Modern web browsers have evolved to a point where a heavy-handed reset or reboot css is no longer required. In this chapter, we will implement a fundamentally different and a much lighter reset strategy by uncovering only the bare minimum set of rules that are needed for consistency according to the new landscape of the web. We will tackle two beasts—an intrinsically responsive layout using CSS grids and blockscoped typography, both of which in my opinion will form the basis of user interfaces (UX/UI) on the web in future.

Baselining CSS

In the last chapter we created a blank file to test the responsiveness of an empty page. That worked perfectly and was easy enough to implement. We simply touched a new file and opened it on a browser like Chrome, like so:

$ touch example0.html     // Create a new file but do not write anything on it. 

$ chrome example0.html    // Open this 0 byte files on your favorite browser.

Now let us take our work on the Toucaan CSS framework forward from this point. Let's inspect this 0 byte blank page on the console of the browser. Press ⌘+⌥+I keys if you are on the Mac with Google Chrome:

Blank webpage on the browser window.

You will see that even though we loaded a blank file on to the browser, there still are a few html elements that are rendered on the DOM. Every web browser will render these elements, just to display the blank page correctly.

Browsers will "fix" the html on page because it is in the nature of HTML to be forgiving, and modern browsers are smart enough to handle issues like missing or unmatched tags quietly.

<!-- Blank page as rendered on desktop Chrome, Firefox, Brave & Safari. -->
<html>
  <head></head>
  <body></body>
</html>

Notice that the browser also applies a default user-agent^* stylesheet called html.css under the page. See the 'Styles' block (screenshot above) of your browser's console. This html.css file is a default set of rules that each browser is shipped with upon install. Up until a few years ago it was this html.css file that used to contain several inconsistencies across vendors but that is no longer the case today.

We can assume that html.css—the unset cascade—itself is practically the consistent reset.css for our daily use.

A very interesting example of reset was shared by developer Andy Bell last week for a blog type of application. While their reset may be limited in scope it does help us establish the fact that there is very little arm-twisting required over a browser's own set of rules to establish consistency. This is great news and one of the main reasons why we will try and keep Toucaan a loosely coupled CSS framework for 2020.

Head over here to see what the latest html.css looks like on major browsers today:

Webkit html.css@ Chrome & Safari

Quantum html.css@ Firefox

Chromium html.css@ Blink or Edge browser

Getting back to the DOM, given that there are only three html elements required for a webpage to be valid, we will start with baselining Toucaan for only three baseline elements of html, namely:

1. <html> tag or the **:root** element,
2. <body> tag, and the… 
3. <head> tag.

The <head> element is always set to display:none;, so effectively there are only two html tags <body> and <html> for us to play with. Given below is how we will structure our baseline reset for Toucaan:


<style>
    /* The following is pure css and not sass/scss. */
    @import url('toucaan/portrait/portrait.css') only screen and (orientation: portrait);

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

    @media only screen and (orientation: portrait) {
        :root { 
            /* Portrait variables go here.  */ 
        } 
    }

    @media only screen and (orientation: landscape) {    
        :root { 
            /* Landscape variables go here. */ 
        }
    }

    /* Bare minimum elements required for a valid webpage */
    html { }

    body { }
</style>

That's it. This is what a modern reset.css would look like on Toucaan.

What it also means is that everything else that goes into designing an application, the other html elements and their corresponding styles, can be covered using optional CSS helpers to support the entire spectrum of devices and browsers. My guess is that there wouldn't be much rules to import even for the most sophisticated web applications out there, but who knows? Let us see where we can go with Toucaan before committing.

Note that on the reset above I have inlined the portrait ⇋ landscape switch along with baseline tag selectors for html and body elements each and put everything inside a <style> … </style> tag. We do this to ensure that all the critical above-the-fold css is available for the first contentful paint (FCP) as soon as possible and it helps to declare all global css variables from one place.

Some of you pointed me towards Steve Souder's article don't use @import from 2009 but I can confirm that this position is no longer valid. The fact that almost 50% of the web is on http/2 and that there is a possibility of hardcaching all CSS locally using a serviceworker, I think we are good to go with imports in 2020 and beyond. Besides, our little CSS import switch will request only one external CSS file for a given 'viewport state', just like a <link> url does.

Feel free to dissect the position I have taken on using CSS @imports on Toucaan but for now I am gonna happily report that not using CSS imports to separate critical from non-critical CSS is an anti-pattern that should do be done away with. Toko, toko!

Great, so we now have a foundation for a new reset file on Toucaan. Let us add some meat to it next.

Layouts with CSS Grids.

One of the things that I'm (super!) chuffed about using for layouts on Toucaan is the CSS grids. Layouts on Toucaan are exclusively going to be based on CSS grids. Period.

To enable grids we simply apply the following rule on the body element of our inline-reset:

    body {
        display: grid;
    }

That's it. We are all set for any kind of responsive layout with Toucaan now.

Enabling grid on the body ensures that every direct child on page can now behave as part of a larger blueprint specified under a grid system. Not only that, we can also specify different layouts for portrait and landscape switch and swap out the layout according to the new state of the viewport.

I don't think there is any other way that I would do layouts in 2020.

Support from CSS grids is substantial in 2019.

As you can see the support for CSS grids has grown sufficiently with nearly every major browser having implemented the newest specification. Here is what our inline-reset with CSS grids would look:


<style>
    /* The following is pure css and not sass/scss. */
    @import url('toucaan/portrait/portrait.css') only screen and (orientation: portrait);

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

    @media only screen and (orientation: portrait) {
        :root { 
            /* Portrait variables go here.  */ 
        } 
    }

    @media only screen and (orientation: landscape) {    
        :root { 
            /* Landscape variables go here. */ 
        }
    }

    /* Bare minimum elements required for a valid webpage */
    html { }

    body { 
        display: grid; /* Semantic layouts! */
    }
</style>

We have a very simple reset.css that is grounded in the realities of the web today. In the next chapter we will move the display: grid rule into its own separate class named .layout-palette, which will describe how the header, the footer and the main body on a webpage will be laid out in a given context.

CSS grids aren't anything new but they certainly are a new 'standards' tool that is available at our disposal. After having dabbled with CSS floats, flexbox and whatnot for years, I am convinced that CSS grids are the only logical way to do layouts. It is simple, semantic and much easier to reason about than anything else on market.

Why no CSS float or no flexbox? = Why CSS grids only!

Thing is that if you want to do modern layouts in 2020 (and beyond) you shouldn't be using flexbox or floats anymore. It is just plain wrong. This of course doesn't mean that you shouldn't use flexbox or floats on your CSS at all, but using those element level properties for sitewide layouts is an anti-pattern—it is almost like a hack that we have had to live with in absence of grids. I feel very strongly about this, so let me explain this a little more:

The body element on an empty webpage is like a raw piece of land waiting to be cut-up into smaller rectangles to form the foundation of a house. Each of these tiny rectangles have a different meaning or a purpose, like a kitchen or a bedroom or a living space, but are also a part of a larger blueprint of a building that is yet to be built.

A set of rectangular jigsaw pieces on a website that sit next to each other in harmony with shared edges.

CSS grids are an ideal tool to break down this whole patch of land—the body—into smaller rectangles because it is a very top ↝ down view of the land. Whereas with flexbox you are more at the element level. Flexing is like the kitchen saying 'hey, I am a DIV and I am going to be stretching all the way leftwards to occupy whatever space is available'. Flexbox adds a certain behavior to the HTML element that needs to be counter balanced by another element (often sibling) with a behavior in the opposite direction.

It is like two little men trying to flex their muscles against each other and in process locking themselves in to form a layout. As sort of dynamic equilibrium instead of harmony. Not a very ideal situation because if the viewport were to go ultrawidescreen suddenly, the layout will fail.

<img src="https://raw.githubusercontent.com/marvindanig/assets/master/traffic-jam.jpg" alt="Blank web page." width="100%">
A soup of elements in a traffic jam.
Credit: <a href="https://unsplash.com/photos/o1eDaWJanpA" rel="nofollow">Joline Torres</a>, Unsplash.

Similarly, using CSS floats with a left or right momentum on the element turns a webpage into a 'traffic jam.' Almost always there is at least one element that is trying to get ahead of others. Such a layout too, like with the flexbox, is locked in a dynamic equilibrium that can easily fail on ultra-widescreens or some weird orientation towards one side. CSS floats for layouts are an absolute no-no!

Not to mention the amount code required to deliver the results with floats or flexbox is almost always higher than with CSS grids. In my opinion since layout is the boundary of control, the blueprint of proportions and meaning, the basis foundation on which a house with a function will be built, it is better to use CSS grids to split the view into meaningful part that fit together naturally.

Doing anything else like using the flexbox or CSS floats or tables (does anyone?) is just plain wrong.

Blockscoped Typography.

The second beast that we are going to go after with Toucaan is blockscoping typography. It is possible, but before we deep dive into it, let us look at one of the common memes that gets thrown around about CSS. About how difficult it is to fit text inside a box:

It has been traditionally been difficult to scale text within a box.

Unsurprisingly, there is quite a lot of developer merchandise available out there that sells this meme printed on coffee mugs or t-shirts. I'm afraid those are gonna have to go away with the new powers of CSS.

Let us first try and solve "'CSS is Awesome' in a box" problem using our portrait ⇋ landscape switch and then we'll use that solution to introduce blockscoped typography on our framework for everyone else to use. Scaling text is obviously a hard problem so I'm going to pin more on maths instead of design sense here. We will try and reconcile engineering with design principles later on.

Shown below is the code I penned using our orientation switch along with some responsive typography:

See the Pen CSS is Awesome by Marvin Danig (@marvindanig) on CodePen.

Try and scale the viewport on your desktop, mobile or tablet to test it. The contents inside the box will (should) scale naturally, down to subpixel accuracy, without use of any JavaScript or special font or hardcoded CSS locks or newer properties like clamp(), minmax() etc. A simple orientation switch is enough to fit the text reliably.

Does it 🤯 your mind? Well, it did for me!

Let us look at the step-by-step solution next:

Step 1.

I started with the following HTML and CSS:

<div class="box">
  <p>CSS</p>
  <p>is</p>
  <p>awesome.</p>
</div>

We didn't have to separate the words into three separate lines (p tags) but it offers better control, so I did it.

/* CSS */ 
*,
*:after,
*:before {
  box-sizing: border-box;
  margin: 0;
  padding: 0;
}

@media only screen and (orientation: portrait) {
  :root {
    --bu: calc(100vw/100);
  }
}

@media only screen and (orientation: landscape) {
  :root {
    --bu: calc(100vh/100);    /* Axiom: 100vh of landscape === 100vw of portrait. */
  }
}

Note that we have used CSS variables to define font size according to the orientation of the viewport and we are banking on the shorter side of the screen, breadth, for reliable scaling. We are thus relying on following two axioms:

Axiom 1: "100vh of landscape === 100vw of portrait."
Axiom 2: The shorter side of the rectangle i.e. breadth has less potential of variation upon resizing.

I must reiterate here that no special formulae or CSS locks or clamp() with minmax() has been used or is required to scale text accurately. Hardcoding safe values on code feels like an anti-pattern anyway, an aberration that we can avoid to align ourselves better to the idea of writing scalable software.

Step 2.

We know that the box around the text is a square, so its sides are equal. ~~To start I am going to use viewport width to specify dimensions of our div.box inside the portrait part of our orientation switch:~~ I set the sides of the square to 50% of breadth by using 50 bu's (breadth units), where each --bu css variable defined on the :root element stands for the viewport width or height depending on device orientation:

*,
*:after,
*:before {
  box-sizing: border-box;
  margin: 0;
  padding: 0;
}

@media only screen and (orientation: portrait) {
  :root {
    --bu: calc(100vw/100);
  }
}

@media only screen and (orientation: landscape) {
  :root {
    --bu: calc(100vh/100);    /* 100vh of landscape === 100vw of portrait. */
  }
}

.box {
    text-transform: uppercase;
    font-family: arial, sans-serif;
    font-weight: 600;
    text-align: center;  
    width: calc(50 * var(--bu));    /* 50% of breadth */
    height: calc(50 * var(--bu));
    border: calc(2 * var(--bu)) solid black;

}

/* Simple blockscoped typography based on breadth of the rectangle . */
p:nth-child(1) {
    font-size: calc(1/4 * 50 * var(--bu));              /* 25% of the width of the box. */
    line-height: calc(1.25 * 1/4 * 50 * var(--bu));     /* Line height = 1.25 */
}

p:nth-child(2) {
    font-size: calc(50/4 * var(--bu));
    line-height: calc(1.25 * 50/4 * var(--bu));
}

p:nth-child(3) {
    font-size: calc(50/6 * var(--bu));
    line-height: calc(1.25 * 50/4 * var(--bu));
}


/* Required on Codepen: */
body {
  min-height: 100vh;
  display: -webkit-box;
  display: flex !important;
  align-items: center;
  justify-content: center;
}

Step 3.

Great, so now we have square with width and height of calc(50 * var(--bu)). This is the 100% width or height of the box. To blockscope typography inside the box, we will use the dimensions of the box to arrive at text sizing elements like font-size and line-height, like so:

/* 25% of the width of the box. */
font-size: calc(1/4 * (50 * var(--bu)));

/* Line height = 1.25 times font size */
line-height: calc(1.25 * 1/4 * 50 * var(--bu));

That's it.

The text in the box will now scale responsively with subpixel accuracy as the browser is resized or the orientation is changed. Scaling is so accurate that even reflow isn't be triggered in 99% of the time!

Ala, welcome to blockscoped responsive typography with Toucaan. 😎

Feel free to test the demo by resizing your browser to its extremes and by going on any device between an Apple Watch 5 to OLED TVs. Report issues on Github if you bump into one.

Given that there is so much that can happen with typefaces I'll keep my ideas about blockscoped typography in an evaluative mode for now. It is yet to be seen if Toucaan can nail intrinsic layouts with blockscoped typography, especially for some more complex layouts. So look out for another chapter on this topic soon!

A note about vocabulary in use today:

Height and width is how we usually refer to the dimensions of a screen or the browser window. But what we are doing here, in mathematical speak, is referring to a simple rectangle with a length and a breadth. The labels height and width are all but an accurate description in the context of the desktop. Where the monitor is mounted in a way that the contents are displayed along the vertical plane. But height and with become somewhat invalid as soon as we start surfing content on a mobile or a tablet that is not held up vertically.

Use length & breadth instead of height & width?

One could be lying down on a sofa looking up towards the ceiling into the phone. Or looking down on a tablet lying flat on a desk, meaning parallel to the floor. Since the screen is no longer restricted to displaying content along the vertical plane, using height and width to specify its dimensions isn't always a 100% accurate. Labeling it with length and breadth however will be, no matter what the orientation of the screen is. 🤯

*For sake of clarity on Toucaan I'll often use mathematical labels length and breadth instead of height and width to refer to the dimensions of the rectangular display. There is an added advantage of doing this—we exactly know that the shorter side of the rectangle is the breadth, which could be viewport width or viewport height depending on orientation.

The final reset:

This is what our final reset.css on Toucaan looks like:

/* Modern reset using CSS Grids for layouts,    */
/* a typography pallete with block scopes and   */
/* a few accessibility-first media queries.     */

<style>
    @charset "UTF-8";   /* Recommended reading: https://www.w3.org/International/questions/qa-css-charset.en */

    /* Option 1. Use system fonts */

    /* Option 2. Use 'privacy safe' self-hosted typefaces with subsetting, or use…  */
    @font-face {
        font-family: "Font Family";
        src: url(data:font/opentype;base64, _font_subsetted_string_); 
        font-style: normal;
        font-weight: 300;
    }

    /* Option 3. Hosted typefaces such as from Google Fonts. */
    @import url(https://fonts.googleapis.com/css?family=Font+Family:300,300i&display=swap); 

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

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

    @media only screen and (orientation: portrait) {
        :root { 
            --bu: calc(100vw/100); /* Tentative */
        } 
    }

    @media only screen and (orientation: landscape) {    
        :root { 
            --bu: calc(100vh/100);  /* Tentative */
        }
    }

    /* Sane defaults below */s
    *, *:after, *:before   {
        box-sizing: border-box;
        /* I have a feeling that using margin & padding on elements instead */
        /* of the flexbox is somewhat an anti-pattern now but I am not sure. */
        /* We will come back to this topic in sometime. */
        margin: 0;  
        padding: 0; 
    }

    html {
        background-color: white; /* Always set the background color */ 
        -moz-osx-font-smoothing: grayscale;
        -webkit-font-smoothing: antialiased;
        overflow-x: hidden;
        overflow-y: scroll;
        text-size-adjust: 100%;
    }

    body {

        /* Move this into font-family. */
        font-size: calc(4 * var(--bu)); /* Theoretical a.t.m */
        font-family: 'Font Family', system-ui, -apple-system, BlinkMacSystemFont, Segoe UI, Roboto, Oxygen, Ubuntu, Cantarell, Droid Sans, Helvetica Neue, Fira Sans, sans-serif!important;

        font-smooth: always;
        font-weight: 300;   
        font-style: normal;
        font-synthesis: none;
        font-stretch: ultra-condensed;
        font-variant: no-common-ligatures proportional-nums slashed-zero;
        font-kerning: normal;
        text-rendering: geometricPrecision; /* Why not: text-rendering: optimizeSpeed;?… in light of PWA. */
        font-display: swap;
        font-display: optional;

        -webkit-tap-highlight-color: rgba(0, 0, 0, 0);
        -webkit-backface-visibility: hidden;

        -webkit-font-smoothing: subpixel-antialiased;
        -moz-osx-font-smoothing: grayscale;
        -webkit-osx-font-smoothing: antialiased;


        line-height: calc(1.5 * 4 * var(--bu));  /* Or 1.5 */

        /* Colors + contrast (This will go into the color palette.) */
        color: rgba(0, 0, 0, 0.95);
        background-color: white;

        /* Dimensions */
        border: none;
        min-height: 100vh;


        /* Behavior */
        overflow: auto;
        -webkit-overflow-scrolling: touch;
        scroll-behavior: smooth;
        touch-action: auto;
        display: grid; /* Grids are meant for layouts, flex are meant for element behavior! */
    }



    /* Accessibility specific media queries go below. */

    /* 1. Dark mode (or light) depending on requirement. */
    @media screen and (prefers-color-scheme: dark) {
        body {
            background-color: #343434;
            color: #fff;
        }
    }

    /* 2. Override animations for users with motion sickness or other vestibular disorders. */
    @media (prefers-reduced-motion: reduce) {
        * {
            animation-duration: 0.01ms !important;
            animation-iteration-count: 1 !important;
            transition-duration: 0.01ms !important;
            scroll-behavior: auto !important;
        }
    }

</style>

Welcome to intrinisically scalable layouts using CSS grids, responsive blockscoped typography and an orientation based design behavior separated along portrait & landscape css to gracefully adapt according to the new landscape of the web.

We will refactor the above shown reset with more explanatory notes in the future chapters. Onwards to typesetting and more CSS grids in the next chapter!

I have updated the Toucaan repository with this article and the latest code. Please note that everything on this repo is currently experimental in nature, so feel free to question, star, jump-in or offer sage advice. Contributions to Toucaan are also super welcome. Toko, toko!

Written by: Marvin Danig, CEO & Cofounder of Bubblin Superbooks. Follow me on Twitter or Github?

I am super thankful to Sonica Arora, Satyendra Sharma and Abigail Rennemeyer for the edits and helping me check the code for accuracies.

Toucaan—Rethinking CSS Frameworks. 📖

Marvin Danig — Thu, 17 Oct 2019 15:57:06 +0000

[Last update: October, 12^th 2019.]

❥ TLDR; This is the first of the many chapters on a new CSS framework called Toucaan. In this introductory post we talk about the new landscape of the web, consider miniature viewports like that of the Apple Watch 5 and the new Chromium based surface (V9 web browser) on a Tesla Model 3 and Model S as part of the web. Form factors available today are so diverse and different from barely four years ago that design strategies of the past such as "mobile first" or barely responsive are no longer viable. The slate of glass is resizable practically on a continuum, just like the web browser itself.

Modern web browsers too have evolved and gotten so much better that we no longer need a heavy-handed approach to force consistency across vendors. With Toucaan we will try to move away from traditional reset or reboot css and implement a simpler and lighter strategy instead. So, welcome to Toucaan—a tropical new CSS framework for the web, with fewer defaults, newer patterns and a much simpler cascade.

This chapter is available on a book that you can preorder.

Introduction

2020 is almost here.

It is unlikely that you or I are going to blast off to Mars or the Moon on a Spacex Starship anytime soon so we better turn our gaze towards another frontier of technology: CSS. 🙃

Let's take a look at how we will be writing web applications in 2020 and beyond, here on Earth.

Through this post we will revisit the basics of a web page, i.e. HTML & CSS, and develop a clean, intelligent and maintainable CSS framework from scratch. I named our new CSS framework Toucaan and you can join me on the journey of building it together. Here is its official repository and a silly Toucan logo that I made using CSS.

The Tropical CSS Framework.

Qualitatively speaking, the intent of Toucaan is to weed out all the unwanted CSS that your webapp doesn’t need. It is a deep dive into core CSS properties and web standards in a bid to discover new and useful patterns according to the new landscape of the web. We might identify a few anti-patterns in the process that our industry may currently be plagued with too, but we can address those on-the-fly as we go about building Toucaan ground up.

Why call it Toucaan?

Well, quite simply because I owned the pretty domain name.

Besides, Toucan is a beautiful bird. This aggressive little arboreal ramphastidus symbolizes both beauty and strength. We are going to base our CSS framework on this highly social and resilient bird to implement a styling stricture that will cover all the wilderness on the web. Ocassionally—though rarely—we may even spar with other CSS frameworks using our "mean" oversized and colorful bill.

So—say hello to Toucaan—the tropical CSS framework for the web. 😉

[Say it aloud:] CSS may be hard but… if Tou-caan, then you-can-too!

With Toucaan we will revisit every web design and layouting principle that there is. Test our ideas out in the open. No trick or technique, whether old or new is off the table, but we will definitely try to avoid using hacks. There are few other rules that Toucaan will adhere to and those are described here.

Now there are a lot of well established CSS frameworks out there like the Bootstrap, Bulma, Foundation, TailwindCSS and a bunch of strategies like the BEM, OOCSS or SMACSS (and others) to organize the application code but we will not try to imitate or wrestle with those. We will rather write Toucaan on a blank slate and in such a way that we do not take away anything from what most of these tools have to offer finally, but we add more to what's on the table for everyone to consider and use on production.

Let's begin.

The New Landscape of Web

Before we write our first line of code let us take a deep breath and look at the variety of devices that are a part of the web today. With subtle differences in their aspect ratios, device handling & user behavior, browser support and screenwise capabilities it is important to understand what the new landscape of the web looks like today and understand exactly what we are up against for a new CSS framework of 2020.

Here are some of the devices that sport a modern web browser:

There is the Apple Watch 5 with a web browser, iPhones in numerous sizes instead of just one model that Apple used to come up with earlier, multiple iPads, iPad Pros and Android tablets plus desktops, laptops and TV sets with a stock browser that work surprisingly well. Given that Samsung came out with a foldable phone recently and Microsoft is probably coming out with a foldable Surface tablet very soon, it is safe to assume that physical form is no longer a reliable viewport classifier that is so commonly used by every other framework.

It is rather safe to assume that screen-sizes are available on a linear continuum of form-factors and that a large phone could easily be considered a phablet or a tablet could easily become more than a desktop and so on depending on hardware and options. Whereas there is a large variation in the form factors available on the web, there is also substantial variation in the way each surface exposes the controls and input methods to the user—ala, accessibility over content. Let's not forget that there are cars too on the web now—in that they sport a neat web browser for those who need to be online while being on road. And then there are low-powered devices on the budget end of the market, like the Nokia 2.2 on Android (A53 core) or similar that are very popular in their segment as well.

Credit: Stuart O'Neil, The Noun Project.

Since Toucaan is about living CSS a short distance into the future, we will consider the V9 web browser from Tesla into the scope of our project as well. This is something that I have been meaning to do for sometime and given that people would have nothing to do but surf the web or read a book in a car that's driving itself, this seems like a reasonable thing to do.

Web is way bigger than it ever was.

A cool trivia: I wanted to publish this article three years ago but the rate of change in industry kept me from doing so. With new features being rolled out every week it was hard to track changes and decide on a strategy. CSS grids, ES6 and the whole reactive developer toolchain thing (I am looking at you, the noisy folks of React & Vue.JS!) followed by Apple & Google announcing the non-rectangular notched phones and so on. Web is enormous now, and it is much harder to design and scale websites between the lowest and the highest options that there are.

Notice that we are not even into talking about web browsers yet and yet the range of hardware itself is diverse enough to somewhat trump the very first assumption taken by nearly all the existing frameworks:

"Hardcoded break point values using CSS @media-queries".

Voila, we have our first anti-pattern to go after now! ( ͡° ͜ʖ ͡°)

What's with the hardcoded break points, eh?

Breakpoints are hardcoded on Tailwind CSS like this [1, 2], for example.

// tailwind.config.js
module.exports = {
  theme: {
    screens: {
      'sm': '640px', // Translates to hardcoded break-points in media queries.
      'md': '768px',
      'lg': '1024px',
      'xl': '1280px',
    }
  }
}

On Bulma, the break points [1] are used to silo blocks of code similarly like so:

/* Bulma CSS like any other framework uses hardcoded breakpoints like so: */ 

@media screen and (max-width: 768px) { /* Some style classes & rules here. */ }

@media screen and (min-width: 769px), print { /* Same classNames but different rules here. */ }

@media screen and (max-width: 1023px) { /* We armtwist the ruleset again… */ }

@media screen and (min-width: 1024px) { /* Are we on the desktops now? */ }

@media screen and (min-width: 1216px) { /* Dang!, what are we supporting here? */ }

@media screen and (min-width: 1408px) { /* Is this the iPad Pro 12.9 inches or something else? */ }

Then for each silo elsewhere on the CSS…

+mobile
  +typography-size('mobile')

+tablet
  +typography-size('tablet')

+touch
  +typography-size('touch')

+desktop
  +typography-size('desktop')

+widescreen
  +typography-size('widescreen')

+fullhd
  +typography-size('fullhd')

…hundreds of classNames are repeated to cater to the behavior desired in each silo of devices. Pretty much every CSS framework follows this pattern and a breakpoint is added every few years to account for industry-level changes. The question is how many hardcoded breakpoints will we continue to add as our industry evolves at a break-neck speed?

At what point will the hardcoded breakpoints become all too many?

Mode driven instead of data driven:

While it would be a nice exercise to plot a graph of all the screen sizes (pixel ratio data) that are available on market, but going down this path to figure out a new set of breaking point values to separate mobile from tablets from watches from desktops from cars to any other new kind of surface that is about to come on the web is anything but scalable. Or even practical.

In my opinion using hardcoded values on CSS media queries is an artifact of the tunnel vision of mobile web that we have held since the very first iPhone. It is rather a simplistic solution of a simpler time that is no longer valid, and therefore an anti-pattern that we should move away from. We need something smarter to handle the diversity of web devices now.

So, is there a way to implement layout responsively without using hardcoded break-points?

Turns out, yes there is!

We can build any kind of responsive application using a really simple and smart set of rules that we will talk about in the next section.

The 'Two States' of Web Design.

Let's create a blank page on your machine and load it on a desktop browser first.

This is easy, simply jump into your terminal and:

$ touch example0.html     // Create a new file but do not write anything on it. 

$ chrome example0.html    // Open this 0 byte files on your favorite browser.

What do you see on this blank page?

Of course nothing, it is an all-white or an all-black blank page depending on your browser's defaults. Did you know that this blank web page is the most responsive web page in the whole world wide web?

No CSS or media query is required to adapt the UX/UI of a blank page on mobile or desktop or any other device on web. You can resize the browser to any aspect ratio and the blank web page will continue to scale perfectly and responsively.

Viewport rectangles of the browser window on resize.

Well, of course a blank page is going to be responsive you'd say but this is a hypothetical situation Marvin, so let's turn the table over and orient the desktop in portrait mode instead:

Now the desktop in portrait orientation is going to reveal a browser window that is longer in height and shorter in width—kind of like a mobile phone but on a much bigger piece of glass. In reality a very small group of people use desktops in portrait mode (mostly developers) but the usage is possible nevertheless. Use of portrait mode grows on tablets—with about 60% iPad users preferring landscape over portrait where as the story flips completely on a smartphone where about ~96% people prefer the portrait mode over landscape depending on content. With Apple Watch, the tiniest of screens on web, I suspect that nearly 100% of usage would be in portrait mode given that the device is physical tied to the wrist that way.

Here are some graphs & stats if you're interested.

On Tesla Model S the browser open in portrait orientation just like a desktop in portrait mode while on Model 3 it does so in landscape mode. Well this discussion kind of uncovers that all of the web is viewed in only two modes of orientation—portrait or landscape—and square is the geometric point of inflexion where the media query needs to switch from portrait to landscape and vice-versa. Interesting.

This also means that there are only two states of design on web no matter which device or orientation one may choose to consume web on. It is a hard cold fact that electronic screens are rectangular in shape—well, almost—and therefore, the point of inflexion for all style rules to switch mode should be where the viewport itself becomes a square and starts flexing in the other direction. Since there are hardly any devices in shape of a perfect square, mathematically speaking we can take it for granted that a webpage will either render in portrait mode or landscape.

And oh, oh, ICYMI, there is a lot more math coming into CSS in the near future so we'll have trigonometry at our disposal eventually!

<blockquote class="twitter-tweet" data-lang="en">

The CSS Working Group agreed this morning on adding many math functions. We now have:

• calc()
• min()
• max()
• clamp()
• sin()
• cos()
• tan()
• acos()
• asin()
• atan()
• atan2()
• hypot()
• sqrt()
• pow()

The face of CSS is rapidly changing.

— Benjamin De Cock (@bdc) February 28, 2019

Kickstarting the code

Now that we have covered some ground for Toucaan to work on let's start wiring up all the ideas discussed above into code. Since a webpage can be rendered in only one of the two states of the viewport, either portrait or landscape, we'll begin with the following ruleset for our new framework:

@media only screen and (orientation: portrait) {
  :root { /* Portrait variables go here.  */ } 

  @import url('toucaan/portrait/portrait.css') only screen and (orientation: portrait);   
}

@media only screen and (orientation: landscape) {    
  :root { /* Landscape variables go here. */ }

  @import url('toucaan/landscape/landscape.css') only screen and (orientation: landscape); 
}

The twin code blocks above may not seem like much at this stage but this dual state switch is exactly what we are going to use to go about scaling our layout across all the web devices on the planet. Notice that we are using a standard asynchronous @import call to request only so much CSS that a given "viewport state" will require. On the desktop, this state of a given render will not change unless the browser window is resized or if the user decides to swivel the monitor over.

Organizing your CSS this way ensures that both "states" of every element that will render on the DOM have been considered and then we can be sure that the webpage will scale desirably across the entire spectrum of devices that are on the web. It also helps avoiding a gigantic reset.css/reboot.css which can be a pain on low-powered devices. So hang in there for a little bit and stand by for the next chapter on Toucaan in which we will take up baselining CSS across vendors and introduce scalable responsive typography without use of javascript.

I have setup a tiny repository for Toucaan and checked-in all that is under experimentation right now. Feel free to star, jump-in, offer sage advice or contribute to Toucan!

Written by: Marvin Danig, CEO & Cofounder of Bubblin Superbooks. Follow me on Twitter or Github perhaps?

Super thankful to Sonica Arora, Abigail Rennmeyer, Varun Singh and Nilesh Trivedi for helping me review this post for accuracies.

This article was originally published at Bubblin

To Serif or Not To (Sans) Serif?

Marvin Danig — Thu, 20 Jun 2019 19:38:47 +0000

Usually when I'm tired of coding I look up to design.

Art is pleasing to the eyes and it helps me take my mind off development whenever I can. This time around I decided to dive into typography to understand what kind of typefaces look good on the books that we publish on Bubblin, and why?

To serif or not to (sans) serif, that is the question.

When it comes to web typography, this is a settled battle more or less. That if you're designing for web use sans serif typography but if you are designing for print go for serif typefaces that compel authority over minimalism. That adage about what works on the web and what doesn't, and vice-versa.

But the question is, again, why?

Why do sans serif typefaces work better on web but not the serif ones?
Why do the flourishes of serif fonts compel class and authority on print books?

Goes without saying here that following the design guidelines (such as to use sans serif typefaces on the web) is critical for inclusivity.

Always design for the form and function both.

Through this post we will look at some of the reasons why the guidelines in the first place and how we can typeset our website correctly for accessibility.

"The best font choices are those where readers notice the message."

Let's take a look at the anatomy of a typeface first:

[ Image credit: Designer Insights ]

Serifs are those decorative flourishes at the end of the strokes. As you can see from the anatomy above, `serif` typefaces look fancier and well-decorated, but their flourishes work only at a sufficiently large size. When the typeface is shrunk below a certain threshold, these flourishes turn into noise and lower overall legibility—meaning, they do not help our ability to recognize individual letters or words at speed, thus affecting visual accessibility. > Serifs are used to guide the horizontal “flow” of the eyes; The lack of serifs is said to contribute to a vertical stress in sans serifs, which is supposed to compete with the horizontal flow of reading. – [De Lange et al., 1993](http://cajun.cs.nott.ac.uk/compsci/epo/papers/volume6/issue3/rudi.pdf). Before we take up what _"flow" of the eyes_ is here and how _vertical stress_ helps with readability on web, let's step away from typography for a moment and take a look at animation first. --- Yes, a typical animation film from Disney or Pixar, for example. Animation is storytelling as a function of time. In other words time is the glue between storytelling and the motion of story i.e. flow. You may be surprised that this motion or flow of story can be depicted on a single shot of frame as well. Look at Lightning McQueen below, for example: It's a still picture but there is motion in it too.

[ Image credit: Cars Movie @Pixar ]

Notice the blurred alphabets 'E' and 'D' on the side of the race track that suggest McQueen is speeding through the frame. This blurring is called motion blur or pan blur depending on how the camera or the subject moved and left behind a trail as the frame was being captured. Those hazy attributes stretching E & D alphabets represent the flow of time, they hint us about movement, its direction and speed.

Below is another picture of Tibetan wild asses running amok in Ladakh.

[ Image credit: Satyendra Sharma]

On this picture you can see that the animals are running forward but their heads are bobbing up and down too. Even though the picture is hazy, and the attributes of the animals aren't very clear, but the motion is evident from a single shot due to saccadic perception.

The serifs on a typeface cue horizontal motion similarly.

They guide the horizontal “flow” of the eyes as suggested by De Lange in their study of typographical accessibility. This makes perfect sense on print because we turn the pages from left to right horizontally, and the typefaces being floored along a track motions us to move forward in the direction of flow of story—ala, line-tracking.

On web however, the story is laid out vertically and the flow is scrolled downwards. Using serif fonts with horizontal marks therefore clashes with the direction of flow on a scroll. This is why typefaces that look good and feel right on web are taller and san-serif i.e. ones that present higher vertical stress than horizontal.

That's all for a gyan post this week. I had fun analyzing typography closely. Did you?

Written by: Marvin Danig, CEO of Bubblin Superbooks. Follow me on Bubblin!

Google Pixel 3 has a notch!

Marvin Danig — Wed, 10 Oct 2018 00:25:17 +0000

If you weren't paying attention, Google announced the Pixel 3 XL today, and it has a notch! Yep, that dreaded notch that some developers loathe, but the consumers seem to be okay with.

Today's announcement from Google means that as an industry we're headed towards non-rectangular viewports where one cannot assume that a CSS width declared @100% will be equal to 100% available width on the viewport, especially around the notch in landscape mode.

Thankfully, there's an easy standard fix for this issue as described on the following blog post. Quite interesting to note that Google announced CSS support for notched devices barely a month ago and followed it up with a notched phone themselves.

Take your web development skills a notch higher

Marvin Danig — Thu, 13 Sep 2018 18:50:53 +0000

Raise your hands if you love the notch on iPhone X, XS, XR or XS Max! 🙋🏻‍♀️🙋‍♂️

Okay, not many hands went up there, but I'm sure as a developer you do love some extra "real estate" on your screen to be able to make use of. A beautiful edge-to-edge display—well, almost—makes the notch at the top of the bezel less of an eyesore for most people.

In fact, it's not even an issue for most websites in portrait mode.

Landscape viewing is where the notch pokes in the eye.

Take a look at dev.to for example:

I'm not sure if you can see in the image clearly but the header ends abruptly both on left and right hand side, leaving behind a feeling of a bug in the layout. This is truer and worse on Youtube.com:

Terrible.

The issue feels particularly bad on Youtube because I normally watch videos in landscape mode and after every video I get to see this glaring bug with blood red color all over it. 🤢

It's important to note here that all of the websites discussed above do have their header width set to 100% in their layout. So there is an understood expectation for the header to occupy full width of the screen. But that's not the case however. It's just that browsers like Safari and even Chrome v69 on iOS introduce these white bars by adding a little bit of extra margin to your page so that the content isn’t obscured by the notch.

They call it safe area margins.

Enter viewport-fit meta tag and CSS environment variables.

Here's a simple fix to use all the extra space. To tell the browser to expand into the display cutout (notched) area, set the viewport-fit property to cover like so:

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

That should do the trick, especially for the sticky header on top. If you want to use the entire screen area but at the same time avoid content going under the notch, use css environment variables like so:


.content {
  padding: 16px;
  padding-left: env(safe-area-inset-left);
  padding-right: env(safe-area-inset-right);
}

/* Basically there are four CSS rule options to handle 
   the notch from all four sides of the iPhone. I don't 
   recommend using them though!

padding: env(safe-area-inset-top) 
         env(safe-area-inset-right) 
         env(safe-area-inset-bottom) 
         env(safe-area-inset-left);

*/

Another approach to solving left and right padding on the body of content correctly is to simply use width definitions per @media-query, like so:


@media only screen and (orientation: portrait) {
    body {
        .shrink {
            width: 95%;        
        }
    }
}

@media only screen and (orientation: landscape) {
    body {
        .shrink {
            width: 90%;      // Shrink a little extra to avoid the notch.
        }
    }
}


.center {
    text-align: center;
    margin: 0 auto;
}

And then in your HTML, the main container element can sit with css classes shrink center to work across all devices and all viewports with just one rule definition. I prefer doing it this way to avoid using device specific hacks like safe-area-insets.

<header>
    <!--Sticky header with 100% width across and above the notch -->
<header>
<main class="shrink center">
    <!-- Body goes here -->
</main>
<footer>
    <!-- Full screen width under the notch -->
</footer>

That's how Bubblin Superbooks scales from Apple Watch to the iPad to desktop all the way up to television sets. 🎩

There are some other fancy solutions around the notch out there using JavaScript but it's really not recommended. Overkill. Less code means better maintainability. And similarly, less CSS => more scalability.

That's all for now folks. Stay cool. ❤️

Follow me on Twitter or on Github.

This post originally appeared on The Bubblin Blog

How to set up a simple jekyll blog near your rails app.

Marvin Danig — Tue, 04 Sep 2018 21:40:44 +0000

So your prototype is ready to go live and you need a blog to announce your upstart to the world.

Great!, but how do you do that?

…¯\(ツ)/¯

It's so easy to set up a blog that you wouldn't want to miss all that "domain authority" on web for your fledgling company. Miss out on the SEO juices that come along with a subdirectory like this: /domain.com/blog?

IMO, if you're doing a tech startup it is important to wiggle a little harder and setup your own blog. Blog is how the search Gods will look at you, at minimum, instead of Medium.

The following guide will help you setup a simple Jekyll blog alongside your rails app but the process would essentially be the same no matter which stack (node, python, java or others) you're on.

This post assumes that you love ruby_on_rails like I do and have an application (startup?) alive at your own domain.com. And now, you need a blog at /blog url of domain.com to dent the world with your announcement post.

Dang!, you're at the right place at the right time right now, so read on…

Of course, we too made our announcement too using the same technique last week!

We wanted to have a blog for Bubblin Superbooks to release new features on and post updates to. We are on rails 5.2 and wanted our blog to reside on the same top_level_domain (https://bubblin.io/blog vs. blog.bubblin.io) as the main product itself. Why? Because SEO, if you missed it earlier.

There's a couple of ways of setting up a blog, and quite a few open source options (wordpress/ghost etc.) out there, but we decided on using Jekyll with markdown for the sake of simplicity.

Jekyll is rack based like all rails-apps generally are, and I really enjoy writing with markdown.

For the uninitiated, Jekyll is a simple blog-aware generator, so all we need to do is be able to publish it alongside our rails app online, via the public directory. The web-server will take care of the rest from there. Note the blog doesn't have to be coupled with the rails app itself, it just has to sit nearby, like a sibling, and work in a way similar to how static uploads do.

Let's look at the setup first.

Setup

Assuming that your startup (or rails app) is going to be called domain.com, in your terminal:


$ mkdir ~/projects/domain.com
$ cd ~/projects/domain.com
$ rails new domain.com          // your app may already exist.

Now that we have the rails app (~/project/domain.com/domain.com), let's go ahead and get our blog ready. As of writing this post jekyll requires you have at least Ruby 2.2.5 installed on your system, but for the latest instruction, check the Jekyll setup guide.

$ cd ~/projects/domain.com      // or cd .. if you're inside the rails app.
$ gem install bundler jekyll
$ jekyll new domain.blog
$ cd domain.blog && bundle install

Go ahead and commit your blog to its own new repo:

$ git init && git add . -A
$ git commit -m "Setting up a jekyll blog on the side…"
$ git remote add origin git@github.com:username/domain.blog.git
$ git push -u origin master

Once Jekyll finishes you'll have the blog at ~/project/domain.com/domain.blog and the Rails app at ~/project/domain.com/domain.com, like so:

➜ marvindanig-@bubblin in ~/projects/domain.com: $ ls

domain.blog domain.com

Configuration

This is what our jekyll blog looks like:

➜  ls ~/project/domain.com/public/domain.blog
404.html      Gemfile.lock  _posts        bin           index.md
Gemfile       _config.yml   _site         contact.md

Modify the baseurl option on _config.yml of your jekyll instance to point it to /blog.

baseurl: "/blog"            // the subpath of your site, e.g. /blog, /docs

This is important so that assets load and link back properly. To ensure everything is working properly, start the Jekyll server and preview the blog on your browser. You can also apply a theme to your blog to match with your site's layout. We customized our Jekyll blog and open sourced our theme in form of a gem along with a guide to help you dip your fingers in quickly:

https://github.com/bookiza/bubblin-jekyll

(Simply fork it, replace logos and links and you're all set!)

Since we're hosting Bubblin on Linode I wanted to make sure that the public/ directory is committed properly. Remove 'public/' from .gitignore file if that is necessary to commit the directory. What we’ll be doing next is simply add a shared directory on our deployer recipe to tell rails where the requests to our blog will go. Thereon we can just build and rsync the Jekyll site to our blog directory on server. Easy peasy.

We're using Capistrano for build deployments so I added the "blog/" as a linked_directory on our deployer recipe:

➜ $ cd ~/project/domain.com/domain.com/config/        // In your rails/node/python app
➜ $ vi ~/project/domain.com/domain.com/config/deploy.rb

Add public/blog to the following line:

set :linked_dirs, %w{public/blog log tmp/pids tmp/cache tmp/sockets vendor/bundle public/system}

Exit vim with \wq!.

Publish

To publish we’ll use a two line deployer script that builds jekyll and rsyncs it to the public directory of our Rails application. If you don’t have rsync installed, you could use scp instead, or you’ll need to install one of these tools with your favorite package manager. Since I'm on mac, I use the Homebrew.

$ cd ~/project/domain.com/domain.blog/ && mkdir bin     // Create a `bin` dir here.
$ cd bin && touch deploy                // Note there is no dotfile extension on this script
$ vi deploy

Add the following lines to it:

#! /bin/sh

jekyll build
rsync -va _site/ ../domain.com/public/domain.blog
# rsync -va _site/ deployer@domain.com:/var/www/domain.com/shared/public/blog   // Uncomment for production.

Exit vim with \wq!. It’s a good idea to make it executable as well:

chmod +x ~/project/domain.com/domain.blog/bin/deploy

At the root of your blog execute $ . bin/deploy, and you’ll see rsync run and put the Jekyll build inside your rails app's public/ directory.

Now you can work on the app and the blog independently without mixing dependencies.

That's how you setup a simple jekyll blog near your rails app. And all the best with your startup!

P.S.: Did you know Bubblin is to books, what Jekyll is to blogs?

A condensed version of this post appeared on The Bubblin Blog