Progress Delayed Is Progress Denied

May 5th, 2021 No comments

The bombshell article of the week is from Alex Russell of Google/Chrome. Alex has long been super critical of Apple, particularly about how there is literally no option to run any other browser than Safari on iOS. This article isn’t just fist-waving about that, but a dissertation accusing Apple of real harm to the web platform by sluggish progress on Safari and a no-web-apps App Store.

Apple’s iOS browser (Safari) and engine (WebKit) are uniquely under-powered. Consistent delays in the delivery of important features ensure the web can never be a credible alternative to its proprietary tools and App Store.

I appreciate Alex’s take here. It gives credit where credit is due, it places blame where it feels most fair to place it, and brings data to a complex conversation that deserves it. It’s hard not to get through the article and think that the web would be in a better place should Apple…

  1. Allow alternative browsers on iOS
  2. Allow web apps in the App Store
  3. Move faster with web platform features in Safari

Taking them one at a time…

  1. Do I want this? Yes. It seems reasonable that my $1,000 extremely powerful computer phone should be able to run whatever browser I want, particularly one from a company that makes a really good one and very much wants to ship it on my phone. In reality, I’m sure the complications around this are far beyond my understanding. I always think about that Chrome update that literally broke macOS. Could that happen on iOS? While lack of features might abstractly make for unhappy customers, a bricked phone very directly makes for unhappy customers. I suspect it more boils down to the fact that Google is an advertising company that innovates on tracking technology and Apple is a hardware company that innovates on privacy. That’s a rock-and-hard-place situation and this browser situation is one of the consequences.
  2. Do I want this? Yes. I don’t even know how to make native apps aside from software that turns web apps into native apps with magic. If web apps could go in the Apple App Store, it opens the door for people like me (and there are a lot of me). In reality, I’m sure the complications around this are far beyond my understanding. Is quality control harder? I gotta imagine it is. Is security harder to lock down? I gotta imagine it is. Are customers clamoring for it? I’m not sure I hear them very loudly. People do have a choice, as well: iOS is only 15% of the phone market. If you want an alternative browser and an alternative app store, you can have it.
  3. Do I want this? Yes. Heck, we celebrate little wins that Safari ships. I certainly don’t want to wait years for every clearly-useful feature. It will be interesting to measure the time for contain and container queries. That one looms large for me as I want to use it as soon as possible without polyfills, once it stabilizes. I know the joke goes that “Safari is the new IE”, but I don’t tend to feel that day to day in my typical web dev work. I feel like I can ship extremely capable websites to all browsers including Safari and not worry terribly about Safari being a second-class experience (I don’t make games or VR/AR experiences, though). I’m honestly more worried about Firefox here. Apple and Google have more money than God. It’s Mozilla I worry about being DDoS’d with web-feature onslaught, although to be fair, they seem to be doing fine at the moment.

As far as Safari-behind-ness goes, I think more about the DevTools than I do web platform features.

There is the Apple-is-restrictive angle (fair enough), but also the Apple-is-slow angle here. Slow is a relative term. Slow compared to what? Slow compared to Chrome. Which begs the question: why does Chrome get to dictate the exact speed of the web? I always think of Dave’s “Slow, like brisket.”

There’s a lot of value in slow thinking. You use the non-lizard side of your brain. You make more deliberate decisions. You prioritize design over instant gratification. You can check your gut instincts and validate your hypothesis before incurring mountains of technical debt.

I think just enough iteration before a release produces better products. Because once it’s out, it’s out. There’s no turning back or major API changes. 

Maybe a slower-moving web is frustrating sometimes, but does it mean we get a better one in the end? My baby bear brain tells me there is a just right somewhere in the middle.

Direct Link to ArticlePermalink


The post Progress Delayed Is Progress Denied appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

Categories: Designing, Others Tags:

How To Power Through Designer Apathy

May 5th, 2021 No comments

Sometimes you just don’t give a damn anymore. Possibly the only thing worse than designer’s block is designer’s apathy: that sinking feeling you get when you realize that you just don’t care about this particular piece of work anymore is disheartening.

The dread of going back to it is paralyzing.

There are many reasons you can stop caring about your work. Maybe you’ve just done the same thing too many times in a row. Maybe your client is insisting on asking for things you know won’t work for them. Maybe something much more important just happened in your life, and you’ve got bigger things to worry about. You could be discouraged by the apparent ‘sameness’ of bandwagon-hopping designs.

I’ve been not caring about my work ever since I was first asked to pick up my toys

Whatever the reason, we all experience times when we know exactly what we have to do… we just don’t care.

I’m something of an expert on this phenomenon. I’ve been not caring about my work ever since I was first asked to pick up my toys. Worse, I have the attention span of a goldfish, even now.

Web design is different. When I discovered it, it was new, exciting, and I could do it on the computer. I loved it, and I still do. Writing code that makes design happen in a browser window will never get old for me.

But even so, sometimes, a particular project will make me want to throw up my hands in exasperation and play video games ‘til Judgement Day. I’d welcome Skynet with tacos and RPGs.

So what do we do about it? First, answer this question: who is the project for?

For A Client

If the project is for a client, it’s just gotta get done. There’s no way around that. You made a commitment. You’re going to follow through and give it your best possible effort because you’re a professional. Anything less would be wrong.

However, that doesn’t mean you have to just power through with only coffee and misery for company. There are things you can do to make the work easier on yourself. The less miserable you are while you work, the better quality you can deliver.

For Yourself

There are a couple of schools of thought here. The first is that it’s perfectly fine to give up on personal projects when you stop caring. I mean, it’s your free time. Why spend it on something you don’t care about?

On the other hand, is a commitment made to yourself any less important than a commitment made to someone else? Many people seem to be perfectly fine with breaking promises to themselves when they’d never willingly do that to a client. Is that wrong?

I usually buy myself a drink and forgive myself, but it’s worth thinking about.

The deciding factor for me is whether my personal project will have any sort of lasting benefit. If whatever I’m designing, writing, or making counts as a long-term investment in my career or quality of life, then it absolutely has to get done, even when I’m not feeling it. Otherwise, I call it a learning experience and move on.

How To Power Through

So, for whatever reason — whether because you have to, or you want to — you’re gonna power through. Here are five ways to do it in style:

1. Start

The hardest part of doing work you don’t care about is starting. This is when you’ll be tempted to procrastinate until the last minute. Try not to.

2. Switch To A Different Part Of The Project

If you can safely (without causing problems) work on a different aspect of the project for a while, try that. The mere variety, the break from the work in front of you before, can boost your morale.

Indeed, working on a different part of the project can give you ideas of getting the most troubling bits done faster or more easily.

3. Do Something Old In A New Way

This one has its pros and cons.

Pro: You can look at this project as a chance to try out a new grid framework, script, code editor, or another tool of some kind. Injecting the process of discovery into an otherwise boring project can make it a lot more fun and even make you look forward to working on it.

Con: You’ll need to plan for extra hours and use some version control; because bringing a new tool or process into play is almost guaranteed to make something interesting go wrong — when this happens, you probably shouldn’t bill the client for the extra hours spent on StackOverflow.

4) Make Like Aziz Ansari And Treat Yo’self

Celebrate the milestones of your project. Don’t celebrate with video games if you need to get any more work done that day. That can go very wrong. But do celebrate. Reward yourself because you’re doing something difficult.

