Tag: Feature

Creating Stylesheet Feature Flags With Sass !default

!default is a Sass flag that indicates conditional assignment to a variable — it assigns a value only if the variable was previously undefined or null. Consider this code snippet:

$ variable: 'test' !default;

To the Sass compiler, this line says:

Assign $ variable to value 'test', but only if $ variable is not already assigned.

Here’s the counter-example, illustrating the other side of the !default flag’s conditional behavior:

$ variable: 'hello world'; $ variable: 'test' !default; // $ variable still contains `hello world`

After running these two lines, the value of $ variable is still 'hello world' from the original assignment on line 1. In this case, the !default assignment on line 2 is ignored since a value has already been provided, and no default value is needed.

Style libraries and @use...with

The primary motivation behind !default in Sass is to facilitate the usage of style libraries, and their convenient inclusion into downstream applications or projects. By specifying some of its variables as !default, the library can allow the importing application to customize or adjust these values, without completely forking the style library. In other words, !default variables essentially function as parameters which modify the behavior of the library code.

Sass has a special syntax just for this purpose, which combines a stylesheet import with its related variable overrides:

// style.scss @use 'library' with (   $ foo: 'hello',   $ bar: 'world' );

This statement functions almost the same as a variable assignment followed by an @import, like so:

// style.scss - a less idiomatic way of importing `library.scss` with configuration $ foo: 'hello'; $ bar: 'world'; @import 'library';

The important distinction here, and the reason @use...with is preferable, is about the scope of the overrides. The with block makes it crystal clear — to both the Sass compiler and anyone reading the source code — that the overrides apply specifically to variables which are defined and used inside of library.scss. Using this method keeps the global scope uncluttered and helps mitigate variable naming collisions between different libraries.

Most common use case: Theme customization

// library.scss $ color-primary: royalblue !default; $ color-secondary: salmon !default:    // style.scss @use 'library' with (   $ color-primary: seagreen !default;   $ color-secondary: lemonchiffon !default:  );

One of the most ubiquitous examples of this feature in action is the implementation of theming. A color palette may be defined in terms of Sass variables, with !default allowing customization of that color palette while all other styling remains the same (even including mixing or overlaying those colors).

Bootstrap exports its entire Sass variable API with the !default flag set on every item, including the theme color palette, as well as other shared values such as spacing, borders, font settings, and even animation easing functions and timings. This is one of the best examples of the flexibility provided by !default, even in an extremely comprehensive styling framework.

In modern web apps, this behavior by itself could be replicated using CSS Custom Properties with a fallback parameter. If your toolchain doesn’t already make use of Sass, modern CSS may be sufficient for the purposes of theming. However, we’ll examine use cases that can only be solved by use of the Sass !default flag in the next two examples.

Use case 2: Loading webfonts conditionally

// library.scss $ disable-font-cdn: false !default; @if not $ disable-font-cdn {   @import url(''https://fonts.googleapis.com/css2?family=Public+Sans&display=swap''); }   // style.scss @use 'library' with (   $ disable-font-cdn: true ); // no external HTTP request is made

Sass starts to show its strength when it leverages its preprocessor appearance in the CSS lifecycle. Suppose the style library for your company’s design system makes use of a custom webfont. It’s loaded from a Google’s CDN — ideally as quick as it gets — but nevertheless a separate mobile experience team at your company has concerns about page load time; every millisecond matters for their app.

To solve this, you can introduce an optional boolean flag in your style library (slightly different from the CSS color values from the first example). With the default value set to false, you can check this feature flag in a Sass @if statement before running expensive operations such as external HTTP requests. Ordinary consumers of your library don’t even need to know that the option exists — the default behavior works for them and they automatically load the font from the CDN, while other teams have access to the toggle what they need in order to fine tune and optimize page loading.

A CSS variable would not be sufficient to solve this problem — although the font-family could be overridden, the HTTP request would have already gone out to load the unused font.

Use case 3: Visually debugging spacing tokens

View live demo

!default feature flags can also be used to create debugging tools for use during development. In this example, a visual debugging tool creates color-coded overlays for spacing tokens. The foundation is a set of spacing tokens defined in terms of ascending “t-shirt sizes” (aka “xs”/”extra-small” through “xl”/”extra-large”). From this single token set, a Sass @each loop generates every combination of utility classes applying that particular token to padding or margin, on every side (top, right, bottom, and left individually, or all four at once).

Since these selectors are all constructed dynamically in a nested loop, and single !default flag can switch the rendering behavior from standard (margin plus padding) to the colored debug view (using transparent borders with the same sizes). This color-coded view may look very similar to the deliverables and wireframes which a designer might hand off for development — especially if you are already sharing the same spacing values between design and dev. Placing the visual debug view side-by-side with the mockup can help quickly and intuitively spot discrepancies, as well as debug more complex styling issues, such as margin collapse behavior.

Again — by the time this code is compiled for production, none of the debugging visualization will be anywhere in the resulting CSS since it will be completely replaced by the corresponding margin or padding statement.

Further reading

These are just a few examples of Sass !default in the wild. Refer to these documentation resources and usage examples as you adapt the technique to your own variations.

The post Creating Stylesheet Feature Flags With Sass !default appeared first on CSS-Tricks.

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


, , , , ,

In-Browser Performance Linting With Feature Policies

Here’s a neat idea from Tim Kadlec. He uses the Modheader extension to toggle custom headers in his browser. It also lets him see when images are too big and need to be optimized in some way. This is a great way to catch issues like this in a local environment because browsers will throw an error and won’t display them at all!

As Tim mentions, the trick is with the Feature Policy header with the oversized-images policy, and he toggles it on like this:

Feature-Policy: oversized-images ‘none’;

Tim writes:

By default, if you provide the browser an image in a format it supports, it will display it. It even helpful scales those images so they look great, even if you’ve provided a massive file. Because of this, it’s not immediately obvious when you’ve provided an image that is larger than the site needs.

The oversized-images policy tells the browser not to allow any images that are more than some predefined factor of their container size. The recommended default threshold is 2x, but you are able to override that if you would like.

I love this idea of using the browser to do linting work for us! I wonder what other ways we could use the browser to place guard rails around our work to prevent future mistakes…

Direct Link to ArticlePermalink

The post In-Browser Performance Linting With Feature Policies appeared first on CSS-Tricks.


, , , ,

Weekly Platform News: Feature Policy, ECMAScript i18n API, Packaged PWAs

Šime posts regular content for web developers on webplatform.news.

New Feature Policy API in Chrome

Pete LePage: You can use the document.featurePolicy.allowedFeatures method in Chrome to get a list of all Feature Policy-controlled features that are allowed on the current page.

This API can be useful when implementing a feature policy (and updating an existing feature policy) on your website.

  1. Open your site in Chrome and run the API in the JavaScript console to check which Feature Policy-controlled features are allowed on your site.
  2. Read about individual features on featurepolicy.info and decide which features should be disabled ('none' value), and which features should be disabled only in cross-origin <iframe> elements ('self' value).
  3. Add the Feature-Policy header to your site’s HTTP responses (policies are separated by semicolons).
  4. Feature-Policy: geolocation 'self';sync-xhr 'none'
  5. Repeat Step 1 to confirm that your new feature policy is in effect. You can also scan your site on securityheaders.com.

In other news…

  • Dave Camp: Firefox now blocks cookies from known trackers by default (when the cookie is used in a third-party context). This change is currently in effect only for new Firefox users; existing users will be automatically updated to the new policy “in the coming months.”
  • Pete LePage: Chrome for Android now allows websites to share images (and other file types) via the navigator.share method. See Web Platform News Issue 1014 for more information about the Web Share API. Ayooluwa Isaiah’s post from yesterday is also a good reference on how to use it.
  • Valerie Young: The ECMAScript Internationalization APIs for date and time formatting (Intl.DateTimeFormat constructor), and number formatting (Intl.NumberFormat constructor) are widely supported in browsers.
  • Alan Jeffrey: Patrick Walton from Mozilla is working on a vector graphics renderer that can render text smoothly at all angles when viewed with an Augmented Reality (AR) headset. We plan to use it in our browsers for AR headsets (Firefox Reality).
  • Pinterest Engineering: Our progressive web app is now available as a standalone desktop application on Windows 10. It can be installed via the Microsoft Store, which “treats the packaged PWA as a first class citizen with access to Windows 10 feature APIs.”
  • Jonathan Davis: The flow-root value for the CSS display property has landed in Safari Technology Preview. This value is already supported in Chrome and Firefox. See Web Platform News Issue 871 for a use case.

The post Weekly Platform News: Feature Policy, ECMAScript i18n API, Packaged PWAs appeared first on CSS-Tricks.


, , , , , , , ,

Weekly Platform News: Feature Policy, Signed Exchanges, iOS browsers

👋 Hey folks! This is the first edition of a new weekly update we’ll be posting that covers timely news at the intersection of development standards and the tools that make them available on the web. We often talk about the pace of change in our industry. It’s fast and touches everything from the HTML, CSS and JavaScript we write to the landscape of browsers that renders them. Please help us welcome Šime Vidas, who will be keeping us all on the up and up with curated updates from his own blog of regular development updates, webplatform.news.

Feature Policy in Chrome

Andrew Betts: Websites can use the HTTP Feature-Policy response header to prevent third parties from secretly using powerful features such as geolocation, and to disable certain bad practices (e.g. document.write, parser-blocking JavaScript, un-optimized images).

This allows good practices to be more easily rewarded. … Search results could be badged with some approving “fast” logomark or (more controversially perhaps) get a higher result ranking if they disallow themselves certain policy-controlled behaviors.

Feature Policy is an emerging technology. See featurepolicy.info for more information about individual policies and their level of support in browsers.

Signed exchanges on Google Search

The mobile version of Google Search includes AMP results on search results pages. When the user taps on an AMP result, the AMP page loads from Google’s domain (google.com) and is displayed in the AMP Viewer.

Google Search now supports an alternative: If a website signs its AMP pages, and the visitor uses Chrome for Android, then tapping on an AMP result instead loads the signed version of the AMP page from Google’s servers, but to the user it appears as if they have navigated to the website normally.

The technology that enables this is called Signed HTTP Exchanges (SXG). See the announcement on Google Webmaster Central Blog for more details. The specification describes the following use case:

In order to speed up loading but still maintain control over its content, an HTML page in a particular origin “O.com” could tell clients to load its sub-resources from an intermediate content distributor that’s not authoritative, but require that those resources be signed by “O.com” so that the distributor couldn’t modify the resources.

Websites can add support for signed exchanges by running AMP Packager on the server side. Cloudflare has launched a free feature called “AMP Real URL” that fully automates the signing process for AMP pages served from its CDN.

Alternative iOS browsers

Henrik Joreteg: On iOS, several important APIs are limited to Safari and are not available in any of the alternative iOS browsers. These include service workers, web payments, and camera access.

Chrome for iOS supports web payments via a custom implementation. I’ve created a browser support table on HTML5test that highlights the differences between some of the popular iOS browsers.

The post Weekly Platform News: Feature Policy, Signed Exchanges, iOS browsers appeared first on CSS-Tricks.


, , , , , , ,

New CodePen Feature: Prefill Embeds

I’ve very excited to have this feature released for CodePen. It’s very progressive enhancement friendly in the sense that you can take any <pre> block of HTML, CSS, and JavaScript (or any combination of them) and enhance it into an embed, meaning you can see the rendered output. It also lets you pass in stuff like external resources, making it a great choice for, say, documentation sites or the like.

Here’s an example right here:

<div id="root"></div>
@import url("https://fonts.googleapis.com/css?family=Montserrat:400,400i,700"); body {   margin: 0;   font-family: Montserrat, sans-serif; } header {   background: #7B1FA2;   color: white;   padding: 2rem;   font-weight: bold;   font-size: 125% }
class NavBar extends React.Component {   render() {     return(       <header>         Hello World, {this.props.name}!       </header>     );   } } ReactDOM.render(   <NavBar name="Chris" />,   document.getElementById('root') );

What you can’t see is is this block, appended to the embed snippet:

<pre data-lang="html">&lt;div id="root">&lt;/div></pre> <pre data-lang="scss" >@import url("https://fonts.googleapis.com/css?family=Montserrat:400,400i,700"); body {   margin: 0;   font-family: Montserrat, sans-serif; } header {   background: #7B1FA2;   color: white;   padding: 2rem;   font-weight: bold;   font-size: 125% }</pre>   <pre data-lang="babel">class NavBar extends React.Component {   render() {     return(       &lt;header>         Hello World, {this.props.name}!       &lt;/header>     );   } } ReactDOM.render(   &lt;NavBar name="Chris" />,   document.getElementById('root') );</pre>

If I want to update that demo, I can do it by editing this blog post. No need to head back to CodePen. 🙌

Direct Link to ArticlePermalink

The post New CodePen Feature: Prefill Embeds appeared first on CSS-Tricks.


, , ,