Webmasters Gallery

This article is a sponsored by Bryntum

Team, assemble! Need to coordinate a crew of superheroes across the globe to save the world? A scheduler can help. Same for web applications that serve any group of collaborating users — whether that includes wearing a cape or not.

Event calendars and schedulers may often seem the same; sometimes, a calendar is all you need. However, a scheduler does a lot more than block out a day or time slot, especially for the “supervisors” and “managers”, i.e., the Nick Fury of the teams, who do more than give out assignments and due dates but also need to track the usage of available resources — like staffs’ work hours, or inanimate resources, like an operating room in a hospital — to ensure the efficiency of each task, resource, and process.

In this post, you’ll find some of the best commercial web scheduler libraries (JavaScript based) with amazing UX and high efficiency that are currently available. Let’s dive in right away, shall we?

Bryntum Scheduler

This super easy to integrate scheduler works seamlessly with any frontend stack such as Angular, React, Vue, or vanilla JS. The Bryntum website has examples in all the supported frameworks, and numerous sample use-cases to assist your integration process.

As for its appearance, if any of the modern themes provided with the scheduler won’t do so, you can quickly achieve a tailored look using CSS or SASS variable-based styling while still maintaining high-performance and responsive rendering throughout different screen sizes.

Now, the features are where the rubber meets the road. Drag and drop support; Export to Excel, PDF, and PNG; Custom data fields and filtering; Dependency arrows between events for process visualization; And many more. Here’s a comprehensive list of their scheduler features at Bryntum’s website.

That’s not all. There’s a Pro version. The highlight is the Resource Histogram — which is an intuitive overview of resource allocation. Additionally, there’s Travel time visualization, Overview of non-working hours, Skill matching, and more in the Pro tool chest. Plus, rewiring any of the default actions to your liking is an effortless undertaking due to the many configuration settings provided in the API.

Support is available by means of professional services, active forums, and a slew of exhaustive documentation comprising live demos. You can start a 45-day free trial right away or contact their sales team for any inquiries regarding pricing and features.

DHTMLX Scheduler

Here is another modern scheduler with the availability of integrations with over ten different frameworks, including some of the popular JavaScript ones like jQuery. The DHTMLX scheduler offers a default theme (in both light and dark mode) uses gradients to standout. However, if that’s not your cup of tea, and neither is any of the other themes, there’s also the option to tinker under the CSS hood to customize the look.

Apart from the fundamental features, like being able to set up recurring appointments, and the Pro features, there’s also a Google Maps integration to include rich location data to the events. In Pro version, there’s the multiple resource view — the overview of allocated resources — that comes handy in delegating tasks, and to track the efficiency of each delegation. PDF export is available as an add-on.

Support is accessible through technical requests, forums, and API documentation. A 30-day free trial can be opted. For licensing and pricing, you can drop them a message or schedule a call.

MindFusion Scheduler

Although not feature-extensive but budget-friendly, the MindFusion scheduler (ready to download and test) is a good place to start if its rudimentary components are enough to get the job done for you and you don’t mind rolling up your sleeves to do a little revamp.

Basics like appointments, multiple calendar views, drag-and-drop, timetables for resources, and such are covered. CSS themes allow for easy alterations according to your preferences. Schedule export/Import in XML and JSON is included. A few sample use-cases are also available for you to peruse.

For technical support, you can drop in a ticket, check out its forum, or even acquire any of its consulting services. They also offer discounts for eligible customers. Even though seemingly a little bland, their documentation is robust. For any queries, you can reach them through email or phone.

DayPilot Pro Scheduler

There’s an open-source version that you can build up from. However, the Pro version is something not to be missed out on. The period for technical support for the Pro version is less than that of what DayPilot ’s peers offer, but it doesn’t skimp on features and is within a reasonable price for a single developer plan.

Most features expected to be in a Pro version are included, like the Resources overview, Resources utilization snapshot, comprehensive filtering, drag and drop, export options, etc. Besides the handful of themes provided, custom styling can be done with CSS. Some samples are also available to learn from.

The scheduler works with most of the common JavaScript libraries, and documentations are present for each separately. Support is available through forums and email. You can contact them for quotes and licensing queries. There’s a 60-days trial available.

Syncfusion Scheduler

