CSS Grid Layout vs CSS Frameworks

November 24, 2019 • Frameworks, layout

“CSS Grid or CSS Framework? What should I use for my next project?” It is a question often asked by web developers, specifically new ones after they are introduced to the CSS Grid layout. CSS Grid layouts allows developers to build custom complex layouts with absolute control only by using Native CSS properties without relying on any frameworks which are bound by basic 12 column grid layouts plagued with default styling rules and do not offer a lot of room for customization. On the other hand building grid layouts with frameworks like Bootstrap feels like a breeze without the need of writing any CSS style rules or media queries to make the layout responsive.

Initially, when CSS Grid layout was introduced, it lacked cross browser compatibility which made many web developers a bit hesitant towards its implementation but that is not the case now! Which brings us to a question where we evaluate whether the CSS grid layout has eliminated the need for CSS Frameworks like Bootstrap to create layouts?

giphy

Don’t worry! If you have faced such questions yourself then you are at the right post. This post is all about that. I am going to highlight the differences between CSS Grid vs CSS Framework. We will also ponder the cross browser compatibility between these two. By the end of this article, you will be able to make a judgment call about your next pick among CSS Grid or CSS Framework. Let’s hit the road with a basic definition of these two!

What Are CSS Frameworks?

A CSS framework are also interchangeably referred as CSS libraries The basic purpose is to bring a more standardized practice for web development. Using a CSS Framework or CSS library you can fast-track your web development effort as it allows you to use predefined web elements. Meaning, if you wish to add a UI element for your web-application then all you need to do is include the framework CSS and JS file in your project and specify the HTML class for the element you want to style. This is how a CSS framework works.

Almost every CSS Framework has a grid, few of them have more grids to offer, few CSS frameworks even offer advanced JavaScript functions around interactive UI patterns.

To make it clear, we can take an example of a Bootstrap framework which is, in my opinion, one of the most famous CSS frameworks.

what's bootstrap?

Bootstrap is a front-end CSS framework, open-source and on GitHub, which helps in the UI development of the basic components of the CSS. You can change the style of your buttons, fonts and much more using Bootstrap.

Let us take an example, say you have to define a rounded button to your website, now instead of writing a fresh piece of code, you can leverage the CSS frameworks such as Bootstrap to provide you with an already defined code for the button you wish to have.

css button

To display the above buttons in your website, all you need to do is copy the below HTML code and paste it in your web application project, of course, you will have to specify the button text as per your requirements but the rest is all taken care of!

Cross Browser Compatibility Of CSS Frameworks

Cross Browser compatibility is a headache for web developers to face every day. With such an overwhelming advancement in browser development, the need to develop a web page that delivers a uniform cross browser experience is increasing day by day.

Gone are those days when everyone was on Safari and Internet Explorer. Many other browsers have taken the internet by storm like Google Chrome, Mozilla Firefox, Opera, and they are loved more than the Internet Explorer if we refer to browser market share. Millions of people prefer different browser and every browser company focuses on being different. This is what helps it to be liked by the people. This has increased the headache that comes from cross browser compatibility.

CSS Frameworks lifts this burden for you. A framework is not coded for a single browser. If it is, how do you think it will get popular? It won’t. A framework developer already knows that it will be used by millions of people who will be sitting on which browser, nobody knows. Hence, the frameworks are neutral and resolve the cross browser compatibility issues. You can just focus on the designing and creative parts of the website while using the framework.

Keep in mind though, that irrespective of which CSS framework you use and no matter how much cross browser compatible it may be. It is always recommended to perform an End-to-End integration testing of your web application across different browsers. The process is termed as cross browser testing and you can perform it over 2000 real browsers in real-time with LambdaTest, an online cross browser testing tool. You can even execute Selenium automation testing using our online Selenium Grid.

Benefits of Using CSS Frameworks

Code Maintenance: CSS Frameworks helps in easing out the code maintenance. Code maintenance is required once the code is developed and maybe the website has also been published. We often make changes to the code and add or modify functionalities of certain elements or complete the website. We need to maintain the code in such cases. Maintaining is a process of not affecting the parts of the website that are required to be constants. Since frameworks reduce the code and bring about fixed notations into the code, it is always easy to maintain the code.

Consistency and Uniformity: It is fairly obvious that when you have something predefined with some rules and functions of its own, you apply those things everywhere around the globe. The same thing happens when you use a framework in CSS. A framework has predefined functions to use its functionalities. If you want to use a particular feature of a framework, you will have to use the same functions no matter where you are sitting on the planet. This creates consistency in the code. A code is consistent and uniform throughout the project and the same project can be done by people sitting at different locations in the geographic. This consistency and uniformity help the developers understand the code and save a lot of time. This is one of the major reasons that the developers do not try to develop their own code or functionality but try to use the existing ones and modify them according to themselves. It is easier for everyone.

Quick Deliveries: This point is quite implicit, and you must have already guessed it in your mind. Using frameworks saves a lot of time in your project building and hence the delivery is really quick. The time is saved by the use of predefined functions and functionalities that you need. Let me give you a simple example to show you the same. You are a developer and you have been given a project to develop. A project where you have the functionality to write the text in a box (preferably with rounded corners) and the tooltip describing its meaning. Now, these things can be done within 5 minutes if you are using a CSS framework called Bootstrap. But you want to use your own code. So, you start developing. Leave aside the rounded corner buttons. You will definitely need to use a lot of your head and time while developing the tooltip functionality. This will unnecessarily increase your time to many folds. Also, remember that this is a complete project and not a single web page that you can get away with an excuse. Your project will contain many such functionalities which are just a one-line job if you use a framework. On the other side, your client will not have any effect and does not care what you use. Whether you use a framework, or you go for your own coding, a tooltip is a tooltip and that is what matters to the client. So, it is better to use a framework to save time and deliver quick.

Vast Communities: CSS Frameworks over CSS Grid, takes a huge advantage from its vast communities. These communities are set up because of the vast number of users of the framework and the fact that frameworks have been in the business for a long time now. As the number of users grows, the problems faced by the people also increase. These people reach out to other people on the internet who maybe have solved that problem already or have reached out to other people in the past and just know the solution. This chain goes on and on. This process has increased the number of users who are using a framework. It is quite obvious that if I give you a choice to choose between something of which huge support is available and something whose mediocre support is available; you will be inclined towards the huge support one. This support helps you break any hurdle you are facing and experiment with something of your own. You will have a huge number of people who are knowledgeable and ready to support.

Frameworks are not new: Frameworks are not new. They have existed since the time’s developers have come across this problem of repeating some complex things again and again. They developed frameworks that can be used by many people and any person around the globe. CSS Grid is not so old. It came across long after the frameworks when people started using grids way too much or should I say the need for grids arose way too much. The age of both of these concepts matter. Since frameworks started before grids, the number of projects that have used frameworks are more. Even for building grids. A good number of these projects have been finished but many projects continue long after they are delivered or published. This is because there is always a scope for modification or advancement. You might start adding new functionality to your websites or modify the older one to a beautiful look. If your project has been a hit, you will surely be stuck with it. These projects used frameworks and if a new person is working on it, he will get used to the frameworks. Maybe he uses the same in the next projects on which he will work on. This increases the usage of frameworks and everything gets connected. More the projects on frameworks, more people working on it, vaster the community, better the framework is.

Documentations: CSS Frameworks that have been already developed contain documentations that are helpful in learning how to use the framework effectively. This process is underrated but is very important as it takes a lot of time in developing the documentation. Consider you are not using the frameworks but are more interested in developing your own. One the framework is done; you need documentation too for teaching everybody how does the framework work. If you are going to upload your framework on the internet as an open-source or for the usage of other people then you need some platform to tell them how does that framework work. This is where documentation comes in handy which are often taken for granted when we are learning a new framework. As soon as we find a new framework, we will immediately navigate to the documentation to learn about it. This is a basic step but when it comes to our own documentation, we understand the importance of it. Moreover, these documentations need to be updated as your framework updates. Creating documentation might seem some pain in the beginning but is of a lot of help and makes your work easier in the long run. So, overall, having documentation actually glorifies the framework and its usage.

Drawbacks of CSS Frameworks

Makes you work in its way: Framework will restrict the way you code and the way you work. A framework as discussed is built for everyone and keeping in mind every developer out there. This restricts the way you should have worked or could have worked. Now, you need to work the way the framework wants you to work. This includes the designing part. You cannot design something that you were thinking in your mind. You need to use the framework classes which already have built that part. This can be a button, a simple layout or anything that you want. Arguably, yes you can change the thing by coding it on top of the framework but, what is the point of using the framework when you have to use so much on top of it. This gives rise to uniform websites that we will discuss as the next con.

Uniform Website: Using a framework restricts the way you needed to design the small elements of your design. Using the classes of the framework will give you the same structure more or less of every element. Since every big element is the combination of many small elements, the big elements become the same structure. This makes two websites using the same framework as a uniform. Not entirely but you can easily tell by looking at the structures. Uniform websites are always a bad thing for a website developer. Until and unless you have a website where the traffic you are getting is mandatory, like some college admission website or a government website, you need to have a different and appealing structure. The first impression on a user is always the way you have structured your website and how it is displayed. It is quite common that two websites on a particular topic like News or Digital Products will look similar if they have used the same framework.

Forces you to learn a new framework: In the above sections I mentioned that there are many frameworks available in the market today which work on CSS. I have listed a few at the starting of this post. Now it is obvious that every framework is different in its own way. Similar to the different browsers that we have in the market. Since there are so many frameworks, it is obvious that you must be having your own favorite framework and have been working on it for some time. This creates problems when your client wants you to work on a different framework. This means he wants his project to be developed using another framework of which you have no idea about. Now you have to learn an entirely new framework just for one project and maybe you will never use that framework again. This is a loss of time for a developer but there is no option.

When Should You Use CSS Frameworks?

If you are a beginner in front end web development and haven’t yet mastered CSS then using a CSS framework is the right fit for you. Frameworks like Bootstrap are super easy to master and can create complete web page layouts within seconds without the need of writing any CSS code. Offering unprecedented ease of use, lightning-fast deployment, close to 100% cross browser support, standardization of the codebase and easy learning curve makes CSS frameworks an attractive choice for you. If your aim to build standard cross browser compatible layouts at a lightning fast-pace rather than complex cutting edge layouts, you should pick CSS frameworks over the CSS grid.

Moreover, CSS frameworks like Materialize or Bootstrap are much more than Grid systems, In fact, grids are just a tiny feature of a CSS framework. If you want to build different UI components like navbar, carousel, sliders, cards, accordions, tabs, pop-ups, modals, buttons, etc at lightning pace with a minimum CSS styling then you should be using CSS frameworks.

Now, that we have a good understanding of what a CSS Framework is! It is time to dwell on a CSS Grid layout.

What Is CSS Grid Layout?

CSS Grid is a layout technique use grid on your web page. It is a technique that is only described in CSS and not in HTML. So, to adhere to the needs of web developers, CSS grids provide the ease of developing complex and twisted responsive web design. If you are a web developer or web tester then you already know the relevance of a responsive website. Before you start off your next web project, make sure to avoid these top mistakes for responsive web design.

A simple CSS Grid example looks like below:

css form

Src: https://gridbyexample.com/examples/example13/

The above image shows different grids for different elements of a web page like Header, Sidebar, etc.

As you can notice, CSS Grid helps in the alignment of the elements according to the web developer. Choosing CSS Grid vs CSS Frameworks can allow you to deliver a complex web application with a lot of tables, in a very short time.

While there is no way that CSS Grid can match up with the versatility of CSS Frameworks, there are some times when a developer has to think about the two for one particular project or certain parts of the project. CSS Grid has evolved better than before expanding its functionalities. Considering you have to build a layout that is visually appealing, it is very easy if you go for CSS Grid. Using CSS Grid layout, it minimizes the efforts and layout complexities. So, if you need to change the structure anytime afterward, the other structures won’t be affected to a greater extent.

For example, let’s say you have two grids side by side and an image after the grids in the same plane. Now, in the future, if you want to add another grid in the same plane, CSS Grid will divide the required space equally without affecting the coordinates of the image.

Grids are very adaptable to the space assigned to them. It helps the elements never overlap or create certain layout problems.

Advantages Of CSS Grid Layout

Building complex 2D Grid Systems: Use of CSS Grid vs CSS framework is ideal in cases where you need to build complex 2-dimensional layouts which popular frameworks like bootstrap cannot offer. Building complex layouts like – Mosaic Photo Gallery or Masonry Layouts is not possible to build without using the CSS grid. The majority of CSS frameworks offer basic 12 column responsive grids that have a limited application unfit for modern cutting edge design.

