SPFX - SCSS modules, support for CSS @Container queries

[stevesuk]

What type of issue is this?

Question

What SharePoint development model, framework, SDK or API is this about?

💥 SharePoint Framework

Target SharePoint environment

SharePoint Online

What browser(s) / client(s) have you tested

• 💥 Internet Explorer
• 💥 Microsoft Edge
• 💥 Google Chrome
• 💥 FireFox
• 💥 Safari
• mobile (iOS/iPadOS)
• mobile (Android)
• not applicable
• other (enter in the "Additional environment details" area below)

Issue description

I noticed that when compiling .scss modules for an SPFX, CSS container queries are not supported. Since webparts can end up being inserted in to a variety of different container widths, depending on the section layout - it would be really useful to be able to use container queries (which use the parent element width/height as a trigger for CSS styling). My work around at the moment is to include a standard CSS file with the styling that benefits from container queries, and use a unique CSS classname in my SPFX. However, it would be better if you could use these queries in compiled SCSS modules.

Is there a way of doing this?

Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.

[StfBauer]

This one can be added to a list of problems:

• @layered styles: CSS build pipeline broken with modern CSS and layered styles. #8725
• Brocken SASS implementation: 🐞 Multi-issue problem with SASS aka SASS-dart - Yarn / NPM workspace configuration #8916

Let's talk about container queries for a moment. While they might seem super fancy, they could work better with SharePoint. SharePoint has a 12-grid layout, which is documented here:
https://learn.microsoft.com/en-us/sharepoint/dev/design/grid-and-responsive-design

Under the Hood, they use:

• .CanvasSection-xl12 - 12 columns
• .CanvasSection-xl8 - 8 columns
• .CanvasSection-xl6 - 6 columns
• .CanvasSection-xl4 - 4 columns
• .CanvasVerticalSection - Vertical Section

The last vertical section is out of the grid and needs to be added to the documentation.

To make the container query work - you could rely on min-width width of all sorts, but you still don't know the container you are in. If you tend to define container-name as well as container-type then every web part would overwrite each of the values newly with every new webpart, despite for the columns you need to change the out of the box CSS styles, which is not supported nor recommended. If container-name ever has to come from Microsoft, it needs to be documented for us to save to use it.

The other option would be chasing down pixel value for the outer container, which doesn't indicate how many grid columns your web part can populate. Also, you do not know if you may be on four grid columns on a tablet or 12 grid on a desktop. Neither will it be safe when Microsoft changes pixel values only by a bit because your breakpoints may not match.

Container queries in this context are a fragile construct. So the webpart might work today but not tomorrow suddenly out of the blue anymore.

So the safer way is to work with the SharePoint given grid system and not against it as described here - https://n8d.at/how-to-make-your-web-parts-responsive-to-the-parent-container.

Those grid columns are defined and documented, and maybe, in future, we can use something like CSS Subgrid.

We are currently on the sass 1.44, which should already support @ container queries, but those will likely be lost along the way, presumably in postCSS and CSS module compilation.

Would it be great to have it in future - I need to find out where SharePoint and the page designs are heading, so the customisations might break. Also, we need more documentation from Microsoft on the page side of things before we can fully leverage container queries.

What's good for early adoption might not be good for production.

[StfBauer]

@nick-pape any news or workaround not that?

[StfBauer]

I found the reason why container queries along side with so many other browser supported web standard do not work.

clean-css@4.2.1 which the SASS SPFx build task uses was released almost 6 years ago and does a decent job by 6 year old standard, by removing all it is unaware of. Such as @layer and @container CSS options.

However a there is a workaround that get offered by the build change and clean-css. It is to disable it completely. The negative impact is that is doesn't do it's magic anymore, while allowing to write web standard and widely browser supported CSS.

Another interesting fact that sp-build-core tasks got already update. Not so the @microsoft/sp-build-web@1.20.1 package.

The workaround

Like I said the workaround is to disable it completely.

build.sass.setConfig({
  dropCssFiles: true,
  useCSSModules: true,
  warnOnNonCSSModules: false,
  cleanCssOptions: {
    level: 0,
    compatibility: {
      colors: {
        hexAlpha: false, // controls 4- and 8-character hex color support
        opacity: true // controls `rgba()` / `hsla()` color support
      }
    }
    , returnPromise: true
  },
  autoprefixerOptions: { overrideBrowserslist: ["> 1%", "last 2 versions", "not dead"] }
});

With these options inserted into the gulpfile.js.

 cleanCssOptions: {
    level: 0,
    compatibility: {
      colors: {
        hexAlpha: false, // controls 4- and 8-character hex color support
        opacity: true // controls `rgba()` / `hsla()` color support
      } 
    }
    , returnPromise: true
  }

Clean CSS Level 0 disable clean-css entirely, not optimal but even better than use this outdate version.

In addition to the autoprefixerOptions:

{
autoprefixerOptions: { overrideBrowserslist: ["> 1%", "last 2 versions", "not dead"] }
}

These options finally remove the support for IE10+ making the CSS by itself more cleaner.

I really hope that we will see these enhancements in the 1.20.0 version of the generator.

@nick-pape @AJIXuMuK @stevesuk

PS: There are in addition to this other bug in the CSS compilation that causes other issues too.

[tymvios]

Hello @StfBauer ,

I tried the workaround with no success on the container queries. Do we have an update when this will be officially supported natively by SPFx? We currently use a bunch of media queries like the suggestions in your article for the webpart to know where it is. But I feel this creates a lot more overhead when trying to make things responsive and having to change layouts in multiple locations in your css.

(the attachment below is the same webpart just placed in different placeholders)

[stevesuk]

Our workaround is to reference a standard CSS file in the project, which we use only for the elements that require a Container query. All the other styling in the project stays within SCSS modules. In the CSS file, we reference the elements we wish to apply Container sizing to by ID - so as not to conflict with the class names generated from the SCSS modules.

It would be great to be able to manage the whole process in SCSS - but our current work-around is OK until the framework is updated.