With a complete keyboard interaction setup, Syncfusion Scheduler is accessible and friendly. In addition to vanilla JavaScript, it’s also available for React, Angular, Vue, and Blazor frameworks.

All major scheduler features are present. Appointments, Timelines, and Agendas are covered. Export is available in Excel documents; export and import are possible with iCal documents.

Styling can be done by overriding the default CSS file. There’s a theme builder, too, to assist in creating a custom theme. And a few UI kits, like one for Adobe XD, is provided with the scheduler.

API documentation is available for all supported integrations. There’s a 30-day trial period, or you can check out some editable demos to try the product. Or you can contact Syncfusion through a form or any of the contacts provided at their site for more information. Technical support is provided via requests and forums.

Conclusion

For teams working remotely across the globe or together in an office, as well as for any group of collaborating users, a scheduler can be a valuable tool indeed. If you’d like to share a scheduler that you’ve tried and loved, please let us know in the comments. Happy scheduling!

Christian Heilmann gave this talk at Typo3 Developer Days. I’m linking it up because it strikes an already stricken nerve in me. The increasing complexity of web development has an inverse relationship with the decreasing number of entry points for those getting into web development.

I love how Christian compares two hypothetical development stacks.

He’s definitely a bit glib, but the point is solid. Things are more complex today than they were, say, ten years ago. I remember struggling with Grunt back then and thinking I’d never get it right. I did eventually, and my IDE was never the same after that.

It’s easy to get swept up in the complexity, even for those with experience in the field:

This world is unfortunately becoming lost or, at least, degraded — not because it is no longer possible to view the source of a webpage, but because that source is often inscrutable, even on simple webpages.

— Pixel Envy “A View Source Web”

Christian’s post reminds me that the essence of the web is not only still alive but getting better every day:

• Browsers are constantly updated.
• The web standardisation process is much faster than it used to be.
• We don’t all need to build the next killer app. Many a framework promises scaling to infinity and only a few of us will ever need that.

He goes on to suggest many ways to remove complexity and abstractions from a project. My biggest takeaway is captured by a single headline:

The web is built on resilient technologies – we just don’t use them

Which recalls what Molly White said earlier this year that there’s always an opportunity to swing the pendulum back:

The thing is: none of this is gone. Nothing about the web has changed that prevents us from going back. If anything, it’s become a lot easier. We can return. Better, yet: we can restore the things we loved about the old web while incorporating the wonderful things that have emerged since, developing even better things as we go forward, and leaving behind some things from the early web days we all too often forget when we put on our rose-colored glasses.

We can return. We can restore all the things. So, tell me: do you take the red pill or the blue one?

To Shared Link — Permalink on CSS-Tricks

---

Christian Heilmann: Let’s make a simpler, more accessible web originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Imagine walking into a bustling corporate event filled with anticipation. The room is abuzz with conversations, and the energy is palpable as employees and leaders prepare for a day of learning and collaboration.     

As the keynote speaker takes the stage, the atmosphere shifts to focused attention and excitement. This transition marks the crucial moment in the event, where insights are shared, and leadership principles are highlighted, setting the stage for transformative discussions.

Corporate events are essential for fostering growth, building team cohesion, and sparking innovation. A significant highlight of these events is often a leadership keynote speaker, whose role is pivotal in setting the tone and motivating attendees. 

But what makes these speakers so inspiring? 

Let’s delve into the key elements that enable a leadership keynote speaker for corporate events to leave a lasting impact.

1. Engaging Storytelling

Leadership keynote speakers use storytelling to engage their audience, making abstract concepts relatable and driving key messages home in memorable ways. They connect with people on a deeper level because their stories frequently touch on familiar themes like invention, cooperation, and resilience.

This approach turns a presentation into a dynamic and immersive experience that leaves a lasting impression on the audience. 

2. Expertise and Credibility

Leadership keynote speakers’ credibility is based on their extensive experience, practical insights, and real-world applications. Their blend of theory and practice enhances their authority and makes their message more impactful.

The combination of theory and practice reinforces their authority and provides valuable, actionable insights for the audience. 

3. Visionary Thinking

