Category: Design

A/B Testing Instant.Page With Netlify and Speedcurve

Instant.Page does one special thing to make sites faster: it preloads the next page when it’s pretty sure you’re going to click a link (either by hovering over 65ms or mousedown on desktop, or touchstart on mobile), so when you do complete the click (probably a few hundred milliseconds later), it loads that much faster.

It’s one thing to understand that approach, buy into it, integrate it, and consider it a perf win. I have it installed here!

It’s another thing to actually get the data on your own site. Leave it to Tim Kadlec to get clever and A/B test it. Tim was able to do a 50/50 A/B split with performance-neutral Netlify split testing. Half loaded Instant.Page, the other half didn’t. And the same halves told SpeedCurve which half they were in, so performance charts could be built to compare.

Tim says it mostly looks good, but his site probably isn’t the best test:

It’s also worth noting that even if the results do look good, just because it does or doesn’t make an impact on my site doesn’t mean it won’t have a different impact elsewhere. My site has a short session length, typically, and very lightweight pages: putting this on a larger commercial site would inevitably yield much different results.

I’d love to see someone do this on a beefier site. I’m in the how could it not be faster?! camp, but with zero data.

Direct Link to ArticlePermalink

The post A/B Testing Instant.Page With Netlify and Speedcurve appeared first on CSS-Tricks.


, , ,

The Intriguing Wool Portraits by Salman Khoshroo


How I Used Brotli to Get Even Smaller CSS and JavaScript Files at CDN Scale

The HBO sitcom Silicon Valley hilariously followed Pied Piper, a team of developers with startup dreams to create a compression algorithm so powerful that high-quality streaming and file storage concerns would become a thing of the past.

In the show, Google is portrayed by the fictional company Hooli, which is after Pied Piper’s intellectual property. The funny thing is that, while being far from a startup, Google does indeed have a powerful compression engine in real life called Brotli

This article is about my experience using Brotli at production scale. Despite being really expensive and a truly unfeasible method for on-the-fly compression, Brotli is actually very economical and saves cost on many fronts, especially when compared with gzip or lower compression levels of Brotli (which we’ll get into).

Brotli’s beginning…

In 2015, Google published a blog post announcing Brotli and released its source code on GitHub. The pair of developers who created Brotli also created Google’s Zopfli compression two years earlier. But where Zopfli leveraged existing compression techniques, Brotli was written from the ground-up and squarely focused on text compression to benefit static web assets, like HTML, CSS, JavaScript and even web fonts.

At that time, I was working as a freelance website performance consultant. I was really excited for the 20-26% improvement Brotli promised over Zopfli. Zopfli in itself is a dense implementation of the deflate compressor compared with zlib’s standard implementation, so the claim of up to 26% was quite impressive. And what’s zlib? It’s essentially the same as gzip.

So what we’re looking at is the next generation of Zopfli, which is an offshoot of zlib, which is essentially gzip.

A story of disappointment

It took a few months for major CDN players to support Brotli, but meanwhile it was seeing widespread adoption in tools, services, browsers and servers. However, the 26% dense compression that Brotli promised was never reflected in production. Some CDNs set a lower compression level internally while others supported Brotli at origin so that they only support it if it was enabled manually at the origin.

Server support for Brotli was pretty good, but to achieve high compression levels, it required rolling your own pre-compression code or using a server module to do it for you — which is not always an option, especially in the case of shared hosting services.

This was really disappointing for me. I wanted to compress every last possible byte for my clients’ websites in a drive to make them faster, but using pre-compression and allowing clients to update files on demand simultaneously was not always easy.

Taking matters into my own hands

I started building my own performance optimization service for my clients.

I had several tricks that could significantly speed up websites. The service categorized all the optimizations in three groups consisting of several “Content,” “Delivery,” and “Cache” optimizations. I had Brotli in mind for the content optimization part of the service for compressible resources.

Like other compression formats, Brotli comes in different levels of power. Brotli’s max level is exactly like the max volume of the guitar amps in This is Spinal Tap: it goes to 11.

Brotli:11, or Brotli compression level 11, can offer significant reduction in the size of compressible files, but has a substantial trade-off: it is painfully slow and not feasible for on demand compression the same way gzip is capable of doing it. It costs significantly more in terms of CPU time.

