# The Every Layout Blog CSS layout problems, solved with an algorithmic approach This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Complex conditional width using flex-basis with clamp DevFeed: [Complex conditional width using flex-basis with clamp]() Original publisher: [Read original article]() Author: Heydon Pickering Published: 2022-08-25T00:00:00Z Content type: tutorial Language: en Sources: [The Every Layout Blog]() Topics: [CSS](), [modern web development](), [Web Development]() Tags: [code](), [css](), [details]() ### AI overview This tutorial explains how to create a responsive Sidebar layout with CSS flex-basis, min-inline-size, min(), and clamp(). It describes how the relationship between the sidebar and non-sidebar widths determines when the layout switches from two columns to a stacked arrangement, while preventing overflow on small screens. ### Source excerpt The primitive Sidebar layout is a kind of quantum layout whereby the sidebar only exists as a sidebar where there is available space. As the Sidebar document details, wrapping from a two-column to a one-column layout depends on the relationship between two things: A minimum percentage width for the non-sidebar element A preferred width for the sidebar element The breakpoint--if you want to call it that--is where (1) equals (2). When (1) becomes less than (2), the sidebar and non-sidebar stack vertically. The sidebar is no longer a sidebar. (2) is either a set flex-basis value or defaults to the (maximum) width of the sidebar's content (implicitly auto). Importantly, if the set value was a percentage, like (1), the breakpoint would never be breached and wrapping would not occur. Why? Because the sidebar would maintain its %-based share of the component in spaces of any size. A flex-basis value of, say, 20ch differs because it's a kind of quasi-fixed value. It will be exactly 20ch unless 20ch is either too small or too large. .sidebar { flex-basis: 20ch; /* ↓ when not a sidebar, let it use up all the space */ flex-grow: 1; } But what if you wanted the sidebar to be 33.333% wide where possible? You can make flex-basis 33.333% then add a min-inline-size: .sidebar { flex-basis: 33.333%; min-inline-size: min(20ch, 100%); /* ↓ when not a sidebar, let it use up all the space */ flex-grow: 1; } The important part is using the target min-inline-size inside the min() function with 100%--a technique borrowed from the Grid layout. Since 100% is really the maximum value for the context, we are effectively toggling min-inline-size on and off, conditionally. Which is the kind of thing people don't think CSS can do. The slightly mind bending thing here is that the "minimum" value of `20ch` once hit immediately becomes greater than the larger value of `33.333%` that it replaces This toggle ensures 20ch is only applied where that value is less than 100%. In other words, it stops stuff ov ## 2nd Edition: Please Mind The Gap DevFeed: [2nd Edition: Please Mind The Gap]() Original publisher: [Read original article]() Author: Heydon Pickering Published: 2021-06-29T00:00:00Z Content type: release Language: en Sources: [The Every Layout Blog]() Topics: [Web Development](), [modern web development]() Tags: [components](), [flexbox](), [margin](), [markup](), [properties](), [release]() ### AI overview Every Layout announces its second edition, which focuses on the CSS gap property and its Flexbox support in modern browsers. The article explains how gap can simplify responsive layout components compared with margin-based techniques, reducing intermediary markup and problems with custom properties and nesting. ### Source excerpt We at Every Layout (try to imagine we have some sort of corporate identity rather than being two blokes with a neat website and a script that generates epubs) are proud to announce the release of our second edition! And we are slashing the already low price of $69 down to just $40 to mark the occasion. Just make sure you use 2ND_COMING at checkout ASAP; we can't keep it at that price forever. What's new, then? This edition is all about the gap property, which is now supported with Flexbox in all modern browsers. Why is gap important? Smart layout primitives like the Cluster, Sidebar, and Switcher are all designed to automatically reconfigure themselves to suit different contexts--and without needing JavaScript or @media queries. When doing this, gutters (margins) between elements can be problematic unless handled carefully. A margin applied to one element to create a gap between it and an adjacent element becomes a misplaced margin when the element wraps: Until now, we have solved this by applying margin to child elements symmetrically (to all sides) and using negative margin to deal with the excess. There's nothing wrong with using negative margins per se; it's more a technique than a hack. But this approach does necessitate what we have come to call an intermediary wrapper...
Child 1
Child 2
What this does is insulate the negative margin from the flow of the document. Then we can apply a sensible margin to the outer component itself. In fact, it's more likely this margin would be applied by a parent Stack element, which injects margin between successive elements (Every Layout components are highly modular and composable). Not only does the negative margin technique represent additional markup, but things start to go awry when it comes to custom properties and nesting. Margins are applied to child elements and child elements become parent elements whe ## Dynamic CSS Components Without JavaScript DevFeed: [Dynamic CSS Components Without JavaScript]() Original publisher: [Read original article]() Author: Heydon Pickering Published: 2019-10-07T00:00:00Z Content type: tutorial Language: en Sources: [The Every Layout Blog]() Topics: [CSS](), [Web Development](), [ui](), [HTML](), [JavaScript]() Tags: [css](), [html](), [javascript](), [server-side-rendering](), [ui](), [web-interface]() ### AI overview The article compares web interface components with electronic components, explaining how props influence rendered HTML. It then proposes CSS components based on a shared styling module with configurable values, while noting that the described approach still relies partly on JavaScript and server-side rendering. ### Source excerpt What is a component? In electronics, it's a discrete device used to affect the behavior of the electricity in a circuit, or electrical system. Electronic components are modular, and are often used in combination to achieve specific values. For example, a number of resistor components of different values might be used in series to produce a desired resistance. Electronic components take an input, augment it internally, and return a different output. In this respect, the only real conceptual difference between electronic components and web interface components is that the former passes the signal along, and the latter passes it down. Props Whether you are using React, Vue, custom elements, or some other component-organized system, inputs tend to be passed to the component via props (properties). The property names/identifiers belong to the component; the values of the properties belong to a containing (ancestor) component and its current state. A UI component outputs (using a return statement in JavaScript) some UI, and the shape this UI takes is, at least partially, beholden to the values of the props originally passed. Like resitors augment the current, UI components augment the interface. Rendering On the web, the UI a component outputs consists of markup/HTML. The structure of that HTML will differ depending on how the current values of its props are interpolated. For example, if a hypothetical users prop consisted of an array of 726 users in its current state, the following render function would output an unordered list of 726 users. Array of 891; list of 891. const render = () => { return `
    ${prop.users.map(user => `
  • ${user.name}
    • `).join('')}
` } What's neat is that I have a single component, as one module definition, that can be instantiated under differing circumstances and produce different outcomes. For example, I might use the same component just to display logged in users. All that has to change is the input: the value of the users prop. ## Why you should buy your staff a copy of Every Layout DevFeed: [Why you should buy your staff a copy of Every Layout]() Original publisher: [Read original article]() Author: Andy Published: 2019-07-30T00:00:00Z Content type: opinion Language: en Sources: [The Every Layout Blog]() Topics: [CSS](), [Front end](), [Design system](), [Framework]() Tags: [css](), [design-system](), [framework](), [front-end]() ### AI overview This opinion article argues that employers should purchase Every Layout for staff training. It presents CSS knowledge and simpler, browser-oriented layouts as ways to reduce mistakes and technical debt, while describing the layouts as portable and interoperable across projects. ### Source excerpt Dear bosses, You have probably been sent this link by a staff member who would like you to buy them a copy of Every Layout. In this post, I'll outline some benefits that you, the boss, can enjoy if you invest in your staff's learning and training by purchasing a copy of Every Layout. When you understand CSS, you generally make fewer mistakes So many mistakes--especially with CSS--can be directly attributed to a lack of knowledge, but you only get that knowledge from learning and experience. We share our vast, combined experience in Every Layout to give people a head-start. CSS is hard, but what we do with Every Layout is demonstrate how keeping things as simple as possible can give your CSS the most power. We leverage the power of the browser and guide it, rather than micro-manage it, for a much more resilient front-end. This approach is completely valid for building a tiny blog, all the way up to a huge design system. We leverage the power of the browser and guide it, rather than micro-manage it We're convinced that our approach in Every Layout will reduce mistakes. In fact, we know it will, because that approach has served us both very well in our combined experience of over 20 years, working on huge projects and tiny projects alike. Good CSS knowledge will help to reduce technical debt CSS is great, but when you over-engineer and over-complicate it, it can get pretty hairy, pretty quickly. A common, knee-jerk response to this conundrum is to employ the use of a CSS-in-JS library or heavy-duty framework, but that is like taking out a Wonga loan to pay off your house. Technical debt is incredibly expensive, and with modern, all-encompassing web-tooling, the interest rates can be extortionate. In contrast to this, the content we created for Every Layout encourages you to write very powerful layouts, with a tiny, native footprint. These layouts are also portable and interoperable, which means that you can very likely use them across most of your team's projects. Using ## Multi-column manipulation DevFeed: [Multi-column manipulation]() Original publisher: [Read original article]() Author: Heydon Pickering Published: 2019-07-20T00:00:00Z Content type: tutorial Language: en Sources: [The Every Layout Blog]() Topics: [CSS](), [Web Development](), [modern web development]() Tags: [css](), [developer-tools](), [example](), [interaction](), [layout]() ### AI overview An exploration of CSS Multi-column Layout, focusing on its unusual horizontal or vertical overflow behavior and the interaction challenges of horizontal scrolling. It also demonstrates quantity-dependent columns that split long bullet lists into two columns when they contain at least five items. ### Source excerpt Despite predating both Grid and Flexbox, Multi-column Layout represents--at least to me--an even more radical departure from the way we normally do and think about CSS layout. Dividing just one element into a multi-column representation of its contents feels weird, heretical even. Setting a multi-column context means asking (flow) content to progress, by column, in a horizontal direction. This invokes one of two issues, depending on whether you set a height on the element. With no set height, there's no limit to the height of the columns. This will result in vertical overflow, and the necessity to scroll down and up the page to read each successive column. Many are likely to find this arduous. With a set height, columns are forced to spawn in the inline (horizontal) direction, creating horizontal overflow. Setting overflow: auto frames this correctly. .columns { height: 25vh; /* ↓ columns defined by width */ columns: 30ch; overflow: auto; } However, despite the increasing popularity of scrolling menus and other such patterns harnessing horizontal scrolling, it is still an unconventional interaction paradigm -- and unconventional patterns are liable to be misapprehended by users. There are ways to increase perceived affordance, of course--perhaps by adding some custom styling to the scrollbar (-webkit-scrollbar), or providing some overflow-dependent shadows. But this may not be enough. Quantity-dependent columns One thing I have been experimenting with is the application of multiple columns in response to content quantity. Let's say I have a bullet list, and let's assume each bullet point is likely to be relatively short; no more than a sentence. There's no benefit to dividing the list into columns when there are only a few points. But the overall height of the list is shortened (and the chance of the reader being able to see the whole list without scrolling is increased) when a long list is divided into two. In the following example, the list is split into two columns w ## Algorithmic Design DevFeed: [Algorithmic Design]() Original publisher: [Read original article]() Author: Heydon Pickering Published: 2019-06-14T00:00:00Z Content type: article Language: en Sources: [The Every Layout Blog]() Topics: [Design system](), [Algorithms](), [Web](), [Web Development](), [CSS](), [consistency]() Tags: [algorithm](), [browsers](), [css](), [design](), [design-system](), [documentation](), [flow](), [layout](), [systems](), [web]() ### AI overview This article explains algorithmic design as a way to make design systems more consistent and less dependent on human vigilance. It applies the idea to web layout, arguing that designers should work with CSS selectors, flow, wrapping behavior, and calculations instead of relying on fixed positions and dimensions. ### Source excerpt The term "system" has two meanings: A set of principles or procedures to be followed; a method A set of interconnecting parts, working together When someone says "design system", one or other of these meanings may come to mind. An effective design system is both these things together: an exemplification of how to proceed. Weak design systems tend to be either (1) or (2) alone; "do as I say" or "here's what was done". Unfortunately, it's quite possible to document something within a (nominal) design system without it being a product of systems thinking. Contradiction, duplication, and any number of errors are inevitable unless you take the whole system into account each time you make a contribution. No individual can do this reliably--especially where the extant "system" has already devolved into a morass of exceptions and caveats. Automating intent Systematic design is better than acting randomly, but it relies too much on the vigilance of its human contributors. An algorithmic approach to design is the antidote. Algorithms, like systems, constitute rules devised by humans. It's just that an algorithm's rules don't have to be carried out by a human. It's dutifully done on their behalf. This means fewer errors and greater consistency, without sacrificing control. Documentation is to a system what extrapolation is to an algorithm. Algorithms amplify design. So long as your algorithms are well-defined, they should be able to reason for themselves and handle different contexts and circumstances. Where the rules are ill-defined, you'll suffer a leaky or malfunctioning system. Like a poorly balanced guitar, it will demand continual tuning. Algorithmic design for the web The layout of web content is innately algorithmic, and the web is responsive due largely to the text wrapping algorithm: words automatically wrap according to the available space, ensuring no content is obscured. We make many of our biggest mistakes as visual designers for the web by insisting on hard codin ## Eschewing Shadow DOM DevFeed: [Eschewing Shadow DOM]() Original publisher: [Read original article]() Author: Heydon Pickering Published: 2019-06-14T00:00:00Z Content type: article Language: en Sources: [The Every Layout Blog]() Topics: [Web Components](), [CSS](), [modern web development](), [React](), [styled-components]() Tags: [css](), [custom](), [element](), [react](), [styled-components]() ### AI overview An examination of styling problems encountered with Shadow DOM, including inconsistent universal styles, limited inheritance, slot restrictions, and specificity issues. The author proposes an experimental alternative for web components that namespaces and embeds prop-derived instance styles in the document head. ### Source excerpt Regarding styling, Shadow DOM is really good at one thing: preventing per-component styles from leaking out and affecting other parts of the document. Unfortunately, Shadow DOM also has a very opinionated way of preventing styles being applied from the parent document. Here is a roundup of the quirks and associated issues I've encountered: Shadow DOM styling issues Universal styles Some universal styles (using the * selector) are applied, and others are not. The color property appears to pierce shadow boundaries, but I've had no luck with box-sizing. Having to set box-sizing: border-box for each component is redundant. Inheritance Document styles are inherited in Shadow DOM. But inheritance only gets you so far, especially since not all properties are inheritable by default anyway. I've tried hacking things together with the explicit inherit keyword, but that seems to have no effect. Using the following is no good, because it forces every node to inherit every property from the parent. If had display: flex applied, every one of the component's descendants would adopt it. * { all: inherit; /* yikes */ } Slot restrictions For performance reasons, the ::slotted() selector, which allows you to style the Light DOM content of your component from within your Shadow DOM, only lets you affect child elements and not descendants at depth. This is a bit restrictive. Worse, you cannot seem to use sibling combinators like + or ~. None of the following works: ::slotted(*) + * /* Nope */ ::slotted(* + *) /* Nope */ ::slotted(*) + ::slotted(*) /* Nope */ Specificity In making layout components, I like to take a progressive approach: style the component and its Light DOM nodes in my document stylesheet, then enhance with instance-specific styles via props (attributes) in Shadow DOM. For a component instance that looks like this... ...I would apply the itemWidth value in the Shadow DOM using interpolation: `