Reduced Code Size: Another major advantage of using the CSS grid over CSS framework is the reduced code size. With CSS Grid you can build any form of grid layout system imaginable only by relying on Native CSS style rules. On the other hand, for realizing Grid layouts using CSS frameworks, the entire framework/library CSS file has to be linked to your project. This is an unnecessary bloatware that is going to add to your project size and reducing the load speed of your website. So, when a user visits your website, a complete list of framework/library files are fetched from the server along with other resources before the webpage loads. This will drastically increase the load time of your website and hurt in SEO rankings on SERP and higher bounce rate. CSS Grids, unlike the framework, does not require any external stylesheet to work. This helps in the faster loading of your website and even in the slower connection, you do not need to worry.

Layout is not affected: A web page consists of many elements. These small elements combine together to form a layout of the web page. A layout is what you see and how you see. For example, I have placed two images side by side and a moving news column beside that. Now there are three elements here and they come under the layout. Now, if I want to change the size of the first image, maybe the column of news will get moved to the next row. This will move the elements present in the next row and the whole layout is affected. This can happen anytime since changing the layout of elements is a very common thing in web development. CSS Grids helps in this. When we use CSS Grids, the change that we do after the development does not affect the layout of the website. Now, instead of images I have a CSS Grid and I change the size of the grid, later on, it will not affect the column news panel at all.

Faster development: Frameworks are huge and heavy but Grids are short and light. They are easy and quick to learn. A framework has a lot of things inside. A complete frame for your website. These things often are related to each other. A good framework user will use all of this to develop something unique because frameworks are often blamed for their monotonic layouts. This will take time and this time pushes the time limits for your projects if any. This is not the case with grids. Grids are very light and contain very few concepts as compared to the frameworks. You can easily get over the concepts in the grid and start development. There are no complexities in developing grids. You do not need to have different elements linked to each other. Grids do not give monotonic layouts. It completely depends upon the developer. Hence, the grid development is faster than the frameworks.

A drawback of CSS Grid Layout

Development: CSS Grids is yet to be developed in a way frameworks are developed. This is because grids are fairly new and many projects had started before grids came into the picture. This means if you are working on that project (in a company or open-source), you are bound to be inclined towards the frameworks. If you know something well enough, you will definitely try to implement that thing. Starting to use CSS Grids above Frameworks without knowing about it completely is rare. But again, grids are gaining popularity among the new projects. It has been some time since the grid is in the market and is used exhaustively. It is still the start for grids if I compare to the grandeur of frameworks but soon it will be a more focussed topic for the development.

As I said, CSS Grid and CSS Framework are two very important aspects of CSS. While some are sure that they will use CSS Framework, some are sure about CSS Grids. There are also people who decide according to the need about what they will be proceeding towards. Since we saw some benefits of grids, let’s see how beneficial is CSS frameworks.

Cross Browser Compatibility Of CSS Grid

The largest hurdle faced by CSS Grid faced on the path to wider adoption by the web developer community was its poor cross browser compatibility and support. A couple of years back until 2017, CSS Grid was only supported by Google Chrome and Firefox while Internet Explorer, Microsoft Edge, Opera, and even Safari did not provide browser support for the CSS grid. Using the CSS grid in production-ready code would mean either serving a massive user base still using legacy browsers messy and broken webpages or wasting hours to somehow code feasible float/flexbox fallbacks. This is why the majority of developers were stuck with using either Float or Flexbox based Grid layouts or relied on CSS frameworks like Bootstrap, Materialize or Bulma to create 12 column grid layouts. This is where CSS frameworks held a key advantage over CSS Grid and continued their dominance.

However, since 2017, CSS Grid has witnessed a massive improvement in browser support. This has completely eroded the key advantage CSS frameworks enjoyed before. As of November 2019, the CSS grid is supported by 93.85% browsers (Can I Use stats). Previously unsupported browsers like IE (v10-11), Edge (v16 ), Opera(v44 ) and Safari(v10.1 ) now support the CSS grid including mobile browsers for both android and iOS.

css grid layout

When Should You Use CSS Grid?

