Sp-dev-docs: Office UI Fabric Grid System was removed from Communication Sites and Online Workbench

[StfBauer]

Category

• [ ] Question
• [ ] Typo
• [x] Bug
• [ ] Additional article idea

Observed Behavior

On communication sites, the Office IU Fabric grid system has been recently replaced by a proprietary custom grid system. It is maybe still based on Office UI Fabric but used different class names then Office UI Fabric.

| Office UI Fabric | Communication site |
| ------------- | ----- |
| .ms-xl12 | .CanvasSection-xl12 |
| .ms-xl8 | .CanvasSection-xl8 |
| .ms-xl6 | .CanvasSection-xl6 |
| .ms-xl4 | .CanvasSection-xl4 |

This has a lot of negative impact on custom SPFx solution that optimised for the use of different part layouts container. The following screenshot shows the newly introduced columns.

This change also causes troubles when local developed web parts then will be used in an online environment, because they might behave differently.

For future development, it is even unclear what the actual plan is in case of SharePoint. Will Office UI Fabric still be supported by SharePoint or is there currently a migration ongoing to a new UI Framework.

[StfBauer]

Meanwhile, I also wrote a blog post on what exactly the issue I ran in and how I was able to solve and adapt to the changed behaviour.
This blog post on 'Major CSS Class changes in Communication Site and Workbench'

This links also the original post where I showed how to address the parent web part zone container.

[andrewconnell]

Related #1279 ?

[StfBauer]

@andrewconnell
I don't think so. Cause if the icon is correct formatted they still work with exactly the same classes in Office 365 and local.

Seems to be more a bug by Chris Kent.

[VesaJuvonen]

@StfBauer - let's try to get this clarified in slightly more detailed level. Unless mistaken, you are directly referencing fabric css styles in the web part html, which will cause potential issues since it's not following up on the fabric usage guidance explained in here - https://docs.microsoft.com/en-us/sharepoint/dev/spfx/office-ui-fabric-integration.

Could you clarify the issue with an example or provide solution project for easier repro steps? - Would help on getting the issue resolution forward. Thx.

[wictorwilen]

This is one of the issues with not using "global styles". It makes sense for custom client side web parts, but the grid system on a page is something that we/I would like to be "static" so that we can ensure that our web parts behave nicely and respect the layout of the page.

[StfBauer]

@VesaJuvonen let me clarify this and give you an example of the default HelloWorld web part because this make I guess visible what actually the problem is.
Sorry for the long post but I hope this clarifies everything. It is an technical/design addtion to what @wictorwilen said.

To make a responsive component this component first need to be responsive to the parent containers and in the last instance to the page.

So to make it responsive it is mandatory that the parent container classes can be a) referred in the web part code and b) are static so that the web parts don't break. (Not only our custom but Microsoft Web Parts too)

You will find the code used in this the explanation on GitHub the web part is named ResponsiveHelloWorld.
The default provisioned web part is a good example. It is a resizable but not responsive example in a narrower sense.

A full-width page web part

This web part uses 12 grid columns and inside the web part, I can make use of 12 grid columns. All fine as shown in this screenshot.

The margin on the left and right is two grid columns wide and the container uses eight grid columns in this example. So the grid code in the web part is in this specific case is correct because I have twelve overall grid columns.
Made possible through @include ms-xl2 and @include ms-xlPush2.

A half/half web part zone

This is where the problem begins. The web part still thinks it was added to a full page width container but instead of 12 grid columns, only six grid columns are available to each side of the web part zones.

You see that the overall design here starts to break. The margin of the two lower web parts is getting narrower. This is because this web part still behave like added to a 12 Grid system but there are only 6 remaining grid columns now left.

To fix the web parts and make them align properly I can change the full-width web part on top and reduce the margin from two grid columns to one grid column.
To do so the ms-xl8 becomes a ms-xl10 for the content. The push, responsible for the margin, need to be reduced from ms-xlPush2 to ms-xlPush1. Resulting in the following setup.

You see that not only the margin on the top web part has been decreased but also the margin on the lower web parts too.

The only way to make this work and align all elements properly is to know that the web part was placed in a container that uses 6 grid columns rather than 12. For this, I need to know the width style sheet class of the parent container which is actually .CanvasSection-xl6 and was previously ms-xl6, for the available 6 grid columns.

Now I need to
a) refer to the parent CSS class outside the scope of the web part, by default and b) make sure that the web part doesn't break the page layout.

This is possible through switching the context and override the default web part 12 grid column behaviour. The following code does that.

// Now I run on the global page context
:global{
  // The parent container has only 6 grid columns
  .CanvasSection-xl6{
    // now back to the web part context
    // Never ever code here because this will break SharePoint
    // and better switch back the scope to the local web part
    :local{
      // back in the local SharePoint Web Part
      .responsiveHelloWorld{
        // now fixing the column setup
        .column {
          @include ms-Grid-col;
          @include ms-xl8; // was @include ms-xl10; on 12 grid columns
          @include ms-xlPush2; // was @include ms-xlPush1; on 12 grid columns
          background-color: black;
        }
      }
    }

  }
}

The result is that now the grid system was reinstated for web parts on half/half web part zones.

You see how nicely the web parts align now and look balance for the end user? So the 12 grid system suddenly become a 6 grid system. That means also that the margin needs to be doubled on the six grid columns through ms-xlPush2.

The content on the other hand now uses the remaining space and only 8 grid columns on a 12 grid setup and four grid columns in a six grid column setup. So one grid column left of the content one grid column right of the content, plus four grid columns for the content makes six grid columns overall.
The exact same calculation needs to be done for different layout options too.

I know it might be a dangerous approach especially if someone enters CSS code directly below the .CanvasSection-xl6 class without switching back the SPFx / CSS Modules context to :local again immediately . I guess you can imagine now that a solid page and grid system with permission to access it from the web part is highly required. Sometimes I maybe need to change the overall experience of a single web part according to the parent container.

This also should work not only for ReactJS web parts but also HTML web parts and other frameworks. Eventually, the default web parts provided by Microsoft does the same inside the React components and assign different web part classes to the content.

Also a valid approach, again, therefore, the web parts access the parent container; Otherwise, they wouldn't work as they do.

We never know in which web part zones the web parts actually will be used and the user experience varies according to the parent container. So change the page layout once, from my perspective is okay, but we should have at least a solid contract on all pages. Technical the mixin from my blog post might end up an integral part of SPFx, with all checks needed.

Finally, one word on the documentation. This documentation needs to be reworked and adapted to the core scenarios with Office UI Fabric and SPFx. Right now it only documents a process and some general possible CSS issues.

[VesaJuvonen]

thx @StfBauer for the additional details, so that we can get this moving internally in engineering. I absolutely agree also on the needs for improving the documentation and we are more than happy to have contributions to this area also from the community.

[VesaJuvonen]

thx Stefan, your clarification is completely understandable and does make a lot of sense as a structure or ask to be supported. Problem is in your implementation case is that it's dependent on the "dom injection" pattern where you jump outside from the web part boundaries to figure out how the web part should be rendered. This does make sense from the end-to-end requirement perspective, but it breaks the rules of web part development.

Our first party web parts are solving the re-render challenge with this.width and OnResize events, but that's not also that straightforward, so we are looking into adding better support for this in future based on your input. Before that's available, we'll work on sharing a mockup to demonstrate how this is solved with 1st party web parts - which then can be taken into account in your solution.

We really appreciate the input, but since we cannot resolve this as such since it's not a bug, will close this one for now. We will have more insights on the upcoming capability whenever it is available.

[msft-github-bot]

Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues