As we’ve been hearing constantly for the last couple of years, AI will soon replace every creative job and we’ll all have to retrain as mechanics or tree surgeons or something. This prediction, apart from being unrealistic, also sounds totally dystopian.
Welcome to the August toolbox. We’ve found goodies for designers, developers, project managers, domain admins, and those of you who wear all of these hats.
We have been talking about CSS3 for a long time. Call me a fossil, but I still remember the new border-radius property feeling like the most incredible CSS3 feature. We have moved on since we got border-radius and a slew of new features dropped in a single CSS3 release back in 2009.
CSS, too, has moved on as a language, and yet “CSS3” is still in our lexicon as the last “official” semantically-versioned release of the CSS language.
It’s not as though we haven’t gotten any new and exciting CSS features between 2009 and 2024; it’s more that the process of developing, shipping, and implementing new CSS features is a guessing game of sorts.
We see CSS Working Group (CSSWG) discussions happening in the open. We have the draft specifications and an archive of versions at our disposal. The resources are there! But the develop-ship-implement flow remains elusive and leaves many of us developers wondering: When is the next CSS release, and what’s in it?
This is a challenging balancing act. We have spec authors, code authors, and user agents working both interdependently and independently and the communication gaps are numerous and wide. The result? New features take longer to be implemented, leading to developers taking longer to adopt them. We might even consider CSS3 to be the last great big “marketing” push for CSS as a language.
That’s what the CSS-Next community is grappling with at this very moment. If you haven’t heard of the group, you’re not alone, but either way, it’s high time we shed light on it and the ideas coming from it. As someone participating in the group, I thought I would share the conversations we’re having and how we’re approaching the way CSS releases are communicated.
Meet The CSS-Next Community
Before we formally “meet” the CSS-Next group, it’s worth knowing that it is still officially referred to as the CSS4 Community Group as far as the W3C is concerned.
And that might be the very first thing you ought to know about CSS-Next: it is part of the W3C and consists of CSSWG members, developers, designers, user agents, and, really, anyone passionate about the web and who wants to participate in the discussion. W3C groups like CSS-Next are open to everyone to bring our disparate groups together, opening opportunities to shape tomorrow’s vision of the web.
CSS-Next, in particular, is where people gather to discuss the possibility of raising awareness of CSS evolutions during the last decade. At its core, the group is discussing approaches for bundling CSS features that have shipped since CSS3 was released in 2009 and how to name the bundle (or bundles, perhaps) so we have a way of referring to this particular “era” of CSS and pushing those features forward.
Why We Need A Group Like CSS-Next
Let’s go back a few years. More specifically, let’s return to the year 2020.
It all started when Safari Evangelist Jen Simmons posted an open issue in the CSSWG’s GitHub repo for CSS draft specifications requesting a definition for a “CSS4” release.
This might be one of the biggest responses — if not the biggest response — to a CSSWG issue based solely on emoji reactions.
The idea of defining CSS4 had some back-ups by Chris Coyier, Nicole Sullivan, and PPK. The idea is to push technologies forward and help educators and site owners, even if it’s just for the sake of marketing.
But why is this important? Why should we care about another level or “CSS Saga”? To get to that point, we might need to talk about CSS3 and what exactly it defines.
What Exactly Is “CSS3”?
The CSS3 grouping of features included level-3 specs for features from typography to selectors and backgrounds. From this point on, each CSS spec has been numbered individually.
However, CSS3 is still the most common term developers use to define the capabilities of modern CSS. We see this across the web, from the way educational institutions teach CSS to the job requirements on resumes.
The term CSS3 loses meaning year-over-year. You can see the dilution everywhere. The earliest CSS3 drafts were published in June 1999 — before many of my colleagues were even born — and yet CSS is one of the fastest-growing languages in the current webscape.
What About The CSS3 Logo?
When we look at job postings, we run into vacancies asking for knowledge of CSS3, which is over 10 years old. Without an updated level, we’re just asking if you’ve written CSS since the border-radius property came out. Furthermore, when we want to learn CSS, a CSS3 logo next to educational materials no longer signals current material. It kind of feels like time has stood still.
Here’s an example job posting that illustrates the issue:
But that’s not all. If you do a Google search on “Learn CSS” and check the images, you might be surprised how many CSS3 logos you can spot:
About 50% of the images show the CSS3 badge. To me, this clearly signals:
CSS3 had still has a huge impact on the ecosystem. The same logo is trying to say it teaches Flexbox all the way to color-mix() — a spread of hundreds of CSS features.
What Exactly Does “Modern CSS” Mean?
CSS3 and HTML5 were big improvements to those respective languages — we’ve come a long way since then. We have features that people didn’t even think were possible back in 2012 (when we officially spoke of CSS3 as a level).
For example, there was a time when people thought that containers didn’t know anything and it never be possible to style an element based on the width of its parent. But now, of course, we have CSS Container Queries, and all of this is possible today. The things that are possible with CSS changed over time, as so beautifully told by Miriam Suzanne at CSS Day 2023.
We do not want to ignore the success of CSS3 and say it is wrong; in fact, we believe it’s time to repeat the tremendous success of CSS3.
Imagine yourself 10 years from now reading a “modern” CSS feature that was introduced as many as 10 years ago. It wouldn’t add up, right? Modern is not a future-proof name, something that Geoff Graham opined when asking the correct question, “What exactly is ‘Modern CSS’?”
“Naming is always hard, yet it’s just something we have to do in CSS to properly select things. I think it’s time we start naming [CSS releases] like this, too. It’s only a matter of time before “modern” isn’t “modern” anymore.”
— Geoff Graham
This is exactly where the CSS-Next community group comes in.
Let’s Talk About “CSS Eras”
The CSS-Next community group aims to align and modernize the general understanding of CSS in the wider developer community by labeling feature sets that have shipped since the initial set of CSS3 features, helping developers upskill their understanding of CSS across the ecosystem.
The definition of what is “current” CSS changes with time. Sometimes, specs are incomplete or haven’t even been drafted. While Baseline looks at the current browser support of a feature in CSS, we want to take a look at the evolution of the language itself. The CSS levels should not care about which browser implemented it first.
It might be more nuanced than this in reality, but that’s pretty much the gist. We also don’t want it to become another “modern CSS” bucket. Indeed, referring to CSS3 as an “era” has helped compartmentalize how we can shift into CSS4, CSS5, and beyond. For example, labeling something as a “CSS4” feature provides a hint as far as when that feature was born. A feature that reaches “baseline” meanwhile merely indicates the status of that feature’s browser implementation, which is a separate concern.
Identifying features by era and implementation status are both indicators and provide meta information about a CSS feature but with different purposes.
It’s fair to wonder if a potential solution is to take a “snapshot” of the CSS feature set each year and use that as a mile marker for CSS feature releases. However, an annual picture of the language is less effective than defining a particular era in which specific features are introduced.
There were a handful of years when CSS was relatively quiet compared to the mad dash of the last few years. Imagine a year in which nothing, or maybe very few, CSS features are shipped, and the snapshot for that year is nearly identical to the previous year’s snapshot. Now imagine CSS explodes the following year with a deluge of new features that result in a massive delta between snapshots. It takes mental agility to compare complete snapshots of the entire language and find what’s new.
Goals And Non-Goals
I think I’ve effectively established that the term “CSS” alone isn’t clear or helpful enough to illustrate the evolution of the CSS, just as calling a certain feature “modern” degrades over time.
Grouping features in levels that represent different eras of releases — even from a marketing standpoint — offers a good deal of meaning and has a track record of success, as we’ve seen with CSS3.
All of this comes back to a set of goals that the CSS-Next group is rallying around:
What we do not want is to:
This doesn’t mean that everything in the last list is null and void. We could, for example, have CSS eras that list all the features specced in that period. And inside that list, there could be a baseline reference for the implementations of those features, making it easier to bring forward some ideas for the next Interop, which informs Baseline.
This leaves the CSS-Next group with a super-clear focus to:
A lot of thought and work has gone into the way CSS is described in eras. The initial idea was to pick up where CSS3 left off and jump straight into CSS4. But the number of features released between the two eras would be massive, even if we narrowed it down to just the features released since 2020, never mind 2009.
It makes sense, instead, to split the difference and call CSS4 a done deal as of, say, 2018 and a fundamental part of CSS in its current state as we begin with the next logical period: CSS5.
Here’s how the definitions are currently defined:
CSS3 (~2009-2012):
Level 3 CSS specs as defined by the CSSWG. (immutable)
CSS4 (~2013-2018):
Essential features that were not part of CSS3 but are already a fundamental part of CSS.
CSS5 (~2019-2024):
Newer features whose adoption is steadily growing.
CSS6 (~2025+):
Early-stage features that are planned for future CSS.
Uncle Sam CSS Wants You!
We released a request for comments last May for community input from developers like you. We’ve received a few comments that have been taken into account, but we need much more feedback to help inform our approach.
We want a big representative response from the community! But that takes awareness, and we need you to make that happen. Anything you can do to let your teams and colleagues that the CSS-Next group is a thing and that we’re trying to solve the way we talk about CSS features is greatly appreciated. We want to know what you and others think about the things we’re wrestling with, like whether or not the way we’re grouping eras above is a sound approach, where you think those lines should be drawn, and if you agree that we’re aiming for the right goals.
We also want you to participate. Anyone is welcome to join the CSS-Next group and we could certainly use help brainstorming ideas. There’s even an incubation group that conducts a biweekly hour-long session that takes place on Mondays at 8:00 a.m. Pacific Time (2:00 p.m. GMT).
On a completely personal note, I’d like to add that I joined the CSS-Next group purely out of interest but became much more actively involved once the mission became very clear to me. As a developer working in an agency, I see how fast CSS changes and have struggled, like many of you, to keep up.
A seasoned colleague of mine commented the other day that they wouldn’t even know how to approach vanilla CSS on a fresh website project. There is no shame in that! I know many of us feel the same way. So, why not bring it to marketing terms and figure out a better way to frame discussions about CSS features based on eras? You can help get us there!
And if you think I’m blameless when it comes to talking about CSS in generic “modern” terms, all it takes is a quick look at the headline of another Smashing article I authored… this year!
Let’s get going with CSS5 and spread the word! Let me hear your thoughts.
I have to thank Jeremy Keith and his wonderfully insightful article from late last year that introduced me to the concept of HTML Web Components. This was the “a-ha!” moment for me:
When you wrap some existing markup in a custom element and then apply some new behaviour with JavaScript, technically you’re not doing anything you couldn’t have done before with some DOM traversal and event handling. But it’s less fragile to do it with a web component. It’s portable. It obeys the single responsibility principle. It only does one thing but it does it well.
Until then, I’d been under the false assumption that all web components rely solely on the presence of JavaScript in conjunction with the rather scary-sounding Shadow DOM. While it is indeed possible to author web components this way, there is yet another way. A better way, perhaps? Especially if you, like me, advocate for progressive enhancement. HTML Web Components are, after all, just HTML.
While it’s outside the exact scope of what we’re discussing here, Any Bell has a recent write-up that offers his (excellent) take on what progressive enhancement means.
Let’s look at three specific examples that show off what I think are the key features of HTML Web Components — CSS style encapsulation and opportunities for progressive enhancement — without being forced to depend on JavaScript to work out of the box. We will most definitely use JavaScript, but the components ought to work without it.
The examples can all be found in my Web UI Boilerplate component library (built using Storybook), along with the associated source code in GitHub.
I really like how Chris Ferdinandi teaches building a web component from scratch, using a disclosure (show/hide) pattern as an example. This first example extends his demo.
Let’s start with the first-class citizen, HTML. Web components allow us to establish custom elements with our own naming, which is the case in this example with a tag we’re using to hold a designed to show/hide a block of text and a
of text we want to show and hide.
<webui-disclosure
data-bind-escape-key
data-bind-click-outside
>
<button
type="button"
class="button button--text"
data-trigger
hidden
>
Show / Hide
</button>
<div data-content>
<p>Content to be shown/hidden.</p>
</div>
</webui-disclosure>If JavaScript is disabled or doesn’t execute (for any number of possible reasons), the button is hidden by default — thanks to the hidden attribute on it— and the content inside of the div is simply displayed by default.
Nice. That’s a really simple example of progressive enhancement at work. A visitor can view the content with or without the .
I mentioned that this example extends Chris Ferdinandi’s initial demo. The key difference is that you can close the element either by clicking the keyboard’s ESC key or clicking anywhere outside the element. That’s what the two [data-attribute]s on the <webui-disclosure tag are for.
We start by defining the custom element so that the browser knows what to do with our made-up tag name:
customElements.define('webui-disclosure', WebUIDisclosure);Custom elements must be named with a dashed-ident, such as or whatever, but as Jim Neilsen notes, by way of Scott Jehl, that doesn’t exactly mean that the dash has to go between two words.
I typically prefer using TypeScript for writing JavaScript to help eliminate stupid errors and enforce some degree of “defensive” programming. But for the sake of simplicity, the structure of the web component’s ES Module looks like this in plain JavaScript:
default class WebUIDisclosure extends HTMLElement {
constructor() {
super();
this.trigger = this.querySelector('[data-trigger]');
this.content = this.querySelector('[data-content]');
this.bindEscapeKey = this.hasAttribute('data-bind-escape-key');
this.bindClickOutside = this.hasAttribute('data-bind-click-outside');
if (!this.trigger || !this.content) return;
this.setupA11y();
this.trigger?.addEventListener('click', this);
}
setupA11y() {
// Add ARIA props/state to button.
}
// Handle constructor() event listeners.
handleEvent(e) {
// 1. Toggle visibility of content.
// 2. Toggle ARIA expanded state on button.
}
// Handle event listeners which are not part of this Web Component.
connectedCallback() {
document.addEventListener('keyup', (e) => {
// Handle ESC key.
});
document.addEventListener('click', (e) => {
// Handle clicking outside.
});
}
disconnectedCallback() {
// Remove event listeners.
}
}Are you wondering about those event listeners? The first one is defined in the constructor() function, while the rest are in the connectedCallback() function. Hawk Ticehurst explains the rationale much more eloquently than I can.
This JavaScript isn’t required for the web component to “work” but it does sprinkle in some nice functionality, not to mention accessibility considerations, to help with the progressive enhancement that allows the to show and hide the content. For example, JavaScript injects the appropriate aria-expanded and aria-controls attributes enabling those who rely on screen readers to understand the button’s purpose.
That’s the progressive enhancement piece to this example.
For simplicity, I have not written any additional CSS for this component. The styling you see is simply inherited from existing global scope or component styles (e.g., typography and button).
However, the next example does have some extra scoped CSS.
That first example lays out the progressive enhancement benefits of HTML Web Components. Another benefit we get is that CSS styles are encapsulated, which is a fancy way of saying the CSS doesn’t leak out of the component. The styles are scoped purely to the web component and those styles will not conflict with other styles applied to the current page.
Let’s turn to a second example, this time demonstrating the style encapsulating powers of web components and how they support progressive enhancement in user experiences. We’ll be using a tabbed component for organizing content in “panels” that are revealed when a panel’s corresponding tab is clicked — the same sort of thing you’ll find in many component libraries.
Starting with the HTML structure:
<webui-tabs>
<div data-tablist>
<a href="#tab1" data-tab>Tab 1</a>
<a href="#tab2" data-tab>Tab 2</a>
<a href="#tab3" data-tab>Tab 3</a>
</div>
<div id="tab1" data-tabpanel>
<p>1 - Lorem ipsum dolor sit amet consectetur.</p>
</div>
<div id="tab2" data-tabpanel>
<p>2 - Lorem ipsum dolor sit amet consectetur.</p>
</div>
<div id="tab3" data-tabpanel>
<p>3 - Lorem ipsum dolor sit amet consectetur.</p>
</div>
</webui-tabs>You get the idea: three links styled as tabs that, when clicked, open a tab panel holding content. Note that each [data-tab] in the tab list targets an anchor link matching a tab panel ID, e.g., #tab1, #tab2, etc.
We’ll look at the style encapsulation stuff first since we didn’t go there in the last example. Let’s say the CSS is organized like this:
webui-tabs {
[data-tablist] {
/* Default styles without JavaScript */
}
[data-tab] {
/* Default styles without JavaScript */
}
[role='tablist'] {
/* Style role added by JavaScript */
}
[role='tab'] {
/* Style role added by JavaScript */
}
[role='tabpanel'] {
/* Style role added by JavaScript */
}
}See what’s happening here? We have two style rules — [data-tablist] and [data-tab] — that contain the web component’s default styles. In other words, these styles are there regardless of whether JavaScript loads or not. Meanwhile, the other three style rules are selectors that are injected into the component as long as JavaScript is enabled and supported. This way, the last three style rules are only applied if JavaScript plops the **role** attribute on those elements in the HTML. Right there, we’re already supplying a touch of progressive enhancement by setting styles only when JavasScript is needed.
All these styles are fully encapsulated, or scoped, to the web component. There is no “leakage” so to speak that would bleed into the styles of other web components, or even to anything else on the page within the global scope. We can even choose to forego classnames, complex selectors, and methodologies like BEM in favour of simple descendent selectors for the component’s children, allowing us to write styles more declaratively on semantic elements.
For most web projects, I generally prefer to bundle CSS (including the web component Sass partials) into a single CSS file so that the component’s default styles are available in the global scope, even if the JavaScript doesn’t execute.
However, it is possible to import a stylesheet via JavaScript that is only consumed by this web component if JavaScript is available:
import styles from './styles.css';
class WebUITabs extends HTMLElement {
constructor() {
super();
this.adoptedStyleSheets = [styles];
}
}
customElements.define('webui-tabs', WebUITabs);Alternatively, we could inject a tag containing the component’s styles instead:
class WebUITabs extends HTMLElement {
connectedCallback() {
this.attachShadow({ mode: 'open' }); // Required for JavaScript access
this.shadowRoot.innerHTML = `
<style> <!-- styles go here --> </style>
// etc.
`;
}
}
customElements.define('webui-tabs', WebUITabs);Whichever method you choose, these styles are scoped directly to the web component, preventing component styles from leaking out, but allowing global styles to be inherited.
Now consider this simple example. Everything we write in between the component’s opening and closing tags is considered part of the “Light” DOM.
<my-web-component>
<!-- This is Light DOM -->
<div>
<p>Some content... styles are inherited from the global scope</p>
</div>
----------- Shadow DOM Boundary -------------
| <!-- Anything injected by JavaScript --> |
---------------------------------------------
</my-web-component>Dave Rupert has an excellent write-up that makes it really easy to see how external styles are able to “pierce” the Shadow DOM and select an element in the Light DOM. Notice how the element that is written in between the custom element’s tags receives the button selector’s styles in the global CSS, while the injected via JavaScript is left untouched.
If we want to style the Shadow DOM we’d have to do that with internal styles like the examples above for importing a stylesheet or injecting an inline block.
That doesn’t mean that all CSS style properties are blocked by the Shadow DOM. In fact, Dave outlines 37 properties that web components inherit, mostly along the lines of text, list, and table formatting.
Even though this second example is more about style encapsulation, it’s still a good opportunity to see the progressive enhancement we get practically for free from web components. Let’s step into the JavaScript now so we can see how we can support progressive enhancement. The full code is quite lengthy, so I’ve abbreviated things a bit to help make the points a little clearer.
default class WebUITabs extends HTMLElement {
constructor() {
super();
this.tablist = this.querySelector('[data-tablist]');
this.tabpanels = this.querySelectorAll('[data-tabpanel]');
this.tabTriggers = this.querySelectorAll('[data-tab]');
if (
!this.tablist ||
this.tabpanels.length === 0 ||
this.tabTriggers.length === 0
) return;
this.createTabs();
this.tabTriggers.forEach((tabTrigger, index) => {
tabTrigger.addEventListener('click', (e) => {
this.bindClickEvent(e);
});
tabTrigger.addEventListener('keydown', (e) => {
this.bindKeyboardEvent(e, index);
});
});
}
createTabs() {
// 1. Hide all tabpanels initially.
// 2. Add ARIA props/state to tabs & tabpanels.
}
bindClickEvent(e) {
e.preventDefault();
// Show clicked tab and update ARIA props/state.
}
bindKeyboardEvent(e, index) {
e.preventDefault();
// Handle keyboard ARROW/HOME/END keys.
}
}
customElements.define('webui-tabs', WebUITabs);The JavaScript injects ARIA roles, states, and props to the tabs and content blocks for screen reader users, as well as extra keyboard bindings so we can navigate between tabs with the keyboard; for example, the TAB key is reserved for accessing the component’s active tab and any focusable content inside the active tabpanel, and the tabs can be traversed with the ARROW keys. So, if JavaScript fails to load, the default experience is still an accessible one where the tabs still anchor link to their respective panels, and those panels naturally stack vertically, one on top of the other.
And if JavaScript is enabled and supported? We get an enhanced experience, complete with updated accessibility considerations.
This final example differs from the previous two in that it is entirely generated by JavaScript, and uses the Shadow DOM. This is because it is only used to indicate a “loading” state for Ajax requests, and is therefore only needed when JavaScript is enabled.
The HTML markup is just the opening and closing component tags:
<webui-ajax-loader></webui-ajax-loader>The simplified JavaScript structure:
default class WebUIAjaxLoader extends HTMLElement {
constructor() {
super();
const shadow = this.attachShadow({ mode: 'open' });
shadow.innerHTML = `
<svg role="img" part="svg">
<title>loading</title>
<circle cx="50" cy="50" r="47" />
</svg>
`;
}
}
customElements.define('webui-ajax-loader',WebUIAjaxLoader);Notice right out of the gate that everything in between the tags is injected with JavaScript, meaning it’s all in the Shadow DOM, encapsulated from other scripts and styles not directly bundled with the component.
But also notice the part attribute that’s set on the element. Here’s where we’ll zoom in:
<svg role="img" part="svg">
<!-- etc. -->
</svg>That’s yet another way we have to style the custom element: named parts. Now we can style that SVG from outside of the template literal we used to establish the element. There’s a ::part pseudo-selector to make that happen:
webui-ajax-loader::part(svg) {
// Shadow DOM styles for the SVG...
}And here’s something cool: that selector can access CSS custom properties, whether they are scoped globally or locally to the element.
webui-ajax-loader {
--fill: orangered;
}
webui-ajax-loader::part(svg) {
fill: var(--fill);
}As far as progressive enhancement goes, JavaScript supplies all of the HTML. That means the loader is only rendered if JavaScript is enabled and supported. And when it is, the SVG is added, complete with an accessible title and all.
That’s it for the examples! What I hope is that you now have the same sort of epiphany that I had when reading Jeremy Keith’s post: HTML Web Components are an HTML-first feature.
Of course, JavaScript does play a big role, but only as big as needed. Need more encapsulation? Want to sprinkle in some UX goodness when a visitor’s browser supports it? That’s what JavaScript is for and that’s what makes HTML Web Components such a great addition to the web platform — they rely on vanilla web languages to do what they were designed to do all along, and without leaning too heavily on one or the other.
HTML Web Components Make Progressive Enhancement and CSS Encapsulation Easier! originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.
Most days, I’m writing vanilla CSS. Thanks to CSS variables and nesting, I have fewer reasons to reach for Sass or any other preprocessor. The times I reach for Sass tend to be when I need a @mixin to loop through a list of items or help keep common styles DRY.
That could change for me in the not-so-distant future since a new CSS Functions and Mixins Module draft was published in late June after the CSSWG resolved to adopt the proposal back in February.
Notice the module’s name: Functions and Mixins. There’s a distinction between the two.
This is all new and incredibly unbaked at the moment with plenty of TODO notes in the draft and points to consider in future drafts. The draft spec doesn’t even have a definition for mixins yet. It’ll likely be some time before we get something real to work and experiment with, but I like trying to wrap my mind around these sorts of things while they’re still in early days, knowing things are bound to change.
In addition to the early draft spec, Miriam Suzanne published a thorough explainer that helps plug some of the information gaps. Miriam’s an editor on the spec, so I find anything she writes about this to be useful context.
There’s a lot to read! Here are my key takeaways…
We’re not talking about the single-purpose, built-in functions we’ve come to love in recent years — e.g., calc(), min(), max(), etc. Instead, we’re talking about custom functions defined with an @function at-rule that contains logic for returning an expected value.
That makes custom functions a lot like a custom property. A custom property is merely a placeholder for some expected value that we usually define up front:
:root {
--primary-color: hsl(25 100% 50%);
}Custom functions look pretty similar, only they’re defined with @function and take parameters. This is the syntax currently in the draft spec:
@function <function-name> [( <parameter-list> )]? {
<function-rules>
result: <result>;
}The result is what the ultimate value of the custom function evaluates to. It’s a little confusing to me at the moment, but how I’m processing this is that a custom function returns a custom property. Here’s an example straight from the spec draft (slightly modified) that calculates the area of a circle:
@function --circle-area(--r) {
--r2: var(--r) * var(--r);
result: calc(pi * var(--r2));
}Calling the function is sort of like declaring a custom property, only without var() and with arguments for the defined parameters:
.elenent {
inline-size: --circle-area(--r, 1.5rem); /* = ~7.065rem */
}Seems like we could achieve the same thing as a custom property with current CSS features:
:root {
--r: 1rem;
--r2: var(--r) * var(--r);
--circle-area: calc(pi * var(--r2));
}
.element {
inline-size: var(--circle-area, 1.5rem);
}That said, the reasons we’d reach for a custom function over a custom property are that (1) they can return one of multiple values in a single stroke, and (2) they support conditional rules, such as @supports and @media to determine which value to return. Check out Miriam’s example of a custom function that returns one of multiple values based on the inline size of the viewport.
/* Function name */
@function --sizes(
/* Array of possible values */
--s type(length),
--m type(length),
--l type(length),
/* The returned value with a default */
) returns type(length) {
--min: 16px;
/* Conditional rules */
@media (inline-size < 20em) {
result: max(var(--min), var(--s, 1em));
}
@media (20em < inline-size < 50em) {
result: max(var(--min), var(--m, 1em + 0.5vw));
}
@media (50em < inline-size) {
result: max(var(--min), var(--l, 1.2em + 1vw));
}
}Miriam goes on to explain how a comma-separated list of parameters like this requires additional CSSWG work because it could be mistaken as a compound selector.
Mixins feel more familiar to me than custom functions. Years of writing Sass mixins will do that to you, and indeed, is perhaps the primary reason I still reach for Sass every now and then.
Mixins sorta look like the new custom functions. Instead of @function we’re working with @mixin which is exactly how it works in Sass.
/* Custom function */
@function <function-name> [( <parameter-list> )]? {
<function-rules>
result: <result>;
}
/* CSS/Sass mixin */
@mixin <mixin-name> [( <parameter-list> )]? {
<mixin-rules>
}So, custom functions and mixins are fairly similar but they’re certainly different:
@function; mixins are defined with @mixin but are both named with a dashed ident (e.g. --name).result in a value; mixins result in style rules.This makes mixins ideal for abstracting styles that you might use as utility classes, say a class for hidden text that is read by screenreaders:
.sr-text {
position: absolute;
left: -10000px;
top: auto;
width: 1px;
height: 1px;
overflow: hidden;
}In true utility fashion, we can sprinkle this class on elements in the HTML to hide the text.
<a class="sr-text">Skip to main content</a>Super handy! But as any Tailwind-hater will tell you, this can lead to ugly markup that’s difficult to interpret if we rely on many utility classes. Screereader text isn’t in too much danger of that, but a quick example from the Tailwind docs should illustrate that point:
<div class="origin-top-right absolute right-0 mt-2 w-56 rounded-md shadow-lg">It’s a matter of preference, really. But back to mixins! The deal is that we can use utility classes almost as little CSS snippets to build out other style rules and maintain a clearer separation between markup and styles. If we take the same .sr-text styles from before and mixin-erize them (yep, I’m coining this):
@mixin --sr-text {
position: absolute;
left: -10000px;
top: auto;
width: 1px;
height: 1px;
overflow: hidden;
}Instead of jumping into HTML to apply the styles, we can embed them in other CSS style rules with a new @apply at-rule:
header a:first-child {
@apply --sr-text;
/* Results in: */
position: absolute;
left: -10000px;
top: auto;
width: 1px;
height: 1px;
overflow: hidden;
}Perhaps a better example is something every project seems to need: centering something!
@mixin --center-me {
display: grid;
place-items: center;
}This can now be part of a bigger ruleset:
header {
@apply --center-me;
/*
display: grid;
place-items: center;
*/
background-color: --c-blue-50;
color: --c-white;
/* etc. */
}That’s different from Sass which uses @include to call the mixin instead of @apply. We can even return larger blocks of styles, such as styles for an element’s ::before and ::after pseudos:
@mixin --center-me {
display: grid;
place-items: center;
position: relative;
&::after {
background-color: hsl(25 100% 50% / .25);
content: "";
height: 100%;
position: absolute;
width: 100%;
}
}And, of course, we saw that mixins accept argument parameters just like custom functions. You might use arguments if you want to loosen up the styles for variations, such as defining consistent gradients with different colors:
@mixin --gradient-linear(--color-1, --color-2, --angle) {
/* etc. */
}We’re able to specify the syntax for each parameter as a form of type checking:
@mixin --gradient-linear(
--color-1 type(color),
--color-2 type(color),
--angle type(angle),
) {
/* etc. */
}We can abstract those variables further and set default values on them:
@mixin --gradient-linear(
--color-1 type(color),
--color-2 type(color),
--angle type(angle),
) {
--from: var(--color-1, orangered);
--to: var(--from-color, goldenrod);
--angle: var(--at-angle, to bottom right);
/* etc. */
}…then we write the mixin’s style rules with the parameters as variable placeholders.
@mixin --gradient-linear(
--color-1 type(color),
--color-2 type(color),
--angle type(angle),
) {
--from: var(--color-1, orangered);
--to: var(--from-color, goldenrod);
--angle: var(--at-angle, to bottom right);
background: linear-gradient(var(--angle), var(--from), var(--to));
}Sprinkle conditional logic in there if you’d like:
@mixin --gradient-linear(
--color-1 type(color),
--color-2 type(color),
--angle type(angle),
) {
--from: var(--color-1, orangered);
--to: var(--from-color, goldenrod);
--angle: var(--at-angle, to bottom right);
background: linear-gradient(var(--angle), var(--from), var(--to));
@media (prefers-contrast: more) {
background: color-mix(var(--from), black);
color: white;
}
}This is all set to @apply the mixin in any rulesets we want:
header {
@apply --gradient-linear;
/* etc. */
}
.some-class {
@apply --gradient-linear;
/* etc. */
}…and combine them with other mixins:
header {
@apply --gradient-linear;
@apply --center-me;
/* etc. */
}This is all very high level. Miriam gets into the nuances of things like:
@when/@else in the mixin. (Which makes me wonder about the newly-proposed if() function and whether it would be used in place of @when.)@layer? scope? Something else?)Miriam has an excellent outline of the open questions and discussions happening around mixins.
Gah, this is a lot for my blonde brain! Anytime I’m neck-deep in CSS specification drafts, I have to remind myself that the dust is still settling. The spec authors and editors are wrestling with a lot of the same questions we have — and more! — so it’s not like a cursory read of the drafts is going to make experts out of anyone. And that’s before we get to the fact that things can, and likely will, change by the time it all becomes a recommended feature for browsers to implement.
This will be an interesting space to watch, which is something you can do with the following resources:
css-mixinsCSS Functions and Mixins Module Notes originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.
It’s been a few months out since A Book Apart closed shop. I’m sad about it, of course. You probably are, too, if you have one of their many brightly-colored paperbacks sitting on a bookshelf strategically placed as a backdrop for your video calls.
It looked for a bit like the books would still be available for purchase through third-party distributors who could print them on demand or whatever. And then a redaction on A Book Apart’s original announcement:
UPDATE: Ownership and publishing rights for all books have been given back to their respective authors. Many authors are continuing to offer their work for free or in new editions. Our hope is that these books will continue to live on forever. A Book Apart no longer sells or distributes books, please reach out to authors for information about availability.
Oh, snap. The books are on the loose and several authors are making sure they’re still available. Eric Meyer, for example, says he and co-author Sara Wachter-Boettcher still figuring out what’s next for their Design for Real Life title:
One of the things Sara and I have decided to do is to eventually put the entire text online for free, as a booksite. That isn’t ready yet, but it should be coming somewhere down the road.
In the meantime, we’ve decided to cut the price of print and e-book copies available through Ingram. [Design for Real Life] was the eighteenth book [A Book Apart] put out, so we’ve decided to make the price of both the print and e-book $18, regardless of whether those dollars are American, Canadian, or Australian.
Ethan Marcotte has followed suit by listing his three titles on his personal website and linking up where they can be purchased at a generous discount off the original price tag, including his latest, You Deserve a Tech Union.
Others have quickly responded with free online versions of their books. Mat Marquis has offered JavaScript for Web Designers free online for a long time. He helped Chris Coyier do the same with Practical SVG this past week. Jeremy Keith put out one of my personal ABA faves (and the first ever ABA-published book) for free, HTML5 for Web Designers.
What about all the other titles? I dunno. A Book Apart simply doesn’t sell or distribute them anymore. Rachel McConnell sells Leading Content Design directly. Every other book I checked seems to be a link back to A Book Apart. We’ll have to see where the proverbial dust settles. The authors now hold all the rights to their works and may or may not decide to re-offer them. Meanwhile, many of the titles are listed in places like Goodreads, Amazon, Barnes & Nobile, etc.
Thanks for all the great reads and years, A Book Apart! You’ve helped man, many people become better web citizens, present company included.
Where You Can Still Get A Book Apart Titles originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.
The B2B online marketplace is changing quickly, powered by advanced technology and changing customer demands. In 2023, the worldwide B2B online sales hit a staggering $18.6 billion, a notable jump from its $6.8 billion rate in 2021.
As 2024 rolls in, having an online presence isn’t enough. Customizing B2B sales has become extremely vital. It leads to more sales and conversions, among other benefits. Let’s look at the top ten strategies for B2B ecommerce personalization.
Personalized suggestions for items are key to B2B ecommerce personalization and success, possibly ratcheting up earnings substantially. For example, Amazon gains 35% of its revenues through recommendations, shooting up conversion rates by as much as 320%.
For B2B, these impacts are even greater as purchasers might be unaware of the complete product lineup. AI-assisted algorithms and customer data allow sellers to propose suitable items, improving customer interaction and assisting buyers in finding useful resolutions.
Personalizing B2B ecommerce is critical to meet unique buyer requirements. Customizing product listings, content, and search results according to user profiles helps customers view pertinent information. This dynamic approach may feature products specific to the buyer’s industry or job role.
Plus, it may display content such as whitepapers and case studies that match their position in the buying process. Such tailoring improves user interaction and directs buyers effectively towards beneficial solutions.
In the B2B world, long-term partnerships and customized solutions are regular. So, account-based personalization is vital to success. This process means changing the online shopping experience for particular accounts and buyers.
This way, companies can meet the specific needs, prices, and buying methods of their top customers. For example, they can show custom prices, deals, and agreed-upon terms. Another option is offering unique product lists, packages, and setups based on the account’s requirements.
Intelligent chatbots and virtual assistants in B2B ecommerce are essential for personalization. These AI-driven instruments improve customer service by giving customized help, responding to questions, and assisting shoppers through buying.
They can be adapted to give product suggestions based on customer wants and browsing history and offer tailored support as per the user’s job, field, or purchase phase. This strategy fulfills B2B buyers’ desire for a consumer-level web experience.
Online B2B sales require tailored prices and personalized quotes to build trust and boost sales. Adjusting prices and custom quotes according to customer groups, past purchases, and agreed contracts upholds fairness and clarity.
The strategies include crafting custom quotes considering special needs, previous orders, and valid discounts based on account status and contract conditions. This method forms a smooth buying journey modified to the circumstance of each B2B shopper.
The self-service experience and account overviews offered by B2B ecommerce help ease the customer’s journey while prioritizing speed and ease. These tailor-made screens let buyers run orders, check account data, and perform tasks themselves.
They primarily offer a combined view of past orders, bills, and account facts. Plus, they allow for easy repeat orders, monitor deliveries, and manage account preferences. This thoughtfulness simplifies tasks and boosts customers’ happiness in the B2B area.
Personal touches in communication and marketing stand out in B2B ecommerce. They help build stronger relations and increase involvement. Companies can inspire deeper connections by tailoring emails, website details, and other contact points to meet their clients’ wants and needs.
Consider dividing email lists by business type, role, or buying stage. Also, modify website details based on how users interact, what they look at, and their past purchases. This focused method improves client interactions and makes B2B relations more effective.
For B2B e-commerce, focusing on mobile-first personalization is critical as more buyers turn to their phones for research and purchase. Making the experience mobile-friendly and providing personalization across all channels gives a reliable and interesting experience for customers who are constantly moving.
Important aspects are adaptable designs, easy navigation, customized recommendations, search results, and content that adjusts based on the user’s device and place. This strategy pays attention to the changing behaviors and likes of B2B buyers.
More and more B2B companies are now using headless commerce systems for added personalization across various contact points. In these system, user interfaces are separate from back-end operations thanks to APIs.
There’s a quick adaptation of distinct experiences without limitations from the system or integrating external tools. This adaptability enables B2B companies to come up with specialized tech for a complete personalization plan.
Continuous checking and improving personalization strategies are vital for B2B ecommerce success. Data insights help enhance customer service and drive better results. A/B testing is critical to comparing tactics like product suggestions, content changes, and cost models.
This method discovers powerful strategies, boosts the number of successful transactions, and maintains a competitive advantage. Constantly updated based on test results, it ensures that customization tactics stay powerful and up to date in the ever-changing B2B environment.
B2B personalization isn’t optional; it’s crucial for strategy. In the future, AI will play an increasingly significant role in advising and customizing loyalty schemes for B2B online trade. Businesses that adopt personalization will flourish, whereas those that trail may lose their competitive advantage. The time has come: either must personalize or risk falling behind.
Featured Image by rawpixel.com on Freepik
The post Top 10 Strategies for B2B ECommerce Personalization In 2024 appeared first on noupe.
Imagine in some parallel universe, your website always loads at lightning speed, no matter how many visitors you have, and you never have to worry about scaling servers or maintaining them. Sounds like a dream, right? Well, in that parallel universe, you’re probably using serverless architecture.
In this article, we’ll show you how to bring serverless architecture into your reality and how this solution can significantly improve your website’s performance. Besides covering the key benefits, we’ll also give you practical tips on implementation. Let’s jump right in and get to it!
Serverless architecture isn’t just a buzzword. It’s a popular and probably indispensable approach to developing and running web applications. So, today we’re talking about serverless architecture, or simply put, a way to develop and run applications without worrying about server management. It’s a hot topic. Seriously, a survey conducted by CNCF found that 58% of participants use serverless computing for certain applications.
Source: https://www.grandviewresearch.com/industry-analysis/serverless-architecture-market
Imagine having an invisible assistant that automatically scales your app’s resources, and handles all the configuration, and monitoring issues. This assistant is cloud services like AWS Lambda, Google Cloud Functions, or Azure Functions.
Serverless apps are made up of small functions that run in response to specific events. For example, someone uploads a file — a function processes it. Someone submits a form — a function handles the data and saves it. Imagine someone places an order. A function automatically processes the payment, updates inventory, and sends notifications to both the customer and the seller. All of this happens without you lifting a finger.
You can set up functions to automatically create backups of important data on a schedule and store them in secure cloud storage. You don’t need to worry about scaling or maintaining servers in advance. The cloud provider handles all of that.
With data engineering solutions, you can ensure that your backups are efficiently managed and seamlessly integrated into your overall data strategy. Utilizing data engineering solutions also enables you to streamline the backup process, ensuring data integrity and security without additional manual effort.
Here are some benefits of serverless architecture:
Even though other public cloud services like database-as-a-service (DBaaS) have more overall users, serverless is actually more popular than newer, trendy services such as machine learning and IoT.
Source: https://www.cbinsights.com/research/serverless-cloud-computing/
Of course, serverless architecture has its pitfalls. For example, cold starts can increase latency when a function is first called (especially if it hasn’t been used for a long time). Also, state management and complex computational tasks require additional planning.
But what matters here is the right approach. With it, a significant improvement in the performance and flexibility of your web application is a pretty realistic goal.
Plus, an AWS Serverless Hero Ben Kehoe quote would be cool to mention at this point:
“If you go serverless because you love Lambda, you’re doing it for the wrong reason. If you go serverless because you love FaaS in general, you’re doing it for the wrong reason. Functions are not the point. … The point is focus: Serverless is a way to focus on business value. It is a trait. It is a direction, not a destination. Climb the never-ending serverless ladder… Find your part of the business value, and achieve a serverless state of mind.”
So you’ve started working with serverless architecture, and now choosing the right platform is key. It’s as important as picking a new computer. You don’t just grab the first one you see, right? You look for the perfect blend of features, price, and compatibility with your needs. The same goes for choosing a serverless platform. Let’s check out how to pick the ideal one.
| Main Serverless Platforms | Description |
| AWS Lambda | One of the pioneers in serverless architecture. It offers tons of integration options with other AWS services (like S3, DynamoDB, and API Gateway). So, if you’re already using AWS, it’s a great choice. |
| Google Cloud Functions | This is Google’s platform. It’s cool, fast, and flexible. It obviously integrates well with other Google Cloud services (like Firebase and BigQuery). It’s perfect if your project heavily uses data. |
| Azure Functions | Microsoft’s platform, so it naturally integrates well with Microsoft products (Azure Storage, Cosmos DB, and Active Directory). We’d recommend this for enterprise applications. |
Do you want to know how to choose the right platform? Let’s find out!
Each platform has its own way of handling automatic scaling and load management. For example, AWS Lambda is known for its reliability and scalability. Google Cloud Functions, on the other hand, offers low latency for global applications thanks to Google’s distributed infrastructure.
Serverless platforms usually follow a “pay-as-you-go” model. This means you only pay for the actual usage of resources. However, pricing structures can vary. AWS Lambda charges based on the number of requests and function execution time. Google Cloud Functions and Azure Functions might offer free tiers with certain limits. This can be a big deciding factor.
We suggest roughly calculating the cost of using each platform based on your current and anticipated loads. This way, you won’t face any unpleasant surprises later on.
If your project already uses cloud services, it’s important to choose a platform that easily integrates with them. For example, if your site uses Google Analytics and Firebase for data management, Google Cloud Functions would be a logical choice. If your application heavily relies on Microsoft products like Office 365 or Azure Active Directory, then Azure Functions makes sense.
Additionally, integrating a password manager with your chosen cloud platform can enhance security by managing credentials seamlessly. For instance, a password manager that works well with Azure can help protect sensitive data and streamline user authentication processes.
Check out the tools and SDKs each platform provides. AWS Lambda, for instance, supports a wide range of programming languages and has excellent documentation. Google Cloud Functions offers handy tools for local development and testing, speeding up the development and deployment process.
The location of data centers affects latency and access speed to your site. If your online store serves customers worldwide, you’ll need a platform with a wide range of data center locations. In this case, AWS Lambda or Google Cloud Functions are ideal. AWS Lambda ensures quick load times due to its scalability, while Google Cloud Functions offers low latency thanks to Google’s global infrastructure.
So, we’ve reached one of the most important parts of optimizing serverless architecture — optimizing the code. Just like you constantly organize your workspace, it’s the same with your code. You’d be surprised at how much faster and more efficiently everything runs when everything is in its place. Here’s how you can make your code as fast and efficient as possible.
Cold start is when your function runs after being idle for a while. This usually takes longer than normal. We have to admit that you can’t completely avoid cold starts. But here are some tips to minimize their impact:
Imagine you’re creating an API for image processing. Break it down into functions that handle uploading, processing, and saving images separately. You’ll be impressed with how much this reduces load time and makes the process more manageable.
Incorporating llm data analytics into your API can provide deeper insights into image processing efficiency and performance. By leveraging llm data analytics, you can optimize each function to ensure faster upload, processing, and saving times, enhancing the overall user experience.
The execution time of a function is another key aspect. The faster your function completes a task, the better your site’s performance.
How to do it?
Handling large volumes of data can significantly slow down function execution. So, it’s crucial to optimize the data volume.
How can you do it?
To optimize your code, you need to know where the delays are and which parts take the most time. Here’s how you can achieve it:
Remember, in serverless architecture, every optimization can significantly impact performance and user experience.
So, we’ve already talked about how important it is to choose the right platform and optimize your code to improve your site’s performance. Now, let’s move on to another key aspect — using a Content Delivery Network, or CDN. This is one of the coolest tools to speed up your site, and here’s why.
A CDN is a network of servers located around the world. They store copies of your static files (like images, CSS, JavaScript), and deliver them to users from the server closest to them. Content loads faster simply because the data has less distance to travel.
Imagine your site is hosted in New York, and you have a user in Tokyo. Without a CDN, all user requests go to New York. This obviously slows down the load time. With a CDN, the requests are handled by a server in Asia, and it eliminates the delay.
Plus, a great thing about using a CDN is that it reduces the load on your serverless functions since the CDN handles part of the work.
Here are a few more benefits of a CDN besides reducing delays:
Using a CDN is a must for any business looking to optimize site performance in a serverless architecture. It makes your site more reliable and faster.
So, you’ve chosen the right platform, optimized your code, and even set up a CDN. What’s next? Now it’s time to start monitoring and testing your site’s speed. This isn’t just a good step—it’s an essential one. If you want to catch potential performance bottlenecks early, you need to regularly run these procedures.
| Monitoring and Testing Tools | Description |
| Google PageSpeed Insights | This free tool from Google analyzes your site and provides recommendations to improve performance. It gives you scores for both mobile and desktop versions of your site.
Additionally, it offers detailed suggestions. For instance, if your site loads slowly on mobile devices, PageSpeed Insights might recommend optimizing images or reducing JavaScript size to address the issue. |
| Lighthouse | Another tool from Google, Lighthouse provides a comprehensive performance analysis of your site. It covers various aspects, including accessibility and SEO metrics. You can run it using Chrome DevTools or as a standalone tool.
Imagine using Lighthouse and finding out that your site’s slow loading is due to numerous render-blocking resources. Lighthouse offers steps to resolve these issues, such as loading JavaScript asynchronously or employing lazy loading for images. |
| New Relic | New Relic offers advanced performance monitoring capabilities, allowing you to track metrics such as server response time, database performance, and resource utilization. |
| AWS CloudWatch | If you’re using AWS Lambda, AWS CloudWatch provides robust monitoring and logging features. You can set up alerts to notify you of any performance issues. |
Here are a few practical tips to simplify these important but sometimes laborious processes of monitoring and testing:
Regular checks, real user monitoring, and load testing will help you ensure a fast and reliable experience for your users. Isn’t that what we’re all aiming for?
This guide covers most aspects related to implementing serverless architecture. We hope this information inspires you to adopt this excellent approach and transform the dream of a lightning-fast site, regardless of visitor volume, into reality.
Featured Image by Growtika on Unsplash
The post Optimizing Website Performance with Serverless Architecture appeared first on noupe.
Everybody loves a beautiful wallpaper to freshen up their desktops and home screens, right? To cater for new and unique artworks on a regular basis, we started our monthly wallpapers series more than 13 years ago, and from the very beginning to today, artists and designers from across the globe have accepted the challenge and submitted their designs to it. Just like this month.
In this post, you’ll find their wallpaper designs for August 2024. All of them come in versions with and without a calendar and can be downloaded for free. As a little bonus goodie, we also added a selection of August favorites from our wallpapers archives that are just too good to be forgotten. A big thank-you to everyone who shared their designs with us this month! Happy August!
Nostalgia
“August, the final breath of summer, brings with it a wistful nostalgia for a season not yet past.” — Designed by Ami Totorean from Romania.
Relax In Bora-Bora
“As we have taken a liking to diving through the coral reefs, we’ll also spend August diving and took the leap to Bora-Bora. There we enjoy the sea and nature and above all, we rest to gain strength for the new course that is to come.” — Designed by Veronica Valenzuela from Spain.
Sandcastle Day
“Join us on Sandcastle Day for a fun-filled beach adventure, where creativity meets the sand — build, play, and enjoy the sun!” — Designed by PopArt Studio from Serbia.
Banana!
Designed by Ricardo Gimenes from Sweden.
Cullion
Designed by Bhabna Basak from India.
Pirate Aged Rum
Designed by Ricardo Gimenes from Sweden.
World Friendship Day
“Cherish the bonds of friendship, share smiles, and create beautiful memories with your friends. Let’s spread love and joy together!” — Designed by Reethu from London.
Summer Day
Designed by Kasturi Palmal from India.
Retro Road Trip
“As the sun dips below the horizon, casting a warm glow upon the open road, the retro van finds a resting place for the night. A campsite bathed in moonlight or a cozy motel straight from a postcard become havens where weary travelers can rest, rejuvenate, and prepare for the adventures that await with the dawn of a new day.” — Designed by PopArt Studio from Serbia.
Spooky Campfire Stories
Designed by Ricardo Gimenes from Sweden.
Happiness Happens In August
“Many people find August one of the happiest months of the year because of holidays. You can spend days sunbathing, swimming, birdwatching, listening to their joyful chirping, and indulging in sheer summer bliss. August 8th is also known as the Happiness Happens Day, so make it worthwhile.” — Designed by PopArt Studio from Serbia.
Bee Happy!
“August means that fall is just around the corner, so I designed this wallpaper to remind everyone to ‘bee happy’ even though summer is almost over. Sweeter things are ahead!” — Designed by Emily Haines from the United States.
Colorful Summer
“‘Always keep mint on your windowsill in August, to ensure that the buzzing flies will stay outside where they belong. Don’t think summer is over, even when roses droop and turn brown and the stars shift position in the sky. Never presume August is a safe or reliable time of the year.’ (Alice Hoffman)” — Designed by Lívi from Hungary.
Psst, It’s Camping Time…
“August is one of my favorite months, when the nights are long and deep and crackling fire makes you think of many things at once and nothing at all at the same time. It’s about heat and cold which allow you to touch the eternity for a few moments.” — Designed by Igor Izhik from Canada.
Oh La La… Paris’ Night
“I like the Paris’ night! All is very bright!” — Designed by Verónica Valenzuela from Spain.
Summer Nap
Designed by Dorvan Davoudi from Canada.
Shrimp Party
“A nice summer shrimp party!” — Designed by Pedro Rolo from Portugal.
Cowabunga
Designed by Ricardo Gimenes from Sweden.
Childhood Memories
Designed by Francesco Paratici from Australia.
Live In The Moment
“My dog Sami inspired me for this one. He lives in the moment and enjoys every second with a big smile on his face. I wish we could learn to enjoy life like he does! Happy August everyone!” — Designed by Westie Vibes from Portugal.
Swimming In The Summer
“It’s the perfect evening and the water is so warm! Can you feel it? You move your legs just a little bit and you feel the water bubbles dancing around you! It’s just you in there, floating in the clean lake and small sparkly lights shining above you! It’s a wonderful feeling, isn’t it?” — Designed by Creative Pinky from the Netherlands.
It’s Vacation O’Clock!
“It’s vacation o’clock! Or is it? While we bend our backs in front of a screen, it’s hard not to think about sandy beaches, flipping the pages of a corny book under the umbrella while waves splash continuously. Summer days! So hard to bear them in the city, so pleasant when you’re living the dolce far niente.” — Designed by ActiveCollab from the United States.
Launch
“The warm, clear summer nights make me notice the stars more — that’s what inspired this space-themed design!” — Designed by James Mitchell from the United Kingdom.
Ahoy
Designed by Webshift 2.0 from South Africa.
Rain, Rain Go Away!
“Remember the nursery rhyme where the little boy pleads the rain to go away? It is one of the most pleasant and beautiful seasons when the whole universe buckles up to dance to the rhythm of the drizzles that splash across the earth. And, it is August, the time of the year when monsoons add a lot of color and beauty to nature. We welcome everyone to enjoy the awesomeness of monsoons.” — Designed by Acodez from India.
Olympic Summer
“The Summer Olympic Games promise two weeks of superhuman struggle for eternal glory. Support your favorites and enjoy hot August.” — Designed by PopArt Studio from Serbia.
Handwritten August
“I love typography handwritten style.” — Designed by Chalermkiat Oncharoen from Thailand.
Hello Again
“In Melbourne it is the last month of quite a cool winter so we are looking forward to some warmer days to come.” — Designed by Tazi from Australia.
El Pollo Pepe
“Summer is beach and swimming pool, but it means countryside, too. We enjoy those summer afternoons with our friend ‘El pollo Pepe’. Happy summer!” — Designed by Veronica Valenzuela from Spain.
Coffee Break Time
Designed by Ricardo Gimenes from Sweden.
Subtle August Chamomiles
“Our designers wanted to create something summery, but not very colorful, something more subtle. The first thing that came to mind was chamomile because there are a lot of them in Ukraine and their smell is associated with a summer field.” — Designed by MasterBundles from Ukraine.
Work Hard, Play Hard
“It seems the feeling of summer breaks we had back in school never leaves us. The mere thought of alarm clocks feels wrong in the summer, especially if you’ve recently come back from a trip to the seaside. So, we try to do our best during working hours and then compensate with fun activities and plenty of rest. Cheers!” — Designed by ActiveCollab from the United States.
Smashing Magazine invited me to sit down for a one-on-one with “Uncle” Dave Rupert to discuss web components, yes, but also check in on Dave’s new Microsoft gig and what the ShopTalk co-host is working on these days.
I first met Dave in 2015 when CSS Dev Conf took place in my backyard, Long Beach. It’s not like we’ve been in super close touch between then and now — we may have only chatted one-on-one like that a couple other times — but talking with Dave each time feels like hanging with a close friend ands this time was no different. Good, good vibes and web nerdery.
To Shared Link — Permalink on CSS-Tricks
Smashing Hour With Dave Rupert originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.
