Tag: Content

Using a brightness() filter to generically highlight content

Rick Strahl:

I can’t tell you how many times over the years I’ve implemented a custom ‘button’ like CSS implementation. Over the years I’ve used images, backgrounds, gradients, and opacity to effectively ‘highlight’ a control. All that works of course, but the problem with most of these approaches is that one way or the other you’re hard coding a color value, image, or gradient.

You certainly have a lot more control if you specify exact colors, but if you can pull off brightening, darkening, or even a hue-shift in a way that feels cohesive on your site, it’s certainly a lot less code to maintain,

.button.specific-button {   background: #4CAF50; } .button.specific-button:focus, .button.specific-button:hover {   background: #A5D6A7; }  /* vs. */ .button:focus, .button:hover {   filter: brightness(120%); }  /* or maybe you're super hardcore and do it everywhere */ :focus, :hover {   filter: brightness(120%) saturate(120%); }

Direct Link to ArticlePermalink


The post Using a brightness() filter to generically highlight content appeared first on CSS-Tricks.

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

CSS-Tricks

, , , , ,

How to Create a “Skip to Content” Link

Skip links are little internal navigation links that help users move around a page. It’s possible you’ve never actually seen one before because they’re often hidden from view and used as an accessibility enhancement that lets keyboard users and screen readers jump from the top of the page to the content without have to go through other elements on the page first.

In fact, you can find one right here on CSS-Tricks if you crack DevTools open.

In my opinion, the best way to implement a skip link is to hide it and then bring it into view when it is focused. So, let’s say we have a link in the HTML:

<a class="skip-to-content-link" href="#main">Skip to content</a>

…we can give it an absolute position and translate it off the screen:

.skip-to-content-link {   left: 50%;   position: absolute;   transform: translateY(-100%); }

Then we can bring it back into view when it’s in focus and style it up a bit in the process:

.skip-to-content-link {   background: #e77e23;   height: 30px;   left: 50%;   padding: 8px;   position: absolute;   transform: translateY(-100%);   transition: transform 0.3s; }  .skip-to-content-link:focus {   transform: translateY(0%); }

This will hide our link until it is focused and then put it into view when it becomes focused.

Now, allow me to elaborate, starting with this quote from Miles Davis:

Time isn’t the main thing. It’s the only thing.

As I sit down to write this article in a rainy Ireland, I think of the challenge that many users face as they use the web that I take for granted. We put so much thought into creating a great user experience without thinking of all our users and how to meet their needs. Admittedly, a skip link was something I had never heard of until completing a course on Frontend Masters by Marcy Sutton. Since learning the power and simplicity of using a skip link, I decided to make it my mission to spread more awareness — and what platform better than CSS-Tricks!

A solution is an answer to a problem, so what’s the solution for helping keyboard users and screen readers find the content of a page quickly? In short, the solution is time. Giving users the ability to navigate to parts of our website that they are most interested in gives them the power to save valuable time.

Take the Sky News website as an example. It offers a “Skip to content” button that allows users to skip all the navigation items and jump straight to the main content.

You can see this button by navigating to the top of the page using your keyboard.  This is similar to the implementation shown above. The link is always in the document but only becomes visible when it’s in focus.

This is the type of skip link we are going to create together in this post.

Our sample website

I built a sample website that we will use to demonstrate a skip link.

The website has a number of navigation links but, in the interest of time, there are only two pages: the home page and the blog page. This is all we need to see how things work.

Identifying the problem

Here’s the navigation we’re working with:

In total, we have eight navigation items that a keyboard user and screen reader must tab through before reaching the main content below the navigation.

That’s the problem. The navigation may be irrelevant for the user. Perhaps the user was given a direct link to an article and they simply want to get to the content.

This is a perfect use case for a skip link.

Creating the link

There are a couple of approaches to creating a Skip to content link.  What I like to do is similar to the Sky News example, which is hiding the link until it is focused.  That means we can drop the link at or near the top of the page, like inside the <header> element.

<header>   <a class="skip-link" href='#main'>Skip to content</a>   <!-- Navigation--> </header>

This link has a .skip-link class so we can style it. Thehref attribute points to #main, which is the ID we will add to the <main> element that comes further down the page. That’s what the link will jump to when clicked.

<header>   <a class="skip-link" href='#main'>Skip to content</a>   <!-- Navigation--> </header> 
 <!-- Maybe some other stuff... --> 
 <main id="main">   <!-- Content --> </main>

Here’s what we have if we simply drop the link into the header with no styling.

This does not look great, but the functionality is there. Try navigating to the link with your keyboard and pressing Enter when it’s in focus.

Now it’s time to make it look pretty. We must first fix the positioning and only show our skip link when it is in focus.

.skip-link {   background: #319795;   color: #fff;   font-weight: 700;   left: 50%;   padding: 4px;   position: absolute;   transform: translateY(-100%); }  .skip-link:focus {   transform: translateY(0%); }

The magic here is in the transform property, which is hiding and showing our skip link depending on whether it is focused or not. Let’s make it look a little nicer with a quick transition on the transform property.

.skip-link {   /* Same as  before */   transition: transform 0.3s; }

It will now transition into view which makes that bit better.

You should now (hopefully) have what I have below:

As you can see, the skip link bypasses the navigation and jumps straight down to the <main> element when clicked.

It’s OK to use more than one link!

Right now, the link only serves one purpose and that is skip to the content of our website. But we don’t have to stop there.

We can go even further and create a skip link that has more options, such as a way to jump to the footer of the site. As you might imagine, this is quite similar to what we’ve already done.

Let’s make the blog page of the example site a little more usable by using multiple skip links. It’s common for blogs to use AJAX that loads in more posts when reaching the bottom of the page. This can make it very difficult to get to the footer of the website. That’s the problem we want to solve in this case.

So let’s add a second link that bypasses all that auto-loading business and jumps the user straight to a #footer element on the page.

<div class="skip-link" >   Skip to <a href='#main'>content</a> or <a href='#footer'>footer</a> </div>

We also need to amend our CSS a little and use the :focus-within pseudo selector.

.skip-link {   transform: translateY(-100%); }  .skip-link:focus-within {   transform: translateY(0%); }

This is saying if anything within our .skip-link element has focus, then we show it. Sadly, neither Internet Explorer nor Opera Mini support focus-within, but its coverage is pretty darn good and there is a polyfill available.

This browser support data is from Caniuse, which has more detail. A number indicates that browser supports the feature at that version and up.

Desktop

Chrome Firefox IE Edge Safari
60 52 No 79 10.1

Mobile / Tablet

Android Chrome Android Firefox Android iOS Safari
80 68 No 10.3

Last thing we need to do is make sure there’s an ID on our footer element so the link has something to jump to.

<footer id="footer">

Here’s what this gives us:

If we wanted to go one step further (and I’d encourage it), we could style each link a little differently so users can distinguish between the two. Both links in this example are plain white which works great for a single button that does a single thing, but it’d be clearer that we’re dealing with two links if they were presented differently.

Jumping to conclusions

Are you using skip links on your site? Or, if not, does this convince you to use one? I hope it’s clear that skip links are a great value add when it comes to the accessibility of a site. While it’s not a silver bullet that solves every accessibility need, it does solve some use cases that make for a much more polished user experience.

Here are some prominent sites that are using this or a similar technique:

The post How to Create a “Skip to Content” Link appeared first on CSS-Tricks.

CSS-Tricks

, , ,
[Top]

Is Having an RSS Feed Just Giving Content Away for Free?

I mean, kinda.

I was just asked this question the other day so I’m answering here because blogging is cool.

The point of an RSS feed is for people to read your content elsewhere (hence the last part of the acronym, Syndication, as in, broadcasting elsewhere). Probably an RSS reader. But RSS is XML, so in a sense, it’s a limited API to your content as well, which people can use to do other programmatic things (e.g. show a list of recent posts on some other site).

If you hate the idea of people seeing your work outside of your website, then don’t have an RSS feed. It doesn’t prevent your site from being scraped (nothing really does), but it isn’t inviting people to your content the way RSS does.

But…

Don’t you want people to read your stuff? Having an RSS feed is saying, “I’m happy to meet you where you are. If you like reading stuff over there, then great, read it over there. I just like it when you read my stuff.”

It’s hard enough to get people to care about your work anyway. Being extra protective over it isn’t going to help that.

Who’s comic book are you more likely to buy? The webcomic you read and laugh at every day because they make it so easy and free to read? Or the comic that you can’t see because you have to pay for to get a peek and have to roll the dice on whether you’re going to like it or not?

What consultant are you more likely to hire? The one that shares a ton of knowledge about their skills and has firmly established themselves as a publicly verifiable expert? Or a consultant with a homepage that’s just a pricing sheet and phone number?

What blog are you more likely to trust a recommendation from? One that you subscribe to on purpose because you like their content and writers? Or some site you randomly landed on?

What web do you want to exist? One with fun interoperable possibilities? Or walled gardens?

The post Is Having an RSS Feed Just Giving Content Away for Free? appeared first on CSS-Tricks.

CSS-Tricks

, , , , , ,
[Top]

Embedded Content in Markdown

Markdown supports HTML, so if you need to, say, embed a YouTube video, you can just copy and paste the embed code from them, drop it into a Markdown document, and you should be good to go. With YouTube specifically, there are other options. But in general, you don’t need to do anything special to embed third-party media in Markdown.

You do need to do whatever is necessary for that particular service though. For example, on CodePen, you visit any particular Pen to get the embed code, click “Embed” in the footer, choose options, and ultimately get the embed code. On Twitter, you click a down arrow thingy and choose Embed Tweet, then get forwarded to some other website where you choose options and ultimately get the embed code. It’s different on every service.

That’s the spirit behind gatsby-remark-embedder from Michaël De Boey, which I recently saw. It spells this out:

Trying to embed well known services (like CodePen, CodeSandbox, Slides, SoundCloud, Spotify, Twitter or YouTube) into your Gatsby website can be hard, since you have to know how this needs to be done for all of these different services.

So what this plugin does is allows you to drop a URL to the thing you’re trying to embed on its own line, and it’s magically transformed into embed code. For example, you put a URL to a Pen like this:

https://codepen.io/Coderesting/pen/yLyaJMz

…and you get:

<iframe   src="https://codepen.io/team/codepen/embed/preview/PNaGbb"   style="width:100%; height:300px;" ></iframe>

…by the time the content makes its way to the DOM.

As an owner of CodePen, I can’t help but to remind you that doing it this way means you can’t take advantage of having a theme or making it editable. But hey, I get it.

What I think is a smidge funny is that… this is exactly what oEmbed is. The whole spirit of oEmbed is, “Put a URL to a thing on its own line and we’ll try to make it into an embed for you.” It’s a clearly defined spec and there is a clear source of data of sites that support the feature.

But I suppose it’s a failing of oEmbed that people either don’t know about it or don’t use it. Even Embedly seems kinda dead-ish?

The post Embedded Content in Markdown appeared first on CSS-Tricks.

CSS-Tricks

, ,
[Top]

Weekly Platform News: Impact of Third-Party Code, Passive Mixed Content, Countries with the Slowest Connections

In this week’s roundup, Lighthouse sheds light on third-party scripts, insecure resources will get blocked on secure sites, and many country connection speeds are still trying to catch up to others… literally.


Measure the impact of third-party code during page load

Lighthouse, Chrome’s built-in auditing tool, now shows a warning when the impact of third-party code on page load performance is too high. The pre-existing “Third-party usage” diagnostic audit will now fail if the total main-thread blocking time caused by third-parties is larger than 250ms during page load.

Note: This feature was added in Lighthouse version 5.3.0, which is currently available in Chrome Canary.

(via Patrick Hulce)

Passive mixed content is coming to an end

Currently, browsers still allow web pages loaded over a secure connection (HTTPS) to load images, videos, and audio over an insecure connection. Such insecurely-loaded resources on securely-loaded pages are known as “passive mixed content,” and they represent a security and privacy risk.

An insecurely-loaded image can allow an attacker to communicate incorrect information to the user (e.g., a fabricated stock chart), mutate client-side state (e.g., set a cookie), or induce the user to take an unintended action (e.g., changing the label on a button).

Starting next February, Chrome will auto-upgrade all passive mixed content to https:, and resources that fail to load over https: will be blocked. According to data from Chrome Beta, auto-upgrade currently fails for about 30% of image loads.

(via Emily Stark)

Fast connections are still not common in many countries

Data from Chrome UX Report shows that there are still many countries and territories in the world where most people access the Internet over a 3G or slower connection. (This includes a number of small island nations that are not visible on this map.)

(via Paul Calvano)

More news…

Read even more news in my weekly Sunday issue that can be delivered to you via email every Monday morning.

More News →

The post Weekly Platform News: Impact of Third-Party Code, Passive Mixed Content, Countries with the Slowest Connections appeared first on CSS-Tricks.

CSS-Tricks

, , , , , , , , , , ,
[Top]

Images Are Not Static Content

We constantly hear about the importance of keeping websites lean and fast. A fast-loading website makes users more satisfied, and satisfied users spend more time and money on your website. However, website optimization is a complex task, as there is not one silver bullet to fix all of the issues causing poor performance.

We also hear that addressing the performance of images is a low hanging fruit if you want to improve your site’s user experience However, anyone who has gotten their hands dirty trying to optimize images and cover major use cases and scenarios with responsive images knows that the complexity of this task escalates quickly. For most medium to large sites, image optimization is not a task suited to humans. This is why image content delivery networks (CDN) exist.

An image CDN is indeed a content delivery network built especially for images. Just like the name suggests. So, why would we need a special CDN to serve images? Why not use a regular CDN to serve static files? Short answer is that images are not static files…

Most image CDNs treat an image as dynamic content by optimizing the image in different ways based on context where the image is consumed.

Explained a bit differently; if you’re using responsive images on your website, an image cdn will automatically generate the derivatives of the image according to the sizes specified in the markup, usually based on some URL parameters. For example, the below code selects from 3 derivatives specified in the srcset attribute based on 3 breakpoints:

<img src="//i.foo.com/image.jpg" alt="cat"    srcset="//i.foo.com/image.jpg?width=320 320w, //i.foo.com/image.jpg?width=640 640w, //i.foo.com/image.jpg?width=1280 1280w"    sizes="(max-width: 480px) 100vw, (max-width: 900px) 33vw, 254px">

This way, the developer or designer doesn’t have to worry about creating all the image versions beforehand. Which is very good news, because the number of derivative images may quickly grow exponentially based on many break points, image formats, and screen resolutions. And that is before we’ve started talking about art direction.

Dynamic Image Optimization on Autopilot

Now that we’ve seen how an image CDN can create different sizes of an image on the fly, let’s examine how this improves web performance.

Before we go further to choose an image CDN for the examples later, it is important to point out the difference between an image CDN and a digital asset management tool (DAM). A DAM, such as Cloudinary, is mostly focused for file management aspect and often allows you to edit images and apply art direction like filters. Usually these DAMs need a general purpose CDN in front and there is little support for automation of image optimization tasks.

On the opposite end of the scale is ImageEngine. ImageEngine is the most effective image CDN on the market thanks to its built in device detection that enables superior image optimization for mobile traffic. Since mobile devices account for more than 50% of the traffic in many countries, ImageEngine truly has an advantage over other CDNs. While most other image CDNs only offer little or no automatic optimization, ImageEngine has more advanced approach thanks to its focus on mobile traffic. Hence, ImageEngine will be able to produce the best results with less implementation effort and maintenance.

How ImageEngine Improves Web Performance

With ImageEngine handling all image traffic, images are no longer static content. Images are now adapted and served exactly in the size, format, compression rate and resolution needed. Fine. But how do we measure the improvement?

These days, the “go to tool” for identifying performance issues and measuring performance is Google Lighthouse. Lighthouse is available as a standalone app and in your Chrome developer tools.

We’ll run a performance audit on an e-commerce demo page listing product images.

The page has a typical responsive grid layout with product images. The layout has a few breakpoints where the display size of the images change because number of items per row changes. Moreover, there is a mouse over feature displaying a different image of the product. The mouseover effect is handled by JavaScript and even the hidden image is always loaded in our example. So all in all, quite a few images and potential sizes.

Step One: Assess Current State

Running the Lighthouse audit on the demo-page we see a number of issues, summarized in a performance score of 98. The best score is 100, so 98 might not seem that bad. Which is true, but pay more attention to the metrics below the score. The performance score is calculated based on a few metrics with varied weighting. The images on our page have direct and indirect impact on these metrics.

In the details of the report, we see a few opportunities related to images listed:

  • Properly size images. The images does not have the right pixel size. This is quite common on pages with a responsive or fluid layout.
  • Serve images in next-gen formats. For Chrome this basically mean to convert images to webp. Usually webp is a more efficient format than most others when it comes to byte size and decode speed.
  • Efficiently encode images. There is more compression that can be applied to the images before impacting perceived visual quality.

The estimated savings (to the right in the report) are huge. This demonstrates why addressing images is considered a low hanging fruit for performance.

If you haven’t signed up already, create a free ImageEngine trial account. Once you’ve completed signup you can define the image origin (usually your website) and a domain from which you want to serve images from. The image may be something like images.mydomain.com. You point this domain name to ImageEngine with a CNAME record in your DNS, and you’re good to go.

The next step is changing the markup to make the most out of ImageEngine’s automatic features.

If our previous image tag looked like this:

<img class="pic-1" src="images/demo9/img-1.jpg">

Our new image tag will look like this when the ImageEngine domain name is serving the images:

<img class="pic-1" src="https://images.mydomain.com/images/demo9/img-1.jpg">

Because our grid layout is fluid with 4 breakpoints, we might also consider to use responsive images syntax:

<img   class="pic-1"    src="https://images.mydomain.com/images/demo9/img-1.jpg"    sizes="(max-width: 576px) 93vw,           (max-width: 768px) 238px, (max-width: 768px) 238px,           (max-width: 992px) 148px, 253px" >

Thanks to ImageEngine’s support for Client hints, ImageEngine will now generate the exact pixel size needed. Client hints are additional HTTP headers the browser can send to enable more accurate image resizing. Client hints are currently only supported by Chrome browsers

Step Three: Measure the Improvement

Running the Lighthouse audit again, we see that the score is now 100. But more importantly, look at the improvements in timings. “Time to interactive” for example. 0.7 seconds less waiting for the user in order to interact with the page. All because images are optimized properly.

What does really “optimized” mean in this case? Why is the page faster and user experience better with ImageEngine? Most of the positive impact is due to reduction in byte size of the images. The less bytes, the faster are the images transferred from the host (or ImageEngine’s edge servers) to the browser. Moreover, lighter images are usually faster to decode and render onto the users screen. This is very simplified, but let’s see how much ImageEngine reduces the image payload using WebPageTest.org to compare our demo site with-, and without ImageEngine:

ImageEngine reduces the image payload to only 25% of the original size.

Bonus: Fix Caching

In the continuous hunt for improved performance, you may have seen this alert from Lighthouse.

Lighthouse thinks the images have a too short Time To Live (TTL) -measured in seconds- in the browser cache. By default, ImageEngine passes on the cache directives given by the origin but luckily this can be changed in ImageEngine’s management interface.

Next Step: Automate Image Optimization

We’ve seen how images should no longer can be treated as static content if we want a high performing web site. Because images have such a high impact on website performance, images must be tailored according to the capabilities and context of the browser and user.

A purpose-built image CDN will relieve humans of the responsibility of trying to accommodate all possible combinations of image formats, sizes and compression levels. Managing image derivatives, is not a task for humans as it will quickly grow to become unmanageable.

Using tools like Lighthouse and WebPageTest.org document the positive impact image CDNs like ImageEngine has on important performance metrics.

The post Images Are Not Static Content appeared first on CSS-Tricks.

CSS-Tricks

, ,
[Top]

How Web Content Can Affect Power Usage

Because we know that all people with battery-powered devices are constantly concerned about their battery levels, and that websites are significant consumers of that battery power, we should probably think about this stuff a lot more than we do.

I’d expect the browser itself to be our main ally here, doing smart things to reduce power consumption without us developers needing to think too much about it. But we’ve learned over the years that it’s always a shared responsibility. We regularly need to help the browser do its job the best it can (think responsive images and will-change).

Some direct tips from Benjamin Poulain and Simon Fraser’s article:

  • Minimize the use of timers to avoid waking up the CPU. Try to coalesce timer-based work into a few, infrequent timers. Lots of uncoordinated timers which trigger frequent CPU wake-ups are much worse than gathering that work into fewer chunks.
  • Minimize continually animating content, like animated images and auto-playing video. Be particularly vigilant to avoid “loading” spinner GIFs or CSS animations that continually trigger painting, even if you can’t see them. IntersectionObserver can be used to run animations only when they are visible.
  • Use declarative animations (CSS Animations and Transitions) where possible. The browser can optimize these away when the animating content is not visible, and they are more efficient than script-driven animation.
  • Avoid network polling to obtain periodic updates from a server. Use WebSockets or Fetch with a persistent connection, instead of polling.

I’d like to see more developer tooling along the lines of how macOS makes it easy to see apps that are demanding significant power:

WebKit DevTools does has it:

We used to have a Battery Status API, but that’s been deprecated, so not a big part of the story right now.

I was just at the Web Unleashed conferencewhere Kyle Simpson talked about this rather directly in his keynote lecture. His main idea is that we should ask users a bit more directly and solicit their preferences. Hey user, are you in a situation where you want to use as little battery power as possible? Tell us and we’ll do what we can to make that happen (even on a site-by-site basis).

Direct Link to ArticlePermalink

The post How Web Content Can Affect Power Usage appeared first on CSS-Tricks.

CSS-Tricks

, , ,
[Top]

Grid, content re-ordering and accessibility

Take this:

<ol>   <li>Get hungry</li>   <li>Order pizza</li>   <li>Eat pizza</li> </ol>

That HTML ends up in the DOM that way (and thus how it is is exposed to assistive technology), and by default, those list items are also visually shown in that order. In most layout situations, the visual order will match that DOM order. Do nothing, and the list items will flow in the block direction of the document. Apply flexbox, and it will flow in the inline direction of the document.

But flexbox and grid also allow you to muck it up. Now take this:

ol {    display: flex;   flex-direction: row-reverse; }

In this case, the DOM order still makes sense, but the visual order is all wrong. It’s not just row-reverse. There are a number of flexbox and grid properties that can get involved and confuse things: the order property, flowing items into columns instead of rows, and positioning items specifically in unusual orders, among others. Even absolute positioning could cause the same trouble.

Manuel Matuzovic says:

If the visual order and the DOM order don’t match, it can irritate and confuse users up to a point where the experience is so bad that the site is unusable.

Rachel Andrew highlights this issue (including things we’ve published) as a big issue, and hopes we can get tools at the CSS level to help.

I think this is something we sorely need to address at a CSS level. We need to provide a way to allow the tab and reading order to follow the visual order. Source order is a good default, if you are taking advantage of normal flow, a lot of the time following the source is exactly what you want. However not always, not at every breakpoint. If we don’t give people a solution for this, we will end up with a mess. We’ve given people these great tools, and now I feel as if I’m having to tell people not to use them.

Direct Link to ArticlePermalink

The post Grid, content re-ordering and accessibility appeared first on CSS-Tricks.

CSS-Tricks

, , ,
[Top]

The Browser Can Remember Edited Content

You can make the text inside any HTML element editable by adding the contenteditable attribute.

<div contenteditable>   Hey, I'm like a textarea kinda now! </div>

I wouldn’t say there are wheelbarrows full of use-cases for that, but it’s neat. One possible use might be an in-progress design in which editing the content from the design itself is useful either for you, or for someone else (a client?) who needs to change the text.

So, great, contenteditable. Now someone can click into the text and edit it.

There is nothing permanent about those changes. Refresh the page, look in another browser or whatever. Those edits are gone.

Say you wanted to do a little better job and make the changes persistent. You aren’t trying to build a CMS here, or save the data through an authenticated connection to a database or anything. You just wanna make the edits to the text are maintained if the page refreshes.

One way is to chuck the data from the text changes you make into localStorage.

  1. When text is edited (on blur of the element), save the data to localStorage using a namespace and the
    ID of the element as the key.
  2. When the page loads, look through localStorage and see if there are any keys that match elements on the page and, if so, replace the content.
const editables = document.querySelectorAll("[contenteditable]");  // save edits editables.forEach(el => {   el.addEventListener("blur", () => {     localStorage.setItem("dataStorage-" + el.id, el.innerHTML);   }) });  // once on load for (var key in localStorage) {   if (key.includes("dataStorage-")) {     const id = key.replace("dataStorage-","");     document.querySelector("#" + id).innerHTML = localStorage.getItem(key);   } }

See the Pen
localStorage + contenteditable
by Chris Coyier (@chriscoyier)
on CodePen.


This reminds me of a few other things…

  • document.designMode = "on" is like a shortcut for making every element on the page behave like it has contenteditable.
  • Mavo is a little bit like this concept only with authentication, true data storage options, and editing UI.
  • If performance is a concern, KV storage is supposed to be a speeder async version of localStorage.

The post The Browser Can Remember Edited Content appeared first on CSS-Tricks.

CSS-Tricks

, , ,
[Top]

Fixed Headers, On-Page Links, and Overlapping Content, Oh My!

Let’s take a basic on-page link:

<a href="#section-two">Section Two</a>

When clicked, the browser will scroll itself to the element with that ID: <section id="section-two"></section>. A browser feature as old as browsers themselves, just about.

But as soon as we position: fixed; came into play, it became a bit of an issue. The browser will still jump to bring the newly targeted element into view, but that element may be obscured by a fixed position element, which is pretty bad UX.

I called this “headbutting the browswer window” nearly 10 years ago, and went over some possible solutions. Nicolas Gallager documented five different techniques. I’m even using a fixed position header here in v17 of CSS-Tricks, and I don’t particularly love any of those techniques. I sort of punted on it and added top padding to all my <h3> elements, which is big enough for the header to fit there.

There is a new way though! Finally!

Šime Vidas documented this in Web Platform News. There are a bunch of CSS properties that go together as part of CSS scroll snapping, but it turns out that scroll-padding and scroll-margin can be used outside of a scroll snapping container.

body {   scroll-padding-top: 70px; /* height of sticky header */ }

This only works in Chromium browsers:

See the Pen
Scroll Padding on Fixed Postion Headers
by Chris Coyier (@chriscoyier)
on CodePen.

This is such a useful thing we shoot hoot and holler for WebKit and Firefox to do it.

The post Fixed Headers, On-Page Links, and Overlapping Content, Oh My! appeared first on CSS-Tricks.

CSS-Tricks

, , , , ,
[Top]