chrome – CSS-Tricks

A Couple Changes Coming in Chrome 108

Geoff Graham — Fri, 04 Nov 2022 13:13:08 +0000

“A change to overflow on replaced elements in CSS”:

From Chrome 108, the following replaced elements respect the overflow property: img, video and canvas. In earlier versions of Chrome, this property was ignored on these elements.
This means that an image which was earlier clipped to its content box can now draw outside those bounds if specified to do so in a style sheet.

So any image, video, and canvas elements that used to overflow by default might get clipped when Chrome 108 ships. The noted situations where this might affect your existing work:

The object-fit property is used to scale the image and fill the box. If the aspect ratio does not match the box, the image will draw outside of the bounds.
The border-radius property makes a square image look like a circle, but because overflow is visble the clipping no longer occurs.
Setting inherit: all and causing all properties to inherit, including overflow.

Worth reading the full article for code examples, but the solution for unwanted clipping is overriding the UA’s default overflow: clip with overflow: visible:

img {
  overflow: visible;
}

“Prepare for viewport resize behavior changes coming to Chrome on Android”:

In November, with the release of Chrome 108, Chrome will make some changes to how the Layout Viewport behaves when the on-screen keyboard (OSK) gets shown. With this change, Chrome on Android will no longer resize the Layout Viewport, and instead resize only the Visual Viewport. This will bring Chrome on Android’s behavior up to par with that of Chrome on iOS and Safari on iOS.

This is a change related to the common headaches of working with viewport units and fixed positioning on mobile touch devices. We’ve covered (and tried solving) it over the years:

“Some Things You Oughta Know When Working with Viewport Units” (Chris Coyier)
“The trick to viewport units on mobile” (Louis Hoebregts)
“The Large, Small, and Dynamic Viewports” (Chris Coyier)
“CSS fix for 100vh in mobile WebKit” (Chris Coyier)

The change means that Chrome on Android will no longer resize the Layout Viewport when the on-screen keyboard is shown. So, the computed values of viewport units will no longer shrink when a device’s keyboard is displayed. Same goes for elements that are designed to take up the full viewport no longer shrinking to accomodate the keyboard. And no longer will a fixed-position element wind up who knows where when the keyboard pops up.

This brings more consistent cross-browser behavior that is on line with Chrome, Safari, and Edge on iOS and iPadOS. That’s great, even if the updated behavior is less than ideal because the keyboard UI can still cover and obscure elements that get in its way.

If you prefer elements to remain visible when that happens, it’s worth looking at a solution Chris shared a long while back that uses the prefixed webkit-fill-available property:

body {
  min-height: 100vh;
  min-height: -webkit-fill-available;
}
html {
  height: -webkit-fill-available;
}

That uses the available space in the viewport rather than what’s covered by the UI… but Chrome currently ignores the property, and I’d bet the nickel in my pocket that it is unlikely to start respecting it in the 108 release. That may be a moot point, though, as Chrome 108 also introduces support for small, large, and dynamic viewport units, which are already supported in Safari and Firefox.

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
108	101	No	108	15.4

Mobile / Tablet

Android Chrome	Android Firefox	Android	iOS Safari
108	107	108	15.4

A Couple Changes Coming in Chrome 108 originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

What is Chromium Without Chrome on Top?

Chris Coyier — Mon, 10 Jan 2022 22:02:49 +0000

Raw Chromium, perhaps?

So, Chrome is based on Chromium which is open-source. Chrome is Chromium with Google’s extra stuff on top of it. What extra stuff? Kinda lots! A few years ago, The Verge published “Microsoft reveals all the Google things it removed in its Chromium Edge browser” with this image from Microsoft listing out all the stuff:

That suggests all this stuff is actually in Chromium, not added later to Chrome in some additional process. That means if you wanna build your own Chromium fork and de-couple yourself from Google, you’ve got some work to do.

Several big players have done that work. Clearly, Microsoft has done it with Edge. Vivaldi and Brave are other big Chromium-based browsers with presumably similar de-Googleification.

Dan Abramov was asking around about this the other day:

is there a regularly updated mod of chrome that’s basically chromium (so chrome minus google-specific stuff except search) but also without experimental features and always based on a stable revision
— Dan (@dan_abramov) December 28, 2021

Sounds like Dan (and by extension: me) learned through this thread that Chromium isn’t actually just the core browser stuff where Chrome then adds stuff on top of it. It’s that if you want to base another browser on Chromium, you have to yank stuff out of Chromium.

Seems a smidge weird to me, but hey, it’s open-source, so if you don’t like it, fork it. And obviously many have. Perhaps most notable is ungoogled-chromium. It lists this as the philosophy:

Remove all remaining background requests to any web services while building and running the browser

Remove all code specific to Google web services

Remove all uses of pre-made binaries from the source code, and replace them with user-provided alternatives when possible.

Disable features that inhibit control and transparency, and add or modify features that promote them (these changes will almost always require manual activation or enabling).

I have zero doubt that the browser world is converging on Chromium. You can imagine Apple hanging onto their own thing with WebKit forever, but things don’t seem to be going terribly well at Mozilla, and they haven’t for a while. Mozilla’s money seems to come from Google anyway so it’s tough to imagine Mozilla’s browser engines hanging on for that much longer. Y’all can call me an ignorant asshole in January 2032 if Mozilla still has a competitive browser engine.

The health of the browser ecosystem would benefit from a cleaner, company-agnostic version of Chromium (and maybe call it something else). If most browsers are based on it, so be it, but let the innovation happen from a level playing field.

What is Chromium Without Chrome on Top? originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

CSS Underlines Are Too Thin and Too Low in Chrome