An inspiring keynote speaker challenges conventional thinking, encouraging the audience to envision new possibilities and innovative solutions. These speakers inspire attendees to rethink their approach and embrace change by offering innovative solutions and forward-thinking ideas.

This visionary approach empowers individuals and organizations for continuous improvement and growth. 

4. Emotional Connection

Effective leadership keynote speakers for corporate events know how to tap into the emotions of their audience. Through passionate delivery and genuine empathy, they create an emotional bond that enhances the overall impact of their message. 

This emotional connection is crucial because it motivates people on a deeper level, inspiring them to act and embrace change. When attendees feel understood and valued, they are more likely to be receptive to new ideas and motivated to implement them.

5. Practical Takeaways

Image Source

While inspiration is essential, practical takeaways are equally important. Leadership keynote speakers provide actionable insights and strategies that attendees can apply immediately. 

Whether it’s through specific leadership techniques, team-building exercises, or personal development tips, these practical elements ensure that the audience leaves with valuable tools to improve their performance and contribute to their organization’s success.

6. Customization and Relevance

To truly inspire, a leadership keynote speaker must tailor their message to the specific audience and context of the event. This customization involves understanding the unique challenges and goals of the organization and its employees. 

By aligning their speech with the audience’s needs and interests, the speaker ensures that their message is relevant and impactful. This personalized approach demonstrates respect for the audience and enhances the speaker’s credibility.

7. Interactive Engagement

Modern leadership keynote speakers often incorporate interactive elements into their presentations. This might include Q&A sessions, live polls, or group activities. 

These interactive components not only break the monotony of a one-way speech but also engage the audience more deeply, making the experience more dynamic and memorable. Interactive engagement fosters a sense of participation and collaboration, which can motivate attendees.

8. Strategic Alignment

Leadership keynote speakers frequently tailor their presentations to the strategic goals of businesses. Their material is tailored to align with the company’s aims and difficulties, with clear guidelines for executives and staff to follow.   

This strategic alignment guarantees that the message is applicable to the organization’s future direction and existing goals, in addition to being motivating. Keynote presenters use a strategy that effectively connects inspiration with execution, enabling participants to apply newly obtained insights to their specific roles and responsibilities.    

9. Long-term Impact

Image Source

Several keynote speakers provide follow-up resources and support to reinforce the lessons learned during their presentations. This may consist of access to additional materials, workshops, or consulting services.

Proficient keynote speakers aim to leave a lasting impression that continues to motivate and inspire long after the event concludes. Their goal is to spark long-term change and improvement, encouraging attendees to take sustained action towards their personal and professional goals. 

Conclusion

A leadership keynote speaker transforms corporate events into memorable experiences through engaging storytelling, credible expertise, visionary thinking, emotional connection, practical takeaways, customization, and interactive engagement. By inspiring individuals and organizations to strive for excellence, leadership keynote speakers for corporate events play a crucial role in driving growth and innovation in the corporate world.

Featured Image by rawpixel.com on Freepik

The post How Leadership Keynote Speakers Inspire at Corporate Events appeared first on noupe.

In the dynamic and competitive world of B2B, finding ways to stand out and grow your business can feel like navigating an endless maze. But what if there was a way to cut through the complexity and supercharge your growth? Enter sales outsourcing—a game-changing strategy that lets you focus on your core strengths while seasoned experts handle the sales hustle.

Imagine having a powerhouse sales team at your disposal without the headaches of hiring, training, and managing an in-house staff. Sales outsourcing can deliver that and more, offering benefits like cost-effectiveness, scalability, and access to top-notch expertise. In this guide, we’ll explore the ins and outs of sales outsourcing, debunk common myths, identify red flags to watch out for, and help you find the perfect partner to elevate your business. Get ready to discover how sales outsourcing can be your secret weapon for achieving unparalleled growth and success in the B2B arena.

Understanding Sales Outsourcing

First things first: what exactly is sales outsourcing? It’s about entrusting your sales activities to a third-party service provider. These pros offer a range of services—from lead generation and appointment setting to full-cycle sales management. By outsourcing these functions, you can tap into top-notch expertise and resources without the hefty costs of maintaining an in-house team. Think of it as having a secret weapon in your business arsenal.

Why B2B Companies Should Consider Sales Outsourcing