Have a snack. Give yourself a round of applause. Whatever it takes, make yourself look forward.

5) Outsource It

As a last resort, you can always outsource the project to someone else. Just make sure it’s someone you can trust to deliver the same quality of work you would normally provide yourself. Make sure to check it over before handing it off to a client.

Alternatively, you could just outsource the bits of the work that you don’t like. Either way, this is a risky strategy because whoever you outsource to might experience delays or, ironically, not care about the project.

Conclusion

You can do it! I believe in you. The really, really boring projects can seem like huge sinkholes of sadness, but they don’t last forever.

 

Featured image via Pexels.

Source

The post How To Power Through Designer Apathy first appeared on Webdesigner Depot.

Categories: Designing, Others Tags:

Jetpack Backup: Roll Back Your WooCommerce Site Without Losing Orders

May 4th, 2021 No comments

Here’s a dilemma: what happens if your WooCommerce site has a problem and the quickest and best way to fix it is to roll back to a previous version? The dilemma is, if you roll back the database, you would lose literal customer orders that are stored in the database. That’s not acceptable for an eCommerce store.

Good news: Jetpack Backup won’t do you wrong like that. You can still restore to a prior point, but you won’t lose any customer order or product data.

Do you lose all the orders that came in since that last backup? Nope.

Will the inventory get all screwed up? Nope.

What about the new products that were added after the restore point? Still there.

All that data is treated as immutable. The way that it plays out is that the database is restored to that point (along with everything else) and that all the new product and order data that has changed since then is replayed on top of the database after the restore.

With Jetpack Backup, there’s absolutely no guesswork. Its real-time snapshots feature has a unique feature that protects WooCommerce customer and product data when rolling back things back so you get the best-case scenario: readily available backups that preserves customer orders and product information.

That’s just one of the magical benefits you get from such a deep integration between Jetpack and WooCommerce. There are others, of course! But you can imagine just what a big deal this specific integration for any WooCommerce-powered store.

And, hey, Jetpack Backup is sold à la carte. So, if backups are all you want from Jetpack, then you can get just that and that alone.


The post Jetpack Backup: Roll Back Your WooCommerce Site Without Losing Orders appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

Categories: Designing, Others Tags:

Let’s use (X, X, X, X) for talking about specificity

May 4th, 2021 No comments

I was just chatting with Eric Meyer the other day and I remembered an Eric Meyer story from my formative years. I wrote a blog post about CSS specificity, and Eric took the time to point out the misleading nature of it (I remember scurrying to update it). What was so misleading? The way I was portraying specificity as a base-10 number system.

Say you select an element with ul.nav. I insinuated in the post that the specificity of that selector was 0011 (eleven, essentially), which is a number in a base-10 system. So I was saying tags = 0, classes = 10, IDs = 100, and a style attribute = 1000. If specificity was calculated in a base-10 number system like that, a selector like ul.nav.nav.nav.nav.nav.nav.nav.nav.nav.nav.nav (11 class names) would have a specificity of 0111, which would be the same as ul#nav.top. That’s not true. The reality is that it would be (0, 0, 11, 1) vs. (0, 1, 0, 1) with the latter easily winning.

That comma-separated syntax like I just used solves two problems:

  1. It doesn’t insinuate a base-10 number system (or any number system)
  2. It has a distinct and readable look

I like the (X, X, X, X) look. I could see limiting it to (X, X, X) since a style attribute isn’t exactly a selector and usually isn’t talked about in the same kind of conversations. The parens make it more clear to me, but I could also see a X-X-X (dash-separated) syntax that wouldn’t need them, or a (X / X / X) syntax that probably would benefit from the parens.

Selectors Level 3 uses dashes briefly. Level 2 used both dashes and commas in different places.

Anyway, apparently I get the bug to mention this every half-decade or so.


The post Let’s use (X, X, X, X) for talking about specificity appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

Categories: Designing, Others Tags:

Creating Colorful, Smart Shadows

May 4th, 2021 No comments

A bona fide CSS trick from Kirupa Chinnathambi here. To match a colored shadow with the colors in the background-image of an element, you inherit the background in a pseudo-element, kick it behind the original, then blur and filter it.

.colorfulShadow {
  position: relative;
}

.colorfulShadow::after {
  content: "";
  width: 100%;
  height: 100%;
  position: absolute;
  background: inherit;
  background-position: center center;
  filter: drop-shadow(0px 0px 10px rgba(0, 0, 0, 0.50)) blur(20px);
  z-index: -1;
}

Negative z-index is always a yellow flag for me as that only works if there are no intermediary backgrounds. But the trick holds. There would always be some other way to layer the backgrounds (like a or whatever).

For some reason this made me think of a demo I saw (I can’t remember who to credit!). Emojis had text-shadow on them, which really made them pop. And those shadows could also be colorized to a similar effect.

CodePen Embed Fallback

Direct Link to ArticlePermalink


The post Creating Colorful, Smart Shadows appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

Categories: Designing, Others Tags:

13 eCommerce Site Search Strategies to Boost Revenue from Existing Visitors

May 4th, 2021 No comments

Let’s be clear about something right at the start: If you’re not optimizing your site search to convert more visitors into buyers, you’re missing out on sales.

People who use site search are telling you they want to buy.

3 Numbers to Show You Why You MUST Optimize Your Site Search

We can’t blame you for wanting proof. Internal Site search sounds boring. It’s just a little bar everyone sticks at the top of the page, right?

Have a look at these site search stats from Shopify:

Clearly, if you want to maximize the revenue you get from the people who already come to your site, then you need a site search tool to help you.

So what does a site search tool need to do?

What Does Your Search Bar Need to Do?

Searching changed during the past few years. People expect super helpful results to their searches. Queries should recognize the keyword the customer is using and return great search results. The entire process should feel seamless and easy. Your internal search tool should also give you clear, actionable data.

So what does a modern, capable site search tool do? Here are a few necessary functions:

  • Your tool should have an advanced search algorithm that can find relevant content and relevant results based on user searches.
  • Understand searches beyond keyword matching. It should discover the user intent behind the searches your customers make to give them the search results they’re looking for.
  • Site search reports are a necessary part of eCommerce. Site search tracking helps with product placement, searchandising, and understanding the website’s visitors.

There are two different ways to understand what your internal site search tool should do.

First, it should serve your customers great search results. This is its primary purpose. When users search your site, they are looking for something specific and probably want to buy it. When they type their query into the search box, they are having an “I want this” moment. Relevant results turn that moment into a sale.

Second, it should serve the interests of the business. Specifically, it should tell you what people want to buy and how they try to find it. Armed with this information, you will be in a better position to stock the right products and stack up the profits.

How Can You Improve Your eCommerce Site Search Functionality?

We’re going to show you how to make your search platform work better for you. Along the way, if you read something and think, “Dang! My site search platform can’t do that,” then you should go find a better search platform.

Let’s get it started with simple UI fixes for your search box.

Sort Out Your Search Box User Interface

People don’t want to search for your search box. Put it in an obvious place, give it some contrast to the surrounding content, and provide an example search query to help people know your search box is the place their search starts. 

Let’s dive into those three tips quickly:

  1. Put your search box in an obvious place. Don’t hide your search box behind a small magnifying glass icon or bury it at the bottom of the page. Highlight it at the top of the page so people can find the search function.
  2. Give it some contrast to the surrounding content. Make your search box stand out by making it a different color, using a dark border, or something else that draws attention.
  3. Provide an example search query. Use something visual to showcase your search function. Words like “Find me a …” or “Tell me what you’re looking for…” will help users search faster.

