SharePoint 2013 Display and Rendering Issues

Having trouble with some of your pages in SharePoint 2013 rendering incorrectly at times, for no apparent reason? If so, you’ve come to the right place, provided that what I’m about to describe is actually your issue, and it’s not related to your html or css.

<div id="cbqwpctl00_" class="cbq-layout-main" />

Seems harmless right? It’s a content query webpart in SharePoint 2013 that doesn’t have any results, so this is the html it outputs. The issue, however, is that a div tag is not a self-closing tag, and browsers essentially look at it like:

<div>

That ends up changing the structure of your document, and will ultimately cause you rendering issues. How did it render in SharePoint 2010? The same exact way – with that self-closing div tag. Wondering why you haven’t seen this issue until now? In SharePoint 2010, tables were a primary part of the html that SharePoint output, and a table essentially protects this little accident from spilling onto the rest of your page. Thus, we never saw it in 2010 because when the webpart rendered it was inside of a table, and that protected the rest of the page. The browser essentially does understand the beginning and ending of the table, and so it is able to correct the initial behavior, and maintain your page’s overall structure.

In SharePoint 2013, however, tables in the standard SharePoint output are gone, and so the above snippet is going to likely wreak havoc on your page. You can fix it in SharePoint 2013 by wrapping a table around your content placeholder or webpart zone, so that what goes inside, ultimately gets contained, but that’s not a solution that I would recommend, since you’re then structuring your document around the technology instead of the content. You might also consider trying to introduce tables through JavaScript, via something like:

$('.ms-webpart-zone').wrap('<table>')

However, this still won’t resolve the issue, because at this point the DOM has already been loaded, and the browser has misinterpreted it.

A clean solution would be ensuring your xsl templates don’t render self-closing tags for html elements like div and span. A simple way to do this is showing text when there are no results. In fact, when you’re in edit mode, you’ll notice your page likely renders fine, and that’s because the default XSL does output a message when no results are found, but it only shows this message while in edit mode. It’s an easy fix to modify this portion of the XSL and take out the condition in the xsl:if statement that only applies the empty text during edit mode (xsl:if test=’$EditMode = True’ ). You could also switch this to an xsl:when / xsl:otherwise structure if you wanted to show different empty text to the editor versus viewer (Imagine utilizing style=’display:none’ on the viewer’s output so that they never actually see text, but the structure still remains correct)

Hopefully if you’ve come across this post and it solves your issue, you’ve arrived here sooner than later. I hope this helped out, and please feel free to leave any additional questions or observations in the comments.

Cheers,
Matt

Add a Comment

Your email address will not be published. Required fields are marked *