Introduction
The pixel has been the unquestioned ruler of web design over the decades. It was the smallest measurement unit of atoms, out of which whole digital Empires were created. Designers would torture themselves over whether the padding should be 10px or 15px and developers would carefully convert fixed grids out of the static mockups into coding. However the digital world is different. We do not develop to one screen size and a set resolution. We are creating on an infinity canvas of 4-inch smartphone screens to the 85-inch 8K television screens.
The fixed pixel is turning into a liability in this new reality, and not an asset. Introduce such concept as pxless design.
This design and development philosophy is called pxless and involves abandoning fixed pixel values in favor of relative ones such as percentages, viewport units, rems and ems. It is the transition to fluidity, scalability and the real responsiveness. Going pxless is not only a technical choice, but it is also a strategic one because it ensures the creation of accessible, future-proof websites that can be breathtakingly impressive on any device, irrespective of the screens density and size.
We are going to in the deep dive discuss the weaknesses of the pixel, how a pixeless workflow works, and the ways that you can begin applying this methodology today to make layouts that are fluid, strong, and easy to use.
The Tyranny of the Pixel
We should know why the pixel is not perfect in our contemporary times to appreciate the worth of the pxless approach.
Screens were relatively homogenous when the web was young. A pixel of one monitor was approximately the size of a pixel of the other. Pixels-based designing was similar to print based designing, you had a fixed canvas and you determined every part of the design. This illusion was, however, broken with the introduction of high-density displays called Retina. The unit size of a pixel is no longer a physical hardware pixel, but an abstract unit that may differ drastically in the physical dimensions by device.
This poses two significant issues to layouts done on pixels:
Rigidity: This layout is pixel based and is fragile. Assuming that you put a container that is 1200px wide, it is okay on a desktop monitor. However at a lower pixel width of 768px the tablet container disrupts the design, leading to horizontal scrolling (or fragmented truncation). The former method was media queries- writing a particular piece of code that would adjust pixel values at particular breakpoints. This however results in breakpoint soup, where developers need to have hundreds of lines of code to resize widths.
Accessibility Failures: This is, perhaps, the most important failure of pixel-based sizing, which is its effect on accessibility. Pixels are the bane of a user in nearly all the major browsers. When a user alters the default font size of his/her browser to some 20px (rather than the usual 16px) to suit his/her vision, a pixel-based layout will tend to disregard this. The text may increase or decrease in size, whereas containers, padding and margins typically remain constant, so text will either spill or get illegible.
These problems are directly resolved in the philosophy of pxless, which considers the screen as a flowing medium instead of a piece of paper.
All a Pxless Layout looks Like.
And when you strip the pixel what then have you? On a pxless architecture, relative units are used, which are associated with each other as opposed to an arbitrary figure.
Rems (root em): A unit with reference to the root HTML font size. If the root size is 16px, 1rem is 16px. Assuming the user alters his root size to 32px, 1rem turns into 32px. Everything does not conflict.
Ems: This is a unit with regard to the font size of the current element. It is ideal with buttons, inputs and compound elements where you desire the padding and margins to expand with increase in the text size.
Viewpoints (vw/vh): The measurement against the size of the window. 1vw is an inch of the display. This makes it possible to have completely fluid typography and layouts that can literally be stretched and shrunk by the window.
Percentages: The conventional fluid grid tool. A 30% wide sidebar never surpasses 30% of the parent sidebar, whether it is a phone screen or a movie screen.
A pxless layout is a layout that hardly contains a specified width and height in pixels. It is not math, ratios, and relationships you see. What comes out is a site that is lively. Once you resize the browser window, the information does not simply jump to another permanent position, but it flows like water into the new form.
The Accessibility Reason: Why Pxless is a Moral Imperative.
Access to the web is no longer a choice but a necessity in terms of professional ethics and the law. The immediate increase in accessibility is one of the best arguments that go in favor of going pxless.
You are giving over control to the user when you use rem to set your margins, paddings and font sizes. An example of a user who has low vision, and has enlarged his browser default font size to 200 percent, requires that your site support the font size increase.
Consider a card component. In a pixel-based design:
- Font size: 16px
- Padding: 20px
- Width: 300px
When a viewer enlarges his or her browser text, it could increase to 32 aimed at the font. But the padding remains to 20px, and the width remains to 300px. The writing is either squeeched, or it is against the sides of the card, or worse still, it is pouring out of the container altogether.
In a pxless design:
- Font size: 1rem
- Padding: 1.25rem
- Width: 18.75rem
As the user increases the size of their browser text, the font increases correspondingly to the size of 32px. However, since the padding is specified in rems then it also scaled to the equivalent of 40px. The width is increased to suit the bigger text. The integrity of the design is maintained and the user is able to read the content without any difficulty. Being pxless, you are creating a safety net to your most vulnerable users.
The use of Pxless Typography.
the low hanging fruit of thepxless transition is typography. It is the simplest to begin with, and probably the most effective.
The common approach of a pxless system is to make the root font size a percentage (typically 100 percent, or 16px, which is the default of the user browser). Based on that, you come up with a rem scale of typography.
Nevertheless, the real strength of the pxless typography is projected together with the contemporary CSS functions such as clamp. Fluid typography was a challenge in the past. It involved complicated computations of viewport widths. You can now specify a fluid font size which goes between a minimum and a maximum font size.
For example:
font-size: clamp(1rem, 2.5vw, 2rem);
This code is the ultimate form of pxless thinking. It informs the browser: Increase the font size to at least 1rem. Make it grow with the viewport width (2.5vw). But see it not get above 2rem.
The system does not require numerous media queries to alter the headline sizes across screens. The text automatically enlarges on bigger screens and decreases on mobile, yet it does not overstep the choice of the user and follows the rem unit. Such fluidic scaling involves a far more smooth experience in reading on devices.
Fluid Spacing and Layouts
After you are good at the use of pxless typography, what you do next is to address the issue of spacing. The developers have traditionally defined margins and padding in fixed pixel values (e.g. margin-bottom: 30px). This leaves a fragmented experience on mobile devices with 30px possibly being a cavernous distance.
In a pixel free layout, the spacing is usually associated with the typography. This principle is called vertical rhythm and it is the idea that you should divide your base line-height by multiples of the spacing. Rems are used to space the text so that when the text is expanded or contracted the amount of white space that surrounds it is also expanded or contracted accordingly.
CSS Grid and Flexbox are extremely popular in the pxless method of layouts. These layout engines were made flexible. CSS GRID: CSS Grid allows the column tracks to be defined with the use of the fr unit (a fraction of available space). You are not telling me, “Make this column 200px wide. You are telling me, provide 1 fraction of the space to this column and 3 fractions to the main content.
Consider a two-column layout.
grid-template-columns: 1fr 3fr;
This is a pxless declaration. It may be a 400 wider screen or a 4000 wider screen, the sidebar will always occupy 1/4 of the screen and content will occupy 3/4 of the screen. You do not need to write media queries to change width: 300px to width: 100% in the cell phones. An option is to just resize the grid template when it is needed, or just allow the grid wrap to happen.
In addition, CSS Grid has the minmax() tool, which is an efficient tool of the pxless toolkit.
grid-template-Columns: repeat ( auto-fit, maxmin ( 300px, 1fr ) ).
This code instructs the browser to make as many columns as it can get within the browser without necessarily having them be less than 300px wide. When space is not sufficient to add a second column which is 300px, the items wrap. This generates a responsive grid that does not have any media query. It is the final manifestation of an inductive design -specifying rules instead of definite dimensions.
The Myth and Design Handoff – Pixel Perfect.
Another obstacle to a pxless workflow, which is one of the largest, is a cultural barrier. Pixels perfection is the major obsession of designers and clients. They consider a web site as a mathematical formula and all the elements have to be arranged to a specific pixel grid. This is the mentality of the print design and it is harmful to the web.
Splitting to a pxless workflow will necessitate a change of perspective on design handoff. Designers ought to consider proportions, ratios and limits as opposed to actual dimensions. The design specification should be in the form of the heading is 3rem and the padding is 2rem relative to the base size rather than providing a developer with a mockup that indicates that the issue is the heading is 48px and the padding is 60px.
This is starting to be supported by tools such as Figma and enables designers to design in relative units. Nevertheless, the discussion must change. We should sensitize the stakeholders that a Web site is not a photograph; it is a living organism. A Web site that appears a little bit different on a 13-inch MacBook than it does on a 15-inch Dell is not a bug, but rather a feature of the web. Through the adoption of the pxless, we are able to tell our clients that the fuzziness of relative units would in fact contribute to a more crisp and useful experience to the end-user.
Challenges of Going Pxless
Naturally, the transition does not occur without any difficulties. The most widespread frustration by developers who are new to the pxless approach is the so-called cascade effect of the em unit.
The em of a child element is relative to its parent, and therefore using nesting elements may cause compounding sizes.
When you have a list and a list and you set the items in the list to 1.2em then the first level will be 1.2 times the parent size. The second level (nested list) will be 1.2 times the first level, and this will give a text size of 1.44 times the original. The third level grows again.
Otherwise this may drive one mad. The answer is to love rem to global typography and spacing (so as not to compound) and em to really isolated parts (such as a button in which you wish the icon and the text to the same scale). The most important thing about successful implementation of pxlass is learning how to work between these units.
The other complication is the fixed size assets, like images. Images have natural pixel sizes. What do you do to put a 1920px image into a fluid one of indeterminate pixel size? CSS properties such as max-width: 100% and modern solutions such as the srcset attribute are the solution. They will automatically become fluid by making sure that images do not outgrow their containers.
The Future is Pxless
The relevance of the pxless philosophy in the future of the web will continue to increase. As foldable phones, circular screens (smartwatches), and pixel densities that are pushing the human eye are now gaining popularity, the notion of the standard pixel is becoming irrelevant.
More than that, even the introduction of Container Queries in CSS is pushing the boundaries even further. Container Queries enable the elements to preset themselves to the size of its parent container instead of the viewport size. It is the further transformation of the pxless design. It enables the elements to be indeed modular and self-enclosed and flexible on how they fit and the font sizes whenever they are placed on the page.
Think about a related posts widget. This widget is pxless and does not depend on the size of the screen. It takes an interest in the room it has been allocated. When it is in a broad sidebar it shows a horizontal grid. When it is within a tight mobile footer, then it presents a vertical stack. This flexibility cannot be achieved on a grid of fixed pixel sizes, but is the default of a container-query based, pxless system.
Conclusion
The web is a form of uncertainty. We do not know what device our users will be using, what they have as a screen resolution and what accessibility options they may have activated. It is doing a disservice to that user by relying on the pixel, which attempts to provide some assurance and yet, only provides rigidity.
Going pxless is the matter of living with that uncertainty. It is regarding the creation of systems that are resilient, flexible and empathetic. It liberates the developers of the maintenance nightmare of breakpoint soup and the user of broken layouts when s/he dares to zoom in.
To make the shift to a pxless workflow, one will have to change his/her mindset. It involves relocation of the painting by numbers to the designing systems. It involves the ability to think in ratios, proportions and relationships. But the payoff is immense. You have code that is easier to maintain, designs that are more robust and a user experience that is user friendly to all, irrespective of their access to the web.
Therefore, next time you are ready to open your CSS file and you have the intuition of typing width: 500px, do not do it. Question: Does this necessarily have to be mended? Or could it be fluid?” Take the leap. Go pxless. Your consumers, your staff and your next-generation self will appreciate you.