User interface upgrades are all about getting people into your search bar as quickly as possible. Once they begin using your search function, you can do a few more things to help them find the right products and make a purchase.

Implement Predictive Search Autocomplete to Help Users

About 30% of your store visitors will use your site search function and 25% of them will click on a search result. This is a massive opportunity for you – if your search results show them what they’re looking for.

The enemy of great site search is the dreaded zero results page. This is when the customer sees no search results for their search query. To avoid zero results pages and help your users, implement a predictive text autocomplete.

Predictive text autocomplete will attempt to finish the user’s query while they are typing. The search bar will show users fast ways to finish their search query. Faster, simpler searches are better for users, especially on mobile devices where typing might be irritating.

Predictive text autocomplete is also better for you because you control those suggestions. Every suggestion should lead to a valid page or product on your website. Eliminating zero results pages leads users to your products so they can buy them.

Prefixbox, providers of a very effective site search solution, have a great guide for using predictive search autocomplete here.

Typo Tolerance for Deeper Engagement

Search engines that understand errors help deeper engagement with customers. Search engines that don’t, send customers to other websites to find what they want to buy. Your site search should have language modeling intelligence so it can understand a query even if words are misspelled.

Users make mistakes and it’s easy to help them. Your preferred tool should produce site search reports that will show you the misspelled queries. Once you see the mistakes people make when they are searching, you can assign keywords to the misspelled words. Then people can make mistakes, find your products anyway, and buy them from you.

Handling Long Tail Semantic Searches

What in the heck is a long tail semantic search? Here are some examples:

  • men’s shoes size 11 black Nike
  • children’s vest high vis safety age 4

These user searches contain loads of useful information if your tool can understand it. A successful tool will see these long-tail searches and adjust the query parameters to find the best match.

In the men’s shoes example, each word becomes a query parameter for the search. So, the results page is going to show products according to these query parameters:

  • Must be men’s shoes
  • Must be size 11 shoes
  • Must be black shoes
  • Must be Nike shoes

From the user’s perspective, a list of black size 11 Nikes for men would be the perfect search results.

If your site search tool doesn’t do this, maybe you should find a new one. A study by Retail Integration Online found websites with semantic site search tools had a 2% cart abandonment rate as opposed to normal text-based websites with abandonment rates of around 40%.

Use A/B Testing to Tweak, Review, and Maximize Profits

Internal search analytics and site search reports lead to trying out different methods. You might find a search query leads to a specific product that isn’t an ideal fit. Change the query’s results to lead people to a different product on the results page. Then compare your results. Which query led to the most conversions and sales?

Here are some examples of A/B testing on the results page:

  • Move your own branded products to the top of the search list. Measure total sales and specific sales of your own brands.
  • Highlight special offers in the search results pages. Test the conversions of these products.

Those are two simple tests you could use on your website. Testing these changes and producing reports will help you understand how to continue to tweak your site search to get the best results.

Some form of A/B testing is important for your site. Without the ability to test your results, you cannot get the best data for your website. A/B testing your site search will show you which internal search changes made the most impact on your sales.

A/B Testing comes with some site search providers, but not all. We recommend going with a solution that gives you A/B testing because of the power of accurate data for your website.

Natural Language Processing for More Accurate Search Results

Natural language processing (NLP) is a massive boost to the functionality of site search because it means the site search function can understand user intent beyond keywords in the query.

Here’s an example: “40th birthday gifts for women.” This query shows results across different categories. There are slippers, wine glasses, teacups, and funny cards. The ability to connect different search results across categories by a ‘meta’ mashup of birthday/40/women separates NLP site search functionality from a basic search.

NLP moves beyond the keyword and into the search intent of your visitors. Displaying results across categories and showing results within a category but limited by a query parameter like color or size are hallmarks of NLP search.

NLP dominates search in the present and it’s hard to see anything different in the future.

Suggest Search Queries

You can access two kinds of data about your visitors:

  • Individual data from their current or previous sessions. You can track their previous purchases, searches, and viewed items. You may also have access to information such as their gender, age, or location.
  • Aggregate data from all visitors to your website. You should know what people are searching for, which categories are most popular, and which pages on your website get the most traffic.

Use these two types of data to create search queries for your users. We call these zero-character searches. As soon as someone highlights the search box, suggestions appear. Sites with this function are making the customer journey even faster by eliminating the need for a search query.

What content type could you suggest?

  • You can suggest popular search queries with an introductory phrase like “People are searching for…”
  • You can suggest the most popular categories on your website with some pictures of products.
  • You can suggest the customer’s previous search queries.

Suggesting search queries will help your visitors move through your site even faster – as long as the queries have relevant products.

Exclude Irrelevant Search Results

No one should use your site search and feel disappointed with the results. If the results for search queries are not relevant, then you should eliminate them. Tweak your search results pages to show people the most relevant results possible.

Imagine someone types “Spaghetti blouse” into the search bar. They’re not looking for pasta. So your site search function should see the query parameter [blouse] and limit the results accordingly.

Site search reports should show you which searches produce irrelevant results. A good place to start is by examining long-tail searches that produce a huge number of results.

Some site search solutions can do this automatically. They do this by tying into the next point: synonyms.

Synonym Management Produces Relevant Answers

Synonyms are words that mean the same or similar things. For example, color synonyms would connect the word “light” to colors like white, light blue, or pale yellow. Your site search should connect these synonyms.

Let’s come back to one of the primary purposes of site search optimization: making the user experience frictionless. So, imagine the user who types in this query:

“dark sneakers”

They want to see black, dark grey, or charcoal-colored shoes. If they see a zero results page because none of your shoes have ‘dark’ in their metadata, that’s frustrating. Likewise, if they see blue, green, and pink shoes, then they have to wade through pages of irrelevant answers.

Set up your site search with synonym management to help connect users to products beyond the keywords they actually type.

Breadcrumbs Help People Navigate

What are breadcrumbs? They are the list of categories at the top of the page showing where people have come from to reach their current page. 

Here is an example:

Home –> Groceries –> Produce –> Vegetables –> Potatoes

Someone seeing this could find their way from the potato section back to the rest of the vegetables easily. This will help people navigate backward from a mistake or navigate backward to find a product related to the one they’ve already found.

Place breadcrumbs at the top of your page. Highlight the specific search the user typed at the end of the breadcrumb chain. These small things help people feel comfortable on your website.

Create a Great Mobile Search Experience

People use their mobile devices for shopping more and more. Everyone knows this. Not everyone seems to connect this to their search bar. Pick up your own phone and test your search box yourself.

Is it easy to use?

Does it have the same features as the desktop version?

What irritates you?

There are a few things we can think of right away to make the mobile search experience better:

  • Limit the search results page to avoid excessive scrolling and loading. Show 3-5 products to avoid overwhelming the user.
  • Features like autocorrect and zero-character searches will save users on typing time.
  • Strong error tolerance will make people feel better because autocorrect mistakes and typos are more common on mobile devices.

No one should feel disadvantaged because they have come to your mobile website. Brilliant customer service means creating a great search experience on mobile devices, too.

Machine Learning for 10x Personalization