In my benchmarks, Brotli:11 takes several hundred milliseconds to compress a single minified jQuery file. So, the only way to offer Brotli:11 to my clients was to use it for pre-compression, leaving me to figure out a way to cache files at the server level. Luckily we already had that in place. The only problem was the fear that Brotli could kill all our processing resources.

Maybe that’s why Pied Piper had to continue rigging its servers for more power.

I put my fears aside and built Brotli:11 as a configurable server option. This way, clients could decide whether enabling it was worth the computing cost.

It’s slow, but gradually pays off

Among several other optimizations, the service for my clients also offers geographic content delivery; in other words, it has a built-in CDN.

Of the several tricks I tried when taking matters into my own hands, one was to combine public CDN (or open-source CDN) and private CDN on a single host so that websites can enjoy the benefits of shared browser cache of public resources without incurring separate DNS lookup and connection cost for that public host. I wanted to avoid this extra connection cost because it has significant impact for mobile users. Also, combining more and more resources on a single host can help get the most of HTTP/2 features, like multiplexing.

I enabled the public CDN and turned on Brotli:11 pre-compression for all compressible resources, including CSS, JavaScript, SVG, and TTF, among other types of files. The overhead of compression did indeed increase on first request of each resource — but after that, everything seemed to run smoothly. Brotli has over 90% browser support and pretty much all the requests hitting my service now use Brotli.

I was happy. Clients were happy. But I didn’t have numbers. I started analyzing the impact of enabling this high density compression on public resources. For this, I recorded file transfer sizes of several popular libraries — including jQuery, Bootstrap, React, and other frameworks — that used common compression methods implemented by other CDNs and found that Brotli:11 compression was saving around 21% compared to other compression formats.

It’s important to note that some of the other public CDNs I compared were already using Brotli, but at lower compression levels. So, the 21% extra compression was really satisfying for me. This number is based on a very small subset of libraries but is not incorrect by a big margin as I was seeing this much gain on all of the websites that I tested.

Here is a graphical representation of the savings.

Vertical bar chart. Compares jQuery, Bootstrap, D3.js, Ant Design, Senamtic UI, Font Awesome, React, Three.js, Bulma and Vue before and after Brotli compression. Brotli compression is always smaller.

You can see the raw data below..Note that the savings for CSS is much more prominent than what JavaScript gets.

Library Original Avg. of Common Compression (A) Brotli:11 (B) (A) / (B) – 1
Ant Design 1,938.99 KB 438.24 KB 362.82 KB 20.79%
Bootstrap 152.11 KB 24.20 KB 17.30 KB 39.88%
Bulma 186.13 KB 23.40 KB 19.30 KB 21.24%
D3.js 236.82 KB 74.51 KB 65.75 KB 13.32%
Font Awesome 1,104.04 KB 422.56 KB 331.12 KB 27.62%
jQuery 86.08 KB 30.31 KB 27.65 KB 9.62%
React 105.47 KB 33.33 KB 30.28 KB 10.07%
Semantic UI 613.78 KB 91.93 KB 78.25 KB 17.48%
three.js 562.75 KB 134.01 KB 114.44 KB 17.10%
Vue.js 91.48 KB 33.17 KB 30.58 KB 8.47%

The results are great, which is what I expected. But what about the overall impact of using Brotli:11 at scale? Turns out that using Brotli:11 for all public resources reduces cost all around:

  • The smaller file sizes are expected to result in lower TLS overhead. That said, it is not easily measurable, nor is it significant for my service because modern CPUs are very fast at encryption. Still, I believe there is some tiny and repeated saving on account of encryption for every request as smaller files encrypt faster.
  • It reduces the bandwidth cost. The 21% savings I got across the board is the case in point. And, remember, savings are not a one-time thing. Each request counts as cost, so the 21% savings is repeated time and again, creating a snowball savings for the cost of bandwidth. 
  • We only cache hot files in memory at edge servers. Due to the widespread browser support for Brotli, these hot files are mostly encoded by Brotli and their small size lets us fit more of them in available memory.
  • Visitors, especially those on mobile devices, enjoy reduced data transfer. This results in less battery use and savings on data charges. That’s a huge win that gets passed on to the users of our clients!

This is all so good. The cost we save per request is not significant, but considering we have a near zero cache miss rate for public resources, we can easily amortize the initial high cost of compression in next several hundred requests. After that,  we’re looking at a lifetime benefit of reduced overhead.

It doesn’t end there

With the mix of public and private CDNs that we introduced as part of our performance optimization service, we wanted to make sure that clients could set lower compression levels for resources that frequently change over time (like custom CSS and JavaScript) on the private CDN and automatically switch to the public CDN for open-source resources that change less often and have pre-configured Brotli:11. This way, our clients can still get a high compression ratio on resources that change less often while still enjoying good compression ratios with instant purge and updates for compressible resources.

This all is done smoothly and seamlessly using our integration tools. The added benefit of this approach for clients is that the bandwidth on the public CDN is totally free with unprecedented performance levels.

Try it yourself!

Testing on a common website, using aggressive compression can easily shave around 50 KB off the page load. If you want to play with the free public CDN and enjoy smaller CSS and JavaScript, you are welcome to use our PageCDN service. Here are some of the most used libraries for your use:

<!-- jQuery 3.5.0 --> <script src="" crossorigin="anonymous" integrity="sha256-xNzN2a4ltkB44Mc/Jz3pT4iU1cmeR0FkXs4pru/JxaQ=" ></script> 
 <!-- FontAwesome 5.13.0 --> <link href="" rel="stylesheet" crossorigin="anonymous" integrity="sha256-h20CPZ0QyXlBuAw7A+KluUYx/3pK+c7lYEpqLTlxjYQ=" > 
 <!-- Ionicons 4.6.3 --> <link href="" rel="stylesheet" crossorigin="anonymous" integrity="sha256-UUDuVsOnvDZHzqNIznkKeDGtWZ/Bw9ZlW+26xqKLV7c=" > 
 <!-- Bootstrap 4.4.1 --> <link href="" rel="stylesheet" crossorigin="anonymous" integrity="sha256-L/W5Wfqfa0sdBNIKN9cG6QA5F2qx4qICmU2VgLruv9Y=" > 
 <!-- React 16.13.1 --> <script src="" crossorigin="anonymous" integrity="sha256-yUhvEmYVhZ/GGshIQKArLvySDSh6cdmdcIx0spR3UP4=" ></script> 
 <!-- Vue 2.6.11 --> <script src="" crossorigin="anonymous" integrity="sha256-ngFW3UnAN0Tnm76mDuu7uUtYEcG3G5H1+zioJw3t+68=" ></script>

Our PHP library automatic switches between private and public CDN if you need it to. The same feature is implemented seamlessly in our WordPress plugin that automatically loads public resources over Public CDN. Both of these tools allow full access to the free public CDN. Libraries for JavaScript, Python. and Ruby are not yet available. If you contribute any such library to our Public CDN, I will be happy to list it in our docs.

Additionally, you can use our search tool to immediately find a corresponding resource on the public CDN by supplying a URL of a resource on your website. If none of these tools work for you, then you can check the relevant library page and pick the URLs you want.

Looking toward the future

We started by hosting only the most popular libraries in order to prevent malware spread. However, things are changing rapidly and we add new libraries as our users suggest them to us. You are welcome to suggest your favorite ones, too. If you still want to link to a public or private Github repo that is not yet available on our public CDN, you can use our private CDN to connect to a repo and import all new releases as they appear on GitHub and then apply your own aggressive optimizations before delivery.

What do you think?

Everything we covered here is solely based on my personal experience working with Brotli compression at CDN scale. It just happens to be an introduction to my public CDN as well. We are still a small service and our client websites are only in the hundreds. Still, at this scale the aggressive compression seems to pay off.

I achieved high quality results for my clients and now you can use this free service for your websites as well. And, if you like it, please leave feedback at my email and recommend it to others.

The post How I Used Brotli to Get Even Smaller CSS and JavaScript Files at CDN Scale appeared first on CSS-Tricks.


, , , , , ,

Understand why CSS has no effect with the Inactive CSS rules indicator in Firefox DevTools

It’s useful when DevTools tells you that a declaration is invalid. For example, colr: red; isn’t valid because colr isn’t a valid property. Likewise color: rd; isn’t valid because rd isn’t a valid value. For the most part, a browser’s DevTools shows the declaration as crossed out with a warning () icon. It would be nice if they went a step further to tell you which thing was wrong (or both) and suggest likely fixes, but hey, I don’t wanna look a gift horse in the mouth.