Šime Vidas — Tue, 04 Jan 2022 15:30:18 +0000

I’ve encountered two bugs in Chrome while testing the new CSS text-decoration-thickness and text-underline-offset properties, and I want to share them with you here in this article.

Default underlines are inconsistent
Luckily, we can override the browsers’ defaults
Chrome bug 1: Underlines are too thin on macOS
Chrome bug 2: Underlines are too low
Help prioritize the Chrome bugs

First, let’s acknowledge one thing:

Default underlines are inconsistent

Let’s add a text link to a plain web page, set its font-family to Arial, and compare the underlines across browsers and operating systems.

From left to right: Chrome, Safari, and Firefox on macOS; Safari on iOS; Chrome, and Firefox on Windows; Chrome, and Firefox on Android.

As you can see, the default underline is inconsistent across browsers. Each browser chooses their own default thickness and vertical position (offset from the baseline) for the underline. This is in line with the CSS Text Decoration module, which specifies the following default behavior (auto value):

The user agent chooses an appropriate thickness for text decoration lines. […] The user agent chooses an appropriate offset for underlines.

Luckily, we can override the browsers’ defaults

There are two new, widely supported CSS properties that allow us to precisely define the thickness and offset for our underlines:

With these properties, we can create consistent underlines even across two very different browsers, such as the Gecko-based Firefox on Android and the WebKit-based Safari on macOS.

h1 {
  text-decoration: underline;
  text-decoration-thickness: 0.04em;
  text-underline-offset: 0.03em;
}

Top row: the browsers’ default underlines; bottom row: consistent underlines with CSS. (Demo)

Note: The text-decoration-thickness property also has a special from-font value that instructs browsers to use the font’s own preferred underline width, if available. I tested this value with a few different fonts, but the underlines were inconsistent.

OK, so let’s move on to the two Chrome bugs I noted earlier.

Chrome bug 1: Underlines are too thin on macOS

If you set the text-decoration-thickness property to a font-relative length value that computes to a non-integer pixel value, Chrome will “floor” that value instead of rounding it to the nearest integer. For example, if the declared thickness is 0.06em, and that computes to 1.92px, Chrome will paint a thickness of 1px instead of 2px. This issue is limited to macOS.

a {
  font-size: 2em; /* computes to 32px */
  text-decoration-thickness: 0.06em; /* computes to 1.92px */
}

In the following screenshot, notice how the text decoration lines are twice as thin in Chrome (third row) than in Safari and Firefox.

From top to bottom: Safari, Firefox, and Chrome on macOS. (Demo)

For more information about this bug, see Chromium issue #1255280.

Chrome bug 2: Underlines are too low

The text-underline-offset property allows us to precisely set the distance between the alphabetic baseline and the underline (the underline’s offset from the baseline). Unfortunately, this feature is currently not implemented correctly in Chrome and, as a result, the underline is positioned too low.

h1 {
  text-decoration: underline;
  text-decoration-color: #f707;

  /* disable “skip ink” */
  -webkit-text-decoration-skip: none; /* Safari */
  text-decoration-skip-ink: none;

  /* cover the entire descender */
  text-decoration-thickness: 0.175em; /* descender height */
  text-underline-offset: 0; /* no offset from baseline */
}

Because of this bug, it is not possible to move the underline all the way up to the baseline in Chrome.

From left to right: Safari, Firefox, and Chrome on macOS. View this demo on CodePen.

For more information about this bug, see Chromium issue #1172623.

Note: As you might have noticed from the image above, Safari draws underlines on top of descenders instead of beneath them. This is a WebKit bug that was fixed very recently. The fix should ship in the next version of Safari.

Help prioritize the Chrome bugs

The two new CSS properties for styling underlines are a welcome addition to CSS. Hopefully, the two related Chrome bugs will be fixed sooner rather than later. If these CSS features are important to you, make your voice heard by starring the bugs in Chromium’s bug tracker.

CSS Underlines Are Too Thin and Too Low in Chrome originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Our favorite Chrome extensions of 2021

Chris Coyier — Tue, 28 Dec 2021 16:11:35 +0000

I hadn’t heard of most of the Chrome extensions that Sarem Gizaw lists as 2021 favorites. Here are my hot takes on all of them, except the virtual learning specific ones that aren’t very relevant to me.

LoomOh that’s neat how it records your screen and your camera, encouraging you to do little personal walkthroughs of a thing for someone. I actually had a guest author use this to pitch an idea and it was both above-and-beyond in a good way, and didn’t look overly difficult to do. I like how it’s a browser app, meaning that something like a Chromebook could use it even though it feels like an app that would otherwise be native.
MoteSimilar in spirit to Loom—leave feedback with your voice instead of writing it out by hand. This is clearly a much more personal way to do things. I wonder if it’s big in the eduction space where that student/teacher connection would be bolstered by this.
WordtuneLooks like a competitor to Grammarly. I like to see that sort of competition. That said, I think Grammarly is good, though a bit heavy handed sometimes. It’s nice to see them being pushed by another player in the same space.
ForestI’m skeptical of productivity apps that ultimately feel like yet-another-app I need to use and learn. But maybe it’s worth it if the point is that it keeps you on task and away from distracting apps? I was very skeptical of Centered, but it really did seem to help the times I tried it.
Dark ReaderThis forces dark mode on sites that otherwise don’t have one. I’ve heard it does a pretty decent job.
Tab Manager PlusI’m as guilty as anyone for having too many tabs open… all the time. But now that Chrome has tab groups natively (as well as “pinning”), I just roll with that.
NimbusInteresting that this is in an entirely different category that Loom. I guess it’s more about screenshots than video. Note that you don’t need a browser plugin to do full-length screenshots—in DevTools you can do CMD+Shift+P then search for “Capture Full Size Screenshot.” I actually use that quite a bit. For other screenshots, I’m super hot on Cleanshot.
StylusI love that this exists and that it is still somewhat actively developed (a beta exists). Being able to slap some extra CSS onto sites of your own liking and have it persist is super cool, and a community of user-created styles for other websites is even cooler.
RakutenThis is one of those things that automatically applies coupons during checkout to eCommerce stores. Skeeves me out for some reason, especially the “Cash Back” idea. I would think that if they are sending you money, it’s because they are making money off of you, meaning it’s from hidden-feeling affiliate partnerships or by selling your purchase data and personal details.