Machine learning analyzes user behavior and creates responses to drive sales. What responses could happen?

  • On-site messaging, such as a discount pop-up when someone searches for a specific product or category.
  • Suggesting related products based on user behavior analysis.

For example, imagine a man browsing through a sporting goods store. He checks out the product pages for three Reebok products. As he carries on searching, Reebok products get boosted in the results because he seems to prefer them.

Machine learning is better for these kinds of changes because it can happen quickly and on a large scale.

Use Site Search Analytics to Dig Into Revenue

Your analytics will show you what’s working and what’s not. Most sites are familiar with Google analytics. Your site search function should come with analytics like this to help you see the right data.

Which data points are the most helpful?

  • Most Searched Keywords
  • Clicks to Conversion
  • Geographical Locations
  • Query/Product Relationships
  • Zero Results Pages
  • Number of Searches Per User

All these, and more, will give you the right analytics reports to make better tweaks to your site search and query connections.

Site Search Drives Conversions and Revenue Growth

Every study conducted so far tells us site search is a key part of eCommerce success. Site search users buy more often, spend more money, and convert to loyal customers. 

If your site search isn’t on point yet, we strongly recommend following these 13 tips to get it sorted out as quickly as possible.


Photo by Myriam Jessier on Unsplash

Categories: Others Tags:

Chapter 8: CSS

May 3rd, 2021 No comments

In June of 2006, web developers and designers from around the world came to London for the second annual @media conference. The first had been a huge success, and @media 2006 had even more promise. Its speaker lineup was pulled from some of the most exciting and energetic voices in the web design and browser community.

Chris Wilson was there to announce the first major release to Microsoft’s Internet Explorer in nearly half a decade. Rachel Andrew and Dave Shea were swapping practical tips about CSS and project management. Tantek Çelik was sharing some of his recent work on microformats. Molly Holzschlag, Web Standards Project lead at the time, prepared an illuminating talk on internationalization and planned to join a panel about the latest developments of CSS.

The conference kicked off on Thursday with a keynote talk by Eric Meyer, a pioneer and early adopter of CSS. The keynote’s title slide read “A Decade of Style.” In a captivating and personal talk, Meyer recounted the now decade-long history of Cascading Style Sheets, or CSS. His own professional history intertwined and inseparable from that of CSS, Meyer used his time on the stage to look at the language’s roots and understand better the decisions and compromises that had led to the present day.

At the center of his talk, Meyer unveiled the secret to the success of CSS: “Never underestimate the effect of a small, select group of passionate experts.” CSS, the open and accessible design language of the Web, thrived not because of the technology itself, but because of people—the people who built it (and built with it) and what they shared as they learned along the way. The history of CSS, Meyer concluded, is the history of the people who made it.

Fifteen years after that talk, and nearly three decades after its creation, that is still true.


On Thursday morning, October 20th, 1994, attendees of another conference, the Second International WWW Conference, shuffled into a room on the second floor of the Ramada Hotel in Chicago. It was called the Gold Room. The Grand Hall across the way was quite a bit larger—reserved for the keynote presentations on the day—but the Gold Room would work just fine for the relatively smaller group that had managed to make the early morning 8:30 a.m. panel.

Most in attendance that morning would have been exhausted and bleary-eyed, tired from late-night networking events that had spanned the previous three nights. Thursday was Developer Day, the final day of the conference.

The Chicago conference had been preceded six months earlier by the first WWW conference in Geneva. The contrast would have been immediately apparent. Rather than breakout sessions focused on standards and specs, the halls buzzed with industry insiders and commercial upstarts selling their wares. In a short amount of time, the Web had gone mainstream. The conference in Chicago reflected that shift in tone: it was an industry event, with representatives from Microsoft, HP, Silicon Graphics, and many more.

The theme of the conference was “Mosaic and the Web,” and the site of Mosaic’s creation, NCSA, had helped to organize the event. It was a fact made more dramatic by a press release from Netscape, a company mostly staffed by former NCSA employees, just days earlier. The first version of their browser—dramatically billed as “Mosaic killer”—was not only in beta, but would be free upon release (a decision that would later be reversed). Most members of the Netscape team were in attendance, in commercial opposition of their former employer and biggest rival.

The grand intrigue of commercial clashes somewhat overshadowed the first morning session on the last day of the conference, “HTML and SGML: A Technical Presentation.” This, in spite of the fact that the Web’s creator, Sir Tim Berners-Lee, was leading the panel. The final presenter was Håkon Wium Lie, who worked with Berners-Lee and Robert Calliau at CERN. It was about a new proposal for a design language that Lie was calling Cascading HTML Style Sheets. CHSS for short.

The proposal had come together in a hurry. A conversation with standards editor Dave Ragget helped convince Lie of the urgency. Running right up to the deadline, Lie had posted the first draft of his proposal ten days before the conference.


Lie had come to the Web early and enthusiastically. Early enough to have used Nicola Pellow’s line-mode browser to telnet into the very first website. And enthusiastic enough to join Berners-Lee and the web team at CERN shortly after graduating from the MIT media lab in 1992. “I heard the big bang and came running,” is how Lie puts it.

Hakon Wium Lie (Credit: Heinrich-Böll-Stiftung)

Not long after he began at CERN, the language of the web shifted. Realizing that the web’s audience could not stare at black text on a white background all day, the makers of Mosaic introduced a tag that let website creators add inline images to their website. Once the gate was open, more features rushed out. Mosaic added even more tags for colors and fonts and layout. Lie, and the team at CERN, could only sit on the sidelines and watch, a fact Lie would later comment on, saying, “It was like: ‘Darn, we need something quick, otherwise they’re going to destroy the HTML language.’”

The impending release of Netscape in 1994 offered no relief. Marc Andreessen and his team at Netscape promised a consumer-focused web browser. Berners-Lee had developed HTML—the singular language of the web—to describe documents, not to design them. To fill that gap, browsers stuffed the language of HTML with tags to allow designers to create dynamic and stylized websites.

The problem was, there was not yet a standard way of doing this. So each browser added what they felt was necessary and others were forced to either follow suit or go their own way. “As soon as images were allowed inline in HTML documents, the web became a new graphical design medium,” programmer and soon-to-be W3C member Chris Lilley posted to www-talk around that time, “If style sheets or similar information are not added to HTML, the inevitable price will be documents that only look good on a particular browser.”

Lie’s proposal—which he began working on almost as soon as he joined up at CERN—was for a second language. CHSS used style sheets: separate documents that described the visual design of HTML without affecting its structure. So you could change your HTML and your style sheet stayed the same. Change the style sheet and HTML stayed the same. Content lived in one place, and presentation in another.

There were other style sheet proposals. Rob Raisch from O’Reilly and Viola creator Pei-Yuan Wei each had their own spin. Working at CERN, where the web had been created, helped boost the profile of CHSS. Its relative simplicity also made it appealing to browser makers. The cascade in Cascading HTML Style Sheets, however, set it apart.

Each person experiences the web through a prism of their own experience. It is viewed through different devices, under different conditions. On screen readers and phones and on big screen TVs. One’s perception of how a page should look based on their situation runs in stark contrast to both the intent of the website’s author and the limitations and capabilities of browsers. The web, therefore, is chaotic. Multiple sources mingle and compete to decide the way each webpage is perceived.

