Una doing an amazing job of showing just how (dare I say it?) easy CSS layout has gotten. There is plenty to learn, but what you learn makes sense, and once you have, it’s quite empowering.
The demos are all together here.
Direct Link to Article — Permalink
The post 10 modern layouts in 1 line of CSS appeared first on CSS-Tricks.
You can support CSS-Tricks by being an MVP Supporter.
I’m excited to share some of the newer features in Chrome DevTools with you. There’s a brief introduction below, and then we’ll cover many of the new DevTools features. We’ll also look at what’s happening in some other browsers. I keep up with this stuff, as I create Dev Tips, the largest collection of DevTools tips you’ll find online!
It’s a good idea to find out what’s changed in DevTools because it’s constantly evolving and new features are specifically designed to help and improve our development and debugging experience.
Let’s jump into the latest and greatest. While the public stable version of Chrome does have most of these features, I’m using Chrome Canary as I like to stay on the bleeding edge.
Lighthouse is an open source tool for auditing web pages, typically around performance, SEO, accessibility and such. For a while now, Lighthouse has been bundled as part of DevTools meaning you can find it in a panel named… Lighthouse!
I really like Lighthouse because it’s one of easiest parts of DevTools to use. Click “Generate report” and you immediately get human-readable notes for your webpage, such as:
Document uses legible font sizes 100% legible text
Or:
Avoid an excessive DOM size (1,189 elements)
Almost every single audit links to developer documentation that explains how the audit may fail, and what you can do to improve it.
The best way to get started with Lighthouse is to run audits on your own websites:
Even though Lighthouse has been part of DevTools for a while now (since 2017!), it still deserves a significant mention because of the user-facing features it continues to ship, such as:
This is a subtle and, in some ways, very small feature, but it can have profound effects on how we treat web accessibility.
Here’s how it works. When you use Inspect Element — what is arguably the most common use of DevTools — you now get a tooltip with additional information on accessibility.
The reason I say this can have a profound impact is because DevTools has had accessibility features for quite some time now, but how many of us actually use them? Including this information on a commonly used feature like Inspect Element will gives it a lot more visibility and makes it a lot more accessible.
The tooltip includes:
To try this out, right-click (or Cmd + Shift + C) on an element and select Inspect to view it in DevTools.
I made a 14-minute video on Accessibility debugging with Chrome DevTools which covers some of this in more detail.
Exactly as it says on the tin, you can use Chrome DevTools to emulate vision impairments. For example, we can view a site through the lens of blurred vision.
How can you do this in DevTools? Like this:
Cmd + Shift + C).Cmd + Shift + P on Mac, Ctrl + Shift + P on Windows).We used blurred vision as an example, but DevTools has other options, including: protanopia, deuteranopia, tritanopia, and achromatopsia.
Like with any tool of this nature, it’s designed to be a complement to our (hopefully) existing accessibility skills. In other words, it’s not instructional, but rather, influential on the designs and user experiences we create.
Here are a couple of extra resources on low vision accessibility and emulation:
The Performance Panel in DevTools can sometimes look like a confusing mish-mash of shapes and colors.
This update to it is great because it does a better job surfacing meaningful performance metrics.
What we want to look at are those extra timing rectangles shown in the “Timings” in the Performance Panel recording. This highlights:
As a bonus, if you find the Largest Contentful Paint event in a Performance Panel recording, you can click on it to get additional information.
While there is a lot of golden information here, the “Related Node” is potentially the most useful item because it specifies exactly which element contributed to the LCP event.
To try this feature out:
If you want to quickly get started using DevTools to analyze performance and you’ve already tried Lighthouse, then I recommend the Performance Monitor feature. This is sort of like having WebPageTest.org right at your fingertips with things like CPU usage.
Here’s how to access it:
Cmd + Shift + P on Mac, Ctrl + Shift + P on Windows)The Performance Monitor can give you interesting metrics, however, unlike Lighthouse, it’s for you to figure out how to interpret them and take action. No suggestions are provided. It’s up to you to study that CPU usage chart and ask whether something like 90% is an acceptable level for your site (it probably isn’t).
The Performance Monitor has an interactive legend, where you can toggle metrics on and off, such as:
CSS-Tricks has already covered these features, so go and check them out!
I’m sure you noticed that I’ve been using Chrome throughout this article. It’s the browser I use personally. That said, it’s worth considering that:
In other words, keep an eye out because this is a quickly evolving space!
We covered a lot in a short amount of space!
Please check out my mailing list, Dev Tips, if you want to stay keep up with the latest updates and get over 200 web development tips! I also have a premium video course over at ModernDevTools.com. And, I tend to post loads of bonus web development resources on Twitter.
The post A Look at What’s New in Chrome DevTools in 2020 appeared first on CSS-Tricks.
You can support CSS-Tricks by being an MVP Supporter.
As a web designer, you’re constantly being bombarded with messages that tell you to acquire new skills, try new tools, and keep on hustling.
But if you’re constantly changing things up, does it do the opposite of what you originally set out to do? In other words, if you always have to start over, is it possible to ever really achieve anything?
I think it ultimately depends on why you’re making the change.
One of the reasons I despise New Year’s resolutions is because it’s change for the sake of change:
It’s a new year, so it’s time to get all hyped up about this one thing I need to change about myself!
There’s a reason why so many resolutions fail by February. When you force a change, it’s really hard to stay invested in it, especially if it’s something you’ve chosen to do because everyone else has.
Change should be driven by necessity.
That said, when it comes time to make changes as a web designer, is it ever really necessary? Or are you learning new skills, trying new tools, or switching up your client list simply because it’s what you believe you have to do?
It’s important to be open to change, but you should only invest your time, money, or effort when it’s the absolute right move for you. Here are some ways you’ll know when that’s the case:
…Round Out the Basics
If you’re a new designer and there are gaps in your education and training (and I don’t mean formally, just in general), then there’s no reason to hesitate in spending time to acquire those skills.
This doesn’t just go for basic skills as a web designer or as a coder. This also goes for skills you need to become a successful freelancer.
…Add Evergreen Skills to Future-Proof Your Position
As you move up in your career, you’ll eventually find other skills worth learning. Just make sure they’ll help you move the needle.
The best way to do that is to focus on acquiring evergreen skills that’ll always be useful to you, no matter what stage you’re at in your career or how the design landscape changes. They should also go beyond the average skill set of a designer, so they help you stand out further from the pack.
… Create a Better Situation for Yourself
The web is constantly evolving, which means that your responsibilities and skills as a web designer will have to change in order to adapt. Whenever one of these shake-ups occurs, you should either be ready to master the needed skill right away or, better yet, have been working on it beforehand.
Take, Google’s mobile-first indexing, for instance. It announced it was going to be making this shift years before website rankings were impacted. Designers had plenty of time to not only learn what was needed to design for the mobile-first web, but to get all their existing clients’ sites in shape for it.
…Your Existing Ones Are Slowing You Down
If you’re doing a lot of things from-scratch (like writing emails to clients or creating contracts), that’s a good sign your toolbox needs some improvement.
As a web designer, you should be focused on creating, not on the tedious details involved in running a business or communicating with clients. That’s just not a good use of your time. A lot of this stuff can easily be automated with tools and templates.
…You’re Turning Down Business
In some cases, it’s the right thing to say “no” to prospective clients — like when they’re a bad fit or can’t afford your rates. However, there are other times when you desperately want to be able to say “yes”, but you don’t have the capacity for the job or you’re unable to cover the full scope of what they need.
This is where new tools come in handy. For instance, let’s say you’ve been approached by a ecommerce company that not only wants you to build a new store, but also needs it fully optimized for search (it’s not the first time this has happened either). Rather than turn something like that down, you may find that the addition of an SEO tool to your toolbox is all you need to be able to say “yes”.
…You Have Extra Room in Your Budget
Obviously, you don’t want to throw away money on a bunch of tools simply because a ton of people are talking about them. But you’ll eventually get to a point where the tools that served you well in the first year of business need to be replaced.
If you get to a point where you have extra time to experiment and there’s room in your budget for upgraded tools, go ahead and assess what you currently have and test out replacement solutions that will help you work better, faster, and smarter.
…You’re Not Doing Well
“Well” here is subjective. For instance:
When something has been amiss for awhile, the last thing you should do is lean into it and hope it gets better.
…The Web is Changing
Notice a trend here? Each of these changes (skills, tools, and now business opportunities) is often driven by the fact that the web is always changing. And as the web changes, you have to be ready to evolve.
In terms of business opportunities, what you’ll realistically need to do is look for new kinds of design work as technologies make your job obsolete. Take website builders like Wix or Shopify, for example. As business owners and entrepreneurs take it upon themselves to build their own websites, more and more web designers will need to find other kinds of clients and jobs to take on.
…You Want to Diversify Your Income
This is something many web designers are doing already as they’ve discovered how beneficial it is to have predictable recurring revenue streams.
But even if you’ve already found one way to diversify and stabilize your income (like by offering website maintenance services), you may become interested in exploring other opportunities along the way. If you have the capacity to pursue them, then go for it.
As you can see, change can be a very good thing for a web designer, their business, and their clients. However, there should be a very good reason for the change and you need to prepare yourself for how it’s going to impact what you’re doing now before implementing it. No amount of change can happen without some level of sacrifice.
Featured image via Unsplash.
Back in May, I learned about Firefox adding masonry to CSS grid. Masonry layouts are something I’ve been wanting to do on my own from scratch for a very long time, but have never known where to start. So, naturally, I checked the demo and then I had a lightbulb moment when I understood how this new proposed CSS feature works.
Support is obviously limited to Firefox for now (and, even there, only behind a flag), but it still offered me enough of a starting point for a JavaScript implementation that would cover browsers that currently lack support.
The way Firefox implements masonry in CSS is by setting either grid-template-rows (as in the example) or grid-template-columns to a value of masonry.
My approach was to use this for supporting browsers (which, again, means just Firefox for now) and create a JavaScript fallback for the rest. Let’s look at how this works using the particular case of an image grid.
In order to do this, we go to about:config in Firefox and search for “masonry.” This brings up the layout.css.grid-template-masonry-value.enabled flag, which we enable by double clicking its value from false (the default) to true.
The HTML structure looks something like this:
<section class="grid--masonry">
<img src="black_cat.jpg" alt="black cat" />
<!-- more such images following -->
</section>The first thing we do is make the top-level element a CSS grid container. Next, we define a maximum width for our images, let’s say 10em. We also want these images to shrink to whatever space is available for the grid’s content-box if the viewport becomes too narrow to accommodate for a single 10em column grid, so the value we actually set is Min(10em, 100%). Since responsivity is important these days, we don’t bother with a fixed number of columns, but instead auto-fit as many columns of this width as we can:
$w: Min(10em, 100%);
.grid--masonry {
display: grid;
grid-template-columns: repeat(auto-fit, $w);
> * { width: $w; }
}Note that we’ve used Min() and not min() in order to avoid a Sass conflict.
Well, that’s a grid!
Not a very pretty one though, so let’s force its content to be in the middle horizontally, then add a grid-gap and padding that are both equal to a spacing value ($s). We also set a background to make it easier on the eyes.
$s: .5em;
/* masonry grid styles */
.grid--masonry {
/* same styles as before */
justify-content: center;
grid-gap: $s;
padding: $s
}
/* prettifying styles */
html { background: #555 }Having prettified the grid a bit, we turn to doing the same for the grid items, which are the images. Let’s apply a filter so they all look a bit more uniform, while giving a little additional flair with slightly rounded corners and a box-shadow.
img {
border-radius: 4px;
box-shadow: 2px 2px 5px rgba(#000, .7);
filter: sepia(1);
}The only thing we need to do now for browsers that support masonry is to declare it:
.grid--masonry {
/* same styles as before */
grid-template-rows: masonry;
}While this won’t work in most browsers, it produces the desired result in Firefox with the flag enabled as explained earlier.
grid-template-rows: masonry working in Firefox with the flag enabled (Demo).But what about the other browsers? That’s where we need a…
In order to be economical with the JavaScript the browser has to run, we first check if there are any .grid--masonry elements on that page and whether the browser has understood and applied the masonry value for grid-template-rows. Note that this is a generic approach that assumes we may have multiple such grids on a page.
let grids = [...document.querySelectorAll('.grid--masonry')];
if(grids.length && getComputedStyle(grids[0]).gridTemplateRows !== 'masonry') {
console.log('boo, masonry not supported 😭')
}
else console.log('yay, do nothing!')
If the new masonry feature is not supported, we then get the row-gap and the grid items for every masonry grid, then set a number of columns (which is initially 0 for each grid).
let grids = [...document.querySelectorAll('.grid--masonry')];
if(grids.length && getComputedStyle(grids[0]).gridTemplateRows !== 'masonry') {
grids = grids.map(grid => ({
_el: grid,
gap: parseFloat(getComputedStyle(grid).gridRowGap),
items: [...grid.childNodes].filter(c => c.nodeType === 1),
ncol: 0
}));
grids.forEach(grid => console.log(`grid items: ${grid.items.length}; grid gap: ${grid.gap}px`))
}Note that we need to make sure the child nodes are element nodes (which means they have a nodeType of 1). Otherwise, we can end up with text nodes consisting of carriage returns in the array of items.
Before proceeding further, we have to ensure the page has loaded and the elements aren’t still moving around. Once we’ve handled that, we take each grid and read its current number of columns. If this is different from the value we already have, then we update the old value and rearrange the grid items.
if(grids.length && getComputedStyle(grids[0]).gridTemplateRows !== 'masonry') {
grids = grids.map(/* same as before */);
function layout() {
grids.forEach(grid => {
/* get the post-resize/ load number of columns */
let ncol = getComputedStyle(grid._el).gridTemplateColumns.split(' ').length;
if(grid.ncol !== ncol) {
grid.ncol = ncol;
console.log('rearrange grid items')
}
});
}
addEventListener('load', e => {
layout(); /* initial load */
addEventListener('resize', layout, false)
}, false);
}Note that calling the layout() function is something we need to do both on the initial load and on resize.
To rearrange the grid items, the first step is to remove the top margin on all of them (this may have been set to a non-zero value to achieve the masonry effect before the current resize).
If the viewport is narrow enough that we only have one column, we’re done!
Otherwise, we skip the first ncol items and we loop through the rest. For each item considered, we compute the position of the bottom edge of the item above and the current position of its top edge. This allows us to compute how much we need to move it vertically such that its top edge is one grid gap below the bottom edge of the item above.
/* if the number of columns has changed */
if(grid.ncol !== ncol) {
/* update number of columns */
grid.ncol = ncol;
/* revert to initial positioning, no margin */
grid.items.forEach(c => c.style.removeProperty('margin-top'));
/* if we have more than one column */
if(grid.ncol > 1) {
grid.items.slice(ncol).forEach((c, i) => {
let prev_fin = grid.items[i].getBoundingClientRect().bottom /* bottom edge of item above */,
curr_ini = c.getBoundingClientRect().top /* top edge of current item */;
c.style.marginTop = `${prev_fin + grid.gap - curr_ini}px`
})
}
}We now have a working, cross-browser solution!
In a real world scenario, we’re more likely to have each image wrapped in a link to its full size so that the big image opens in a lightbox (or we navigate to it as a fallback).
<section class='grid--masonry'>
<a href='black_cat_large.jpg'>
<img src='black_cat_small.jpg' alt='black cat'/>
</a>
<!-- and so on, more thumbnails following the first -->
</section>This means we also need to alter the CSS a bit. While we don’t need to explicitly set a width on the grid items anymore — as they’re now links — we do need to set align-self: start on them because, unlike images, they stretch to cover the entire row height by default, which will throw off our algorithm.
.grid--masonry > * { align-self: start; }
img {
display: block; /* avoid weird extra space at the bottom */
width: 100%;
/* same styles as before */
}We can also make the first item stretch horizontally across the entire grid (which means we should probably also limit its height and make sure the image doesn’t overflow or get distorted):
.grid--masonry > :first-child {
grid-column: 1/ -1;
max-height: 29vh;
}
img {
max-height: inherit;
object-fit: cover;
/* same styles as before */
}We also need to exclude this stretched item by adding another filter criterion when we get the list of grid items:
grids = grids.map(grid => ({
_el: grid,
gap: parseFloat(getComputedStyle(grid).gridRowGap),
items: [...grid.childNodes].filter(c =>
c.nodeType === 1 &&
+getComputedStyle(c).gridColumnEnd !== -1
),
ncol: 0
}));Let’s say we want to use this solution for something like a blog. We keep the exact same JS and almost the exact same masonry-specific CSS – we only change the maximum width a column may have and drop the max-height restriction for the first item.
As it can be seen from the demo below, our solution also works perfectly in this case where we have a grid of blog posts:
You can also resize the viewport to see how it behaves in this case.
However, if we want the width of the columns to be somewhat flexible, for example, something like this:
$w: minmax(Min(20em, 100%), 1fr)Then we have a problem on resize:
The changing width of the grid items combined with the fact that the text content is different for each means that when a certain threshold is crossed, we may get a different number of text lines for a grid item (thus changing the height), but not for the others. And if the number of columns doesn’t change, then the vertical offsets don’t get recomputed and we end up with either overlaps or bigger gaps.
In order to fix this, we need to also recompute the offsets whenever at least one item’s height changes for the current grid. This means we need to also need to test if more than zero items of the current grid have changed their height. And then we need to reset this value at the end of the if block so that we don’t rearrange the items needlessly next time around.
if(grid.ncol !== ncol || grid.mod) {
/* same as before */
grid.mod = 0
}Alright, but how do we change this grid.mod value? My first idea was to use a ResizeObserver:
if(grids.length && getComputedStyle(grids[0]).gridTemplateRows !== 'masonry') {
let o = new ResizeObserver(entries => {
entries.forEach(entry => {
grids.find(grid => grid._el === entry.target.parentElement).mod = 1
});
});
/* same as before */
addEventListener('load', e => {
/* same as before */
grids.forEach(grid => { grid.items.forEach(c => o.observe(c)) })
}, false)
}This does the job of rearranging the grid items when necessary even if the number of grid columns doesn’t change. But it also makes even having that if condition pointless!
This is because it changes grid.mod to 1 whenever the height or the width of at least one item changes. The height of an item changes due to the text reflow, caused by the width changing. But the change in width happens every time we resize the viewport and doesn’t necessarily trigger a change in height.
This is why I eventually decided on storing the previous item heights and checking whether they have changed on resize to determine whether grid.mod remains 0 or not:
function layout() {
grids.forEach(grid => {
grid.items.forEach(c => {
let new_h = c.getBoundingClientRect().height;
if(new_h !== +c.dataset.h) {
c.dataset.h = new_h;
grid.mod++
}
});
/* same as before */
})
}That’s it! We now have a nice lightweight solution. The minified JavaScript is under 800 bytes, while the strictly masonry-related styles are under 300 bytes.
Well, @supports just so happens to have better browser support than any of the newer CSS features used here, so we can put the nice stuff inside it and have a basic, non-masonry grid for non-supporting browsers. This version works all the way back to IE9.
It may not look the same, but it looks decent and it’s perfectly functional. Supporting a browser doesn’t mean replicating all the visual candy for it. It means the page works and doesn’t look broken or horrible.
Well, we can apply the fancy styles only if the root element has a js class which we add via JavaScript! Otherwise, we get a basic grid where all the items have the same size.
The post A Lightweight Masonry Solution appeared first on CSS-Tricks.
You can support CSS-Tricks by being an MVP Supporter.
2020-07-31T08:00:00+00:00
2020-08-01T05:07:51+00:00
Everybody loves a beautiful wallpaper to freshen up their desktops and home screens, right? To cater for new and unique artworks on a regular basis, we started our monthly wallpapers challenge more than nine years ago, and from the early days on to today, artists and designers from all across the globe have accepted the challenge and submitted their designs to it. It wasn’t any different this time around, of course.
In this post, you’ll find their wallpapers for August 2020. All of them are available in versions with and without a calendar — to help you count down the days to a big deadline (or a few days off, maybe?) or continue to use your favorite even after the month has ended. You decide. A big thank-you to everyone who shared their designs with us — we sincerely appreciate it!
As a little bonus goodie, we also added some “oldies” at the end of this post, timeless wallpaper treasures that we rediscovered way down in our archives and that are just too good to gather dust. Now there’s only one question left to be answered: Which one will accompany you through the new month?
Did you know that you could get featured in one of our upcoming wallpapers posts, too? We are always looking for creative talent, so if you have an idea for a wallpaper for September, please don’t hesitate to submit it. We’d love to see what you’ll come up with. Join in! ?
Designed by LibraFire from Serbia.
“Women’s Equality Day is a US celebration of the prohibition denying voting rights on the basis of sex. It’s a celebration of those trailblazers and suffragists who faught for their right to vote. So this 26th of August let’s honor them for the vitally important change they brought about back in 1920.” — Designed by Ever Increasing Circles from the United Kingdom.
“August is the month when we get sunburnt doing agricultural works, hike across the wild and untamed forests, and explore the depths of sun-kissed oceans and seas. The wind is mild and warm, the nights are filled with chatter, smiles, and music. August days are scattered around everywhere, and we try to catch and use up each and every one of them until summer gets lost in the face of murky autumn. In August, we chase laughs, sunsets, and memories.” — Designed by PopArt Studio from Serbia.
“My dog Sami inspired me for this one. He lives in the moment and enjoys every second with a big smile on his face. I wish we could learn to enjoy life like he does! Happy August everyone!” — Designed by Westie Vibes from Portugal.
“A lot of summer activities and holiday travels had to be canceled this month, but our pets don’t know that – they’re perfectly happy to lie around at home and soak up the sun. I wanted to make some calming art that would channel that energy, to help people recharge between all the stressors you have to face these days.” — Designed by Erin Ptah from the United States.
Designed by Ricardo Gimenes from Sweden.
“Somewhere it’s summer, somewhere else it’s winter time.” — Designed by Dan Di from Italy.
“Freedom is the highest value. August tells the tales of sacrifices and courage of a nation that fought its way through a very difficult path for independence.” — Designed by AufaitUX from India.
A crackling fire, a well-deserved nap on a hot summer day, a cornfield glowing golden in the midday sun — a lot of things have inspired the design community to create an August wallpaper in the last few years. Here are some favorites from our archives. (Please note that these designs don’t come with a calendar.)
“‘Always keep mint on your windowsill in August, to ensure that the buzzing flies will stay outside where they belong. Don’t think summer is over, even when roses droop and turn brown and the stars shift position in the sky. Never presume August is a safe or reliable time of the year.’ (Alice Hoffman)” — Designed by Lívi from Hungary.
“Headed towards Smoky Mountain Bigfoot Conference this summer? Oh, they say it’s gonna be a big one! Get yourself out there well-prepared, armed with patience and ready to have loads of fun with fellow Bigfoot researchers. Looking forward to those campsite nights under the starry sky, with electrifying energy of expectations filling up the air? Lucky you!” — Designed by Pop Art Studio from Serbia.
Designed by Francesco Paratici from Australia.
“I love typograhy handwritten style.” — Designed by Chalermkiat Oncharoen from Thailand.
“August means that fall is just around the corner, so I designed this wallpaper to remind everyone to ‘bee happy’ even though summer is almost over. Sweeter things are ahead!” — Designed by Emily Haines from the United States.
“This is a moment from Southern Estonia that shows amazing summer nights.” Designed by Erkki Pung / Sviiter from Estonia.
Designed by Ricardo Gimenes from Sweden.
“Meet Lucy: she lives in California, loves summer and sunbathing at the beach. This is our Jimi Hendrix Experience tribute. Have a lovely summer!” — Designed by PopArt Web Design from Serbia.
“August is one of my favorite months, when the nights are long and deep and crackling fire makes you think of many things at once and nothing at all at the same time. It’s about heat and cold which allow you to touch the eternity for a few moments.” — Designed by Igor Izhik from Canada.
“In Melbourne it is the last month of quite a cool winter so we are looking forward to some warmer days to come.” — Designed by Tazi from Australia.
“Liqiu signifies the beginning of autumn in East Asian cultures. After entering the Liqiu, the mountains in Eastern Taiwan’s East Rift Valley are covered in a sea of golden flowers, very beautiful. The production season for high-mountain daylilies is in August. Chihke Mountain, in Yuli Township, and Sixty-Stone Mountain, in Fuli Township, which are both located in Hualien County, are two of the country’s three high-mountain daylily production areas.” — Designed by Hong, Zi-Qing from Taiwan.
Designed by Dorvan Davoudi from Canada.
“Janmashtami, the day that Lord Krishna was born, is an important Hindu Festival which is celebrated worldwide. The idea was to create the Lord Krishna’s flute-playing persona, in a minimalist design form.” — Designed by Damn Perfect from Jaipur, India.
“I love going to aquariums – the colors, patterns and array of blue hues attract the nature lover in me while still appeasing my design eye. One of the highlights is always the jellyfish tanks. They usually have some kind of light show in them, which makes the jellyfish fade from an intense magenta to a deep purple – and it literally tickles me pink. On a recent trip to uShaka Marine World, we discovered that the collective noun for jellyfish is a bloom and, well, it was love-at-first-collective-noun all over again. I’ve used some intense colours to warm up your desktop and hopefully transport you into the depths of your own aquarium.” — Designed by Wonderland Collective from South Africa.
“This summer I have a telescope. Every night I look to the sky and I look into the stars. Fortunately, I can see Saturn.” — Designed by Verónica Valenzuela from Spain.
Designed by Andr?? Presser from Germany.
“I love the summer nights and the sounds of the sea, the crickets, the music of some nice party.” — Designed by Maria Karapaunova from Bulgaria.
Every second week, we send out useful front-end & UX techniques. Subscribe and get Smart Interface Design Checklists PDF in your inbox.
Front-end, design and UX. Sent 2× a month.
You can always unsubscribe with just one click.
There are tons of smokin’ hot websites out there, with an equal or greater number of talented designers and developers who make them. The web is awesome like that and encourages that sort of creativity.
Even so, it amazes me that certain traits find their way into things. I mean, it makes sense. Many of us use the same UI frameworks and take cues from sites we admire. But every once in a while, my eye starts catching wind of the zeitgeist and commonalities that come with it.
The latest one? Blobby shapes. It’s a fun flourish that adds a little panache, especially for flat designs that need a splash of color or an interesting focal point that leads the eye from one place to anther. I’m sure you’ve seen it. I spent one week collecting screenshots of websites I came across that use it. I certainly wan’t looking for examples; they just sort of popped up in my normal browsing.
I’m sorry if it seems like I’m calling out people because that’s my intention. I actually love the concept — so much, in fact, that I’m considering it on a project! Some of the examples in that gallery are flat-out gorgeous.
After spotting these blobby shapes a number of times, I’ve started to notice some considerations to take into account when use them. Things like:
All of this has me thinking about how the websites of today will be looked at by the developers of tomorrow. Remember way back, like 15 years ago, when many sites adopted Apple’s use of reflective imagery? I probably still have some Photoshop muscle memory from replicating that effect so many times.
Skeuomorphism, bevels, animated GIF backgrounds, long shadows, heroes, gradients, bokeh backgrounds… all of these and many other visual treatments have had their day in the sun. Perhaps blobs will join that club at some point. Perhaps they’ll come back in style after that. Who knows! I just find it interesting to reflect on the things that have inspired us over the last three decades and imagine how the things we do today will be seen through the long lens of time.
It’d be awesome to see other instances of blobby shapes — share ’em if you’ve got ’em!
The post Spotting a Trend appeared first on CSS-Tricks.
You can support CSS-Tricks by being an MVP Supporter.
You know the title attribute? I can do this:
<div title="The Title">
I'm a div with a `title`
</div>And now if I’m on a device with a mouse pointer and hover the cursor over that element, I get…
Which, uh, I guess is something. I sometimes use it for things like putting an expanded date or time on an element that uses shorthand for it. It’s a tiny bit of UX helpfulness reserved exclusively for sighted mouse users.
But it’s not particularly useful, as I understand it. Ire Aderinokun dug into how it’s used for the element (a commonly cited example) and found that it’s not-so-great alone. She suggests a JavaScript-enhanced pattern. She also mentions that JAWS has a setting for announcing titles in there, so that’s interesting (although it sounds like it’s off by default).
I honestly just don’t know how useful title is for screen readers, but it’s certainly going to be nuanced.
I did just learn something about titles though… this doesn’t work:
<!-- Incorrect usage -->
<svg title="Checkout">
</svg>If you hover over that element, you won’t get a title display. You have to do it like this:
<!-- Correct usage -->
<svg>
<title>Checkout</title>
<!-- More detail -->
<desc>A shopping cart icon with baguettes and broccoli in the cart.</desc>
</svg>Which, interestingly, Firefox 79 just started supporting.
When you use title like that, the hoverable area to reveal the title popup is the entire rectangle of the .
I was looking at all this because I got an interesting email from someone who was in a situation where the title popup only seemed to come up when hovering over the “filled in” pixels of an SVG, and not where transparent pixels were. Weird, I thought. I couldn’t replicate in my testing either.
Turns out there is a situation like this. You can apply a
2020-07-30T13:00:00+00:00
2020-08-01T05:07:51+00:00
The word Renaissance — which means “rebirth” in French — was given to a tremendous period of philosophical and artistic achievements that began in the 14th century.
During this time, there were a wide range of developments, including:
These developments and more made the Renaissance one of the most productive artistic eras in history, dramatically reducing the creative barrier and attracting a large audience rather than just a small group of elites.
Just like the Renaissance era, today’s web design field is exploring its potential through no-code development platforms (NCDPs). These tools allow non-programmers to create application software through graphical user interfaces and configuration, instead of traditional computer programming.
In 2000, usability expert Jakob Nielsen introduced “Jakob’s Law,” the idea that users develop mental models of the products they interact with based on their previous experience. The more users can focus on their goal without challenging this mental model, the easier it is for them to achieve that goal.
“CSS is closer to painting than Python.”
—?Chris Coyier, co-founder at CodePen
Design and development skills are rooted in different types of thinking and require different types of tools. While designers use WYSIWYG editors like Figma, Sketch, and Photoshop to place elements on the canvas, developers work with IDEs like VSCode, Webstorm, and Brackets. In order to remain productive, designers and developers need to be able to make changes and receive instant feedback, according to their mental model.
So, using drag and drop builders may actually interfere with developers who want to debug fast, but working only with a text editor may be inappropriate for designers who want to test composition.
Many designers understand the functional differences between a mockup and a working product. In order to understand the possibilities of the medium, where to draw the boundaries and how to deal with the constraints, many designers are willing to “get their hands dirty” when it comes to learning code — but they have difficulties.
One of the main reasons designers are not coders is because there is a large gap between the designer’s mental model and the conceptual model of many code editors. Design and development take two very different modes of thought. This mismatch leads to a difficult and frustrating learning curve for designers that they might not be able to overcome.
Abstraction is a core concept of computer science. Languages, frameworks, and libraries are built on different abstraction layers of complexity to facilitate, optimize, and guarantee productivity.
“Visual programming tools abstract code away from the creator, making them significantly more accessible. The real magic of these tools, however, is how they integrate all of the underlying layers of software into end products, providing useful functionality through modular components that can be harnessed through intuitive visual interfaces.”
— Jeremy Q. Ho, No Code is New Programming
When working with abstraction layers, there are tools such as Editor X and Studio for websites/web applications, Draftbit and Kodika for mobile apps, and Modulz for design systems, which enable a visual representation of code, in addition to code capabilities.
By adopting a familiar visual medium, the learning curve becomes easier for designers.
If Chris Wanstrath the co-founder and former CEO of GitHub said, “the future of coding is no coding at all,” then surely no-code is a legitimate way to develop — despite the perception that these tools don’t offer the flexibility to write your own code, line by line.
Indeed, we see that interest in the term “nocode” is growing:
In order to understand the development of no-code tools for designers, you need to know the distinction between two types of programming:
Declarative languages are often domain-specific languages, or DSL, which means they’re used for a specific purpose, in a specific domain.
For example, SQL is DSL for working with databases, HTML is DSL for adding semantic structure and meaning to content on a web page, and CSS is DSL for adding style.
“There are too many variables to consider. The point of CSS is to make it so you don’t have to worry about them all. Define some constraints. Let the language work out the details.”
— Keith J. Grant, Resilient, Declarative, Contextual
Imperative programming sets specific, step-by-step instructions to the browser to get the desired result, while declarative programming states the desired result and the browser does the work by itself.
The effort to create a visual interface tool for web design development started in the 1990s through groundbreaking attempts like InContext Spider, Netscape Navigator Gold, Microsoft FrontPage, and of course, Dreamweaver.
During this period, the common terminology included: visual HTML authoring tool, WYSIWYG web page compositor, or simply HTML editor. The term “no-code” was popular in the 1990s — but for a different reason. In 1996, the American rock band Pearl Jam released their fourth studio album, No Code.
These no-code tools dramatically reduced the creative barrier and attracted a large audience, the Internet wasn’t ready for these types of tools at the time.
This effort was limited for the following reasons:
When the inventor of the World Wide Web Tim Berners-Lee launched his creation in 1989, he didn’t offer a way to design a website.
This came along in October 1994, after a series of suggestions on how to design the Internet by different people — including one from Håkon Wium Lie — who proposed an idea that attracted everyone’s attention. Lie believed in a declarative style that would allow browsers to handle the processing — it was called Cascading Style Sheets, or simply CSS.
“CSS stood out because it was simple, especially compared to some of its earliest competitors.”
— Jason Hoffman, A Look Back at the History of CSS
For a long time after, CSS provided design solutions for a single object — but it didn’t give an adequate response to the relationship between the objects.
Methods to address this were effectively hacks, and they weren’t able to handle a great deal of complexity. As sites evolved from simple documents to complex applications, web layouts became difficult to assemble. Instead of using a style in a declarative way as Lie designed, web developers were forced to use imperative programming.
A grid system based on the rules of Swiss designer Josef Müller-Brockmann that was customary in print from the 1940s seems like a distant dream when considering anything related to the Web.
Because of these layout limitations, no-code platforms were forced to add an abstract layer to perform backstage calculations. This layer causes a range of problems, including losing the semantic value of the objects, performance issues, bulky code, a complex learning curve, unscalability, and accessibility issues.
In the early days, browser makers were the ones who decided how to build the Internet. This led to the Web becoming a manipulative commodity. Competition between browsers led to unique “design features”. This forced the need to rebuild the same site several times, so it could be accessed from multiple browsers.
“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.”
— Amy Dickens, Web Standards: The What, The Why, And The How
To offset the need to build websites that fit specific browsers, the World Wide Web Consortium (WC3) community was established at MIT in 1994. The WC3 is an international community working to develop functional, accessible and cross-compatible web standards.
When the standards were introduced, browser makers were encouraged to stick to one way of doing things — thus preventing several versions of the same site from being built. Despite WC3’s recommendations, it took a long time for browsers to meet the same standards.
Due to a lack of alignment between the browsers (Internet Explorer, I’m looking at you), CSS for a time was stuck and no new capabilities were added. Once a declarative language doesn’t support something, it requires you to lean on all kinds of imperative hacks in order to achieve that goal.
In the early years of the Web, sites were developed as a collection of static pages with no semantic meaning. When Web 2.0 arrived, it received the description “the web as a platform,” which led to a significant change — pages had dynamic content, which affected the connection to the data, and of course the semantic meaning.
“Sites in the 1990s were usually either brochure-ware (static HTML pages with insipid content) or they were interactive in a flashy, animated, JavaScript kind of way.”
— Joshua Porter, Web 2.0 for Designers
Indeed, connecting to data using a no-code approach has existed for a long time — but the user experience was difficult. Additionally, the transition to semantic marking so content could be detected in no-code tools was difficult because of the mixing between declarative and imperative programming.
No-code tools didn’t mesh with those core tasks.
On June 29, 2007, the nature of the Internet was changed dramatically. This was the day when Steve Jobs introduced the iPhone — a combination of mobile phone and media player that connected to the Internet and enabled multi-touch navigation.
When the iPhone was introduced in 2007, it was a turning point for web design. All of a sudden web designers lost control of the canvas on which we designed websites. Previously, websites only had to work on monitor screens, which varied in size, but not all that much. How were we supposed to make our websites work on these tiny little screens?
— Clarissa Peterson, Learning Responsive Web Design
This created new challenges for web design development. Mainly, how to build a site that can be used on multiple types of devices. Many “hack” approaches to layout design simply fell apart — they caused more problems than they solved.
Everything needed to be reevaluated.
Browsers supporting WC3 standards (Chrome and Firefox ) have huge market share today, which has pushed more browsers to support the standards. The fact that all of the browsers support the same standard, enable alignment in the building of sites and ensure these capabilities would continue to work as standards and browsers evolve.
Methods such as media query, flexbox and grid — which are natively available in the browsers for layout design — have paved the way for flexible layouts, even when element sizes are dynamic.
“When CSS Grid shipped in March 2017, our toolbox reached a tipping point. At last we have technology powerful enough to let us really get creative with layout. We can use the power of graphic design to convey meaning through our use of layout—creating unique layouts for each project, each section, each type of content, each page.”
— Rachel Andrew, The New CSS Layout
In this way, HTML became cleaner and it was able to achieve its original purpose: a semantic description of the content.
Finally, thanks to alignment between the browsers and new capabilities, no-code tools are backed by powerful, uniform technology. These changes created a clearer distinction between declarative and imperative. New possibilities were created to solve old problems.
“Simplicity is the ultimate sophistication.”
— Leonardo da Vinci
The developments of the Internet over the years has led to a situation where the abstraction between design and code is constantly improving. This has implications for the way web designers plan and implement their designs.
While popular design tools use static content for dynamic web design, no-code tools allow designers to work with the web’s own materials.
“Photoshop is the most effective way to show your clients what their website will never look like.”
— Stephen Hay, author of Responsive Design Workflow
If we have a complex design with different states, micro-interactions, animations and responsive breakpoints —?by using no-code tools we can work in a more tangible way.
Additionally, the development of the web enables no-code tools to clearly separate content from the design (which allows designers to visually manage real content). Reflecting the dynamic content in the design (e.g. text, images, videos, and audio), gives designers a clearer understanding of how it will appear.
The advantage of working in the no-code workspace is that interactions appear immediately. This allows designers to quickly test their design choices and see if they work.
After investing in design perfection, designers should explain the visual and conceptual decisions to developers through prototypes. Prototypes not only take time in terms of preparation, but their design is also often implemented incorrectly due to misinterpretations.
With no-code tools, designers are able to place objects on their display and handle their visibility and behavior with ease and speed. In other words, they can design the end result without depending on anyone else.
To use myself as an example, when the Coronavirus pandemic hit, I worked with a small team on a project to help connect young volunteers to isolated seniors. In just three days, myself and another designer built the website and connected user registration data to a database, while the team’s developer worked to integrate data from the site into a separate mobile app.
Will no-code tools completely replace developers? The short answer: No. The significant change is in the way designers and developers can work together to create websites.
In addition to the development of CSS, Javascript has also evolved in parallel and perhaps even more. The idea that frontend developers need to control all the abilities makes no sense. And yet, the development of no-code over the years has enabled designers to build their own designs.
It’s a win-win situation, in which? developers can focus on developing logic, and designers have more control over the user experience and styling.
I don’t want to leave you with the impression that designers have complete freedom to design with no-code tools. There are still some missing style capabilities that CSS has not yet solved, and these still require imperative development.
Unlike in the Middle Ages, where art was considered as handicraft without a theoretical basis, Renaissance developments changed the status of the artist — who was suddenly considered a polymath.
No-code tools remove bottlenecks, which allows designers to gain more ownership, influence, and control over the experiences they design.
We’ve come a long way from the days when designers weren’t able to bring their designs to life. As the Internet evolves, browsers align, capabilities are added and the accessibility of technology becomes easier — designers are faced with new opportunities to create, think, and change their status with no-code tools.
The no-code movement not only affects how things are done, but by who.
Credits: Yoav Avrahami and Jeremy Hoover contributed to this article.
(fb, ra, yk, il)