Browser extensions have come a long way toward being cross-browser compatible, so I’d think a lot of these are available for Safari and Firefox now—or at least could be without enormous amounts of work if the authors felt like doing it.

Notably, there are no ad blocker plugins in the list. Not a huge surprise there, even though I’m sure they are some of the most-downloaded and used. I use Ghostery, but I haven’t re-evaluated the landscape there in a while. I like how Ghostery makes it easy for me to toggle on-and-off individual scripts, both on individual sites and broadly across all sites. That means I could enable BuySellAds (something even Adblock Plus does by default) and Google Analytics scripts, but turn off A/B testers or gross ad networks.

To Shared Link — Permalink on CSS-Tricks

Our favorite Chrome extensions of 2021 originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

On Browser-Specific URL Schemes

Chris Coyier — Tue, 26 Oct 2021 20:06:29 +0000

We’ve covered URL schemes:

A URL Scheme is like “http://…” or “ftp://…”. Those seem like a very low-level concept that you don’t have much control over, but actually, you do!

I’d call it non-trivial, but developers can register new URL schemes in apps that users install. Back in 2017, Microsoft Edge did this:

microsoft-edge://

If you use that, the behavior is to open the URL in Microsoft Edge — even if you’ve chosen a different default browser. So if I, as a blogger, wanted to essentially force you to use Edge for this site, I could, by starting every single URL with this URL scheme. I won’t, but I could. And so could Microsoft.

At the time, Daniel Aleksandersen wrote a program called EdgeDefelector to circumvent that behavior and explained:

I don’t hate Microsoft Edge — maybe you do! — but I do believe users who have bothered to configure a different default web browser should be allowed to keep using that default web browser.

This has come back into the public eye a bit as the Brave browser now supports the microsoft-edge:// URL scheme. Apparently, not only does an app need to register a URL scheme, but other apps that support clicks-on-links need to honor it too. Firefox is also thinking of adding it. I think the risk of not supporting the URL scheme is that clicks on links like that could do nothing instead of actually opening the URL.

A lot of the talk is about Windows 11. But here on my Mac, I see this URL scheme do what it intends across all these browsers.

Safari

Chrome

Firefox

Brave

Daniel goes further:

So, how did we get here? Until the release of iOS version 14 in September 2020, you couldn’t change the default web browser on iPhones and iPads. Google has many apps for iOS, including a shell for its Chrome browser. To tie all its apps together, Google introduced a googlechrome: URL scheme in February 2014. It could use these links to direct you from its Search or Mail app and over to Chrome instead of Apple’s Safari browser.

Here’s my iPhone 13 opening googlechrome://css-tricks.com with and without Google Chrome installed.

iOS Safari with Google Chrome installed

iOS Safari without Google Chrome installed

Seems like that would be Google’s sin, but it is apparently Apple that allowed it on iOS. Daniel once more:

The original sin was Apple’s, but Microsoft is gulping the juice of the apple with gusto.

I’m not as boned up on all this as I should be, but I think if I made software that was involved here, I’d be tempted to intercept these URL schemes and have them open in the browser the user is already in. The web is the web, there should be no reason any given URL has to open in any specific browser.

On Browser-Specific URL Schemes originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Custom State Pseudo-Classes in Chrome

Šime Vidas — Thu, 06 May 2021 14:28:53 +0000

There is an increasing number of “custom” features on the web platform. We have custom properties (--my-property), custom elements (), and custom events (new CustomEvent('myEvent')). At one point, we might even get custom media queries (@media (--my-media)).

But that’s not all! You might have missed it because it wasn’t mentioned in Google’s “New in Chrome 90” article (to be fair, declarative shadow DOM stole the show in this release), but Chrome just added support for yet another “custom” feature: custom state pseudo-classes (:--my-state).

Built-in states

Before talking about custom states, let’s take a quick look at the built-in states that are defined for built-in HTML elements. The CSS Selectors module and the “Pseudo-classes” section of the HTML Standard specify a number of pseudo-classes that can be used to match elements in different states. The following pseudo-classes are all widely supported in today’s browsers:

User action
`:hover`	the mouse cursor hovers over the element
`:active`	the element is being activated by the user
`:focus`	the element has the focus
`:focus-within`	the element has or contains the focus
Location
`:visited`	the link has been visited by the user
`:target`	the element is targeted by the page URL’s fragment
Input
`:disabled`	the form element is disabled
`:placeholder-shown`	the input element is showing placeholder text
`:checked`	the checkbox or radio button is selected
`:invalid`	the form element’s value is invalid
`:out-of-range`	the input element’s value is outside the specificed range
`:-webkit-autofill`	the input element has been autofilled by the browser
Other
`:defined`	the custom element has been registered

Note: For brevity, some pseudo-classes have been omitted, and some descriptions don’t mention every possible use-case.

Custom states

Like built-in elements, custom elements can have different states. A web page that uses a custom element may want to style these states. The custom element could expose its states via CSS classes (class attribute) on its host element, but that’s considered an anti-pattern.

Chrome now supports an API for adding internal states to custom elements. These custom states are exposed to the outer page via custom state pseudo-classes. For example, a page that uses a element can declare styles for that element’s custom --loading state.

live-score {
  /* default styles for this element */
}

live-score:--loading {
  /* styles for when new content is loading */
}

Let’s add a `--checked` state to a element

The Custom State Pseudo Class specification contains a complete code example, which I will use to explain the API. The JavaScript portion of this feature is located in the custom element‘s class definition. In the constructor, an “element internals” object is created for the custom element. Then, custom states can be set and unset on the internal states object.

Note that the ElementInternals API ensures that the custom states are read-only to the outside. In other words, the outer page cannot modify the custom element’s internal states.

class LabeledCheckbox extends HTMLElement {
  constructor() {
    super();

    // 1. instantiate the element’s “internals”
    this._internals = this.attachInternals();

    // (other code)
  }

  // 2. toggle a custom state
  set checked(flag) {
    if (flag) {
      this._internals.states.add("--checked");
    } else {
      this._internals.states.delete("--checked");
    }
  }

  // (other code)
}

The web page can now style the custom element’s internal states via custom pseudo-classes of the same name. In our example, the --checked state is exposed via the :--checked pseudo-class.

labeled-checkbox {
  /* styles for the default state */
}

labeled-checkbox:--checked {
  /* styles for the --checked state */
}

Try the demo in Chrome

This feature is not (yet) a standard

Browser vendors have been debating for the past three years how to expose the internal states of custom elements via custom pseudo-classes. Google’s Custom State Pseudo Class specification remains an “unofficial draft” hosted by WICG. The feature underwent a design review at the W3C TAG and has been handed over to the CSS Working Group. In Chrome’s ”intent to ship” discussion, Mounir Lamouri wrote this:

It looks like this feature has good support. It sounds that it may be hard for web developers to benefit from it as long as it’s not widely shipped, but hopefully Firefox and Safari will follow and implement it too. Someone has to implement it first, and given that there are no foreseeable backward incompatible changes, it sounds safe to go first.

We now have to wait for the implementations in Firefox and Safari. The browser bugs have been filed (Mozilla #1588763 and WebKit #215911) but have not received much attention yet.

Custom State Pseudo-Classes in Chrome originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

New in Chrome 88: aspect-ratio

Geoff Graham — Wed, 20 Jan 2021 18:54:56 +0000

And it was released yesterday! The big news for us in CSS Land is that the new release supports the aspect-ratio property. This comes right on the heels of Safari announcing support for it in Safari Technology Preview 118, which released January 6. That gives us something to look forward to as it rolls out to Edge, Firefox and other browsers.

Here’s the release video skipped ahead to the aspect-ratio support:

For those catching up:

An aspect ratio defines the proportion of an element’s dimensions. For example, a box with an aspect ratio of 1/1 is a perfect square. An aspect ratio of 3/1 is a wide rectangle. Many videos aim for a 16/9 aspect ratio.
Some elements, like images and iframes, have an intrinsic aspect ratio. That means if either the width or the height is declared, the other is automatically calculated in a way that maintains its proportion.
Non-replaced elements, like divs, don’t have an intrinsic aspect ratio. We’ve resorted to a padding hack to get the same sort of effect.
Support for an aspect-ratio property in CSS allows us to maintain the aspect ratio of non-replaced elements.
There are some tricks for using it. For example, defining width on an element with aspect-ratio will result in the property using that width value to calculate the element’s height. Same goes for defining the height instead. And if we define both the width and height of an element? The aspect-ratio is completely ignored.

Seems like now is a good time to start brushing up on it!

CSS Box Sizing Module Level 4 (Official specification, currently in Editor’s Draft)
MDN Documentation
A First Look at aspect-ratio (CSS-Tricks)
Defining An Aspect Ratio Unit for CSS (Rachel Andrew, CSS-Tricks notes)

To Shared Link — Permalink on CSS-Tricks

New in Chrome 88: aspect-ratio originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

What’s New In DevTools (Chrome 86)

Geoff Graham — Wed, 26 Aug 2020 14:45:15 +0000

It wasn’t that long ago that Umar Hansa published a look at the most interesting new features in Chrome DevTools released in 2020. In fact, it was just earlier this month!

But in that short amount of time, Chrome has a few new tricks up its sleeve. One of the features Umar covered was the ability to emulate certain browsing conditions including, among many, vision deficiencies like blurred vision.

Chrome 86 introduces new emulators!

Emulate missing local fonts (great for testing when a user’s device does not have an installed font)
Emulate prefers-reduced-data (to complement Chrome support for this new feature!)
Emulate inactive users (yay, no more multiple browser windows with different user accounts!)

To Shared Link — Permalink on CSS-Tricks

What’s New In DevTools (Chrome 86) originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

A Look at What’s New in Chrome DevTools in 2020

Umar Hansa — Fri, 31 Jul 2020 14:00:29 +0000

I’m excited to share some of the newer features in Chrome DevTools with you. There’s a brief introduction below, and then we’ll cover many of the new DevTools features. We’ll also look at what’s happening in some other browsers. I keep up with this stuff, as I create Dev Tips, the largest collection of DevTools tips you’ll find online!

It’s a good idea to find out what’s changed in DevTools because it’s constantly evolving and new features are specifically designed to help and improve our development and debugging experience.

Let’s jump into the latest and greatest. While the public stable version of Chrome does have most of these features, I’m using Chrome Canary as I like to stay on the bleeding edge.

Lighthouse

Lighthouse is an open source tool for auditing web pages, typically around performance, SEO, accessibility and such. For a while now, Lighthouse has been bundled as part of DevTools meaning you can find it in a panel named… Lighthouse!

Well done, Mr. Coyier. 🏆

I really like Lighthouse because it’s one of easiest parts of DevTools to use. Click “Generate report” and you immediately get human-readable notes for your webpage, such as:

Document uses legible font sizes 100% legible text

Or:

Avoid an excessive DOM size (1,189 elements)

Almost every single audit links to developer documentation that explains how the audit may fail, and what you can do to improve it.

The best way to get started with Lighthouse is to run audits on your own websites:

Open up DevTools and navigate to the Lighthouse panel when you are on one of your sites
Select the items you want to audit (Best practices is a good starting point)
Click Generate report
Click on any passed/failed audits to investigate the findings

Even though Lighthouse has been part of DevTools for a while now (since 2017!), it still deserves a significant mention because of the user-facing features it continues to ship, such as:

An audit that checks that anchor elements resolve to their URLs (Fun fact: I worked on this!)
An audit that checks whether the Largest Contentful Paint metic is fast enough
An audit to warn you of unused JavaScript

A better “Inspect Element”

This is a subtle and, in some ways, very small feature, but it can have profound effects on how we treat web accessibility.

Here’s how it works. When you use Inspect Element — what is arguably the most common use of DevTools — you now get a tooltip with additional information on accessibility.

Accessibility is baked right in!

The reason I say this can have a profound impact is because DevTools has had accessibility features for quite some time now, but how many of us actually use them? Including this information on a commonly used feature like Inspect Element will gives it a lot more visibility and makes it a lot more accessible.

The tooltip includes:

the contrast ratio of the text (how well, or how poorly, does the foreground text contrast with the background color)
the text representation
the ARIA role
whether or not the inspected element is keyboard-focusable

To try this out, right-click (or Cmd + Shift + C) on an element and select Inspect to view it in DevTools.

I made a 14-minute video on Accessibility debugging with Chrome DevTools which covers some of this in more detail.

Emulate vision deficiencies

Exactly as it says on the tin, you can use Chrome DevTools to emulate vision impairments. For example, we can view a site through the lens of blurred vision.

That’s a challenge to read!

How can you do this in DevTools? Like this:

Open DevTools (right click and “Inspect” or Cmd + Shift + C).
Open the DevTools Command menu (Cmd + Shift + P on Mac, Ctrl + Shift + P on Windows).
Select Show Rendering in the Command menu.
Select a deficiency in the Rendering pane.

We used blurred vision as an example, but DevTools has other options, including: protanopia, deuteranopia, tritanopia, and achromatopsia.

Like with any tool of this nature, it’s designed to be a complement to our (hopefully) existing accessibility skills. In other words, it’s not instructional, but rather, influential on the designs and user experiences we create.

Here are a couple of extra resources on low vision accessibility and emulation:

Get timing on performance

The Performance Panel in DevTools can sometimes look like a confusing mish-mash of shapes and colors.

This update to it is great because it does a better job surfacing meaningful performance metrics.

What we want to look at are those extra timing rectangles shown in the “Timings” in the Performance Panel recording. This highlights:

DOMContentLoaded: The event which triggers when the initial HTML loads
First Paint: When the browser first paints pixels to the screen
First Contentful Paint: The point at which the browser draws content from the DOM which indicates to the user that content is loading
Onload: When the page and all of its resources have finished loading
Largest Contentful Paint: The largest image or text element, which is rendered in the viewport

As a bonus, if you find the Largest Contentful Paint event in a Performance Panel recording, you can click on it to get additional information.

Nice work, CSS-Tricks! The Largest Contentful Paint happens early on in the page load.

While there is a lot of golden information here, the “Related Node” is potentially the most useful item because it specifies exactly which element contributed to the LCP event.

To try this feature out:

Open up DevTools and navigate to the Performance panel
Click “Start profiling and reload page”
Observe the timing metrics in the Timings section of a recording
Click the individual metrics to see what additional information you get

Monitor performance

If you want to quickly get started using DevTools to analyze performance and you’ve already tried Lighthouse, then I recommend the Performance Monitor feature. This is sort of like having WebPageTest.org right at your fingertips with things like CPU usage.

Here’s how to access it:

Open DevTools
Open up the Command menu (Cmd + Shift + P on Mac, Ctrl + Shift + P on Windows)
Select “Show performance monitor” from the Command menu
Interact and navigate around the website
Observe the results

The Performance Monitor can give you interesting metrics, however, unlike Lighthouse, it’s for you to figure out how to interpret them and take action. No suggestions are provided. It’s up to you to study that CPU usage chart and ask whether something like 90% is an acceptable level for your site (it probably isn’t).

The Performance Monitor has an interactive legend, where you can toggle metrics on and off, such as:

CPU usage
JS heap size
DOM Nodes
JS event listeners
Documents
Document Frames
Layouts / sec
Style recalcs / sec

CSS overview and local overrides

CSS-Tricks has already covered these features, so go and check them out!

CSS Overview: A handy DevTools panel that gives a bunch of interesting stats on the CSS your page is using
Local Overrides: A powerful feature that lets you override production websites with your local resources, so you can easily preview changes

So, what about DevTool in other browsers?

I’m sure you noticed that I’ve been using Chrome throughout this article. It’s the browser I use personally. That said, it’s worth considering that:

Firefox DevTools is looking pretty great right now
With Microsoft Edge extending from Chromium, it too will benefit from these DevTools features
As evident on the Safari Technology Preview Release Notes (search for Web Inspector on that page), Safari DevTools has come a long way

In other words, keep an eye out because this is a quickly evolving space!

Conclusion

We covered a lot in a short amount of space!

Lighthouse: A panel that provides tips and suggestions for performance, accessibility, SEO and best practices.
Inspect Element: An enhancement to the Inspect Element feature that provides accessibility information to the Inspect Element tooltip
Emulate vision deficiencies: A feature in the Rendering Pane to view a page through the lens of low vision.
Performance Panel Timings: Additional metrics in the Performance panel recording, showing user-orientated stats, like Largest Contentful Paint
Performance Monitor – A real-time visualization of performance metrics for the current website, such as CPU usage and DOM size

Please check out my mailing list, Dev Tips, if you want to stay keep up with the latest updates and get over 200 web development tips! I also have a premium video course over at ModernDevTools.com. And, I tend to post loads of bonus web development resources on Twitter.

A Look at What’s New in Chrome DevTools in 2020 originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Improving Chromium’s browser compatibility in 2020

Chris Coyier — Tue, 07 Jul 2020 14:44:19 +0000

This is exactly what I love to hear from any browser vendor:

When it comes to browser compatibility, there are still too many missing features and edge-case bugs. But it doesn’t have to be this way. Things can and will get better, if browser vendors can understand what is causing the most pain, and take action to address the causes. In Chrome we’re doing our best to listen, and we’re doing our best to address what we’re hearing. We hope it helps, and we’re looking forward to a more compatible 2021.

I love the nod to that super clever div that looks different in every browser. This is a solid list from Stephen McGruer. My favorite:

Like Flexbox, CSS Grid is an important component of modern layout. Looking at the early survey results it seems like the story for CSS Grid support in Chromium is fairly good (we have our friends from Igalia to thank for that!). There is one clear exception – Chromium still doesn’t support subgrid.
Hopefully, it won’t be an exception for much longer. It’s still early days, but I’m excited to share that a team at Microsoft Edge are working on rearchitecting Chromium’s Grid support to use the new LayoutNG engine – and as part of this are intending to add subgrid support!

Not that anyone should relax, but I think right now is probably the best level of browser compatibility we’ve ever seen.

To Shared Link — Permalink on CSS-Tricks

Improving Chromium’s browser compatibility in 2020 originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

How to Build a Chrome Extension

Sarah Drasner — Tue, 19 May 2020 14:38:42 +0000

I made a Chrome extension this weekend because I found I was doing the same task over and over and wanted to automate it. Plus, I’m a nerd living through a pandemic, so I spend my pent-up energy building things. I’ve made a few Chrome Extensions over the years, hope this post helps you get going, too. Let’s get started!

Create the manifest

The first step is creating a manifest.json file in a project folder. This serves a similar purpose to a package.json, it provides the Chrome Web Store with critical information about the project, including the name, version, the required permissions, and so forth. Here’s an example:

{
 "manifest_version": 2,
 "name": "Sample Name",
 "version": "1.0.0",
 "description": "This is a sample description",
 "short_name": "Short Sample Name",
 "permissions": ["activeTab", "declarativeContent", "storage", ""],
 "content_scripts": [
   {
     "matches": [""],
     "css": ["background.css"],
     "js": ["background.js"]
   }
 ],
 "browser_action": {
   "default_title": "Does a thing when you do a thing",
   "default_popup": "popup.html",
   "default_icon": {
     "16": "icons/icon16.png",
     "32": "icons/icon32.png"
   }
 }
}

You might notice a few things- first: the names and descriptions can be anything you’d like.

The permissions depend on what the extension needs to do. We have ["activeTab", "declarativeContent", "storage", ""] in this example because this particular extension needs information about the active tab, needs to change the page content, needs to access localStorage, and needs to be active on all sites. If it only needs it to be active on one site at a time, we can remove the last index of that array.

A list of all of the permissions and what they mean can be found in Chrome’s extension docs.

"content_scripts": [
  {
    "matches": [""],
    "css": ["background.css"],
    "js": ["background.js"]
  }
],

The content_scripts section sets the sites where the extension should be active. If you want a single site, like Twitter for example, you would say ["https://twitter.com/*"]. The CSS and JavaScript files are everything needed for extensions. For instance, my productive Twitter extension uses these files to override Twitter’s default appearance.

"browser_action": {
  "default_title": "Does a thing when you do a thing",
  "default_popup": "popup.html",
  "default_icon": {
    "16": "icons/icon16.png",
    "32": "icons/icon32.png"
  }
}

There are things in browser_action that are also optional. For example, if the extension doesn’t need a popup for its functionality, then both the default_title and default_popup can be removed. In that case, all that’s needed the icon for the extension. If the extension only works on some sites, then Chrome will grey out the icon when it’s inactive.

Debugging

Once the manifest, CSS and JavaScript files are ready, head over to chrome://extensions/from the browser’s address bar and enable developer mode. That activates the “Load unpacked” button to add the extension files. It’s also possible to toggle whether or not the developer version of the extension is active.

I would highly recommend starting a GitHub repository to version control the files at this point. It’s a good way to save the work.

The extension needs to be reloaded from this interface when it is updated. A little refresh icon will display on the screen. Also, if the extension has any errors during development, it will show an error button with a stack trace and more info here as well.

If the extension need to make use of a popup that comes off the extension icon, it’s thankfully fairly straightforward. After designating the name of the file with browser_action in the manifest file, a page can be built with whatever HTML and CSS you’ll like to include, including images (I tend to use inline SVG).

We’ll probably want to add some functionality to a popup. That make take some JavaScript, so make sure the JavaScript file is designated in the manifest file and is linked up in your popup file as well, like this:

In that file, start by creating functionality and we’ll have access to the popup DOM like this:

document.addEventListener("DOMContentLoaded", () => {
 var button = document.getElementById("submit")

 button.addEventListener("click", (e) => {
   console.log(e)
 })
})

If we create a button in the popup.html file, assign it an ID called submit, and then return a console log, you might notice that nothing is actually logged in the console. That’s because we’re in a different context, meaning we’ll need to right-click on the popup and open up a different set of DevTools.

We now have access to logging and debugging! Keep in mind, though, that if anything is set in localStorage, then it will only exist in the extension’s DevTools localStorage; not the user’s browser localStorage. (This bit me the first time I tried it!)

Running scripts outside the extension

This is all fine and good, but say we want to run a script that has access to information on the current tab? Here’s a couple of ways we would do this. I would typically call a separate function from inside the DOMContentLoaded event listener:

Example 1: Activate a file

function exampleFunction() {
 chrome.tabs.executeScript(() => {
   chrome.tabs.executeScript({ file: "content.js" })
 })
}

Example 2: Execute just a bit of code

This way is great if there’s only a small bit of code to run. However, it quickly gets tough to work with since it requires passing everything as a string or template literal.

function exampleFunction() {
 chrome.tabs.executeScript({
   code: `console.log(‘hi there’)`
  })
}

Example 3: Activate a file and pass a parameter

Remember, the extension and tab are operating in different contexts. That makes passing parameters between them a not-so-trivial task. What we’ll do here is nest the first two examples to pass a bit of code into the second file. I will store everything I need in a single option, but we’ll have to stringify the object for that to work properly.

function exampleFunction(options) {
 chrome.tabs.executeScript(
   { code: "var options = " + JSON.stringify(options) },
   function() {
     chrome.tabs.executeScript({ file: "content.js" })
   }
 )
}

Icons

Even though the manifest file only defines two icons, we need two more to officially submit the extension to the Chrome Web Store: one that’s 128px square, and one that I call icon128_proper.png, which is also 128px, but has a little padding inside it between the edge of the image and the icon.

Keep in mind that whatever icon is used needs to look good both in light mode and dark mode for the browser. I usually find my icons on the Noun Project.

Submitting to the Chrome Web Store

Now we get to head over to the Chrome Web Store developer console to submit the extension! Click the “New Item” button, the drag and drop the zipped project file into the uploader.

From there, Chrome will ask a few questions about the extension, request information about the permissions requested in the extension and why they’re needed. Fair warning: requesting “activeTab” or “tabs” permissions will require a longer review to make sure the code isn’t doing anything abusive.

That’s it! This should get you all set up and on your way to building a Chrome browser extension! 🎉

How to Build a Chrome Extension originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Native Image Lazy Loading in Chrome Is Way Too Eager

Chris Coyier — Wed, 05 Feb 2020 21:19:30 +0000

Interesting research from Aaron Peters on :

On my 13 inch macbook, with Dock positioned on the left, the viewport height in Chrome is 786 pixels so images with loading="lazy" that are more than 4x the viewport down the page are eagerly fetched by Chrome on page load.
In my opinion, that is waaaaay too eager. Why not use a lower threshold value like 1000 pixels? Or even better: base the threshold value on the actual viewport height.

My guess is they chose not to over-engineer the feature by default and will improve it over time. By choosing a fairly high threshold, they ran a lower risk of it annoying users with layout shifts on pages with images that don’t use width/height attributes.

I think this unmerged Pull Request is the closest thing we have to a spec and it uses language like “scrolled into the viewport” which suggests no threshold at all.

To Shared Link — Permalink on CSS-Tricks

Native Image Lazy Loading in Chrome Is Way Too Eager originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Weekly Platform News: Strict Tracking Protection, Dark Web Pages, Periodic Background Sync

Šime Vidas — Thu, 12 Dec 2019 21:41:42 +0000

In this week’s news: Firefox gets strict, Opera goes to the dark side, and Chrome plans to let web apps run in the background.

Let’s get into the news.

Firefox for Android will block tracking content

Mozilla has announced that the upcoming revamped Firefox for Android (currently available in a test version under the name “Firefox Preview”) will include strict tracking protection by default.

On the phone or tablet, most users care much more about performance and blocking of annoyances compared to desktop. Users are more forgiving when a site doesn’t load exactly like it’s meant to. So we decided that while Firefox for desktop’s default mode is “Standard,” Firefox Preview will use “Strict” mode.

Strict tracking protection additionally blocks “tracking content”: ads, videos, and other content with tracking code.

(via Mozilla)

Opera adds option that renders all websites in dark mode

Opera for Android has added a “Dark web pages” option that renders all websites in dark mode. If a website does not provide dark mode styles (via the CSS prefers-color-scheme media feature), Opera applies its own “clever CSS changes” to render the site in dark mode regardless.

(via Stefan Stjernelund)

Periodic Background Sync is coming to Chrome

Google intends to ship Periodic Background Sync in the next version of Chrome (early next year). This feature will enable installed web apps to run background tasks at periodic intervals with network connectivity.

Chrome’s implementation restricts the API to installed web apps. Chrome grants the permission on behalf of the user for any installed web app. The API is not available outside of installed PWAs.

Apple and Mozilla are currently opposed to this API. At Mozilla, there are opinions that the feature is “harmful in its current state,” while Apple states multiple privacy and security risks.

(via Mugdha Lakhani)

More news…

Read more news in my weekly newsletter for web developers. Pledge as little as $2 per month to get the latest news from me via email every Monday.

More News →

Weekly Platform News: Strict Tracking Protection, Dark Web Pages, Periodic Background Sync originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Zero hands up.

Chris Coyier — Wed, 02 Oct 2019 14:13:59 +0000

Asked an entire room full of webdevs yesterday if any of them knew that FF/Chrome/Opera/Brave/etc. for iOS weren't allowed to compete on engine quality.

Zero hands up.

— Alex Russell (@slightlylate) September 25, 2019

It’s worth making this clear then. On iOS, the only browser engine is WebKit. There are other browsers, but they can’t bring their own engine (Blink/Gecko). So, if you’re using Chrome or Firefox on iOS, it’s really the same engine Safari is using, only slightly less capable (e.g. no third-party content blocker apps work in them).

It’s worth knowing that as a developer. While Chrome supports stuff like service workers on their desktop browser and on other platforms, the browser engine made available to non-Safari browsers on iOS does not. You don’t have them there. Likewise for Firefox.

Zero hands up. originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Browser Engine Diversity

Chris Coyier — Tue, 24 Sep 2019 14:18:17 +0000

We lost Opera when they went Chrome in 2013. Same deal with Edge when it also went Chrome earlier this year. Mike Taylor called these changes a “Decreasingly Diverse Browser Engine World” in a talk I’d like to see.

So all we’ve got left is Chrome-stuff, Firefox-stuff, and Safari-stuff. Chrome and Safari share the same lineage but have diverged enough, evolve separately enough, and are walled away from each other enough that it makes sense to think of them as different from one another.

I know there are fancier words to articulate this. For example, browser engines themselves have names that are distinct and separate from the names of the browsers.

Take Chrome, which is based on the open-source project Chromium, which uses the rendering engine Blink and the JavaScript engine V8.

Firefox uses Gecko as its browser engine, which is turning into Quantum, which has sub-parts like Servo for CSS and rendering.

Safari uses WebKit as a browser engine, which has parts like WebCore and JavaScriptCore.

It’s all kinda complicated and I’m not even sure I quite understand it all. My brain just thinks of it as everything under the umbrella of the main browser name.

The two extremes of looking at this from the perspective of decreasing diversity:

This is bad. Decreased diversity may hinder ecosystems from competing and innovating.
This is good. Cross-engine problems are a major productivity loss for the world. Getting down to one ecosystem would be even better.

Whichever it is, the ship has sailed. All we can do is look forward.

Random thoughts:

Perhaps diversity has just moved scope. Rather than the browser engines themselves representing diversity, maybe forks of the engnies we have left can compete against each other. Maybe starting from a strong foundation is a good place to start innovating?
If, god forbid, we got down to one browser engine, what happens to the web standards process? The fear would be that the last-engine-standing doesn’t have to worry about interop anymore and they run wild with implementations. But does running wild mean the playing field can never be competitive again?
It’s awesome when browsers compete on features that are great for users but don’t affect web standards. Great password managers, user protection features, clever bookmarking ideas, reader modes, clean integrations with payment APIs, free VPNs, etc. That was Opera’s play, and now we see many more in the same vein. Vivaldi is all about customization, Brave doubles down on privacy and security, and Puma is about monetization.

Brian Kardell wrote about some of this stuff recently in his “Beyond Browser Vendors” post. An interesting point is that the remaining browser engines are all open source. That means they can and do take outside contributions, which is exactly how CSS Grid came to exist.

Most of the work on CSS Grid in both WebKit and Chromium (Blink) was done, not by Google or Apple, but by teams at Igalia.

Think about that for a minute: The prioritization of its work was determined in 2 browsers not by a vendor, but by an investment from Bloomberg who had the foresight to fund this largely uncontroversial work.

And now, that idea continues:

This isn’t a unique story, it’s just a really important and highly visible one that’s fun to hold up. In fact, just in the last 6 months engineers as Igalia have worked on CSS Containment, ResizeObserver, BigInt, private fields and methods, responsive image preloading, CSS Text Level 3, bringing MathML to Chromium, normalizing SVG and MathML DOMs and a lot more.

What we may have lost in browser engine diversity we may gain back in the openness of browser engines and outside players stepping up.

Browser Engine Diversity originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

chrome – CSS-Tricks

A Couple Changes Coming in Chrome 108

Desktop

Mobile / Tablet

What is Chromium Without Chrome on Top?

CSS Underlines Are Too Thin and Too Low in Chrome

Table of Contents

Default underlines are inconsistent

Luckily, we can override the browsers’ defaults

Chrome bug 1: Underlines are too thin on macOS

Chrome bug 2: Underlines are too low

Help prioritize the Chrome bugs

Our favorite Chrome extensions of 2021

On Browser-Specific URL Schemes

Custom State Pseudo-Classes in Chrome

Built-in states

Custom states

Let’s add a --checked state to a element

This feature is not (yet) a standard

New in Chrome 88: aspect-ratio

What’s New In DevTools (Chrome 86)

A Look at What’s New in Chrome DevTools in 2020

Lighthouse

A better “Inspect Element”

Emulate vision deficiencies

Get timing on performance

Monitor performance

CSS overview and local overrides

So, what about DevTool in other browsers?

Conclusion

Improving Chromium’s browser compatibility in 2020

How to Build a Chrome Extension

Create the manifest

Debugging

Popup functionality

Running scripts outside the extension

Example 1: Activate a file

Example 2: Execute just a bit of code

Example 3: Activate a file and pass a parameter

Icons

Submitting to the Chrome Web Store

Native Image Lazy Loading in Chrome Is Way Too Eager

Weekly Platform News: Strict Tracking Protection, Dark Web Pages, Periodic Background Sync

Firefox for Android will block tracking content

Opera adds option that renders all websites in dark mode

Periodic Background Sync is coming to Chrome

More news…

Zero hands up.

Browser Engine Diversity

Let’s add a `--checked` state to a element