The cascade brings order to the web. Through a simple set of rules, multiple parties—the browser, the user, and the website author—can define the presentation of HTML in separate style sheets. As rules flow from one style sheet to the next, the cascade balances one rule against another and determines the winner. It keeps design for the web simple, inheritable, and embraces its natural unstable state. It has changed over time, but the cascade has made the web adaptable to new computing environments.

After Lie gave his presentation on the second floor of the Ramada Hotel in Chicago, it was the cascade that monopolized discussions. The makers of the web used the CHSS proposal as a springboard for a much wider conversation about author intent and user preferences. In what situation, in other words, the author of a website’s design should override the preference of a user or the determination of a browser. Productive debate spilled outside of the room and onto the www-talk mailing list, where it was picked up by Bert Bos.

Bert Box speaking in front of a presentation slide.
Bert Bos (Credit: dotConferences)

Bos was a Dutch engineer, studying mathematics at the University of Groningen in the Netherlands. Before he graduated, he created a browser called Argo, a well-known and useful tool for several of the University’s departments. Argo was notable for two reasons. The first was that it included an early iteration of what would later be known as applets. The second was that it included Bos’ own style sheet implementation, one that was not too unlike CHSS. He recognized an opportunity.

“Most of the content of CSS1 was discussed on the whiteboard in Sophia-Antipolis in July 1995… Whenever I encounter difficult technical problems, I think of Bert and that whiteboard.”

Hakon Wium Lie

Lie and Bos began working together, merging their proposals into something more refined. The following year, in the spring of 1995, the third WWW conference was held in Darmstadt, Germany. Netscape, having just been released six months earlier, was already coasting on a new wave of popularity led by their new CEO Jim Barksdale. A few months away from the most successful IPO in history, Netscape would soon launch itself into the stratosphere, with the web riding shotgun, still adding new, non-standard HTML features whenever they could.

Lie and Bos had only ever communicated remotely. In Germany, they met in person for the first time and gave a joint presentation on a new proposal for Cascading Style Sheets, CSS (the H dropped by then).

It stood in contrast to what was available at the time. With only HTML at their disposal, web designers were forced to create “page layout via tables and Netscapisms like FONT SIZE,” as one Suck columnist wrote at the time, later quoted in a dissertation written by Lie. Table-bloated webpages were slow to load, and difficult to understand by accessible devices like screen readers. CSS solved those issues. That same writer, though not believing in its longevity, praised CSS for its “simple elegance, but also… its superfluousness and redundancy.”

Shortly after the conference, Bos joined Lie at the W3C. They began drafting a specification that summer. Lie recalls the frenzied and productive work they did fondly. “Most of the content of CSS1 was discussed on the whiteboard in Sophia-Antipolis in July 1995… Whenever I encounter difficult technical problems, I think of Bert and that whiteboard.”


Chris Wilson, in 1995, was already something of an expert in browsers. He had worked at NCSA on the Mosaic team, one of two programmers who created the Windows version. In the basement of the NCSA lab, Wilson was an eager participant in the conversations that helped define the early web.

Most of his colleagues at NCSA packed up and moved to Silicon Valley to work on Netscape’s Mosaic killer. Wilson chose something different. He settled farther north, in Seattle. His first job was with Spry, working on a Mosaic-licensed browser for their Internet In a Box package. However, as an engineer it was hard for Wilson to avoid the draw of Microsoft in Seattle. By 1995, he worked there as a software developer, and by 1996, he was moved to the Internet Explorer team just ahead of the browser’s version 2 release.

Internet Explorer was Microsoft’s late entry to the browser market. Bill Gates had notoriously sidestepped the Internet and the web for years, before completely reversing his company’s position. In that time, Netscape had captured a swiftly expanding market that didn’t exist when they started. They had released two wildly successful versions of their user-friendly, cross-platform browser. Their window to the web was adorned with built-in email, an easy install process, and a new language called JavaScript that let developers add lively animations to a web that had been previously inert.

Microsoft offered comparatively little. Internet Explorer began as a port of Mosaic, but by the time Wilson signed on, it rested on a rewritten codebase. Besides a few built-in native Microsoft features that appealed to the enterprise market, Internet Explorer had been unable to set themselves apart from the sharp focus and pace of Netscape.

Microsoft needed a differentiator. Wilson thought he had one. “There’s this thing called style sheets,” Wilson recalls telling his boss at the time, “it lets you control the fonts and you and you get to make really pretty looking pages, Netscape isn’t even looking at this stuff.” Wilson got approval to begin working on CSS on the spot.

At the time, the CSS specification wasn’t yet complete. To bridge the gap of how things were supposed to work, Wilson met regularly with Lie, Bos, and other members of the W3C. They would make edits to their draft specification, and Wilson would try it out in his browser. Rinse and repeat. Later, they even brought Vidur Apparao from Netscape into their discussions, which became more formal. Eventually, they became the CSS Working Group.

Internet Explorer 3 was released in August of 1996. It was the first browser to have any support for CSS, a language that hadn’t yet been formally recommended by the W3C. Later, that would become an issue. “There are still a lot of IE3s out there,” Lie would later say a few years after its initial release, “and since they don’t conform to the specification, it’s very hard to write a style sheet that will work well with IE3 while also working well with later browsers.”

Screenshot of a page opened in Internet Explorerversion 3. There's an illustration of a brown dog with a blue floppy disk in its mouth. Internet Explorer 3 information is open in a separate window on the right.
Internet Explorer 3 (Credit: My Internet Explorer)

At the time, however, it was imminently necessary. A working version of CSS powered by a browser at the largest tech company in the world lent stability. Table-based layouts and Netscape-only tags were still more widely adopted, but CSS now stood a chance.

By 1997, the W3C split the HTML working group into three parts, with CSS getting its own dedicated group formed from the ad-hoc Internet Explorer 3 team. It would be chaired by Chris Lilley, who came to the web as a computer graphics specialist. Lilley had pointed out years earlier the need for a standardized web technology for design. At the W3C, he would lead the effort to do just that.

The first formal Recommendation of CSS was published in December of 1997. Six months later, CSS version 2 was released.

As chair of the working group, Lilley was active on the www-talk mailing list. He’d often solicit advice or answer questions from developers. On one such exchange, he received an email from one Eric Meyer. “Hey, I threw together these test pages, I don’t know if you’d be interested in them,” was how Meyer remembers the message, adding that he didn’t realize that “there was nothing else quite like it in existence.”


Eric Meyer was at the web conference in Chicago where Håkon Lie first demoed CSS, though not at the session. He didn’t get a chance to actually see CSS until a few years later, at the fifth annual Web Conference in Paris. He was there to present a paper on web technology he had developed while working as the Case Western webmaster. His real purpose there, however, was to discover the probable future of the web.

He attended one panel featuring Håkon Lie and Bert Bos, alongside Dave Raggett. They each spoke to the capabilities of CSS as part of the W3C specification. Chris Wilson was there too, nursing a bit of a cold but nevertheless emphatically demoing a working version of CSS in Internet Explorer 3. “I’d never even heard of CSS before, but by the time that panel was over, the top of my head felt like it had blown off,” Meyer would later say, “I was instantly sold. It just felt right.”

Eric A. Meyer (Credit meyerweb.com)

Meyer got home and began experimenting with CSS. But he quickly hit a wall. He had a little more than a spec to go off of—there wasn’t such a thing as formal documentation or CSS tutorials—but something felt off. He’d code a bit of CSS and expect it to work one way, and it’d work another.

