Tag: Chrome

How to Transition to Manifest V3 for Chrome Extensions

Posted on January 19, 2023 in Design

While I am not a regular Chrome extension programmer, I have certainly coded enough extensions and have a wide enough web development portfolio to know my way around the task. However, just recently, I had a client reject one of my extensions as I received feedback that my extension was “outdated”.

As I was scrambling to figure out what was wrong, I swept my embarrassment under the carpet and immediately began my deep dive back into the world of Chrome Extensions. Unfortunately, information on Manifest V3 was scarce and it was difficult for me to understand quickly what this transition was all about.

Needless to say, with a pending job, I had to painstakingly navigate my way around Google’s Chrome Developer Documentation and figure things out for myself. While I got the job done, I did not want my knowledge and research in this area to go to waste and decided to share what I wish I could have had easy access to in my learning journey.

Why the transition to Manifest 3 is important

Manifest V3 is an API that Google will use in its Chrome browser. It is the successor to the current API, Manifest V2, and governs how Chrome extensions interact with the browser. Manifest V3 introduces significant changes to the rules for extensions, some of which will be the new mainstay from V2 we were used to.

The transition to Manifest V3 can be summarized as such:

  1. The transition has been ongoing since 2018.
  2. Manifest V3 will officially begin rolling out in January 2023.
  3. By June 2023, extensions that run Manifest V2 will no longer be available on the Chrome Web Store.
  4. Extensions that do not comply with the new rules introduced in Manifest V3 will eventually be removed from the Chrome Web Store.

One of the main goals of Manifest V3 is to make users safer and improve the overall browser experience. Previously, many browser extensions relied on code in the cloud, meaning it could be difficult to assess whether an extension was risky. Manifest V3 aims to address this by requiring extensions to contain all the code they will run, allowing Google to scan them and detect potential risks. It also forces extensions to request permission from Google for the changes they can implement on the browser.

Staying up-to-date with Google’s transition to Manifest V3 is important because it introduces new rules for extensions that aim to improve user safety and the overall browser experience, and extensions that do not comply with these rules will eventually be removed from the Chrome Web Store.

In short, all of your hard work in creating extensions that used Manifest V2 could be for naught if you do not make this transition in the coming months.

January 2023 June 2023 January 2024
Support for Manifest V2 extensions will be turned off in Chrome’s Canary, Dev, and Beta channels. The Chrome Web Store will no longer allow Manifest V2 extensions to be published with visibility set to Public. The Chrome Web Store will remove all remaining Manifest V2 extensions.
Manifest V3 will be required for the Featured badge in the Chrome Web Store. Existing Manifest V2 extensions that are published and publically visible will become unlisted. Support for Manifest 2 will end for all of Chrome’s channels, including the Stable channel, unless the Enterprise channel is extended.

The key differences between Manifest V2 and V3

There are many differences between the two, and while I highly recommend that you read up on Chrome’s “Migrating to Manifest V3” guide, here is a short and sweet summary of key points:

  1. Service workers replace background pages in Manifest V3.
  2. Network request modification is handled with the new declarativeNetRequest API in Manifest V3.
  3. In Manifest V3, extensions can only execute JavaScript that is included within their package and cannot use remotely-hosted code.
  4. Manifest V3 introduces promise support to many methods, though callbacks are still supported as an alternative.
  5. Host permissions in Manifest V3 are a separate element and must be specified in the "host_permissions" field.
  6. The content security policy in Manifest V3 is an object with members representing alternative content security policy (CSP) contexts, rather than a string as it was in Manifest V2.

In a simple Chrome Extension’s Manifest that alters a webpage’s background, that might look like this:

// Manifest V2 {   "manifest_version": 2,   "name": "Shane's Extension",   "version": "1.0",   "description": "A simple extension that changes the background of a webpage to Shane's face.",   "background": {     "scripts": ["background.js"],     "persistent": true   },   "browser_action": {     "default_popup": "popup.html"   },   "permissions": [ "activeTab", ],   "optional_permissions": ["<all_urls>"] }
// Manifest V3 {   "manifest_version": 3,   "name": "Shane's Extension",   "version": "1.0",   "description": "A simple extension that changes the background of a webpage to Shane's face.",   "background": {     "service_worker": "background.js"   },   "action": {     "default_popup": "popup.html"   },   "permissions": [ "activeTab", ],   "host_permissions": [ "<all_urls>" ] }

If you find some of the tags above seem foreign to you, keep reading to find out exactly what you need to know.

How to smoothly transition to Manifest V3