One of the biggest arguments against the use of CSS frameworks like Bootstrap, Materialize or Bulma is excessive Code Bloating. Tons of needless CSS styling rules that will never be used will weigh down your project. If you want to keep your website compact in size to boost load speed and performance, CSS Grid is the better choice. Another reason to pick CSS grid over CSS framework is that with frameworks like bootstrap, you’ll be stuck with a primitive 12 column grid system. Achieving a 5 or 7 or 9 column layout would be very difficult. This problem is completely eliminated by the CSS grid. If your project requires a highly custom layout that cannot be achieved by a basic 12 col grid, the CSS grid is the right fit for your needs. The third argument in favor of the CSS grid is that it offers you unmatched flexibility to rearrange sections/areas. With CSS framework Grid systems you can only achieve basic responsive changes in layout according to screen sizes. But CSS Grid offers much more powerful flexibility to complete change layout structure in both horizontal and vertical directions. For eg – moving your vertical sidebar menu from side to top placed horizontally. The final reason because of which you might want to pick CSS grid over CSS frameworks is getting respite from ugly HTML markup with ever-growing Class names and div tags that make your HTML code messy and difficult to read. With the CSS grid your HTML markup will remain untouched.

Future of CSS Grid vs CSS Frameworks

This question pops up in the minds of many developers who are used to using the frameworks and grids for their use.

CSS Grids have continued to gain popularity ever since they were made cross browser compatible. Grids are also underway major developments and have introduced a CSS Subgrid. This will provide you to develop a website as you want on a more granular level than your normal CSS Grid Layout, a better and lighter layout with improved CSS design. However, the cross browser compatibility for CSS Subgrid is not looking so well as of now.

css grid of layout

However, if the CSS Grid Layout was accepted by various browsers, it is only natural to believe that CSS Subgrid won’t be too far long. Rigorous users of CSS Grid layout are hoping for CSS Subgrid to be cross browser compatible soon.

CSS Frameworks as of now are being adopted by many huge firms. The reason is its popularity. CSS Frameworks are very popular and are used today by the majority of the developers because of saving time and energy. However, the future of CSS frameworks is looking a bit grim due to the introduction of CSS Subgrids. However, as of now, web developers are working on frameworks that will be much lighter in weight and will have a possibility of changing the layout of the website according to the usage.

Rigorous users of CSS frameworks believe that CSS Grid should dissolve to be a part of CSS Frameworks. Whereas many agree to it, the challenge is that the framework’s weight will increase much more which we want to decrease. But the future can only be seen in the future and we will see whether these two roads will merge or diverge in the coming years. And whatever the scenario would be, I will be here to give you an update. Till then, Adios!

Written by Nikhil Tyagi

Experienced Frontend Developer and UX Designer who specializes in HTML5, CSS3 SASS/SCSS, Bootstrap 4, Materialize, Semantic UI frameworks, Javascript, Jquery, Ajax, React JS and APIs.

Everyone uses CSS frameworks

October 28, 2019 • Everyone, Frameworks

Every front-end developer uses CSS frameworks, even those saying they don’t.

Anytime the “what’s your favorite CSS framework” question pops up, you read the same comments: a bunch of developers expressing their love for framework X or Y, and others stating they don’t use frameworks.

Some of the reasons why some developers say they don’t use CSS frameworks:

Frameworks are opinionated.
Why would I need a framework when I can write clean CSS myself?
Frameworks are bloated with stuff I don’t need.

But what is a framework, exactly?

A framework is a supporting structure around which something can be built.

A framework doesn’t need to be opinionated. Its CSS can be as clean as yours (or it could literally be yours). It can be super slim, to the point where it includes only a bunch of reusable rules.

If you do one of the following, you’re using a framework even if you say you don’t:

You have a bunch of utility classes that you copy and paste from project to project.
You have a set of basic rules (e.g., for typography and spacing) that you copy into new projects, and then tweak to accommodate different needs.
You have a boilerplate for the style of buttons and forms that is easy to customize.
In general, in any case where you reuse something across different projects.

There’s only one case when you can say you don’t use a CSS framework, and it’s the truth: if you start a project with your CSS files completely blank.

But seriously, why would you do that? ?

I know I’m being pedantic. “When I say I don’t use a CSS framework, I’m referring to Bootstrap, not 20 lines of code!”, I hear you scream. However, I think there’s a misleading message that is delivered to young developers: “Frameworks are bad. If you were a good developer, you’d write clean CSS from scratch”. And yet millions of developers download Bootstrap every month. Are they all making a mistake? Not at all.