That’s when he began to pull together test pages. Meyer would isolate his code to a single feature of CSS. Then he’d test that across browsers, and document their inconsistencies, alongside how he thought they should work. “I think it was mostly the sheer joy of crawling through a new system, pulling it apart, figuring out how it worked, and documenting what worked and what didn’t. I don’t know exactly why those kinds of things excite me, but they do.” Over the years, Meyer has built a career on top of this type of experimentation.

Those test pages—posted to Meyer’s website and later to other blogs—carefully arranged and unknowingly documented the proper implementation of CSS according to its specification. Once Chris Lilley got a hold of them, the CSS Working Group helped Meyer transform them into the official W3C CSS Test Suite, an important tool to assist browsers working to introduce CSS.

Test pages and tutorials on Meyer’s personal site soon became regular columns on popular blogs. Then O’Reilly approached him about writing a book, which eventually became CSS: The Definitive Guide. Research for the book connected Meyer to the people that were building CSS inside of the W3C and browsers. He, in turn, shared what he learned with the web development community. Before long, Meyer had cemented a legacy as a central figure in the history of CSS.

His work continued. When the Web Standards Project reached out to programmer John Allsopp to form a committee dedicated to CSS, he immediately thought of Meyer. Meyer was joined by Allsopp and several others: Sue Sims, Ian Hickson, David Baron, Roland Eriksson, Ken Gunderson, Brade McDaniel, Liam Quinn and Todd Fahrner. Collectively, their official title was the CSS Action Committee, but they often went by CSS Samurai.

CSS was a properly standardized design language. If done right, it could shake loose the Netscape-only features and table-based layouts of the past. But browsers were not catching up to CSS quick enough for some developers. And when they did, it was frequently an afterthought. “You really can’t imagine, unless you lived through it, just how buggy and inconsistent and frustrating browser support for CSS was,” Meyer would later recall. The goal of the CSS Samurai was to fix that.

The committee took a familiar Web Standards Project approach, publishing public reports about lack of browser support on the one hand, and privately meeting with browser makers to discuss changes on the other. A third objective of the committee was to speak to developers directly. Grassroots education became a central goal to the work of the CSS Samurai, an effective instrument of change from the ground up.

Netscape provided the greatest hurdle. Wholly dependent on JavaScript, Netscape used a non-standard version of CSS known as JSSS, a language which by now has been largely forgotten. The browser processed style sheets dynamically using JavaScript to render the page, which made its support uneven and often slow to load. It would not be until the release of the Gecko rendering engine in the early 2000’s, that JSSS would be removed. As Netscape transformed into Mozilla in the wake of that change, it would finally come around to a functional CSS implementation.

But with other browsers, particularly with versions of Internet Explorer that were capturing larger segments of the market, WaSP proved successful. The hearts and minds of developers were with them, as they entered a new era of styling on the web.


There was at least one conversation over coffee that saved CSS. There may have been more, but the conversation in question happened in 1999, between Todd Fahrner and Tantek Çelik. Fahrner was a member of the Web Standards Project and a CSS Samurai, often on the front-lines of change. Among untold work with and for the web, he helped Meyer with the CSS Test Suite and developed a practical litmus test for CSS support known as the Acid Test.

Çelik worked at Microsoft. He was largely responsible for bringing web standards support into Internet Explorer for Mac, years before other major browsers would do the same. Çelik would have a long and lasting impact on the development of CSS. He would soon join the Web Standards Project Steering Committee. Later, as a member of the CSS Working Group, he would contribute and help edit several specifications.

On that particular day, over coffee, the topic of conversation was the web’s existential crisis. For years, browsers had added ad-hoc, uneven and incompatible versions of CSS. With a formalized Recommendation from the W3C, there was finally an objectively correct way of doing things. But if browsers took the new, correct rules from the W3C and applied them to all of the sites that had relied on the old, incorrect rules from before, they would suddenly look broken.

What they needed was a toggle. Some sort of switch that developers could turn on to signal that they wanted the new, correct rules. That day, Fahrner proposed using the doctype declaration. It’s a bit of text at the top of the HTML page that specifies a document type definition (the one Dan Connolly had spent years at the W3C standardizing). The practice became known as doctype switching. It meant that new sites could code CSS the right way, and old sites would continue to work just fine.

When Internet Explorer for Mac version 5 was released, it included doctype switching. Before long, all the browsers did. That swung the door open for standards-compliant CSS in browsers.


“We have not learned to design the Web.” So read the first line of the introduction of Molly Holzschlag’s 2003 book Cascading Style Sheets: The Designer’s Edge. It was a bold statement, not the first or the last from Holzschlag—who has had a profound and lasting impact on the evolution of the web. Throughout her career Holzschlag has been a restless advocate for people that use the web, even when that has clashed with makers of web technology. Her decades long history with the web has spanned well beyond CSS, to almost every aspect of its development and evolution.

Holzschlag goes on. “To get to this point in the web’s history, we’ve had to borrow guidelines from other media, hack and workaround our way through browser inconsistencies, and bend markup so far out of its normal shape that we’ve broken it.”

Molly Holzschlag

At the end of 2000, Netscape released the sixth version of their browser. Internet Explorer 6 came out not long after. The style sheets for these browsers were far more capable than any that had come before. But Microsoft wouldn’t release another browser for five years. Netscape, all but defeated by Microsoft, would take years to regroup and reform as the more capable and standards-compliant Firefox.

The work of the Web Standards Project and the W3C had brought a working version of CSS to the web. But it was incomplete, and often difficult to understand. And developers had to take older browsers into account, which many people still used.

In the early 2000’s, creators of the web were caught between a past riddled with inconsistency and a future that captured their imagination. “Designers and developers were pushing the bounds of what browsers were capable of,” web developer Eevee recalls about using CSS at the time, “Browsers were handling it all somewhat poorly. All the fixes and workarounds and libraries were arcane, brittle, error-prone, and/or heavy.”

Most web designers continued to rely on a combination of HTML table hacks and Netscape-specific tags to create advanced designs. Level two of CSS offered even more possibilities, but designers were hesitant to go all in and risk a bad experience for Netscape users. “Netscape Navigator 4 was holding everyone back,” developer Dave Shea would later say, “It just barely supported CSS, and certainly not in any capacity that we could start building completely table-less sites. And the business case for continued support was too strong to ignore.”

Beneath the surface, however, a vibrant and influential community spread new ideas through blogs and mailing lists and books. That community introduced clever solutions with equally clever names. The “Holly Hack” and “clearfix” from the Position is Everything, maintained by Holly Bergevin and John Gallant. Douglas Bowman’s “Sliding Doors of CSS,” Dan Webb and Patrick Griffith’s “Suckerfish Dropdowns” and Dan Ciederholm’s “Faux Columns” all came from Jeffrey Zeldman’s A List Apart blog. Even Meyer and Allsopp created the CSS Discuss mailing list as a workshop for innovative ideas and practice.

“It’s going to be the people using CSS in the next few years who will come up with the innovative design ideas we need to help drive the potential of the Web in general.”

Molly Holzschlag

And yet, so much of the energy of that community was spent on hacks and workarounds and creative solutions. The most interesting design ideas came always attached with a caveat, a bit of code to make it work in this browser or that. The first edition of CSS Anthology **by Rachel Andrew, which became a handbook for many CSS developers, featured an entire chapter on what to do about Netscape 4.

