All of the work you do to grow your web design business requires an investment of time and energy. And if you do this song-and-dance routine for long enough, you’re bound to become exhausted by it all.
So, how do you stop doing so much without losing momentum?
Productivity tools help quite a bit as do templates — be they for managing projects, clients, or to streamline your design work. In other words, anything you can do to automate, delegate, or outsource work completely can reduce how much work you have to do without cutting too much into your profits.
But then there are still those pesky business management activities that require your involvement. Proposal development. Invoicing. Client onboarding. Marketing. And, on top of all that, you have to look for new clients.
Or do you?
If you’re not familiar with lead magnets and how they can improve your client search efforts, it’s time you became acquainted with them.
What Are Lead Magnets?
As a web designer, you instill trust in your clients by providing a quality service. But have you ever thought about how you could turn trust into a profitable long-term relationship with clients?
Lead magnets are one of the best ways to do this.
In summary, a lead magnet is something that you give away for free on your website, that is immensely valuable to clients. In exchange, you get their email address.
Why Would Web Designers Want to Use Lead Magnets?
If you’re feeling overworked and wishing there were an easier way to grow your web design business, pay close attention to these five benefits:
It’s easy for designers. Because you’re already equipped with a great set of design skills, creating lead magnets will be easy for you (unlike other professionals who usually have to pay others to do it for them).
It’s passive lead generation. Hunting for clients online is time-intensive and tedious. Lead magnets lure prospective clients to your site and help sell them on your services.
List building is automated. You know you need to stay in touch with prospects by email if you want to foster them to conversion. With a lead magnet, you don’t have to deal with the hassle of creating your lead list. Everything is automated.
It makes your business memorable. You’re now not just the guy or gal who designed that amazing website for Company X. You’re the full-fledged web design business that provided a prospective client with a valuable tool that improves how they do business.
The ROI is huge. A lead magnet is something you only have to create once. Aside from promoting it on your marketing channels, you don’t have to do any other work.
Why Would Prospects Be Willing to Give You Their Email?
A lead magnet has to have real value attached to it, as you’ll soon see. Because of this, the people who encounter them understand and accept the trade off.
Look, it takes some effort to unsubscribe from email lists you don’t want to be on. Most people won’t put themselves through this if they don’t believe the communication is worth it — which is good! It means you’ve already done some of the work in convincing them of your value as a design expert.
Now you need to use their contact information and convince them to pay for your services.
How Can Web Designers Use Lead Magnets?
Here are some real examples from designers, agencies, and others in this space that make good use of lead magnets:
Informational Content
As a web designer, you might not be too keen on having to write anything. That said, ebooks are an effective way to generate leads on a website.
Web marketing solutions company Bizzuka has examples of these all over their website.
As you can see, it’s appended to the end of a related blog post. It then drives visitors to a landing page with more information and a simple form.
But if you’re really not comfortable or confident in writing an ebook, and don’t want to pay someone to do it for you, think about filming a video or developing an infographic. Just make sure it’s full of valuable information they’ll be dying to get their hands on.
Educational Content
For those of you that enjoy educating others, this could be a good one for you. You’ll just need to find a way to make this relevant to what you do and how you serve clients.
As their target audience is web designers and developers, they’ve produced an email course that reveals valuable insights gleaned over nearly two decades of working in the industry.
Again, if you want to avoid any writing, you could always create your own video course and then gate it off with a landing page and form. Or you could publish a webinar (live or pre-recorded) that offers highly targeted educational content.
Design Templates
It’s up to you to decide what type of design templates would be the most valuable to your prospective client base. Realistically, these templates will be things like:
Icon sets
Email designs
Infographic wireframes
Presentation shells
Social media kits
Basically, focus on the smaller marketing bits that require a designer’s touch and that they won’t be able to handle on their own. Once they realize how helpful those were, they’ll come to you for web design assistance.
If you’re looking for inspiration on how to promote this type of lead magnet, take WebDesignerDepot‘s lead:
Visitors get to see the awesome lead magnet for themselves, but can only gain access to editable files through a form.
Audits
When you first started designing websites for clients, you probably offered consultation and auditing services for free. But you recognize that time equals money, so why give away valuable advice for free and run the risk of them taking your tips to the competition?
A safe way to do this is to turn your audits into lead magnets. This way, you at least get their email address, so you can follow up post-delivery and work on convincing them to work with you through that direct channel.
When visitors take a peek under their list of Services, they find “Free Website Audit” at the bottom of the list. They’re then taken to the simplest of landing pages:
Lounge Lizard proves that they’re not out to waste anyone’s time. There’s no big sales pitch and no need to ask for excessive information. Just “what’s your domain and how can we contact you”, and that’s it!
Wrapping Up
Before you do anything else, make sure you have an impressive-looking website that attracts visitors. And also get yourself on social media channels like Twitter. Lead magnets don’t usually take too long to make, but you don’t want to waste time building one if you don’t have a reliable place to house it or strategies in place to promote it.
Say we need to render a child element into a React application. Easy right? That child is mounted to the nearest DOM element and rendered inside of it as a result.
render() {
return (
<div>
// Child to render inside of the div
</div>
);
}
But! What if we want to render that child outside of the div somewhere else? That could be tricky because it breaks the convention that a component needs to render as a new element and follow a parent-child hierarchy. The parent wants to go where its child goes.
That’s where React Portals come in. They provide a way to render elements outside the DOM hierarchy so that elements are a little more portable. It may not be a perfect analogy, but Portals are sort of like the pipes in Mario Bros. that transport you from the normal flow of the game and into a different region.
The cool thing about Portals? Even though they trigger their own events that are independent of the child’s parent element, the parent is still listening to those events, which can be useful for passing events across an app.
We’re going to create a Portal together in this post then make it into a re-usable component. Let’s go!
The example we’re building
Here’s a relatively simple example of a Portal in action:
Toggling an element’s visibility is nothing new. But, if you look at the code carefully, you’ll notice that the outputted element is controlled by the button even though it is not a direct descendent of it. In fact, if you compare the source code to the rendered output in DevTools, you’ll see the relationship:
So the outputted element’s parent actually listens for the button click event and allows the child to be inserted even though it and the button are separate siblings in the DOM. Let’s break down the steps for creating this toggled Portal element to see how it all works.
Step 1: Create the Portal element
The first line of a React application will tell you that an App element is rendered on the document root using ReactDOM. Like this;
We need to place the App element in an HTML file to execute it:
<div id="App"></div>
Same sort of thing with Portals. First thing to creating a Portal is to create a new div element in the HTML file.
<div id="portal"></div>
This div will serve as our target. We’re using #portal as the ID, but it doesn’t have to be that. Any component that gets rendered inside this target div will maintain React’s context. We need to store the div as the value of a variable so we can make use of the Portal component that we’ll create:
Looks a lot like the method to execute the App element, right?
Step 2: Create a Portal component
Next, let’s set up the Portal as a component:
class Portal extends React.Component {
constructor() {
super();
// 1: Create a new div that wraps the component
this.el = document.createElement("div");
}
// 2: Append the element to the DOM when it mounts
componentDidMount = () => {
portalRoot.appendChild(this.el);
};
// 3: Remove the element when it unmounts
componentWillUnmount = () => {
portalRoot.removeChild(this.el);
};
render() {
// 4: Render the element's children in a Portal
const { children } = this.props;
return ReactDOM.createPortal(children, this.el);
}
}
Let’s step back and take a look at what is happening here.
We create a new div element in the constructor and set it as a value to this.el. When the Portal component mounts, this.el is appended as a child to that div in the HTML file where we added it. That’s the
line in our case.
The DOM tree will look like this.
<div> // Portal, which is also portalRoot
<div> // this.el
</div>
</div>
If you’re new to React and are confused by the concept of mounting and unmounting an element, Jake Trent has a good explanation. TL;DR: Mounting is the moment the element is inserted into the DOM.
When the component unmounts we want to remove the child to avoid any memory leakage. We will import this Portal component into another component where it gets used, which is the the div that contains the header and button in our example. In doing so, we’ll pass the children elements of the Portal component along with it. This is why we have this.props.children.
Step 3: Using the Portal
To render the Portal component’s children, we make use of ReactDOM.createPortal(). This is a special ReactDOM method that accepts the children and the element we created. To see how the Portal works, let’s make use of it in our App component.
But, before we do that, let’s cover the basics of how we want the App to function. When the App loads, we want to display a text and a button — we can then toggle the button to either show or hide the Portal component.
class App extends React.Component {
// The initial toggle state is false so the Portal element is out of view
state = {
on: false
};
toggle = () => {
// Create a new "on" state to mount the Portal component via the button
this.setState({
on: !this.state.on
});
};
// Now, let's render the components
render() {
const { on } = this.state;
return (
// The div where that uses the Portal component child
<div>
<header>
<h1>Welcome to React</h1>
</header>
<React.Fragment>
// The button that toggles the Portal component state
// The Portal parent is listening for the event
<button onClick={this.toggle}>Toggle Portal</button>
// Mount or unmount the Portal on button click
<Portal>
{
on ?
<h1>This is a portal!</h1>
: null
}
</Portal>
</React.Fragment>
</div>
);
}
}
Since we want to toggle the Portal on and off, we need to make use of component state to manage the toggling. That’s basically a method to set a state of on to either true or false on the click event. The portal gets rendered when on is true; else we render nothing.
This is how the DOM looks like when the on state is set to true.
When on is false, the Portal component is not being rendered in the root, so the DOM looks like this.
More use cases
Modals are a perfect candidate for Portals. In fact, the React docs use it as the primary example for how Portals work:
J Scott Smith shows how Portals can be used to escape positioning:
He has another slick example that demonstrates inserting elements and managing state:
Summary
That’s a wrap! Hopefully this gives you a solid base understanding of Portals as far as what they are, what they do, and how to use them in a React application. The concept may seem trivial, but having the ability to move elements outside of the DOM hierarchy is a handy way to make components a little more extensible and re-usable… all of which points to the core benefits of using React in the first place.
We rolled out a new site design on January 1! This is the 17th version of CSS-Tricks if you can believe that. The versions tend to evolve a decent amount beyond the initial launch, but we archive screenshots on this design history page. Like I said in our 2018 thank you post:
This is easily the most time, effort, and money that’s gone into a redesign since the big v10 design. There are a lot of aesthetic changes, but there was also quite a bit of UX work, business goal orientation, workflow tweaking, and backend development work that went along with it.
This is a big one! The reception so far has been pretty great, but please know that we’ll be refining it and squishing a lot of bugs here in the early days.
Here are some notes about who was involved, how it happened, and things to notice.
Kylie led this project
Kylie Timpani was the lead designer and really whole project lead on this.
I first reached out to her in April 2017, we chatted in May, and kicked off the work in June. From my perspective, this was a pretty casual process, as I had no particular deadlines and fairly loose goals. Let’s make an attractive site that does better in all ways than we do them now.
Kylie was super organized and had a very thoughtful process around every aspect of this. Just in the first block of time that Kylie allocated for this project she:
Took a complete content inventory
Dug into analytic data to understand users, traffic, and usage at a high level
Created, distributed, and analyzed a reader survey to understand readers better and answer specific questions she had for them
Chatted with all the staff members of CSS-Tricks to understand their roles, workflows, and ideas
Kylie’s obviously not the kind of the designer that just whips open a design tool and starts noodling around. As great of a visual designer as she is, the work was highly informed. She went on to speak with our advertising agency, clearly identify the site’s current strengths and weaknesses, and do light wireframing.
I’ve been using Figma for visual design stuff, and Kylie was happy to use that as the design tool. That was nice since we both have Team level access and were able to use it collaboratively. For me, it was mostly useful for being able to see and reference everything, and make notes on the designs.
We also used Asana to track what was being worked on and ultimately as a place to track bugs and places where the design implementation needed attention.
Thanks so much, Kylie for all your excellent work on this project! If anything is a bit off or buggy about the site, it’s my poor implementation. And good luck! ??
?? So! Speaking of big life changing news… in just a couple of weeks I’ll be moving to San Francisco! I’m so SO excited to be joining @nrrrdcore and her truly incredible team over at Apple! ?????
I’ll let y’all explore the design for yourself to find all the little touches we put in, but I’ll give a shout out to a few of them where there is a technical detail you might enjoy.
Orange-to-pink
Clearly, we went all dark mode on this design. It’s nothing to do with the new media query, although that reminds me we might consider alternations for those who specifically set prefers-color-scheme: light;.
The brand/accent/action colors are orange and pink, which looks quite striking against the darkness but works on light backgrounds as well.
I made a quickie little Sass @mixin that allowed me to use those colors (with variations, if needed) at different angles as backgrounds:
There is something about headers that always bring out more complexity than you might expect. I recently went through this with the new CodePen header/sidebar and it as complicated for this site. Part of what complicated this one was:
It has its own set of unique breakpoints. The header is pretty full, so the breakpoints are pretty specific and unique to it.
We wanted a fixed-position (but minified) header that showed up as you scroll down.
When you’re logged in, there is a WordPress admin bar also fixed to the top of the page. I wanted to accommodate for that.
At one point, it was getting pretty messy and I wound up deleting all the CSS for the entire thing and re-wrote it, taking all the states into consideration, and writing media queries that used logic to clearly specify styles in each of those states.
The idea of a not-always-fixed-position header is interesting in and of itself. It means that:
You need to determine when to apply the fixed position
You need to make sure the shift from not-fixed to fixed (and back) doesn’t cause layout shifting
I was dead nervous about attaching an onscroll listener and doing math and such to determine when to do the switch. I’m sure it can be done responsibly, but I haven’t had great luck with that. Instead, I placed a tiny one-pixel element to the screen and attached an IntersectionObserver to it and reacted to that. That gave me the power to adjust where that is in CSS, which was a nice little touch.
One very cool feature of this design is the Mixup area on the homepage. It was one of Kylie’s ideas to show and remind people of the variety and depth of content that is here on CSS-Tricks.
The line that goes through it needs to depend on the height of the HTML content in each of those boxes. The boxes are set on a CSS grid, but they can and should still expand as needed for titles and such. Rather than try to SVG this somehow, the line is essentially stitched together though border and border-radius on individual boxes. To make it line up, I occasionally had to nudge them around with transform.
There was some z-index involved too. It was fun making mistakes along the way:
Cards
I’m kinda in love with native scroll snapping. The cards kinda have a fun animation on desktop, revealing the entire card on hover/focus, and then on mobile you can see the whole card, but are easy to thumb through:
Thanks, Amelia!
The design called for these curved line separators:
I have a small degree of confidence with the SVG path syntax, so I took the first crack at it. I was able to design it in a way that it could draw that line OK and keep the stroke at the desired width, but it didn’t scale quite right.
I brought in SVG expert Amelia Bellamy-Royds to help me get it right. Feel free to inspect the site to see how it was done. It involves masking and nested SVGs and rectangles and transforms and all sorts of fun stuff. Amelia actually created four variations of the code and carefully noted all the pros and cons of each one. Ultimately, we went with this:
Another thing Amelia helped with was the “circle of text” design element. Kylie had these instances mocked out and I thought they were so cool and I definitely wanted to pull it off. There is a really elaborate way to do it by splitting the characters in to spans and transforming them, but that’s a bit messy compared to SVG’s . I knew I wanted to go the SVG route, but perhaps abstract it away into a reusable component so that it wasn’t a heaping pile of code every time I want to use one.
It occurred to me that a web component might be the best way to go here because I can kind of invent the API myself. What I wanted a circle-of-text component to do:
Pass in the text to set on the circle
Declare the radius of the circle
Rotate the circle so I can start the text at any point along the circle
That makes perfect sense as a web component:
<circle-text r="3em" rotate="-90deg">
CSS is super fun & cool & I like CSS!!!
</circle-text>
My expertise with web components is limited, so I reached out to Amelia again who is great both with web components and SVG—a perfect match! This is what she was able to do, which I easily integrated easily into this design.
Thanks, Ana!
Another design thing that Kylie cooked up that I was a bit perplexed by was this line:
I thought maybe SVG again, but I really wanted to nestle regular HTML content in there nicely. I was hoping to pull it over with borders or something CSS-y. I reached out to Ana Tudor who is fantastic at tricky design situations and solving them with native browser tech. Ana was able to whip up a good solution here using multiple gradient backgrounds in the main area and a border for the top right bit that flies off.
Fonts are a unique part of the loading experience of websites in that their presence (or lack of), how they appear, and how they change all play major roles in the perceived performance of the page.
I’ve had the good fortune of being able to chat with Zach Leatherman about font loading before, but I still don’t feel entirely comfortable with what the best practices are in any given situation. For this design of CSS-Tricks, I made the call to use the system font stack for most of the body copy. That has the major benefit of being instantly available to render and aesthetically seems to work well on a technical site, not to mention generally pairing well with Rubik, our header font.
But we still needed to deal with Rubik. There will be an upcoming article from Zach going into this in more details, but the gist is:
Create a minimal subsetted version of Rubik that handles the majority of usage
it
Use it with @font-face using font-display
Load a more robust version in an async second stage
Nice job everyone that worked on the @css relaunch!
Look at those web fonts showing up on that 2.09s Fast 3G first render ?
The Forums is such a complicated area of the site to design and maintain, what I’ve done is just loaded the default bbPress styling for them, instead of trying to override things or start from scratch. I think that’ll be the best route going forward.
There is a Gallery section of this site, but I’m not even linking to it anymore as we didn’t really keep it up to date very well nor did it get used much. The URL’s still work though. Maybe it can make a return someday, but for now, I’m enjoying the reduction of some technical and content debt.
Tech stack
It’s somewhat boring. It’s about the same thing I’ve done forever. It’s a stock install of WordPress with a custom theme, a dozen or so plugins, and a bit of custom-coded functionality, like having the images powered by Cloudinary. It’s running on a custom Media Temple-built box so it can have PHP 7 and MySQL 5.6, plus a firewall that also acts as a CDN. It’s nice to have a pretty snappy foundation, so it’s on me as a front-end dev to keep it that way.
I used SVG for the icons, Sass for the styling, and Babel to write jQuery-based functionality in ES6. I wrote up a Gulp file to do all that processing and run the local BrowserSync dev server. Local WordPress via Local by Flywheel.
I’m actually pretty happy with the stack as it felt quick and productive to me. But I admit, part of me wishes I dug a little harder into new tech, like building webpack-based processing or trying to go all-in on a server-rendered and React-powered headless WordPress via GraphQL kinda thing. That likely would have tripled the dev time for questionable benefits. I would have just done it because it would have been fun and possibly open some interesting future-doors.
My last regret is that I wish I had spun up a real pattern library system from the start. I think I did OK in breaking things up into reusable parts, but the site isn’t truly componentized. As I approached the finish line, I started to see how this could have gone a bit smoother for me should I have worked with true components that accepted data and had variations and such. Native PHP isn’t great for that, so it would have forced me into some kind of templating system, and I probably wouldn’t have regretted it. If I stay in PHP next time, maybe I’d use something like Timber and Twig for all the components, and then Fractal for the pattern library since it supports Twig. I kind of dig the way Timber abstracts the data stuff from the views.
I hadn’t heard of this app until now, but check out Project Wallace:
Project Wallace is a project aimed at gaining insights in your CSS over a longer period of time. It started a couple of years ago as a frustration with existing CSS analyzers that only do a one-time only analysis. As time went by, more and more features were added and now Wallace is place to go for developers who want to know if their complexicity has increased or for a designer who wants to know if all the correct colors and fonts are being used.
Bart Veneman set it up to watch CSS-Tricks, and you can see a before/after comparison and charts over time. Bart blogged about the numbers for us as well. Thanks Bart!
The true usefulness of CodePen Embed Themes came out here. The whole point of an embed theme is that you can use them to match the design of where the Pens will be embedded, and if you need to change that design, you can change them all in one fell swoop. There are probably thousands of embedded Pens on this site, and they all got updated at once with one theme change.
There are a few special things that I’ve done with CodePen embeds on this site:
The are resizable from the bottom right corner. Used jQuery. Like this.
They have a placeholder height. When you embed a Pen, you can choose how tall you want it to be. That’s how tall the will come in as. But I’ve adjust it so that the that is there before the iframe comes in will be that same height, so there is no reflow jank.
We’re gonna bring that feature to CodePen itself real soon. Notice in that RegEx above I’m also forcing the theme id. That way, all embedded Pens definitely have the correct theme, even if we forget.
Achievement unlocked: The custom scrollbar is the new feature that everyone either loves or hates
If there has been one constant in every CSS-Tricks design, it’s that there’s at least one feature people either love or hate. This time, I’m happy to announce it’s the custom scrollbar. In a sense, it’s for myself. I manually use scrollbars quite a bit and it feels both fun and highly usable to grab onto this big beefy chunk of pink love.
It’s also a little inspired by VS Code, which features a pretty beefy scrollbar itself:
There are general usability considerations about custom scrollbars for sure, but I don’t feel like they’ve been breached too heavily here, if at all. I’ve heard some “don’t mess with my browsers UI” feedback, which I sorta get, but does that mean we shouldn’t style any form controls, or even use CSS at all? (LOL.) And don’t scrollbars come from the system, not the browser?
Anyway, I’m not faking them or anything. I’m just using ::-webkit-scrollbar and friends. There is official scrollbar styling stuff on the way, per the CSS specs. I didn’t use any of that stuff/ I think I’ll wait for at least one browser to support it.
We have plenty of bug fixing and polishing to do still on this design. If you’ve emailed or tweeted or communicated with us in some way about it, I’ve probably seen it and have been log it all to make sure it’s all addressed the best we can. Plus stay tuned for some fun new features!
Tim Kadlec on the issues surrounding poor web performance and why it’s so important for us to care about making our sites as fast as possible:
Poor performance can, and does, lead to exclusion. This point is extremely well documented by now, but warrants repeating. Sites that use an excess of resources, whether on the network or on the device, don’t just cause slow experiences, but can leave entire groups of people out.
There is a growing gap between what a high-end device can handle and what a middle to low-end device can handle. When we build sites and applications that include a lot of CPU-bound tasks (hi there JavaScript), at best, those sites and applications become painfully slow on people using those more affordable, more constrained devices. At worst, we ensure that our site will not work for them at all.
Forget about comparing this year’s device to a device a couple of years old. Exclusion can happen on devices that are brand-new as well. The web’s growth is being pushed forward primarily by low-cost, underpowered Android devices that frequently struggle with today’s web.
As Tim mentions at the end of that piece though, it’s easy to forget web performance and it’s sometimes hard to make the case for making a website fast. It’s often seen as a nice-to-have instead of as a core feature in and of itself, like semantic markup and accessibility compliance.
I’m optimistic that the conversation surrounding this topic is improving things though. Having tools like Lighthouse built straight into the browser makes things easier and the abundance of testing tools such as Calibre gives us insights into exactly what and where issues might be. But we also need to remember that this isn’t solely a technical problem — it’s an ethical one, too.
As the Internet has grown and become more common place, it has become a gigantic instrument of change in terms of the way in which we interact with the world and each other.
Like many people, my intro to web development at school was kind of bleak. Our school ICT (Information Computing Technology) lessons taught us very little, using Dreamweaver (back when it was a Macromedia product) as a platform to visually edit a personal website with the biggest lesson being “what is a hyperlink”. We didn’t even view the HTML source of our own websites!
So my education around HTML and CSS came largely from messing around with the “view source” option in websites. I learned through copy-pasting bits and pieces together to create my own websites and downloading templates for bootstrap, before I knew what bootstrap actually was.
Why Am I Telling You This?
Having recently surveyed my Twitter followers (it’s an exact science ?), I discovered that a large chunk of people (43% of the people who voted), knew little to nothing about Web Standards and only 5% of those who voted were active contributors.
[poll] Are you a web developer or tinkerer? Have you built anything for the web before?
Whether you’re a total beginner or full-time web dev, please answer this question > What do you know about Web Standards?
When you look at the ways in which people learn to do web development, it is totally understandable that this might be the case. The volume of online tutorials, boot-camps and online resources for learning how to build websites has lead to an increasing amount of self-taught web developers (like me) building stuff for the web.
This is one of the great successes of the Internet; anyone can learn almost anything? —? and there being more and more resources for learning outside of academia is really positive in terms of lowering barriers to access web development as a career.
Even with free resources online there are still a number of barriers in learning how to be a web developer. I’m not saying these don’t exist — they really do — and we should be doing more as a community to tackle these.
But with the diversification of learning processes comes several challenges, including information overwhelm and knowledge gaps.
When learning how to build web-flavored things, it is very easy to get wrapped up in “how do I build the thing?” This can result in not equally considering the “why should I build it this way?” or “what are all the options for building the thing?”
Consequently, it is equally as easy to become overwhelmed with the many number of ways to solve your web related problem. This can result in picking the first solution from the results of an internet search, without considering whether it is the better (in terms of most robust, accessible and secure) of the options available.
Web Standards and the documentation to support Web Standards, provide a lot of insight about ‘the why’ and ‘the what’ of the world wide web. They are a fantastic resource for any web developer and help you to build things for the web that are functional, accessible and cross-compatible.
This post is designed to help anyone with an interest in the web who wants to get to know more about web standards. We will cover:
An introduction to web standards (what are they, why do they exist and who makes them);
How to navigate and make use of standards in your work;
Ways you can get involved in contributing to new and existing standards.
Let’s begin our introduction to web standards by asking, “Why do we need standards for the web?”
The World Wide Web Before Standards
We can think of the world wide web as an information ecosystem. People create content that is fed into the web. This content is then passed through a browser to allow people to access that information.
Before Web Standards, there weren’t many fixed rules for any part of this system; no formal rules as to how the content should be created, nor any requirements in terms of how a browser should serve up that information to the people that are requesting it.
So, in a way, the web operated a bit like that children’s toy where you have to sort the different shaped blocks into the correct holes. In this analogy, the different types of browsers are the different shaped holes and the content or websites, are the brightly colored blocks.
The sorting shape toy and its colorful blocks (Large preview)
In the past, as a content creator you would make a website to fit the browser it would be intended for. For example, you would create an IE-shaped block to be able to pass this through the Internet Explorer hole.
This meant that this website block you had created would only fit through that one hole and you would need to rebuild your content into other shapes for it to be viewed using any of the other browsers.
Fitting an IE-sized block into an IE-sized hole (Large preview)
Developers in the 90s would often have to make three or four versions of every website they built, so that it would be compatible with each of the browsers available at the time. And what is more, browser makers in attempts to better their competition would introduce “features” that diversified their approach from their competitors.
In the beginning, it was probably fairer to say our Internet browser to content-matching toy looked more like this:
A sorting toy with three round holes and one square hole (Large preview)
This was because browsers were built to handle pretty much the same stuff, which was largely text-based content. So, for the most part, a website block would fit through the majority of the holes, with the exception of maybe one where it might fit — but not perfectly.
As the browsers developed, they begin to add features (e.g. by changing their shape) and it became more and more difficult to make a block that would pass through each of the browser holes. This even meant that a block that could once fit through one particular hole, didn’t fit through that hole any longer; adding these features into the browser would often result in poor reverse compatibility.
A hole that changes over time means all blocks will not always fit through. (Large preview)
This was really damaging for some developers. It created a system in which compatibility was limited to the content creators that could afford to continuously update and refactor their websites for each of the available browsers. For everyone else, every time a new feature or version was released, there was a chance your website would no longer work with that browser.
Web standards were introduced to protect the web ecosystem, to keep it open, free and accessible to all. Putting the web in a protective bubble and disbanding with the idea of having to build websites to suit specific browsers.
When standards were introduced, browser makers were encouraged to adhere to a standardized way of doing things — resulting in cross-compatibility becoming easier for content makers and there no longer being the need to build multiple versions of the same website.
Note: There are still a number of nuances about cross-compatibility amongst browsers. Even today, over 20 years since standards were introduced, we aren’t quite at “one-size fits all” just yet.
Here’s a quick look at some of the key moments in the history of web browser development:
Year
Key moments
1990
Sir Tim Berners Lee releases the WorldWideWeb, the first way in which to browse the web.
1992
MidasWWW was developed as another WWW browser, which included a source code viewer.
1992
Also in 1992 Lynx was released, which was a text-based web browser, it could not display images or any other graphic content.
1993
NCSA Mosaic was released, this is the browser that is credit for being the first to popularize web browsing as it allowed the display of image embedded within text.
1995
Microsoft released Internet Explorer, previously Cello or Mosaic browsers were used on Windows products.
1996
Opera was released publicly, it was previously a research project for a Norwegian telecoms company Telnor.
2003
Safari was released by Apple, previously Macintosh computers shipped with Netscape Navigator or Cyberdog.
2004
In the wake of Netscape Navigator’s demise, Firefox was launched as a free, open-source browser.
2008
Chrome was launched by Google and within six years grew to encompass the majority of the browser market.
2015
Microsoft released Edge, the new browser for Microsoft, replacing Internet Explorer from Windows 10 onwards.
Knowing a bit about the history of standards and why they were introduced, we can start to see the benefits of having standards for the World Wide Web. But why is it important that we continue to contribute to Web Standards? Here are just a few reasons:
Keeping The Web Free And Accessible To All
Without the Web Standards community, browser makers would be the ones making decisions on what should and shouldn’t be features of the world wide web. This could lead to the web becoming a monopolized commodity, where only the largest players would have a say in what the future holds.
Helping Make Source Code Simpler; Reducing Development And Maintenance Time
As more browsers appeared and browser makers began to diversify in their approach, it became more and more difficult to create content that would be served in the same way across multiple browsers. This increased the amount of work required to make a fully compatible website, including bloating the source code for a web page. As developers today we still have to do the odd include [X script] so this works on [X web browser], but without Web Standards, this would be much worse.
Making The Web A More Accessible Place
Web standards help to standardize the way in which a website can interact with assistive technologies. Meaning that browser makers and web developers can incorporate instructions into their pages which can be interpreted by assistive technologies to maintain a common (or sometimes better) end-user experience.
Allowing For Backward Compatibility And Validation
Web standards have created a foundation which allows for new websites, that comply with standards, to work with older browser versions. This idea of backward compatibility is super important for keeping the web accessible. It doesn’t guarantee older browsers will show your content exactly as you expect, but it will ensure that the structure of the web document is understood and displayed accordingly.
Helping Maintain Better SEO (Search Engine Optimization)
Another of the major hidden benefits (at the time that Web Standards was first introduced) was that a Web Standards compliant website was more discover-able by search engines. This became more evident when the Google search became the major player in the search engine world in the early 2000s.
Creating A Pool Of Common Knowledge
A world with web standards creates a place in which a set of rules exists, rules that every developer can follow, understand and become familiar with. In theory, this means that one developer could build a website that complies with standards and another developer could pick up where the former left off without much trouble. In reality, standards provide the foundation for this; but the idea relies heavily on developers writing well-documented code.
Who Decides On What Becomes A Web Standard?
Standards are created by people. In the web and Internet space, there is a strong culture of consensus?—?which means a lot of talking and a lot of discussions.
The groups through which standards are developed are sometimes referred to as “Standards Development Organisations” or SDOs. Key SDOs in the web space include the Internet Engineering Task Force (IETF), the World Wide Web Consortium (W3C), the WHATWG, and ECMA TC39. Historically there were also groups like the Web Standards Project (WaSP), that advocated for Web Standards to be adopted by organizations.
The groups that work on the Internet and Web Standards generally operate under a royalty-free regime. That means when you make use of a web standard you don’t have to pay anyone?—?like someone who might hold a relevant patent. Whilst the idea that you might have to pay royalties to someone to build a web browser or website might seem absurd right now, it wasn’t too long ago that organizations like BT were trying to assert ownership of the concept of the hyperlink. Standards organizations like the ones listed below help keep the web free (or free from licensing fees at least).
What Is IETF?
The IETF is the grandparent of Internet standards organizations. It’s where underlying Internet technologies like TCP/IP (Transmission Control Protocol/Internet Protocol) and DNS (Domain Name System) are standardized. Another key technology developed in IETF is something called Hyper-Text Transport Protocol (HTTP) which you may have heard of.
If you’ve been paying attention to the rise of HTTP2 and the subsequent development of (UDP-based) HTTP3, this is where that work happens. Most of the work in IETF is focused on the lower levels of the Open Systems Interconnection model.
What Is W3C?
The World Wide Web Consortium (W3C) is an international community where member organizations, a full-time staff, invited experts and the public work together to develop Web Standards. Led by Web inventor and Director Tim Berners-Lee and CEO Jeffrey Jaffe, W3C’s mission is to lead the Web to its full potential.
The community was founded in 1994 at MIT (Massachusetts Institute of Technology) in collaboration with CERN. At the time of this post, W3C has 475 member companies and organizations and exists as a consortium between 4 academic institutions: MIT (USA), ERCIM (France), KEIO University (Japan) and Beihang University (China).
Work in W3C happens in working groups and community groups. Community groups are where a lot of initial innovation happens around new web technologies. New web standards can be produced by community groups but they are officially seen as “pre-standard.” Community groups are open for anyone to participate, whether or not the organization you work for or are affiliated with is a W3C member.
W3C working groups are where new web standards are officially minted. Working groups usually start with a submission of a standard, often something that is already shipping in some browsers. However, technical work on refining these standards happens within these groups before the standard goes for final approval as a “W3C Recommendation.” By the time something reaches “recommendation” phase in W3C, it’s most often implemented and in wide use across the web.
Working groups are more difficult for people who are not affiliated with a member organization to become a part of. However, you may become an invited expert to a group. One reason why working groups are a little more difficult to join and operate with more process is that they also act as an intellectual property holder? —? through joining a W3C working group organizations and companies agree to the royalty-free licensing laid out in W3C’s patent policy.
The WHATWG was originally a splinter group from the W3C. It was formed in 2007 because some browser vendors didn’t agree with the direction in which the W3C was pushing HTML. WHATWG continues to be the place where HTML is developed and evolved. However, the community of participation in the HTML specification still includes many people from the W3C community, and many WHATWG-affiliated people participate in W3C working groups.
At the time of this post, the relationship between the W3C and the WHATWG remains in flux. From a developer perspective, this doesn’t matter too much because developers can rely on resources like MDN to reflect the “truth” of which web technologies can be used in specific browsers. However, it has led to a lack of clarity, in terms of where to participate in the development of certain standards. WHATWG also has its own royalty-free license agreement? — the WHATWG participation agreement.
What Is The “Why CG”?
The Web Incubator Community Group (WICG, pronounced Why-CG) is a special community group, within W3C, where some new and emerging web technologies are discussed and developed.
If you have a great idea for a new standard, a new feature for an existing standard or a new technology you think ought to be incorporated into the web, it’s worth checking here first to see if something like it is already being discussed. If it is, great! Jump into these discussions and lend your support. If not, then suggest it! That’s what this group is for.
What Is The ECMA TC39?
Ecma is a standards organization for information and communication systems, which was founded in 1961 to standardize computer systems in Europe. Its name comes from being previously known as the “European Computer Manufacturers Association” but it is now referred to as “Ecma International? — ?European association for standardizing information and communication systems” since the organization went global in 1994.
The ECMA-262 standard outlines the ECMAScript Language Specification, which is the standardized specification of the scripting language known as JavaScript. There are ten editions of ECMA-262 that have been published (the tenth edition was published in June 2018).
TC39 (Technical Committee 39) is the committee that evolves JavaScript. Like the other groups listed here, its members are companies which include most of the major browser makers. The committee has regular meetings which are attended by delegates sent from the member organizations and also by invited experts. The TC39 operates on achieving consensus, as with many of the other groups, and the agreements made often lead to obligations for its members (in terms of future features that member organizations will need to implement). The TC39 process includes accelerating proposals through a set of stages, the progression of a proposal from one stage to the next must be approved by the committee.
What Was The Web Standards Project?
The Web Standards Project was formed in 1998 as a resistance to the feature face-off happening between browsers in the 90s; with a primary goal of getting browser makers to comply with the standards set forth by the W3C.
As the organization grew and the browser wars ended, the project began to shift focus. The group began working with browser makers on improving their standards support, consulting software makers that created tooling for website creation and educating web designers and developers on the importance of web standards. The last of these points, resulted in the creation of the InterAct web curriculum framework which is now maintained by W3C.
The Web Standards Project ceased to be active in 2013. A final blog post was created on March 1st that gives thanks to the hard work of the members and supporters of the project. In the closing remarks of this post, readers are reminded that the job of the Web Standards Project is not entirely over, and that the responsibility now lies with thousands of developers who continue to care about ensuring the web remains a free, open, inter-operable and accessible resource.
How Does Something Become A Web Standard?
So, how are standards made? The short answer is through LOTS of discussions.
Proposals for new standards usually start as a discussion within a community group (this is especially the case in W3C) or through issues raised on the relevant GitHub repository.
Across the different SDOs, there seems to then be a common theme of ascension; after the discussion has begun, it then moves up within the organization, and at each level, a deciding committee needs to reach a consensus to approve the elevation of that discussion. This is repeated until the discussion becomes a proposal, then that proposal becomes a draft and the draft goes on to become an official standard.
Now as previously mentioned, when something isn’t an official standard, this does not necessarily mean that it is not in use within some browsers. In fact, by the time something becomes a standard, it is likely to already have widespread use across many of the available browsers. In this instance, the role of the standard is part of the normalizing and adoption process for new features; it sets out the expected use for something and then outlines how browser makers and developers can conform to this expectation.
What Is TPAC?
Every year, W3C holds one massive event, a week-long multi-group meeting punctuated by a one-day unconference on the Wednesday (the Technical Plenary) combined with a meeting of its Advisory Committee (a group consisting of one person for every organization or company that is a W3C member). Put Technical Plenary and Advisory Committee together, and you get TPAC (often pronounced tee-pac). Although it’s a W3C-run event, you will often find people “from” WHATWG, IETF or TC39 here as well.
This past year, Samsung Internet people came together to participate in TPAC. We also sponsored diversity scholarships which are intended to bring people from under-represented groups to TPAC and to the Web Standards community.
My First TPAC
When I first heard the team talking about TPAC, I had no idea what to expect. After reading up about the event on the TPAC website, I signed myself up and booked my travel. Soon enough, I was on a train from London to Lyon with the team.
The banner at the front entrance of the TPAC venue (Large preview)
On arrival, I was given my Lanyard and a map of the various rooms where all the action was happening. My goal, for the three days I was attending, was to join in with as much accessibility type things as I could. Having arrived shortly after things had begun on my first day, I stood staring at a closed door for the Accessibility Guidelines working group that I wanted to sit in on. Lots of things went through my mind at that moment; “Perhaps I should wait until the break?” “No, don’t be silly, that’s still an hour away.” “Maybe I should knock?” “But wouldn’t that be more interruptive than just going in?” “Maybe I shouldn’t go in at all…” But after a few minutes, I worked up the courage to walk into the room.
There was a round table set up (which is typical of a lot of these sessions) with folks sitting at the tables with laptops; along with a number of seats arranged around the edge of the room for people to join in a more observational role. Each group also had a chat room on IRC, which anyone from the W3C membership could join (whether attending TPAC in person or not). I sat at the end of one of the tables; though I’m still not sure whether that was the proper thing to do in terms of etiquette.
The gigantic bear statue outside of the Cité Centre de Congrès de Lyon, which was the venue for TPAC 2018. (Large preview)
Initially, I was worried that my presence stuck out as much as the gigantic bear statue outside the venue; but no-one in the room paid any mind to my arrival and so the discussion continued. The group was about to move onto receiving an update on the work being done by the Silver Task Force; a community group that is trying to make the accessibility standards themselves more accessible.
It was really interesting to sit at the table for these discussions. Whilst as a first-time attendee, some of the language took some getting used to (terms like ‘conformance’ and ‘normative’); it was super nice to be inside of a room full of people who cared so much about accessibility. Many of the attendees of this working group spoke from a position of lived experience in terms of using the web with an accessibility requirement. Having spent my last three years researching accessibility requirements in digital music technology, I felt quite at home following along with the questions raised by the members of this group.
The work showcased by the Silver Task Force in this first discussion really sparked an interest for me. It felt like quite a refreshing viewpoint of how to make standards, in general, more accessible and frame them in such a way that makes for easier navigation and more tailored advice and guidance. For the following few days, I joined this (much smaller) group and had the chance to input into the conversations? —? which was really positive. Since TPAC, I have joined the community group for the Silver Task Force and have plans to join the weekly meetings in the new year.
Our Samsung group out to dinner during the week TPAC. (Large preview)
One of the nice things about TPAC (for those not chairing a working group or in some sort of leading role) was the ability to dip in and out of sessions. In amongst the things I attended over the few days I was at TPAC, there was a session from the Web Incubator community group (WICG), a developer meet-up with talks from prominent community members and demonstrations of new web technologies, and a Diversity and Inclusion for W3C meeting. An extra added bonus of going to TPAC with the Samsung Internet team was that we got to meet up with people from our team based in Korea, as well as other Samsung team members from the USA.
How To Use Web Standards In Your Work
So, now that you know the why and wherefore of Web Standards, how do you go about using web standards in your work?
Mozilla Developer Network Web Docs (MDN Web Docs)
We (the Samsung Internet team) recommend that if you’re interested in learning more about a particular web standard or technology, you start with the MDN (Mozilla Developer Network) Web Docs. Whilst MDN WebDocs started as Mozilla Project, more recently it has become the place web developers go for cross-browser documentation on web platform technologies.
Last year, Samsung joined Bocoup, Google and Microsoft and W3C to form the MDN WebDocs Product Advisory Board to help ensure that MDN maintains this position.
When you search a technology in MDN, you will see a browser compatibility matrix letting you know what the browser support is. You will also find a link to the most relevant and up to date version of the standard. When you follow a link to a standard, you will be directed to the relevant web page outlining that standard and its technical specifications. These pages can be a little overwhelming at first, as they are somewhat ‘academic’ in structure.
This is the format of a W3C web standard. It features a table of contents on the left-hand side of the page while the content is organized into very structured headers — starting with the version, reports and editors details. These headers in standards are often used to quote the relevant parts of a standard “Oh, but WCAG 2.1 1.2.2 says”; but for those without the alphanumeric memory of a hard-disk, do not fear, it is not a requirement that you have to know these things by heart.
My first piece of advice about navigating web standards is to try not to be overwhelmed by these. If you’ve come from the non-academic route into web development like me, the structure of these documents can at first seem quite formal, and the language can feel this way, too. Don’t let this be a reason to navigate away from using this as a source of information? — ?as quite frankly it is the best source of information available for finding out how and why web things work in the way that they do.
Here are some quick tips for working with web standards:
The TL;DR version
Firstly, it’s important to understand that there isn’t a TL;DR for web standards. The reason they are these long and comprehensive documents is because they have to be. There can’t be any stone unturned when it comes to exacting the structure and expected us of web development things. However (a pro tip, and a way to avoid information overwhelm), is to start with the abstract of the standard and follow any links to introductory documents. In my example, the WCAG 2.1 standard document leads us to another linked page for the Web Content Accessibility Guidelines Overview. Which provides a range of useful documentation including a quick reference guide on how to meet WCAG 2.
Make use the glossary of terms
This just helps to understand the exact meaning of words and phrases in the context of the web standard?. Let’s face it; there are so many terms out there with multiple meanings. Checking out the glossary also helps navigate some of the more academic terms.
The WCAG 2.1 Glossary section, which provides contextual definitions of words and phrases used within the standard. (Large preview)
‘Find in page’ is your friend
Once you have familiarized yourself with an overview and got an idea about the terms used within a web standard, you can start to search through the documentation for the information you require. The web standards are designed in such a way that you can consume them in a number of ways. If you seek to gain a comprehensive understanding then reading from start to finish is advised; however, you can also drop in and out of the sections as you require them. The good folks creating web standards have made efforts to ensure that referential content is linked to the source and any helpful resources are also included, which helps support the kind of “on demand” usage that is common. Take this example from WCAG 2.1:
WCAG 2.1 Guideline on Text Alternatives, in amongst the text are links to success criterions and other useful guidelines. (Large preview)
If you’re not sure?—?ask!
This community is put together from a bunch of people who care and have an investment in the future of web technologies. If you want to make sure you are adhering to Web Standards but maybe have got caught up in a language barrier, and you’re struggling to interpret what is meant by a phrase within a web standard, there are many folks out there that can help. You can raise issues through the W3C GitHub repositories for the W3C Web Standards or join the conversations about Web Standards through the suggested resources on the participate section of the W3C website.
How Do I Get Involved?
So, now that you know how to read up on your standards, what about getting involved?
Well, here are a few places to start:
GitHub repositories for standards
The WC3, TC39, WhatWG and WICG all have organizations on GitHub that contain repositories for the work they are doing. Be sure to check in on the READme, contribution guidelines and code of conduct (if there is one) before you begin. Use the issues of a repository to look at what is currently being discussed in terms of future developments for the standard it relates to.
The W3C website
Here you can look at all the working groups, community groups, and forums. It is a great place to start; if you join the organization and become a member of a community group or working group you’ll be invited to the ongoing discussions, meetings, and events for that group.
The WhatWG website
For all things WhatWG. Here there are guides on how to participate, FAQs, links to the GitHub repositories and a blog that is maintained by members of the WhatWG.
The WICG website
Whilst the Web Incubator Community Group can be found from the W3C website, they are worth a separate shout-out here as they have their own web community page and Discourse instance. (For those of you not familiar with Discourse, it allows communities to create and maintain forums for discussion.)
The TC39 standard
This is pretty comprehensive and includes links to the ways in which you can to contribute to the standard.
Speak to Developer Advocates
Many Web Developer Advocates are members of an SDO or known to be working on standards; teams like ours (the Samsung Internet Developer Advocates) are often involved in the work of Web Standards and happy to talk to developers that are interested in them. After all, standards have a huge impact on the future of the web and in turn the work that we do. So, depending on the web standard that interests you, you’ll be able to find folks like us (who are part of the work for those standards) through social media spaces like Twitter or Mastodon.
Thanks for reading! Remember that web standards impact everyone that builds or consumes websites, so the work of Web Standards is something we should all care about.
If you want to chat more about web standards, accessibility on the web, web audio or open-source adventures? —? you can find me on Twitter and I’m also on Mastodon. ?
A huge thanks to Daniel Appelquist, who helped bring this article together.
Welcome back, WDD Readers. It’s January 2019, and we’re all coming back to work bleary-eyed and bushy-tailed. Why don’t you take a moment to put off wor… I mean get inspired by these new portfolios? We’ve got a fair bit of variety in aesthetics and strategies this month. Enjoy.
Note: I’m judging these sites by how good they look to me. If they’re creative and original, or classic but really well-done, it’s all good to me. Sometimes, UX and accessibility suffer. For example, many of these sites depend on JavaScript to display their content at all; this is a Bad Idea, kids. If you find an idea you like and want to adapt to your own site, remember to implement it responsibly.
Robbygraphics
Robbygraphics starts us off with some modernist minimalism and a touch of illustration. It’s a part of that business-friendly wave of design that I mentioned recently, and it’s a fine example of the trend.
My only critique is that the hero image on the home page could really be SVG. PNG is great and all, but large vector illustrations are better served in a vector format, these days.
Platform: WordPress
O
Yup, this designer is named “O”. The one-page portfolio is a bare-bones as the name, with simple typography, screenshots, and red blobs that change shape as you scroll.
I’m not a huge fan of animations that absolutely depend on having smooth scrolling turned on (I keep it turned off), but overall, it’s a good-looking site.
Platform: Custom CMS built on Ruby (I think)
Florent Biffi
Florent Biffi stands out in the crowd with bold text on a sort of… wrinkled cloth texture? Look, the effect, while simple, is fairly striking. I haven’t seen it a lot. The rest of the site is fairly standard sans-serif fare with thick headings and occasionally-overlapping elements. That first striking visual is enough to keep a user scrolling all on its own, and that’s the point, isn’t it?
Platform: Static Site
Timo Kuilder
Timo Kuilder makes new-age-ish cip-art-ish illustrations that look… way better than that sounds. So of course the whole site leans into the aesthetic, using a light masonry collage of the work to sell their services.
Platform: Cargo Combined with Backdrop, apparently.
D7 Creative
D7 Creative takes an interesting and highly interactive approach by making every section of their one-pager look almost completely different. I mean, that’s one way to showcase your range, right? Plus, they have a fully functioning game of Snake that you can play.
It’s not the most visually consistent approach, but rules are made to be broken eventually.
Platform: WordPress
Playground
Playground is a fusion of the corporate-friendly aesthetic (including lots of solid blue and red) with the constantly-overlapping elements of more post-modernist web design. There’s also plenty of animation, but it’s understated enough that it’s not too distracting. I like this style a lot, but don’t make me come up with a name for it, please.
Platform: Static Site
Camilo Alvarez
Camilo Alvarez hit me right in the nostalgia. I had a phase where I used a sort of “film grain” effect for almost everything. Well the film grain is back with an animated vengeance, overlaid on a sort of post-minimalist design. As with most of these sites, it’s a bit JS-heavy for me, but it’s pretty and it’s making me feel young again, so it’s here on the list.
Platform: WordPress
Fly Digital
Fly Digital is going very minimalist, and reminds me of the ’90s in a good way. I normally wouldn’t recommend a handwriting typeface for body text, but when there’s this little text, you can get away with it. Though the text could be bigger. And I wouldn’t blur out those client logos on the home page, even if you are going to unblur them on hover.
Otherwise, the site feels handmade and old-fashioned without feeling amateurish. It’s a fine line to walk, but they’re doing it.
Platform: WordPress
epo
Where other sites merely feel modern, epo feels super modern. It’s like flat design had a baby with a corporate color palette. It’s like easy listening music in web design form. None of that is criticism, mind you. If it gets them the clients they want, then it’s doing the job right.
Platform: WordPress
Breadhead
Breadhead brings us some of that classic elegant dark-layout minimalism that we don’t see nearly often enough these days. Thin type, illustrations, and an all around classy feel are what will make this design stick in your brain for a while.
Platform: Static Site
Marijn Bankers
Marijn Bankers’ portfolio reminds me, at first, of an animated spa brochure. You know, the whites and pastels, then thin type, the thinly-lined UI elements, everything. As you dive into the site, it feels more like an architecture firm.
And then it all makes sense when you look through the portfolio. His clients are exactly those who would appreciate the aesthetic. I keep highlighting websites with this approach for the simple reason that it works. Portfolios tailored to the clients just work.
Platform: Static Site
Anvar Shoe
Anvar Shoe’s portfolio eschews the aesthetic fusion we’ve been seeing lately for a site that looks positively post-minimalist. It’s artsy all the way with a mostly-one-column layout and effects that, once again, kind of depend on smooth scrolling to look good.
Platform: Static Site
YRS Truly
YRS Truly is an interesting case. I’ve previously featured portfolio sites that mimic an operating system, but this one fuses the “windows” gimmick with the general structure and layout of a normal two-column website. It’s odd, but it works, and it uses UI conventions that most of us are used to.
Platform: WordPress
Cleverbirds
Cleverbirds’ art portfolio is highly presentational and animated. No points for accessibility here, but if you want some creative and pretty ideas for monochromatic web graphics, look no further. It’s on the list because it’s pretty, and that’s that.
Platform: Static Site
João Pereira
João Pereira’s portfolio is just plain pretty; I love the use of color. While the text could use a little more contrast in places, it’s just generally gorgeous. Plus you can click the triangles in the background to see a list of his skills.
Sure, that’s not intuitive, but it’s better than any “skill progress bars” I’ve ever seen.
Platform: Static Site
Kristopher Bolleter
Kristopher Bolleter’s portfolio leads with text that says, “No cliché slogans, just work that speaks for itself.” Well, he might not know how often I use the phrase “speaks for itself”, right?
All kidding aside, he lives by that motto, presenting all his featured work on one page in old-fashioned iMac illustrations. Man it’s been a while since I’ve seen that instead of the mockup mobile devices. The whole thing isn’t very flashy, but it’s effective and serviceable.
Platform: Hugo
Adrien Laurent
Adrien Laurent brings us back to the flashy stuff with their portfolio. It’s post-modernist, presentational, pastel, and loaded with animation (I couldn’t think of an animation-related word that started with “p”).
Platform: Static Site
Translation
Translation takes a generally bold approach, starting with their overall aesthetic, and on to their assertion that “The world doesn’t need another ad agency.” With a monochromatic palette and really big headings, the whole idea seems to be to blast your brain and hope it sticks. Well it’s working for me.
Platform: Static Site
Anthony Florio
Anthony Florio’s portfolio is fairly standard modernist, with light artsy touches in the form of randomly placed illustration. And it wouldn’t be a photographer’s portfolio without some sort of collage.
Do you ever miss the classic grid full of thumbnails? Nah. Me neither.
Platform: Static Site
Corn Studio
No portfolio list of mine is truly complete without someone using yellow right. In this case, it’s the ever-so-appropriately named Corn Studio gracing us with the classic yellow and black, combined with some highly animated minimalism. It’s flat, it’s pretty, and it’s pretty good.
I recently came across an interesting sliced disc design. The disc had a diagonal gradient and was split into horizontal slices, offset a bit from left to right. Naturally, I started to think what would the most efficient way of doing it with CSS be.
Sliced gradient disc.
The first thought was that this should be doable with border-radius, right? Well, no! The thing with border-radius is that it creates an elliptical corner whose ends are tangent to the edges it joins.
My second thought was to use a circle() clipping path. Well, turns out this solution works like a charm, so let’s take a close look at it!
Note that the following demos won’t work in Edge as Edge doesn’t yet support clip-path on HTML elements. It could all be emulated with nested elements with overflow: hidden in order to have cross-browser support, but, for simplicity, we dissect the clip-path method in this article.
Slicing a disc into equal parts
As far as the HTML structure goes, we generate it with a preprocessor to avoid repetition. First off, we decide upon a number of slices n. Then we pass this number to the CSS as a custom property --n. Finally, we generate the slices in a loop, passing the index of each to the CSS as another custom property --i.
- var n = 8;
style :root { --n: #{n} }
- for(var i = 0; i < n; i++)
.slice(style=`--i: ${i}`)
Moving on to the CSS, we first decide upon a diameter $d for our disc. This is the width of our slices. The height is the diameter divided by the number of items calc(#{$d}/var(--n)).
In order to be able to tell them apart, we give our slices dummy backgrounds determined by parity.
To get the disc shape we use a circle() clipping path having the radius $r equal to half the diameter .5*$d and the central point dead in the middle of the assembly. Since we set this clip-path on the slices, the position of the central point for each slice is relative to the slice itself.
Horizontally, it’s always in the middle, at 50% of the slice. Vertically, it needs to be in the middle of the assembly, so that’s where the total number of items and the item’s index which we’ve passed as CSS variables from the preprocessor code come into play.
In the middle of the assembly means at half the height of the assembly from the top of the assembly. Half the height of the assembly is half the diameter .5*$d, which is equivalent to the radius $r. But this value is relative to the whole assembly and we need one that’s relative to the current slice. In order to get this, we subtract the vertical position of the current slice relative to the assembly, that is, how far the top of the current slice is relative to the top of the assembly.
The first slice (of index --i: 0) is at the very top of the assembly, so the amount we subtract in this case is 0.
The second slice (of index --i: 1) is at one slice height from the top of the assembly (the space occupied by the first slice), so the amount we subtract in this case is 1 slice heights.
The third slice (of index --i: 2) is at two slice heights from the top of the assembly (the space occupied by the first and second slices), so the amount we subtract in this case is 2 slice heights.
In the general case, the amount we subtract for each slice is the slice’s index (--i) multiplied by one slice height.
The one little problem in this case is that it also cuts off the top of the first slice and the bottom of the last slice. This may not be an issue in some cases and we can always reset the padding-top on the :first-of-type and the padding-bottom on the :last-of-type to 0:
However, we also have a one-line solution to this problem of creating gaps in between the slices: add a mask on the container!
This mask is a repeating-linear-gradient() which creates transparent stripes of the thickness of the gap $g, repeats itself after a slice height and is limited to the disc diameter $d horizontally and to the disc diameter $d minus a gap $g vertically (so that we don’t mask out the very top and the very bottom as we also did initially with the padding approach).
In order to have a continuous gradient background, we need to give this background a height equal to that of the disc and set its vertical position relative to each slice such that it always starts from the top of the assembly… wherever that may be located relative to the slice.
The top of the first slice (of index --i: 0) coincides with that of the assembly, so our background starts from 0 vertically.
The top of the second slice (of index --i: 1) is 1 slice height below that of the assembly, so its background starts from 1 slice height above vertically. Since the positive direction of the y axis is down, this means our background-position along the y axis is calc(-1*var(--h)) in this case.
The top of the third slice (of index --i: 2) is 2 slice heights below that of the assembly, so its background starts from 2 slice heights above vertically. This makes our background-position along the y axis is calc(-2*var(--h)).
We notice a pattern here: in general, the background-position along the y axis for a slice is calc(-1*var(--i)*var(--h)).
But if we want a left to right gradient, then our background isn’t continuous anymore, something that becomes really obvious if we tweak the stop positions a bit in order to have abrupt changes:
In order to fix this issue, we set the offset as a Sass variable $o, set the horizontal background-size to the slice width (100% or $d) plus twice the offset and make sure we attach the background for the slices that move to the left (in the negative direction of the x axis, so by -$o) on the left side of the slice (background-position along the x axis is 0%) and for the slices that move to the right (in the positive direction of the x axis, so by $o) on the right side of the slice (background-position along the x axis is 100%).
It also works for images, though in this case we need to remove the second background-size value so the image doesn’t get distorted, which leaves us with the caveat of getting vertical repetition if the image’s aspect ratio is greater than calc(#{$d} + #{2*$o}) : #{$d}. This isn’t the case for the square image we’re using below, but it’s still something to keep in mind.
Another thing to note is that above, the top of the image is attached to the top of of the assembly. If we want the middle of the image to be attached to the middle of the assembly, we need to tweak the vertical component of the background-position a bit.
First off, to attach the middle of the image to the middle of a slice, we use a background-position value of 50%. But we don’t want the middle of the image in the middle of each slice, we want it in the middle of the assembly for all slices. We already know the distance from the top of each slice to the vertical midpoint of the whole assembly – it’s the y coordinate of the clipping circle’s central point:
--y: calc(#{$r} - var(--i)*var(--h));
clip-path: circle($r at 50% var(--y))
The distance from the vertical midpoint of each slice to that of the assembly is this value --y minus half a slice’s height. So it results that the background-position we need along the y axis in order to have the vertical midpoint of the image attached to that of the assembly is calc(50% + var(--y) - .5*var(--h)).
This means our slices don’t have the same height anymore. For example, the first one could have a unit height, the second one twice this height, the third one three times this height and so on…
The added heights of all these slices should equal the disc diameter. In other words, we should have the following equality:
h + 2*h + 3*h + ... + n*h = d
This can also be written as:
h*(1 + 2 + 3 + ... + n) = d
which makes it easier to notice something! Within the parenthesis, we have the sum of the first n natural numbers, which is always n*(n + 1)/2!
Just like in the case of equal slices, the y coordinate of the central point of the clipping circle() is the disc radius $r minus the distance from the top of the assembly to the top of the current slice. This is the sum of the heights of all previous slices.
In the case of the first slice (--i: 0), we have no previous slice, so this sum is 0.
In the case of the second slice (--i: 1), we only have the first slice before and its height is the unit height (--h).
In the case of the third slice (--i: 2), the sum we want is that between the height of the first slice, which equals the unit height and that of the second slice, which is twice the unit height. That’s calc(var(--h) + 2*var(--h)) or calc(var(--h)*(1 + 2)).
In the case of the third slice (--i: 3), the sum is that between the height of the first slice, which equals the unit height, that of the second slice, which is twice the unit height and that of the third slice, which is three times the unit height. That’s calc(var(--h) + 2*var(--h) + 3*var(--h)) or calc(var(--h)*(1 + 2 + 3)).
Now we can see a pattern emerging! For every slice of index --i, we have that the added height of its previous slices is the unit height --h times the sum of the first --i natural numbers (and the sum of the first --i natural numbers is calc(var(--i)*(var(--i) + 1)/2)). This means our clip-path value becomes:
circle($r at 50% calc(var(--h)*var(--i)*(var(--i) + 1)/2))
We add the offset back in and we have the following result:
Sadly, having incremental slices means the repeating-linear-gradient() mask method of creating gaps cannot work anymore. What still works however just fine is the vertical padding method and we can set the padding values such that the top one is 0 for the first slice and the bottom one is 0 for the last slice.
For a gradient background, the main idea remains the same as in the case of the equal slices. There are just two things we need to take into account.
One, the background-position along the y axis is minus the distance (in absolute value) between the top of the assembly and the top of the current slice. This distance isn’t calc(var(--i)*var(--h)) like in the case of equal slices of height --h anymore. Instead it’s, as computed a bit earlier, calc(var(--i)*(var(--i) + 1)/2*var(--h)). So the background-position along the y axis is calc(-1*var(--i)*(var(--i) + 1)/2*var(--h)).
And two, we want our background clipped to the content-box so that we keep the gaps, but we need to keep the background-origin to its initial value of padding-box so that our gradient stays continuous.
For an image background whose midpoint is attached to the middle of our assembly, we need to take into account the fact that half a slice height isn’t the same value for all slices anymore. Now the height of a slice is calc((var(--i) + 1)*var(--h)), so this is the value we need to subtract in the formula for the y component of the background-position.
We can also slice our disc along the other direction. This means removing the flex-direction: column declaration from the container and letting the flex-direction be the initial one (row), switching the width and the height, the x and y coordinates of the circular clipping path’s central point, the direction along which we shift the slices, the dimensions and x and y positions of the masking gradient, which we also need to rotate so that it goes along the x axis.
body {
/* same as before */
--w: calc(#{$d}/var(--n));
mask: repeating-linear-gradient(90deg,
red 0, red calc(var(--w) - #{$g}),
transparent 0, transparent var(--w))
calc(50% - #{.5*$g}) 50% / calc(#{$d} - #{$g}) #{$d}
}
.slice {
/* same as before */
width: var(--w); height: $d;
transform: translatey(calc(var(--sign)*2%));
background: hsl(36, calc(var(--parity)*100%), calc(80% - var(--parity)*30%));
clip-path: circle($r at calc(#{$r} - var(--i)*var(--w)) 50%)
}
This gives us equal vertical slices with alternating backgrounds:
For incremental slices, we combine the incremental case with the vertical case, which means swapping the values we have for the previous incremental case along the two axes:
To create the gaps, we use the padding method. But since we’re now in the vertical case, we need horizontal paddings, on the left and on the right and to make sure the padding-left for the first slice is 0 and the padding-right for the last slice is also 0:
box-sizing: border-box;
padding:
0 /* top */
calc((var(--n) - 1 - var(--i))*#{$g}/var(--n)) /* right */
0 /* bottom */
calc(var(--i)*#{$g}/var(--n)) /* left */;
background:
hsl(36, calc(var(--parity)*100%), calc(80% - var(--parity)*30%))
content-box
Again, we generate it with a bit of Pug, the total number of items being the product between the number of columns and the number of rows. For simplicity, we keep the number of rows and the number of columns equal.
- var n = 8, m = Math.pow(n, 2);
style :root { --n: #{n}; --i: 0; --j: 0 }
- for(var i = 1; i < n; i++) {
| .tile:nth-of-type(#{n}n + #{i + 1}) { --i: #{i} }
| .tile:nth-of-type(n + #{n*i + 1}) { --j: #{i} }
- }
- for(var i = 0; i < m; i++)
.tile
We’ve also passed the column and row indices (--i and --j respectively) to the CSS.
Since we’re in the 2D case, we switch from using a 1D layout (flex) to using a 2D one (grid). We also start with the disc diameter $d and, given the number of columns is equal to that of rows (--n), our disc gets divided into identical tiles of edge length --l: calc(#{$d}/var(--n)).
To create the gaps in between the tiles, we use the padding approach on the .tile elements and combine the horizontal and vertical cases such that we have the padding-top for the first row is 0, the padding-left for the first column is 0, the padding-bottom for the last row is 0 and the padding-right for the last-column is 0.
padding:
calc(var(--j)*#{$g}/var(--n)) /* top */
calc((var(--n) - 1 - var(--i))*#{$g}/var(--n)) /* right */
calc((var(--n) - 1 - var(--j))*#{$g}/var(--n)) /* bottom */
calc(var(--i)*#{$g}/var(--n)) /* left */
Note that we’ve used the row index --j for the top to bottom direction (vertical paddings) and the column index --i from the left to right direction (lateral paddings).
To get the disc shape, we again combine the horizontal and vertical cases, using the column index --i to get the x coordinate of the circular clipping path’s central point and the row index --j to get its y coordinate.
clip-path:
circle($r at calc(#{$r} - var(--i)*var(--l))
calc(#{$r} - var(--j)*var(--l)))
For a gradient background, it’s again combining the horizontal and the vertical cases and taking into account that here we have no offset at this point, which means the background-size is the disc diameter $d along both axes.
For an image background, we remove the second background-size value so we prevent the image from getting stretched if it’s not square. We also adapt the code for attaching the image’s midpoint to that of the grid from the 1D case to the 2D case:
For a gradient background, we adapt the equal tiles version to the incremental case. This means tweaking the background-position as we did before for the incremental slices, only this time we do it along both axes, not just along one:
There are probably more variations we could be coming up with, but we’ll stop here. If you have more ideas on how to push this further, I’d love to hear about them!
Every week users submit a lot of interesting stuff on our sister site Webdesigner News, highlighting great content from around the web that can be of interest to web designers.
The best way to keep track of all the great stories and news being posted is simply to check out the Webdesigner News site, however, in case you missed some here’s a quick and useful compilation of the most popular designer news that we curated from the past week.
Note that this is only a very small selection of the links that were posted, so don’t miss out and subscribe to our newsletter and follow the site daily for all the news.
Design Accessible Maps
Why are all Apple Products Photographed at 9:41am?
For the Freelancers: Here are the Most Valuable Freelancing Resources
Designing for Less
Over Instagram
Dimensions.Guide
Designers are Too Busy to Design
How to Create a WordPress Site: The Ultimate Beginner’s Guide 2019
Why Medium is no Longer the Go-to Platform for Programming Blogs
The Best and Worst Identities of 2018, Part 7: The Click-bait-iest Linked
Misrepresenting the Truth to Make Traveling Easier
CleanMock – Stunning Design Mockups Right from your Browser
Design Audits – What are They and Why You Need One
Are Users Really Stupid?
Aesthetics Vs. Function
Design is not Saving the World
Css Broken Grid Generator
What I’ve Learned After a Year of Non-stop UI Grinding
Is your Design Portfolio Hurting You?
How to Use Interactive Elements in Email
70’s Graphic Design Inspiration
8?? Little Tricks to Grow your Design Career
Exploring the Elegance of Line Typography in Web Design
Designing from Scratch: A Blank Canvas
In Praise of Doing Nothing: How to Turn Boredom into Brilliant Ideas
Want more? No problem! Keep track of top design news from around the web with Webdesigner News.
There are so many tools out there to help you pick colors. I totally get it! It’s hard! When colors are done well, it’s like magic. It adds a level of polish to a design that can really set it apart.
Let’s look at some, then talk about this idea some more.
Generating random colors won’t guarantee pleasing palettes, especially if a bunch of random colors are paired together. PleaseJS can help build color schemes that work together. You provide it a base color and other options (like what type of color scheme) and it spits out colors for you.
generates attractive colors by default. More specifically, randomColor produces bright colors with a reasonably high saturation. This makes randomColor particularly useful for data visualizations and generative art.
It doesn’t claim to make multiple colors part of a cohesive theme aside from passing in a base hue or luminosity.
…they don’t exactly tell you how to use them. Steve Schoger makes a point of this, rather hilariously in a blog post. This is a perfectly lovely color palette:
But if you just pick those colors and plop them onto a design, you could end up with something like this:
You might like that, but you’d be in the minority. It’s not a refined design that gets out of the way and would be nice to use every day. Color usage is a bit more complicated than plopping five nice colors into a design. It’s variations on those and using them in tasteful ways, like this:
Masonry layout, on the web, is when items of an uneven size are laid out such that there aren’t uneven gaps. I would guess the term was coined (or at least popularized) for the web by David DeSandro because of his popular Masonry JavaScript library, which has been around since 2010.
JavaScript library. Nothing against JavaScript, but it’s understandable we might not want to lean on it for doing layout. Is there anything we can do in CSS directly these days? Sorta.
Flexbox can do vertical columns with ragged endings too
But it’s not quite as clever, because you’ll need to set a height of some kind to get it to wrap the columns. You’ll also have to be explicit about widths rather than having it decide columns for you.
But it’s doable and it does auto space the gaps if there is room.
If it’s just the uneven brick-like look you’re after, then horizontal masonry is way easier. You could probably even float stuff if you don’t care about the ragged edge. If you wanna keep it a block… flexbox with allowed flex-grow is the ticket.
CSS grid is very amazing and useful in a CSS developer’s everyday life, but it’s not really designed for masonry style layouts. CSS grid is about defining lines and placing things along those lines, where masonry is about letting elements end where they may, but still exerting some positional influence.
Balázs Sziklai has a nice example of auto-flowing grids that all stack together nicely, with pretty good horiziontal ordering:
But you can see how strict the lines are. There is a way though!
Grid + JavaScript-maniplated row spans
Andy Barefoot wrote up a great guide. The trick is setting up repeating grid rows that are fairly short, letting the elements fall into the grid horizontally as they may, then adjusting their heights to match the grid with some fairly light math to calculate how many rows they should span.
What people generally want is column-stacking (varied heights on elements), but with horizontal ordering. That last grid demo above handles it pretty well, but it’s not the only way.
Jesse Korzan tackled it with CSS columns. It needs JavaScript as well to get it done. In this case, it shifts the elements in the DOM to order them left-to-right while providing a horizontal stack using a CSS columns layout. This introduces a bit of an accessibility problem since the visual order (left-to-right) and source order (top-to-bottom) are super different & dash; though perhaps fixable with programmatic tabindex?
, kids. If you find an idea you like and want to adapt to your own site, remember to implement it responsibly.
