Sp-dev-docs: Changes to the DOM which affects SharePoint solutions

[estruyf]

Category

• [ ] Question
• [ ] Typo
• [ ] Additional article idea
• [x] Styling issue

Question

We noticed that all DOM elements got new unique classes that probably get renewed each day/build.

All the useful classes from the following list got removed:

.CanvasZone--noMargin
.ControlZone
.ControlZone-control
.CanvasSection-col
.CanvasSection--read
.CanvasSection-xl8


.CanvasSection--fullWidth
.ControlZoneEmphasisBackground
.CanvasControlToolbar

.CanvasSection
.CanvasZone

Some of these classes were very useful when styling web parts or creating combined experiences. I'm not talking about DOM manipulation, but more to get to know if the web part is alone in its section or with multiple web parts and such.

Probably this creates a huge impact on solution implementations like intranets. If you develop a single web part, this might now be a major issue.

Environment details (development & target environment)

Various environments are affected by it as it is currently rolling out.

[msftbot[bot]]

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

[scubasteveb]

The current placeholders for header/footer sometimes aren't what we need when trying to customize or style a site based on the UI design desired. In cases like this, we have written SPFx extensions to query the DOM for elements by class name and inject our necessary HTML and styles. We understand this really isn't the supported method, but with lack of new placeholder areas, this is our only solution at the time.

We have encountered this case of class names and DOM changing quite frequently and actually have the code retrieve the class name to look for, from a SP list so we can fix it without a code change.

[andrewconnell]

Aside from the reason for using these classes, it's worth noting that Microsoft has been very clear that the DOM is not an API and shouldn't relied on as such.

See the Important note in this section of the docs:
https://docs.microsoft.com/en-us/sharepoint/dev/spfx/enterprise-guidance#in-perspective-sharepoint-framework-in-the-broader-sharepoint-platform

Not here to debate this, just stating in case someone else sees this issue...

[kezack]

Do we have a simple way to know which section the component is positioned in ?

[DonKirkham]

I agree with @andrewconnell about Microsoft has been clear about the DOM is not an API, but is there some mechanism to notify developers that this type of change is coming? Maybe a Roadmap item?

[andrewconnell]

@DonKirkham said:

is there some mechanism to notify developers that this type of change is coming? Maybe a Roadmap item?

ATM, no... they've never shared page source/schema changes.

[PathToSharePoint]

@kezack the SharePoint API allows you to interact with pages and Web Parts. You can for example consume it through PnPjs:
https://pnp.github.io/pnpjs/sp/clientside-pages/

One challenge I've had with this is that the API only sees what has already be saved to the page. Any ongoing edit action - for example a Web Part you just added - is not captured.

[DonKirkham]

I was asked by @VesaJuvonen to post a use case for targeting the global DOM so that engineering could look for possible solutions that would not require DOM targeting. In my case, a client really didn't like the amount of white-space between web parts. Despite my objection and warnings, I built a web part that lets the user control vertical and horizontal spacing between all web parts on the page using ControlZone and CanvasSection-col

[kmprasad4u]

• Vertical Spacing
• Responsive handling of custom web parts based on current section / column size
• Bringing uniformity among OOTB & custom components. Multiple OOTB web parts defines their own way of adding Web Part Title, making it difficult to create consistency among different web parts added in pages.

Problem is client generally don't understand the limitations of Modern UI and are more interested in appearance of sites as we have had all those flexibilities in Classic. As an example a simple requirement for showing a "large" footer is not easily achievable with supported bottom placeholders as the placeholder is fixed in the page reducing the available content area. These are areas where there is a disconnect between expectations and realities. MS needs to get feedback from Businesses to see what they expect out of the portals and need to align with their expectations and come up with solutions so that it becomes easier to convince clients to use Modern UI.

[scubasteveb]

^^^ Per the comment above, we have the same situation with the large footer. The placeholders available do not meet requirements, which is why we target the DOM using data- or ID tags to inject them where we want.

Same for header. We would like more placeholders for handling stuff like custom navigation, search or breadcrumbs.
We are currently using classic pages still to accommodate UI flexibility with User Custom Action scripts and SPFx webparts.

Since the DOM has been changing so much recently, we actually store the css selector in a list and query that in the code to quickly fix it if the DOM changes.

I understand that isn't recommended, but please provide us with more placeholders then in modern pages.

[VesaJuvonen]

@scubasteveb - You mention that the placeholders do not meet the requirements - but what are your requirements? - Can you elaborate that a bit, so that we could potentially provide them in supported manner.

We cannot guarantee not to change the DOM structure again in future, so trying to help by collecting those requirements which forced customers and partners to have a DOM dependency... and to enable them with alternative ways. Thx.

[kmprasad4u]

• Controlling the order of place holders (or Application customizers).. so that we can make the appearance of certain elements in the same order
  https://github.com/pnp/sp-dev-fx-extensions/issues/282
• Allowing to fully hide OOTB header, so that we can place our own headers
• Modern UI OOTB footers are placed with the content and scrolls with the content. May be a placeholder there so that we can have footers along with content... and make it scroll.
• Allowing a Sidebar placeholder
• Placeholder inside the panel that is opened on clicking the hamburger icon for navigation. So that we can add our extra navigation or elements and don't have to have to provide two different functionalities.

• Vertical Section in Left

• Changing Font Family

• Support for multi color theme & provide more clarity on how the themes should be controlled at granular level.
  https://laurakokkarinen.com/how-to-create-a-multicolored-theme-for-a-modern-sharepoint-online-site/

• In multiple places the choices of colors that we can use is very much poor. Like section background or text web part

• Allowing custom command actions in Site Pages (MUI commands before it was released by SharePoint was an use case. There should be some other use cases as well)

• Page Layout without Header (similar to Home Layout). There is really no reason to have an restriction like this.

• 4 column sections & if possible sections within section

• Standard way of customizing web part container/header elements, and expose a web part header component that is leveraged by all OOTB web parts as well as Custom Web Parts

• Embedding one web part from another

• Custom web parts should be allowed to connect to some OOTB web parts like embed web part, doc Lib web part, list web part. Say I want to have my own list of files and wanted to leverage Embed Web part. Or show a like list of files / items based on selection from my custom web part

• Allowing new item / edit item properties in List with SPFx

I started of by writing the requirement for footer placeholder, and I kind of went off-topic :D. I am sure I would have more, just remembering these at the moment.

[AJIXuMuK]

Adding additional command bar (kinda contextual command bar) under standard list command bar.
Example - Command Set Customizer. When the command is executed we want to display additional command bar with a set of different commands available.

[AJIXuMuK]

Another sample - apply styling to list column header. Currently none of the extensions allow that.

[scubasteveb]

@VesaJuvonen @kmprasad4u did a good job of providing some feature requests. Our biggest issue and requirement was for a larger footer placeholder that is not fixed placement and designed for a larger height. We would like it to appear only when you scroll to the bottom of the content, not sticky.

It appears this placeholder exists if you create a footer from the SPO UI using the "change the look" menu, but it isn't available in SPFx.

I like his suggestions here also:
"
Allowing to fully hide OOTB header, so that we can place our own headers

Modern UI OOTB footers are placed with the content and scrolls with the content. May be a placeholder there so that we can have footers along with content... and make it scroll.

Allowing a Sidebar placeholder
"

[willspiering]

Here are two use cases I ran into recently for being able to target the web parts parent container that we have had to use for certain client requests.

• We have multiple web parts that work together for a solution but we don't want certain ones to be visible and take up space while the page is in read mode. There is still some vertical spacing when we don't render the webpart.

• Another use case would be when you don't have any results to return to hide the webpart, but there is still whitespace where that webpart "should" be which throws off alignment of other web parts on the page.

[MartinLaplante]

Some things where we currently use some DOM hacks, in SPFx or Selenium. A supported targeting, or at least knowing that the "data-automation-id" and "id" elements are unlikely to change without notice, would be appreciated:

1. Webpart containers. Sometimes we change them, sometimes we check to see whether they have loaded.

2. Property panes. Again, sometimes we sneak a peek or improve them.

3. Me control (with your photo). Ideally we would like to target the container and the individual commands within it.