Firefox is starting to go a step further in telling you when certain declarations aren’t valid, not because of a syntax error, but because they don’t meet other qualifications. For example, I tossed a grid-column-gap: 1rem on a random <p> and I was told this in a little popup:

grid-column-gap has no effect on this element since it’s not a flex container, a grid container, or a multi-column container.

Try adding either display:grid, display:flex, or columns:2. Learn more

Well that’s awful handy.

Elijah Manor has a blog post and video digging into this a bit.

Direct Link to ArticlePermalink

The post Understand why CSS has no effect with the Inactive CSS rules indicator in Firefox DevTools appeared first on CSS-Tricks.


, , , , , ,

A Primer on Display Advertising for Web Designers

A lot of websites (this one included) rely on advertising as an important revenue source. Those ad placements directly impact the interfaces we build and interact with every day. Building layouts with ads in them is a dance of handling them in fluid environments, and also balancing the need to showcase our content and highlight the ads to make sure they are effective.

In this post, I am going to share a few tips and ideas for integrating ad units into layouts. We’ll take a look at some placement options where we might consider or commonly expect to place advertisements in webpages, then move into styling strategies.

I might use some modern CSS properties along the way that are not fully supported in older browsers. Take a look at @supports if you wish to support old browsers in a progressive enhancement friendly way.

Common Digital Ad Placements

There are many, many different places we can drop ads onto a page and an infinite number of sizes and proportions we could use. That said, there are standard placements and sizes that are commonly used to help establish a baseline that can be used to set pricing and compare metrics across the industry. We’ll cover a few of them here, though you can see just how many options and variations are in the wild.

The Navigation Bar Placement

The space right above the main navigation of a site is often a great placement to put an advertisement. It’s great because — in many cases — navigation is at the top of the page, providing a prominent location that both lends itself to using a full-width layout and lots of user interaction. That’s often why we see other types of important content, like alerts and notifications, occupy this space.

The easiest way to do this is simply placing the ad element above the navigation and call it a day. But what if we want to “stick” the navigation to the top of the page once the ad scrolls out of view?

Here we’re using position: sticky to get that effect on the navigation. As documented by MDN, a sticky element is where:

The element is positioned according to the normal flow of the document, and then offset relative to its nearest scrolling ancestor (and containing block).

It might be tempting to use fixed positioning instead, but that removes the navigation from the normal document flow. As a result, it gets fixed to the top of the viewport and stays there as you scroll. That makes sticky a more viable method with a smoother user experience.

A fixed element literally stays put while it remains in view, while a sticky element is able to “stick” to the top when it reaches there, then “unstick” upon return.

Now, we could do the reverse where the ad is the sticky element instead of the navigation. That’s something you’ll need to weigh because hiding the navigation from view could be poor UX in certain designs, not to mention how persistent advertisements could interfere with the content itself. In other words, tread carefully.

The Header Placement

Displaying ads in the site header is another place we commonly bump into advertisements. There are two widely used patterns using the header placement. In advertising industry jargon, they’re referred to as:

  • Billboard: A rectangular ad that is presented as a main call-to-action These are typically 970⨉250. We could use the widest size there, 970px, to set the size of a site’s main content area.
  • Leaderboard: An ad that is wide, short, and often shares space with another element. These are typically 728⨉90.

The billboard spot, despite being large, is rarely used (estimated at only 2% of sites), but they do command higher rates The leaderboard is far and away the most widely used digital ad size, with a 2019 SEMrush study citing 36% of publishers using leaderboards and 57% of advertisers purchasing them.

The nice thing about a leaderboard is that, even if we use the same 970px container width that the billboard ad command, we still have enough room for another element, such as a logo. I tend to use flexbox to separate the site logo from the ad. I also give the container a fixed height that either equals or is greater than the 90px leaderboard height.

.header .container {   /* Avoid content jumping */   height: 90px;   /* Flexibility */   display: flex;   align-items: center;   justify-content: space-between; }

The Sidebar Placement

The mid page unit ad (also known as medium rectangle) weighs in at 300⨉250 and is the top-performing ad unit — literally #1!

Google study of 2018 clickthrough rates (clicks per thousand views) compared for different ad placements. Google no longer provides these stats. (Source:Smart Insights)

Mid page units have influenced the design of sidebars on sites for a long time. Again, you can see an example right here on CSS-Tricks. 

Crack that open in DevTools and you will see that it has a rendered width of exactly 300px.

We can achieve the same thing using CSS grid:

Let’s say this is the markup of our layout:

<div class="wrapper">   <main>Main content</main>   <aside>Sidebar</aside> </div>

We can set the wrapper as our grid container and define two columns, the second of which is the exact 300px width of our ad unit:

.wrapper {   display: grid;   grid-template-columns: minmax(0, 1fr) 300px; }

If we aren’t displaying too many ads in the sidebar and want to draw more attention to them, we can try using the same sticky technique we did with the navigation placement:

<div class="wrapper">   <main>Main content</main>   <aside>     <div class="is-sticky">Sidebar</div>   </aside> </div>
.is-sticky {   position: sticky;   top: 0; }

But you must keep in mind that it will affect reach if the sidebar is longer than the viewport or when using a dynamic sidebar:

(View demo)

There are two ways I tend to solve this issue. The first is to keep it simple and only make important ads sticky. It’s the same concept applied to the CSS-Tricks sidebar, the only difference is that JavaScript toggles the visibility:

The second is to use a JavaScript library that includes scrolling behavior that can be used to listen for when the user reaches the end of the sidebar before triggering the sticky positioning:

There are other considerations when working with ads in the sidebar. For example, let’s say the ad we get is smaller than expected or the script that serves the ads fails for some reason. This could result in dreaded whitespace and none of the approaches we’ve looked at so far would handle that.

Where’d the widget go? The disable button is a simulation for an ad blocker.

Here’s how I’ve tackled this issue in the past. First, our markup:

<header class="header">   <div class="container">      <div class="header-content"> ... </div>          <aside class="aside">       <div class="aside-ad"> ... </div>       <div class="aside-content"> ... </div>     </aside>    </div> </header>

Then, we set the right measurements for the grid columns:

.header .container {   display: grid;   grid-template-columns: minmax(0, 1fr) 300px;   grid-gap: 24px;   min-height: 600px; /* Max height of the half-page ad */ }

Now let’s make the sidebar itself a flexible container that’s the exact width and height that we exact the ad to be, but hides any content that overflows it.

.aside {   display: flex;   flex-direction: column;   overflow: hidden;   height: 600px;   width: 300px; }

Finally, we can style the .aside-content element so that it is capable of vertical scrolling in the event that we need to display the widget:

.aside-content {   overflow-y: auto; }

Now, we’ve accounted for situations where the size of the ad changes on us or when we need fallback content.

No more whitespace, no matter what happens with our ad!

Styling Digital Ads

Now that we’ve looked at placements, let’s turn our attention to styling digital ads. It’s always a good idea to style ads, particularly for two reasons:

  1. Styling ads can help them feel like a native part of a website.
  2. Styling ads can make them more compelling to users.

Here are a few tips we can leverage to get the most from ads:

  • Use a flexible layout so things look good with or without ads. Let’s say an image doesn’t load for some reason or suddenly needs to be removed from the site. Rather than having to refactor a bunch of markup, it’s ideal to use modern CSS layout techniques, like flexbox and grid, that can adapt to content changes and reflow content, as needed.
  • Use styling that is consistent with the site design. Ads that look like they belong on a site are not only easier on the eye, but they leverage the trust that’s been established between the site and its readers. An ad that feels out of place not only runs the risk of looking spammy, but could compromise user trust as well.
  • Use a clear call to action. Ads should provoke action and that action should be easy to identify. Muddying the waters with overbearing graphics or too much text may negatively impact an ad’s overall performance.
  • Use accurate language. While we’re on the topic of content, make sure the ad delivers on its promises and sets good expectations for users. There’s nothing more annoying than expecting to get one thing when clicking on something only to be sold something else.
  • Use high-res images. Many ads rely on images to draw attention and emphasize content. When we’re working with ads that contain images, particularly smaller ad placements, it’s a good idea to use high-resolution images so they are crystal clear. The common way to do that is to make an image twice the size of the space to double its pixel density when it renders.

When working with custom ads where you have control over how they are implemented, like the ones here on CSS-Tricks, it’s a lot easier to adapt them to a specific layout and design. However, in cases where they are injected dynamically, say with a script, it might not be possible to wrap them in a div that can be used for styling; tactics like using ::before and ::after pseudo-elements as well as [attribute^=value] selectors are your friend in these situations.

Many advertising platforms will generate a unique ID for each ad unit which is great. They often start with the same prefix that we can use to target our styles:

[id^="prefix-"] {   /* your style */ }

Handling Responsive Ads

Ad platforms that provide a script to inject ads will often handle responsive sizing by bundling their own styles and such. But, when that’s not the case, or when we have complete control over the ads, then accounting for how they display on different screen sizes is crucial. Proper responsive handling ensures that ads have a clear call-to-action at any screen size.

Flexbox, Grid and nth-child

One thing we can do is re-order where an ad displays. Again, flexbox and grid are great CSS techniques to lean on because they employ the order property, which can change the visual placement of the ad without affecting the order of the actual source code.

In this example, we will try to reorder our items so the ad is visible “above the fold,” which is a fancy way of saying somewhere at the top of the page before the user needs to start scrolling.

Here’s our markup: 

<div class="items">   <div class="ad">...</div>   <div class="item">...</div>   <div class="item">...</div>   <!-- and so on... --> </div>

We can use :nth-child to select one or more items based on their source order, according to a formula:

.items {   display: grid;   /* ... */ } 
 .item:nth-child(-n+2) {   order: -1; } 
 @media only screen and (min-width: 768px) {   .article:nth-child(-n+3) {     order: -1;   } }

This selector will target the first n elements and set their order to a negative value. This allows the ad to dive between the items depending on the size of the viewport:

Handling Static Ads

Not all ads can be perfectly flexible… or are even designed to be that way. We can still sprinkle in some responsive behavior to ensure they still work with a layout at any given screen size.

For example, we can place the ad in a flexible container and hide the parts of the ad that overflow it.

Obviously, there’s a good deal of design strategy needed for something like this. Notice how the important ad content is flush to the left and the right is simply cut off.

Here’s the markup for our flexible container:

<div class="ad">   <img src="" alt="728x90" /> </div>

Depending on whether the ad’s important content is on the left or right of the ad layout, we can justify the container content either to flex-start, flex-end, or even center, while hiding the overflowing portion.

.ad {   display: flex;   justify-content: flex-end; /* depending on the side your important content live */   overflow: hidden; }

Handling Responsive Images

While ads aren’t always made from static images, many of them are. This gives us an opportunity to put the  <picture> tag to use, which gives us more flexibility to tell the browser to use specific images at specific viewport sizes in order to fill the space as nicely as possible.

<picture>   <!-- Use the ad_728x90.jpg file at 768px and above  -->   <source media="(min-width: 768px)" srcset="ad_728x90.jpg">   <!-- The default file -->   <img src="ad_300x250"> </picture>

We covered it a little earlier, but using high-resolution versions of an image creates a sharper image, especially on high-DPI screen. The <picture> element can help with that. It’s especially nice because it allows us to serve a more optimized image for low-resolution screens that are often associated with slower internet speeds.

Another thing you can do is using srcset to support multiple display resolutions which will allow the browser to choose the appropriate image resolution:

<img srcset="ad_300x250@2.jpg, ad_300x250@2.jpg 2x" src="ad_300x250_fallback.jpg" />

We can even combine the two:

<picture>   <!-- ... -->   <source media="(min-width: 768px)" srcset="ad_728x90.jpg, ad_728x90@2.jpg 2x" />   <!-- ... -->   <img srcset="ad_300x250@2.jpg, ad_300x250@2.jpg 2x" src="ad_300x250_fallback.jpg" /> </picture>

Let’s make sure we set the right width for the ad:

.selector {   width: 250px; }

And let’s use media queries for <picture> to handle the different assets/sizes:

.selector {   width: 300px;   height: 250px; } 
 @media (min-width: 768px) {   .responsive-ad {     width: 728px;     height: 90px;   } }

For more flexibility, we can make the image responsive in relation to its parent container:

.selector img {   display: block;   width: 250px;   height: auto; }

In the case of srcset, there’s no need to worry much about performance because the browser will only download the needed asset for a specific resolution.

Phew, there’s so much to consider when it comes to display advertising! Different types, different sizes, different variations, different layouts, different formats, different viewport sizes… and this is by no means a comprehensive guide to all-things-advertising.

But hopefully this helps you understand the elements that make for effective ads as a site publisher, especially if you are considering ads for your own site. What we’ve covered here should certainly get you started and help you make decisions to get the most from having ads on a site while maintaining a good user experience.

The post A Primer on Display Advertising for Web Designers appeared first on CSS-Tricks.


, , ,

How to Create a High Converting Landing Page: 3 Crucial Considerations


Optimum Type: A Big Book Filled With Typographic Inspiration


Adding CSS to a Page via HTTP Headers

Only Firefox supports it, but if you return a request with a header like this:

Header add Link "<style.css>;rel=stylesheet;media=all"

…that will link to that stylesheet without you having to do it in the HTML. Louis Lazaris digs into it:

[…] the only thing I can think of that could justify use for this in production is as a way to include some Firefox-only CSS, which Eric Meyer mentions as a possibility in an old post on this subject. But it’s not guaranteed to always only work in Firefox, so that’s still a problem.

Do with this what you like, but it’s extremely unlikely that this will have any use in a real project.

I appreciate some classic CSS trickery.

Direct Link to ArticlePermalink

The post Adding CSS to a Page via HTTP Headers appeared first on CSS-Tricks.


, , ,

The Best Design System Tool is Slack

There’s a series questions I have struggled with for as long as I can remember. The questions have to do with how design systems work: Where should we document things? Do we make a separate app? Do we use a third-party tool to document our components? How should that tie into Figma or Sketch? What about written documentation? Should we invest a lot of time into making a giant Polaris-like wiki of how to build things?

The issue with all these tools and links and repositories is that it can become increasingly difficult to remember where to go for what kind of information. Designers should go here and engineers should go there — unless, of course, you’re an iOS engineer, then you need this special resource instead. It can be overwhelming and confusing for everyone that doesn’t live within the orbit of design systems drama and is just trying to ship a feature on time.

After years of struggling with these questions, I think my current advice to my past (and current) self is this: meet the people where they are. And where are most people asking questions about design systems, whether that’s a color variable or a component or a design pattern?

In Slack!

The other day I thought it would be neat to set up some Slackbot custom responses to do a rather simple thing. When someone types color me into a channel, I all the color variables and their hex values are pasted. That way, no one needs to learn a new tool or bookmark yet another link.

Here’s how it works.

We first have to open up the settings of the organization you’re in and click the “Customize” item in this dropdown:

That pops open a new tab with the “Customize your Workspace” settings. If you select “Slackbot” from the options, then you can then see all of the custom responses that have been set up already. From there, we can create a new response like this:

That n is what breaks things onto a new line so that I can now test it out in a chat with myself once I’ve saved this:

Because this takes up so much darn space, I also made separate answers for each color, like blue and purple. But all of this has me wondering: how else can we use Slack — or whatever chat app or communication tool — to extend the cause of good design systems work?

I bet there’s a ton of other things we can do to improve our lives within tools like this and make design systems work even easier.

The post The Best Design System Tool is Slack appeared first on CSS-Tricks.


, , , ,

On fixed elements and backgrounds

After just playing with apsect-ratio and being pleasantly surprised at how intuitive it is, here’s an example of CSS acting unintuitively:

If you have a fixed element on your page, which means it doesn’t move when you scroll, you might realise that it no longer acts fixed if you apply a CSS filter on its nearest ancestor. Go ahead, try it on the CodePen.

This is because applying a filter on the fixed element’s immediate parent makes it becoming the containing block instead of the viewport.

Hui Jing has more to teach in there about scrolling, rendering performance, and trickery with using pseudo elements to avoid issues.

I find this kind of thing among the most challenging CSS concepts to wrap my mind around, like Block Formatting Contexts (BFCs). A BFC Is A Mini Layout In Your Layout. 🤯

Direct Link to ArticlePermalink

The post On fixed elements and backgrounds appeared first on CSS-Tricks.


, ,