Let’s face it—managing sales isn’t always a walk in the park. You might be grappling with limited time, a lack of sales expertise, or the constant struggle to generate high-quality leads. Sound familiar? Sales outsourcing can be your solution. By bringing in experienced sales professionals, you’ll have strategies that actually work, freeing you up to focus on what you do best. 

So, when is the right time to consider sales outsourcing for your B2B company? Here are some optimal scenarios:

1. When Scaling Rapidly: If your company is growing quickly and you need to scale your sales efforts to match, outsourcing can provide the necessary resources and expertise without the long lead times associated with hiring and training new in-house staff. This ensures you don’t miss out on opportunities due to a lack of sales capacity.
2. Launching a New Product or Service: Introducing a new product or service to the market requires a focused and strategic sales effort. Outsourcing can help you quickly ramp up and execute a targeted sales campaign, leveraging specialists who understand how to penetrate new markets and drive adoption.
3. Entering New Markets: Expanding into new geographical regions or industries often involves navigating unfamiliar territory. Sales outsourcing partners with experience in these areas can provide valuable insights, connections, and localized strategies to ensure a successful market entry.
4. During Economic Downturns: In times of economic uncertainty, maintaining a full-scale in-house sales team can be financially burdensome. Outsourcing allows you to maintain robust sales efforts while managing costs more effectively, helping you stay competitive without overextending your budget.
5. When Experiencing High Turnover: High turnover rates in your sales team can disrupt your pipeline and slow down growth. Outsourcing provides stability and consistency, ensuring your sales efforts continue seamlessly even as you address internal HR challenges.
6. Lacking In-House Expertise: If your existing team lacks the expertise needed for complex sales processes or specific industries, outsourcing to specialists can fill the gap. These professionals bring a wealth of knowledge and proven strategies to the table, driving better results than a generalist team might achieve.
7. Focusing on Core Competencies: Sometimes, it’s simply a matter of focus. Your core team might be better utilized in product development, customer service, or other areas crucial to your business’s success. Outsourcing sales allows your team to concentrate on what they do best while experts handle the sales function.
8. Short-Term Projects and Campaigns: For specific projects or sales campaigns, such as seasonal promotions or trade show follow-ups, outsourcing can provide the necessary boost without long-term commitments. This flexibility allows you to scale your sales efforts up and down as needed.

Debunking Common Myths About Sales Outsourcing

Despite its many use cases, sales outsourcing often gets a bad rap due to common misconceptions. Let’s set the record straight:

1. Myth: Outsourcing means losing control over sales.
   • Reality: A reputable outsourcing partner works closely with you, ensuring alignment with your goals and maintaining transparency. You remain in control of strategy and outcomes.
2. Myth: Outsourced teams don’t understand my industry.
   • Reality: Many outsourcing firms specialize in specific industries. By choosing a partner with relevant experience, you gain access to professionals who understand your market and its nuances.
3. Myth: Outsourcing is only for big companies.
   • Reality: Sales outsourcing is scalable and can be tailored to fit businesses of all sizes. Whether you’re a startup or an established enterprise, there’s a solution that fits your needs.
4. Myth: It’s too expensive and not cost-effective.
   • Reality: When you factor in the costs of hiring, training, and maintaining an in-house team, outsourcing often proves to be more economical, delivering high ROI through increased sales efficiency.

Choosing the Right Sales Outsourcing Partner

Finding the right partner is crucial. Here’s what to look for:

1. Industry Experience: A partner with experience in your industry will understand your market and challenges better, leading to more effective sales strategies.
2. Reputation: Do your homework. Read reviews, testimonials, and case studies to gauge their track record. A reputable partner will have a history of success.
3. Flexibility: One size does not fit all. Look for a partner who can tailor their services to your specific needs, providing a customized approach.
4. Pricing: Ensure their pricing structure fits your budget and offers good value. You want a partner who provides quality services without breaking the bank.

5 Red Flags When Vetting Outsourced Sales Partners

Choosing the right sales outsourcing partner is critical, but it’s equally important to be aware of potential red flags:

1. Lack of Transparency: If a potential partner is vague about their processes, success metrics, or pricing, it’s a sign they might not be fully trustworthy. Transparency is key to a successful partnership.
2. Poor Communication: Frequent communication lapses or delays in responses can indicate future challenges in collaboration. Effective communication is essential for aligning goals and strategies.
3. Overpromising: Be wary of partners who guarantee unrealistic results. Sales processes involve many variables, and no reputable firm will promise overnight success.
4. No Track Record: A lack of case studies, testimonials, or verifiable success stories can be a red flag. Established partners should have a proven track record and be willing to share their achievements.
5. High Employee Turnover: Consistency is crucial in sales. High turnover rates within the outsourcing firm can lead to disruptions and a lack of continuity in your sales efforts.

What’s Next?

Sales outsourcing offers a strategic advantage for B2B companies looking to grow their businesses without the headaches of managing an in-house sales team. By tapping into the expertise and resources of seasoned professionals, you can overcome common sales challenges, streamline your operations, and focus on what you do best—delivering outstanding products and services.

Whether you’re scaling rapidly, launching a new product, entering new markets, or simply seeking to optimize your sales efforts, outsourcing can provide the flexibility and expertise you need to thrive. 

Remember, the right outsourcing partner is out there—one who aligns with your goals, understands your industry, and delivers real, measurable results. So, don’t hesitate. Explore sales outsourcing today and watch your B2B business soar to new heights.

Featured Image by Stephen Dawson on Unsplash

The post Supercharge Your B2B Growth with Sales Outsourcing: Here’s How appeared first on noupe.

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:

1. People want badges or logos to aid in signaling skills.
2. The CSS3 brand has made a large impact on the web ecosystem.
3. The CSS3 logo has reached the end of its efficacy.

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.

Why Isn’t This Part Of The Web Platform Baseline?

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.

Why Not Work With An Annual Snapshot Instead Of A Numbered Era?

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:

• Help developers learn CSS.
• Help educators teach CSS.
• Help employers define modern web skills.
• Help the community understand the progression of CSS capabilities over time.
• Create a shared vernacular for describing how CSS evolves.

What we do not want is to:

• Affect spec definitions.
  CSS-Next is not a group that would define the working process of or influence working groups such as the CSSWG.
• Create official developer documentation.
  Making something like a new version of MDN doesn’t get us closer to a better understanding of how the language changes between eras.
• Define browser specification work.
  This should be conducted in relevant standardization or pre-standardization forums (such as the CSSWG or OpenUI).
• Educate developers on CSS best practices.
  That has much more to do with feature implementations than the features themselves.
• Manage browser compatibility data.
  Baseline is already doing that, and besides, we’ve already established that feature specifications and implementations are separate concerns.

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:

• Research the community’s understanding of modern CSS,
• Build a shared understanding of CSS feature evolution since CSS3,
• Grouping those features into easily-digestible levels (i.e., CSS4, CSS5, and so on), and
• Educate the community about modern CSS features.

We’d Likely Start With The “CSS5” Era

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.

Resources

• CSS-Next Group Homepage
• CSSWG Drafts Issue #4770: Let’s Define CSS 4
• CSS-Next Issue #92: Initial CSS Level Categorization

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.

Example 1:

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

that holds the

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.

Example 2:

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.

Quickly: “Light” DOM versus Shadow DOM

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.

Progressively enhance the tabbed component with JavaScript

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.

Example 3:

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.

Wrapping up

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…

Custom functions are advanced custom properties

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 help maintain DRY, reusable style blocks

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:

• Functions are defined with @function; mixins are defined with @mixin but are both named with a dashed ident (e.g. --name).
• Functions 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:

• Applying mixins at the root level (i.e., not in a selector)
• Working with Container Queries with the limitation of having to set global custom properties on another element than the one that is queried.
• The possibility of conditionally setting mixin parameters with something 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.)
• Why we might draw a line at supporting loops the same way Sass does. (CSS is a declarative language and loops are imperative flows.)
• Scoping mixins (@layer? scope? Something else?)

Miriam has an excellent outline of the open questions and discussions happening around mixins.

That’s, um, it… at least for now.

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:

• Proposal: Custom CSS Functions & Mixins (GitHub Issue #9350)
• CSS Mixins & Functions Explainer (Miriam Suzanne)
• Layered Toggles: Optional CSS Mixins (Roman Komarov)
• All GitHub issues tagged css-mixins

---

CSS 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.