The innovators of CSS—beset by disparities difficult to explain—were forced to pick apart the language and find a way through to their designs. In the wake of that newness came a creative surge. Some of the most expressive and shrewd designs in the web’s history came out of this era.

That very same community, however, often fell to a collective preoccupation with what they could make CSS do. A culture that, at times, overvalued hacks and workarounds. Largely out of necessity, shared education focused on the how rather than the why. Too-clever techniques that sometimes outpaced their usefulness.

That would begin to change. Holzschlag ended the introduction to her book on CSS with a nod to the future. “It’s going to be the people using CSS in the next few years who will come up with the innovative design ideas we need to help drive the potential of the Web in general.”


Dave Shea was an ideological disciple of the Web Standards Project, an active member of a growing CSS community. He agreed with Holzschlag. “We entered a period where individuals could help shape the future of the web,” he would later describe the moment. Like others, he was frustrated with the limitations of browsers without CSS support.

The antidote to this type of frustration was often to have a bit of fun. Though getting larger by the day, the web design community was small and familiar. For some, it became a hobby to disseminate inspiration. Domino Shriver compiled a list of CSS designs in his site, WebNoveau, later maintained by Meryl Evans. Each day, new web pages designed with CSS would be posted to its homepage. Chris Casciano’s Daily CSS Fun amended that approach. Each day he’d post a new style sheet for the same HTML file, capturing the wide range of designs CSS made possible. In May of 2003, Shea produced his own take on the format when he launched the CSS Zen Garden. The project rested on a simple premise. Each page used exactly the same HTML file with exactly the same content. The only thing that was different was the page’s style sheet, the CSS that was applied to that HTML. Rather than create them himself, Shea solicited style sheets from developers all over the world to create a digital gallery of CSS inspiration. Designs ranged from constructed minimalism to astonishingly baroque. It was a playground to explore what was possible.

At once a source of influence, a practical demonstration of CSS advantages, and a showcase of great web design, the Zen Garden spread to the far ends of the web. What began with five designs soon turned into a website filled with dozens of different designs. And then more. “Hundreds of designers have made their mark—and sometimes their reputations—by creating Zen Garden layouts,” author Jeffrey Zeldman would later say in his book Designing with Web Standards, “and tens of thousands all over the world have learned to love CSS because of it.”

Though Zen Garden would become the most well-known, it was only one contribution to a growing oeuvre of inspiration projects on the web. Web creators wanted to look to the future.

In 2005, Shea published a book based on the project with Molly Holzschlag called The Zen of CSS Design. By then, CSS had web designers’ full attention.


In 1998, in an attempt to keep pace with Microsoft, Netscape made the decision to release their browser for free, and to open source its source code under a newly formed umbrella project known as Mozilla that would ultimately lead to the release of the Firefox browser in 2003.

David Baron and Ian Hickson both began their careers at Mozilla in the late 1990’s as volunteers, and later interns, on the Mozilla Quality Assurance team, identifying standards-compliance bugs. It was through the course of their work that they became deeply familiar not just with how CSS was supposed to work, but how, in practice, it was being used inside of a standards-driven browser. During that time, Hickson and Baron became an integral part of a growing CSS community, and joined the CSS Samurai. They helped write and run the tests for the CSS Test Suite. They became active participants in the www-style mailing list, and later, the CSS Working Group itself.

While Meyer was writing his first book, CSS: The Definitive Guide, he recalls asking Baron and Hickson for help in understanding how some parts of CSS worked. “I doubt that I will ever stop owing them for their dedication to getting me through the wilderness of my own misunderstandings,” he would later say. It was their attention to detail that would soon make them an incredible asset.

Browsers understand style sheets, the language of CSS, based on the words of the specifications at the W3C. If the language is not specific enough, or if not every edge case or feature combination has been considered, this can lead to incompatibilities among browsers. While working at the W3C, Hickson and Baron helped bring the vague language of its technical specifications into clearer focus. They made the definition of CSS more precise, consistent, and easier to implement correctly.

Their work, alongside Bert Bos, Tantek Çelik, Håkon Lie and others, led to a substantial revision of the second version of CSS, what CSS Working Group member Elika Etemad would later describe as “a long process of plugging the holes, fixing errors, and building test suites for the core CSS standard.” It was tireless work, as much about conversation with browser programmers as actual technical work and writing.

It was also a job nobody thought would take very long. There had been two versions of CSS released in a few years. A minor revision was expected to take a fraction of the time. One night at a conference a few months in, several CSS editors commented that if they stayed up late one night, they might be able to get it done before the next day. Instead, the work would take nearly a decade.

For years, Elika Etemad, then known only as ‘fantasai’, had been an active member of the www-style mailing list and Mozilla bug tracker. It had put her in conversations with browser makers, and members of the W3C. Though she had spoken with many different members of the CSS Working Group over the years, some of her most engaged and frequent discussions were with David Baron and Ian Hickson. Like Hickson and Baron, ‘fantasai’ was uncovering bugs and spec errors that no one else had noticed—and happily reporting what she found.

Elike Etemad speaking in front of a podium for CSS Day.
Elika Etemad (Credit: Web Conferences Amsterdam)

That work earned her an invite to the W3C Technical Plenary in 2004. Each year, members of the W3C working groups travel to shifting locations (2020 was the first year it was held virtually) for the event. W3C discussions are mostly done through emails and conference calls and editorial comments. For some members, the plenary is the only time they see each other face to face all year. In 2004, it was held in the south of France, in a town called Mandelieu-la-Napoule, overlooking the Bay of Cannes. It was there that Etemad met Baron and Hickson in person for the first time.

The CSS Working Group, several years into their work on CSS 2.1, invited Etemad to join them. Microsoft had all but pulled back from the standards process after the release of Internet Explorer 6 in 2001. The working group had to work with actively developed browsers like Mozilla and Opera while constrained by the stagnant IE6. They spent years ironing out the details, always feeling on the verge of completion. “We’re almost out of issues, and the new issues we are getting are usually minor stuff like typo fixes and so forth,” Hickson posted in 2006, still years away from a final specification.

During this time, the CSS Working Group was also working on something new. Hickson and Baron had learned from CSS 2.1, an exhaustive but monolithic specification. “We succeeded,” Hickson would later comment, “but boy are they insanely complicated. What we should have done instead is just break the constraints and come up with something simpler, ideally something that more closely matched what browsers implemented at the time.” Over time, the CSS Working Group began to shift their approach. Specifications would no longer be a single, immutable document. It would change over time to accommodate real-world browser implementations.

Beginning with CSS3, also transitioned to a new format to cover a wider set of features and maintain pace with browser development. CSS3 consists of a number of modules, each that addresses a single area of functionality—including color, font, text, and more advanced concepts like media queries. “Some of the CSS3 modules out there are ‘concept albums,’” ‘fantasai’ describes, “specs that are sketching out the future of CSS.” These “concepts” are developed independently and at a variable pace. Each CSS3 module has its own editors. Collectively, they have contributed to a bolder vision of CSS. Individually, they are developed alongside real-world browser implementations and, on their own, can more deftly adapt to change.

The modular approach to CSS3 would prove effective. The second decade of CSS would introduce sweeping changes and refreshing new features. The second decade of CSS would be different than the first. New features would lead to new designs, and eventually, a new web.


The post Chapter 8: CSS appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

Categories: Designing, Others Tags:

3 Essential Design Trends, May 2021

May 3rd, 2021 No comments

Spring and fresh designs are in the air. This month, it’s obvious that designers are feeling creative with new and interesting concepts that range from a new style for cards, homepage experimentation with multiple entry points or calls to action, and risky typography options.

Here’s what’s trending in design this month.

1. “Flat” Cards

Card-style design elements that allow users to click through to other content aren’t new, but the design of these cards is fresh and interesting.

Rather than more heavily designed cards with shadows and layers of content, flat styles are trending. Expect this trend to explode thanks to usage by Google for a shopping experience page.

The Google example below is interesting because Google’s Material Design guidelines are what helped card-style elements grow in popularity previously. However, those cards did include more layers, color options, buttons inside the cards, and shadows.

Today’s trending cards are completely flat. And beautiful.

Each of these websites does it in a slightly different way.

Heartcore, a consumer technology VC company, uses a series of flat cards as a navigation element to help users find their way through the website. Each features a bright color background with an illustration and a simple text block.

Each card has a nice hover state where only the illustration zooms inside the card frame. This is an interesting effect because it is exactly the opposite of the previous iteration of cards, which zoomed the entire card as a hover state.

Google Shopping uses that whole card bounce hover state (plus a not-so-flat shadow) for each card. The initial design is sleek with the pairing of white and image cards with simple text in each. You are enticed to click around to see what happens.

Click on Greece is a travel website design that uses simple cards with a minimal color and text overlay. The consistency of these cards makes the design pop and the beauty of the images draw you in. Each card also has a hover state with a darker color mask to guide navigation and make text elements easier to read.

2. Multiple Homepage Entry Points

For a long time, designers have been working off the philosophy that the homepage should have one direct entry point, creating a direct funnel for the user experience.

These designs throw that idea out the window, with multiple entry points and click elements.

You can think of it as the “create your own adventure” option for these designs.

It can be a risky concept if you are diving into analytics to pay attention to user paths. You want to make sure you know what choices users are making so that you can help them on the journey to the content and information that you want them to get from the visit.

But this type of design scheme does feel somewhat personalized, putting the user in more control.

Parcouse Epicuriens uses three flat card-style elements to help users pick what they want to see from the home page. There’s no other button or direct call to action, which is somewhat uncommon in today’s website design landscape. Users have to pick from one of the cards, scroll, or enter using the hamburger menu icon.

Tasty Find uses search options to help users start their journey. What’s interesting here are the choices – search for the food you want, pick something random, or (in the small print) find even more options. Users get three choices to begin their journey with the website.

What’s interesting is how simple this complex user journey looks. The design is easy to digest, but so many options could overwhelm users. This is one of those situations where you have to watch return search data and information and weigh the risk versus the reward of so much choice. It’ll be interesting to watch this design over time and see if the options decrease in number.

Accord also has several levels of user engagement opportunity. Option 1: Every block contains a click element. Option 2: Use the search at the top to narrow choices. This is an interesting configuration as the homepage for an e-commerce website because they get right to product selection and shopping without a softer sell or introduction.

3. Risky Typography

Typographic risk has been an ongoing theme for a little while. Designers are embracing experimental and novelty typefaces to stand out in the cluttered website space. Sometimes it works beautifully, and other times, it can fall short.

Here, each of these trending website designs uses a risky typography treatment. The risks are a little different for each design, from readability to comprehension to font delivery.

How Many Plants has duel typography risks: A funky typeface paired with odd word breaks. Interestingly enough, readability isn’t as big of a concern as you might think. This is likely because there aren’t many words, and they are short. Plus, the imagery ties in nicely.

Do you notice a similarity between How Many Plants and The Great Lake? The typography has the same style with a blocky, slab, sans serif with alternating thick and thin strokes. (It’s the same font.)

The risk in the typography design for The Great Lake isn’t in the homepage display, although you might wonder what the design is about. It is carrying this font throughout the design. While it looks great large and with only a few words, it gets a little more difficult the more you see it. This type of mental reading weight can be difficult for visitors over time, creating an element of risk.

Zmaslo uses an interesting typeface with a liquid effect on top of an unusual word. That combination of text elements makes you think hard to read the homepage, despite its neat looks. The risk here is weighing visual interest against comprehension. Depending on the audience, this risk can be worth the chance.

Conclusion

Spring always seems to be that time of year where designers start thinking about new, fresh design elements. That might explain some of the “riskier” design choices and experimentation here.

Regardless of the motivation, it is always fun to see the creative stretch happen. It can be even more interesting to see what elements from these trends continue to grow in the coming months.

Source

The post 3 Essential Design Trends, May 2021 first appeared on Webdesigner Depot.

Categories: Designing, Others Tags:

Swipey Image Grids

May 3rd, 2021 No comments

I hope people think of SVG as a vector format that is good for drawing things. There is plenty more to know, but here’s one more: SVG is good for composition. You draw things at very specific coordinates in SVG and, while they can scale, they tend to stay put. And while SVG is a vector format, you can place raster images onto it. That’s my favorite part of Cassie’s “Swipey image grids” post. The swipey part is cool, but the composition is even cooler.

<svg viewBox="0 0 100 100">
  <rect x="30" y="0" width="70" height="50" fill="blue"/>
  <rect x="60" y="60" width="40" height="40" fill="green"/>
  <rect x="0" y="30" width="50" height="70" fill="pink"/>

  <image x="30" y="0" width="70" height="50" href="https://place-puppy.com/300x300"/>
  <image x="60" y="60" width="40" height="40" href="https://place-puppy.com/700x300"/>
  <image x="0" y="30" width="50" height="70" href="https://place-puppy.com/800x500"/>
</svg>

You’ll need to check this out in Chrome, Edge or Firefox:

CodePen Embed Fallback

Don’t miss Cassie’s interactive examples explaining preserveAspectRatio. That’s a thing I normally think of on the itself, but is used to great effect on the elements themselves here. It’s like a more powerful object-fit and object-position.

Direct Link to ArticlePermalink


The post Swipey Image Grids appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

Categories: Designing, Others Tags:

Popular Design News of the Week: April 26, 2021 – May 2, 2021

May 2nd, 2021 No comments

Every day design fans submit incredible industry stories to our sister-site, Webdesigner News. Our colleagues sift through it, selecting the very best stories from the design, UX, tech, and development worlds and posting them live on the site.

The best way to keep up with the most important stories for web professionals is to subscribe to Webdesigner News or check out the site regularly. However, in case you missed a day this week, here’s a handy compilation of the top curated stories from the last seven days. Enjoy!

Curated List Of Awesome Lists

20 Best New Websites, April 2021

I Studied The Fonts Of The Top 1000 Websites; Here’s What I Learned

Markdown To Slideshow

WordPress Checklist: 17 Steps to Launching Your Site

Understanding Easing Functions For CSS Animations And Transitions

This is Tech! Illustrations About Technical Processes

This Amazing AI Tool Lets You Create Human Faces From Scratch

When You Shouldn’t Display Radio Buttons in a List Format

Lightweight, Privacy-First, Open-Source Comment System

8 Stunning Examples of CSS Glassmorphism Effects

CSS Tips

Source

The post Popular Design News of the Week: April 26, 2021 – May 2, 2021 first appeared on Webdesigner Depot.

Categories: Designing, Others Tags: