CSS - Layout

Instead of attaching tooltips directly to document.body, attach them to a predefined div in document.body.

BAD

GOOD

Introduction

Tooltips in our app were taking >80ms. And during this time, the main thread was blocked, you couldn’t interact with anything.

Other components like modal, popover, dropdown had similar performance issues. In some cases, a modal took more than 1 second to appear while making the UI unresponsive.

Read on in the source link for details.

Visually-hidden styles are used to hide content from most users, while keeping it accessible to assistive technology users.

It works because the content is technically visible and displayed — it appears in the accessibility tree and the render tree, both of which are used by assistive technologies — it’s just that the rendered size is zero.

Our industry has largely settled on a standard CSS pattern for this, refined over years of testing and iteration, by many people. This pattern:

[…]

This article is not about when or why you would use visually-hidden content. There’s a number of excellent articles that discuss these questions in detail, notably Scott O’Hara’s Inclusively Hidden. But most of them don’t go into much detail about the specific CSS involved — why do we use this particular pattern, with these specific properties? So today I’m going to dissect it, looking at each of the properties in turn, why it’s there, and why it isn’t something else.

[T]he problem highlighted by the CSS is Awesome meme […] is an issue of overflow. You have made a fixed width container and are trying to put content into that container which is too big, what do you want CSS to do here?

CSS by default will do what you see in the meme because to do anything else would cause data loss, which [in] CSS terms means that some of your content vanishes.

We try and avoid data loss because if something on your page vanishes at certain screen sizes – because of overlap, or it going off the side of the screen, you may be unaware of it. A quick eyeballing of the page may not cause something missing to jump out at you. You will tend to spot the messy overflow though.

A good example of this design pattern can be seen in the Box Alignment specification, with the safe and unsafe alignment keywords. Safe alignment, means that your chosen alignment method won’t be used if it causes data loss, unsafe means that data loss may happen.

[…]

Better ways to stop content just “honking out of the box”

The author of the meme wondered why the box didn’t grow to fit the content. However if you give something a fixed size in CSS, it will respect that size. What the author really wanted was to make the box min-content sized. With a box that has a width of min-content the box will grow as big as it needs to be to contain the content, with all soft-wrapping opportunities taken, but no bigger.

If instead, you want to make the box not wrap at all, then give it a width of max-content. The text will then display all as one line and take no soft-wrapping opportunities.

Perhaps you need to have the box that fixed width, but don’t mind if it grows taller. In that case use overflow-wrap: break-word.

Take a look at [this CodePen] for all your awesome possibilities.

Layout is where the browser figures out the geometric information for elements: their size and location in the page. Each element will have explicit or implicit sizing information based on the CSS that was used, the contents of the element, or a parent element. The process is called Layout in Chrome, Opera, Safari, and Internet Explorer. In Firefox it’s called Reflow, but effectively the process is the same.

Similarly to style calculations, the immediate concerns for layout cost are:

1. The number of elements that require layout.
2. The complexity of those layouts.

TL;DR

• Layout is normally scoped to the whole document.
• The number of DOM elements will affect performance; you should avoid triggering layout wherever possible.
• Assess layout model performance; new Flexbox is typically faster than older Flexbox or float-based layout models.
• Avoid forced synchronous layouts and layout thrashing; read style values then make style changes.

See the source link for details and solutions.

All of the below properties or methods, when requested/called in JavaScript, will trigger the browser to synchronously calculate the style and layout*. This is also called reflow or layout thrashing, and is common performance bottleneck.

Generally, all APIs that synchronously provide layout metrics will trigger forced reflow / layout. Read on for additional cases and details.

Let me show you a way I recently discovered to center a bunch of elements around what I call the pivot. I promise you that funky HTML is out of the question and you won’t need to know any bleeding-edge CSS to get the job done.

[…]

[H]ere’s a sample of the HTML that drives this puzzle:

Here’s a generalized version of the [styles]. As you can see, it’s just 15 lines of simple CSS:

Here are the CSS ingredients we used for a media-query-less card component:

• The clamp() function helps resolve a “preferred” vs. “minimum” vs. “maximum” value.
• The flex-basis property with a negative value decides when the layout breaks into multiple lines.
• The flex-grow property is used as a unit value for proportional growth.
• The vw unit helps with responsive typography.
• The  object-fit property provides finer responsiveness for the card image, as it allows us to alter the dimensions of the image without distorting it.