Posted on:
Categories: SharePoint;Office 365
Description:

Setup

​To gain understanding of the observation and to see first-hand, here are the things I’ve done to reproduce the weird project site timeline summary issue.

  • Create a new site collection with Publishing template.
  • Create a Project site subsite.
  • Edit the page and remove all the generated web parts except for the Project Summary web part on the home page.
  • Set these tasks (note they are all expired)

 

  • Use these rules (I set it as alternate CSS for quick reference)
    #s4-workspace {
        width: auto !important;
    }
    #contentBox {
        min-width: 0;
    }
    #DeltaPlaceHolderSearchArea {
        display: none;
    }

That is all in terms of setup.


To elaborate on the CSS rules, there are defaults for each of those elements. s4-workspace has a default width that SharePoint sets via Javascript; for me, it was 1061px. Contentbox’s min-width is set by core15.css, which is 703px. These two elements need to be overwritten so that the inner contents can be exposed to the changing window size. Similarly, the search box is removed simplicity because after a certain width, the search box prevents the page from shrinking.

Behaviour

When you land on your project page, Project Summary’s default behaviour will display the timeline view, then the late/upcoming view for a second, and then switch back to the timeline view automatically. Of course, users can use the pagination arrows to manually navigate through the views as well.


We want a responsive project site; using the CSS above makes the project summary an overly simplified responsive site for this blog’s purposes. Meaning, the Project Summary web part will shrink according to window width. With a little more work, the timeline view can be fully responsive, but the problem lies with the late view.


If you resize the window, at some point, the late view items disappear, where everything else stays the same. It’s easy to point fingers at the branding or customizations, but in fact, the disappearing act is something that SharePoint Online does natively and this can cause a problem for the end user given the behavior.

 

Inspecting the page, and on the late area, the focus is brought to:

 

As you resize the page, an additional "display: none" is added on dynamically via javscript.


Searching the source code for the full ID will return nothing. Luckily, if we search for _LatePanel, we have a single result from a SharePoint  Online .js file

 

Using the Pretty Print function that comes with Chrome, we have resulting code that looks like this

function i() {
      var e = $get(a._controlId + "_LatePanel"), d = $get(a._controlId + "_UpcomingPanel"), g;
//... some code here …
      if (d)
            if (b > 0) {
                  d.style.display = "";
            ​      d.style.width = k * b + "px";
                  m("UpcomingPanel", b)
            } else
                   d.style.display = "none";
      if (e)
            if (c > 0) {
                  e.style.display = "";
                  e.style.width = k * c + "px";
                  m("LatePanel", c)
            } else
                  e.style.display = "none";
//... some code here …
      return (b + c) * k
}


And by connecting the dots, you see that here, SharePoint is using a if-else statement to dynamically set the display (back from none if it was attached earlier), and width, otherwise, hide the panel.


As for why SharePoint decides to do that and what purpose that served, we have no idea. Perhaps it was a left-over artifact from SharePoints prior, but keep in mind, we had to remove 3 “levels of fail-safes” in the form of set width, min-width, and unshrinkable search bar, to figure find out this oddity.