I have summarized the transition to Manifest V3 in four key areas. Of course, while there are many bells and whistles in the new Manifest V3 that need to be implemented from the old Manifest V2, implementing changes in these four areas will get your Chrome Extension well on the right track for the eventual transition.

The four key areas are:

  1. Updating your Manifest’s basic structure.
  2. Modify your host permissions.
  3. Update the content security policy.
  4. Modify your network request handling.

With these four areas, your Manifest’s fundamentals will be ready for the transition to Manifest V3. Let’s look at each of these key aspects in detail and see how we can work towards future-proofing your Chrome Extension from this transition.

Updating your Manifest’s basic structure

Updating your manifest’s basic structure is the first step in transitioning to Manifest V3. The most important change you will need to make is changing the value of the "manifest_version" element to 3, which determines that you are using the Manifest V3 feature set.

One of the major differences between Manifest V2 and V3 is the replacement of background pages with a single extension service worker in Manifest V3. You will need to register the service worker under the "background" field, using the "service_worker" key and specify a single JavaScript file. Even though Manifest V3 does not support multiple background scripts, you can optionally declare the service worker as an ES Module by specifying "type": "module", which allows you to import further code.

In Manifest V3, the "browser_action" and "page_action" properties are unified into a single "action" property. You will need to replace these properties with "action" in your manifest. Similarly, the "chrome.browserAction" and "chrome.pageAction" APIs are unified into a single “Action” API in Manifest V3, and you will need to migrate to this API.

// Manifest V2 "background": {   "scripts": ["background.js"],   "persistent": false }, "browser_action": {   "default_popup": "popup.html" },

// Manifest V3 "background": {   "service_worker": "background.js" }, "action": {   "default_popup": "popup.html" }

Overall, updating your manifest’s basic structure is a crucial step in the process of transitioning to Manifest V3, as it allows you to take advantage of the new features and changes introduced in this version of the API.

Modify your host permissions

The second step in transitioning to Manifest V3 is modifying your host permissions. In Manifest V2, you specify host permissions in the "permissions" field in the manifest file. In Manifest V3, host permissions are a separate element, and you should specify them in the "host_permissions" field in the manifest file.

Here is an example of how to modify your host permissions:

// Manifest V2 "permissions": [    "activeTab",    "storage",    "http://www.css-tricks.com/",    ":///*"  ]
// Manifest V3 "permissions": [    "activeTab",    "scripting",    "storage" ], "host_permissions": [   "http://www.css-tricks.com/"  ], "optional_host_permissions": [    ":///*"  ]

Update the content security policy

In order to update the CSP of your Manifest V2 extension to be compliant with Manifest V3, you will need to make some changes to your manifest file. In Manifest V2, the CSP was specified as a string in the "content_security_policy" field of the manifest.

In Manifest V3, the CSP is now an object with different members representing alternative CSP contexts. Instead of a single "content_security_policy" field, you will now have to specify separate fields for "content_security_policy.extension_pages" and "content_security_policy.sandbox", depending on the type of extension pages you are using.

You should also remove any references to external domains in the "script-src", "worker-src", "object-src", and "style-src" directives if they are present. It is important to make these updates to your CSP in order to ensure the security and stability of your extension in Manifest V3.

// Manifest V2 "content_security_policy": "script-src 'self' https://css-tricks.com; object-src 'self'"
// Manfiest V3 "content_security_policy.extension_pages": "script-src 'self' https://example.com; object-src 'self'", "content_security_policy.sandbox": "script-src 'self' https://css-tricks.com; object-src 'self'"

Modify your network request handling

The final step in transitioning to Manifest V3 is modifying your network request handling. In Manifest V2, you would have used the chrome.webRequest API to modify network requests. However, this API is replaced in Manifest V3 by the declarativeNetRequest API.

To use this new API, you will need to specify the declarativeNetRequest permission in your manifest and update your code to use the new API. One key difference between the two APIs is that the declarativeNetRequest API requires you to specify a list of predetermined addresses to block, rather than being able to block entire categories of HTTP requests as you could with the chrome.webRequest API.

It is important to make these changes in your code to ensure that your extension continues to function properly under Manifest V3. Here is an example of how you would modify your manifest to use the declarativeNetRequest API in Manifest V3:

// Manifest V2 "permissions": [   "webRequest",   "webRequestBlocking" ]

// Manifest V3 "permissions": [   "declarativeNetRequest" ]

You will also need to update your extension code to use the declarativeNetRequest API instead of the chrome.webRequest API.

Other aspects you need to check

What I have covered is just the tip of the iceberg. Of course, if I wanted to cover everything, I could be here for days and there would be no point in having Google’s Chrome Developers guides. While what I covered will have you future-proofed enough to arm your Chrome extensions in this transition, here are some other things you might want to look at to ensure your extensions are functioning at the top of their game.

  • Migrating background scripts to the service worker execution context: As mentioned earlier, Manifest V3 replaces background pages with a single extension service worker, so it may be necessary to update background scripts to adapt to the service worker execution context.
  • Unifying the **chrome.browserAction** and **chrome.pageAction** APIs: These two equivalent APIs are unified into a single API in Manifest V3, so it may be necessary to migrate to the Action API.
  • Migrating functions that expect a Manifest V2 background context: The adoption of service workers in Manifest V3 is not compatible with methods like chrome.runtime.getBackgroundPage(), chrome.extension.getBackgroundPage(), chrome.extension.getExtensionTabs(), and chrome.extension.getViews(). It may be necessary to migrate to a design that passes messages between other contexts and the background service worker.
  • Moving CORS requests in content scripts to the background service worker: It may be necessary to move CORS requests in content scripts to the background service worker in order to comply with Manifest V3.
  • Migrating away from executing external code or arbitrary strings: Manifest V3 no longer allows the execution of external logic using chrome.scripting.executeScript({code: '...'}), eval(), and new Function(). It may be necessary to move all external code (JavaScript, WebAssembly, CSS) into the extension bundle, update script and style references to load resources from the extension bundle, and use chrome.runtime.getURL() to build resource URLs at runtime.
  • Updating certain scripting and CSS methods in the Tabs API: As mentioned earlier, several methods move from the Tabs API to the Scripting API in Manifest V3. It may be necessary to update any calls to these methods to use the correct Manifest V3 API.

And many more!

Feel free to take some time to get yourself up to date on all the changes. After all, this change is inevitable and if you do not want your Manifest V2 extensions to be lost due to avoiding this transition, then spend some time arming yourself with the necessary knowledge.

On the other hand, if you are new to programming Chrome extensions and looking to get started, a great way to go about it is to dive into the world of Chrome’s Web Developer tools. I did so through a course on Linkedin Learning, which got me up to speed pretty quickly. Once you have that base knowledge, come back to this article and translate what you know to Manifest V3!

So, how will I be using the features in the new Manifest V3 going forward?

Well, to me, the transition to Manifest V3 and the removal of the chrome.webRequest API seems to be shifting extensions away from data-centric use cases (such as ad blockers) to more functional and application-based uses. I have been staying away from application development lately as it can get quite resource-intensive at times. However, this shift might be what brings me back!

The rise of AI tools in recent times, many with available-to-use APIs, has sparked tons of new and fresh SaaS applications. Personally, I think that it’s coming at a perfect time with the shift to more application-based Chrome extensions! While many of the older extensions may be wiped out from this transition, plenty of new ones built around novel SaaS ideas will come to take their place.

Hence, this is an exciting update to hop on and revamp old extensions or build new ones! Personally, I see many possibilities in using APIs that involve AI being used in extensions to enhance a user’s browsing experience. But that’s really just the tip of the iceberg. If you’re looking to really get into things with your own professional extensions or reaching out to companies to build/update extensions for them, I would recommend upgrading your Gmail account for the benefits it gives in collaborating, developing, and publishing extensions to the Chrome Web Store.

However, remember that every developer’s requirements are different, so learn what you need to keep your current extensions afloat, or your new ones going!

How to Transition to Manifest V3 for Chrome Extensions originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

CSS-Tricks

, , ,

A Couple Changes Coming in Chrome 108

Posted on November 4, 2022 in Design

“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, image, video, and canvas elements that were once clipped might display the overflow 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 visible overflow is overriding the UA’s default overflow: visible with overflow: clip:

img {   overflow: clip; }

“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:

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

Mobile / Tablet

Android Chrome Android Firefox Android iOS Safari
No 106 No 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.

CSS-Tricks

, , ,
[Top]

A Chrome Extension for Cloudinary That Helps You Pluck Out Useful Media URLs From Your Library Quickly

Posted on February 10, 2022 in Design

(This is a sponsored post.)

Cloudinary is a host for your digital assets like images and video. If you don’t already know them, you should, because you can build it into the asset management you almost certainly need to do if you run any size of website. Cloudinary helps you serve the assets as efficiently as technologically possible, meaning optimization, resizing, CDN hosting, and goes further in allowing interesting transforms on those assets.

If you already use it, unless you use it entirely through the APIs, you’ll know Cloudinary has a Media Library that gives you a UI dashboard for everything you’ve ever uploaded to Cloudinary. This is where you find your assets and open them up to play with the settings and transformations and such (e.g. blur it — then serve in the best possible format with automatic quality adjustments). You can always pop over to cloudinary.com to use this. But wouldn’t it be nice if this process was made a bit easier?

That clutch moment where you get the URL of the image you need.

There are all sorts of moments while bopping the web around doing our jobs as developers where you might need to get your fingers on an asset URL.

Gimme that URL!

Here’s a personal example: we have a little custom CMS thing for building our weekly email The CodePen Spark. It expects a URL to an image.

This is the exact kind of moment that the brand new Chrome Media Library Extension could help. Essentially it gives you a context menu you can use right in the browser to snag a URL to an asset. Right click, Insert and Asset URL.

It pops up a UI right inline (where you are on the web) of your Media Library, and you pick an image from there. Find the one you want, open it up, and you can either “edit” it to customize it to your liking, or just Insert it straight away.

Then it plops the URL right onto the site (probably an input) where you need it.

You can set up defaults to your liking, but I really like how the defaults are f_auto and q_auto which are Cloudinary classics that you’ll almost surely want. They mean “serve in the best possible format” and “optimize it intelligently”.

Sharon Yelenik introduced it on the Cloudinary blog:

Say your team creates social posts on a browser tab on an automated marketing application. To locate a media asset, you must open another tab to search for the asset within the Media Library, copy the related URL, and paste it into the app. In some cases, you even have to download an asset and then upload it into the app.

Talk about a classic example of menial, mundane, and repetitive chores!

Exactly. I like the idea of having tools to optimize workflows that should be easy. I’d also call Cloudinary a bit of a technical/developer tool, and there is an aspect to this that could be set up on anyone’s machine that would allow them to pick assets from your Media Library easily, without any access control worries.

If all this appeals to you:

Get the Chrome Extension

Or see more at Cloudinary Labs, documentation, and blog post.

A Chrome Extension for Cloudinary That Helps You Pluck Out Useful Media URLs From Your Library Quickly originally published on CSS-Tricks. You should get the newsletter and become a supporter.

CSS-Tricks

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

Helpful Tips for Starting a Next.js Chrome Extension

Posted on February 10, 2022 in Design

I recently rewrote one of my projects — Minimal Theme for Twitter — as a Next.js Chrome extension because I wanted to use React for the pop-up. Using React would allow me to clearly separate my extension’s pop-up component and its application logic from its content scripts, which are the CSS and JavaScript files needed to execute the functionality of the extension.

As you may know, there are several ways to get started with React, from simply adding script tags to using a recommended toolchain like Create React App, Gatsby, or Next.js. There are some immediate benefits you get from Next.js as a React framework, like the static HTML feature you get with next export. While features like preloading JavaScript and built-in routing are great, my main goal with rewriting my Chrome extension was better code organization, and that’s really where Next.js shines. It gives you the most out-of-the-box for the least amount of unnecessary files and configuration. I tried fiddling around with Create React App and it has a surprising amount of boilerplate code that I didn’t need.

I thought it might be straightforward to convert over to a Next.js Chrome extension since it’s possible to export a Next.js application to static HTML. However, there are some gotchas involved, and this article is where I tell you about them so you can avoid some mistakes I made.

First, here’s the GitHub repo if you want to skip straight to the code.

New to developing Chrome extensions? Sarah Drasner has a primer to get you started.

Folder structure

next-export is a post-processing step that compiles your Next.js code, so we don’t need to include the actual Next.js or React code in the extension. This allows us to keep our extension at its lowest possible file size, which is what we want for when the extension is eventually published to the Chrome Web Store.

So, here’s how the code for my Next.js Chrome extension is organized. There are two directories — one for the extension’s code, and one containing the Next.js app.

📂 extension   📄 manifest.json 📂 next-app   📂 pages   📂 public   📂 styles   📄 package.json README.md

The build script

To use next export in a normal web project, you would modify the default Next.js build script in package.json to this:

"scripts": {   "build": "next build && next export" }

Then, running npm run build (or yarn build) generates an out directory.

In this case involving a Chrome extension, however, we need to export the output to our extension directory instead of out. Plus, we have to rename any files that begin with an underscore (_), as Chrome will fire off a warning that “Filenames starting with “_” are reserved for use by the system.”

Screenshot of the Next.js Chrome Extension Chrome Extension Store with a failed to load extension error pop-up.
What we need is a way to customize those filenames so Chrome is less cranky.

This leads us to have a new build script like this:

"scripts": {   "build": "next build && next export && mv out/_next out/next && sed -i '' -e 's//_next/./next/g' out/**.html && mv out/index.html ../extension && rsync -va --delete-after out/next/ ../extension/next/" }

sed on works differently on MacOS than it does on Linux. MacOS requires the '' -e flag to work correctly. If you’re on Linux you can omit that additional flag.

Assets

If you are using any assets in the public folder of your Next.js project, we need to bring that into our Chrome extension folder as well. For organization, adding a next-assets folder inside public ensures your assets aren’t output directly into the extension directory.

The full build script with assets is this, and it’s a big one:

"scripts": {   "build": "next build && next export && mv out/_next out/next && sed -i '' -e 's//_next/./next/g' out/**.html && mv out/index.html ../extension && rsync -va --delete-after out/next/ ../extension/next/ && rm -rf out && rsync -va --delete-after public/next-assets ../extension/" }

Chrome Extension Manifest

The most common pattern for activating a Chrome extension is to trigger a pop-up when the extension is clicked. We can do that in Manifest V3 by using the action keyword. And in that, we can specify default_popup so that it points to an HTML file.

Here we are pointing to an index.html from Next.js:

{   "name": "Next Chrome",   "description": "Next.js Chrome Extension starter",   "version": "0.0.1",   "manifest_version": 3,   "action": {     "default_title": "Next.js app",     "default_popup": "index.html"   } }

The action API replaced browserAction and pageAction` in Manifest V3.

Next.js features that are unsupported by Chrome extensions

Some Next.js features require a Node.js web server, so server-related features, like next/image, are unsupported by a Chrome extension.

Start developing

Last step is to test the updated Next.js Chrome extension. Run npm build (or yarn build) from the next-app directory, while making sure that the manifest.json file is in the extension directory.

Then, head over to chrome://extensions in a new Chrome browser window, enable Developer Mode*,* and click on the Load Unpacked button. Select your extension directory, and you should be able to start developing!

Screenshot of Chrome open to Google's homepage and a Next.js Chrome extension pop-up along the right side.

Wrapping up

That’s it! Like I said, none of this was immediately obvious to me as I was getting started with my Chrome extension rewrite. But hopefully now you see how relatively straightforward it is to get the benefits of Next.js development for developing a Chrome extension. And I hope it saves you the time it took me to figure it out!

Helpful Tips for Starting a Next.js Chrome Extension originally published on CSS-Tricks. You should get the newsletter and become a supporter.

CSS-Tricks

, , , , ,
[Top]

What is Chromium Without Chrome on Top?

Posted on January 10, 2022 in Design

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:

A long list of features Microsoft has removed from Chromium split into four columns.

So, not all Chromium features are from Chrome

I guess that implies all this stuff is actually in Chromium, but not added to Chrome in some build step. 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:

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:

  1. Remove all remaining background requests to any web services while building and running the browser
  2. Remove all code specific to Google web services
  3. Remove all uses of pre-made binaries from the source code, and replace them with user-provided alternatives when possible.
  4. 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. You should get the newsletter and become a supporter.

CSS-Tricks

, ,
[Top]

CSS Underlines Are Too Thin and Too Low in Chrome

Posted on January 4, 2022 in Design

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.

But 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.

Sign in with your Google account and click the star button on issues #1172623 and #1255280.

CSS Underlines Are Too Thin and Too Low in Chrome originally published on CSS-Tricks

CSS-Tricks

, ,
[Top]

Our favorite Chrome extensions of 2021

Posted on December 28, 2021 in Design

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

CSS-Tricks

, , ,
[Top]

Custom State Pseudo-Classes in Chrome

Posted on May 6, 2021 in Design

There is an increasing number of “custom” features on the web platform. We have custom properties (--my-property), custom elements (<my-element>), 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 <live-score> 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 <labeled-checkbox> 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.

The post Custom State Pseudo-Classes in Chrome appeared first on CSS-Tricks.

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

CSS-Tricks

, , ,
[Top]

New in Chrome 88: aspect-ratio

Posted on January 20, 2021 in Design

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!

Direct Link to Article — Permalink

The post New in Chrome 88: aspect-ratio appeared first on CSS-Tricks.

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

CSS-Tricks

,
[Top]

What’s New In DevTools (Chrome 86)

Posted on August 26, 2020 in Design

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!)

Direct Link to Article — Permalink

The post What’s New In DevTools (Chrome 86) appeared first on CSS-Tricks.

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

CSS-Tricks

, ,
[Top]