You could use a super slim framework or create one yourself, and it would be fine. You could use a heavier framework or create one yourself, and it would be fine.

Starting from (literally) scratch every time does not prove you’re a good developer.

Let me walk you through the main problems a framework helps you solve and why we all need one.

When Claudia and I started working on the CodyHouse Components project (a library of HTML, CSS, JS web components), we soon realized how important it is to have global styles and abstract rules.

A global style is a rule that, when modified, affects all the components it crosses (e.g., a buttons.scss file where you store the style of your buttons).

A CSS abstraction is a rule that gives the same result regardless of the element it is applied to (e.g., utility classes).

Global styles make your project customizable. For example, if you create a reusable typography.scss file where you define the type scale, you can 1) edit the type scale and affect all the components of your current project or 2) set a custom type scale for your next project.

Type scale as set in the CodyHouse Framework

CSS abstractions make it easier to create component variations without the headaches caused by naming things. For example, imagine you create a new component. If you want to create two class modifiers where the text is aligned in the center or right, you end up doing the following:

Then you create another component and have the same ‘issue’. Once again, you create two new class modifiers:

An alternative approach would be creating 3 utility classes (abstractions):

Now you can have infinite components and apply the same utility classes to align text.

I’m not suggesting you should create utility classes for everything (even though some frameworks do so, and developers love them). Find your own balance, create the abstractions you need.

If you come up with a pattern that works, why wouldn’t you extend it to new projects (and include it in your framework)? For example, you start working on accessibility and soon realize how handy it is the .sr-only utility class:

Is there any reason why you shouldn’t use it in all your projects? Nope.

Opening up an old CSS project is a pain; we all know that. However, it doesn’t need to be THAT painful. Using the same framework across multiple projects means working with patterns you’re already familiar with. If you use the same mixins, global settings, grid rules, and utility classes, you’ll need less time figuring out how to do stuff.

For example, let’s imagine you have created a scale of spacing values:

Spacing scale as set in the CodyHouse Framework

You know you can go ahead and modify a component using one of the scale values:

The spacing values may vary in different projects, but the way you apply them is the same. You go ahead and set padding: var(--space-md). If it’s too small/big, you can pick another value (or edit the scale).

The alternative approach would be:

First, figure out how spacing rules were set when the project was initiated.
Then, apply the spacing rules.

That extra step makes all the difference in the world. It’s where the frustration lies: figuring out things when you, or someone else you work with, already went through that process before.

Frameworks evolve and get updated (e.g., when you learn new patterns and replace old ones). There will be cases when you still need to remember how/why some rules were set in the first place. It sucks, but working with reusable patterns (framework) means reducing the number of times this happens.

One more advantage of creating your own framework is learning to identify reusable patterns. You find that piece of your CSS puzzle that could work across multiple projects, and decide to store it in a safe place (your framework).

Or, you can learn from frameworks created by other developers. Question why that rule was abstracted. If you can’t come up with an answer, google it; or ask the author.

The process of questioning what you do and discovering the mechanics behind a decision is what makes you learn. Not the assumption that you have to come up with all the solutions yourself.

A CSS framework is a tool. It’s not good or bad, and it doesn’t define you as a developer. When you find a pattern that works, save it. If you find a framework that ticks all your boxes, use it. As long as you learn in the process, nothing bad comes from using it. Quite the opposite.

If you’re looking for a lightweight front-end framework for building accessible, bespoke interfaces, check out CodyHouse!

Toucaan-Rethinking CSS Frameworks

October 16, 2019 • Frameworks, Toucaan-Rethinking

[Last updated: 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.

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.

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:

Major web devices.

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.

Major web devices.

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.

Major web devices.

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.

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.

Major web devices.

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!

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.

P.S.: It is likely that some of you viewed this article on your desktop or mobile. If you did that, I recommend you bookmarking us for the iPad next time! 🙂

UX Frameworks – Make sense of mess and get that spark, faster

October 8, 2019 • Frameworks, Sense

Frameworks are repeatable mental models, methodologies, and activities that you can use to synthesize qualitative research, identify emerging insights and opportunities to generate ideas. Use these UX Frameworks to re-frame how you solve problems.