JPGs not showing in browser window

I have to preface that I’m *not* a web designer (should I send you some snapshots of the web pages I have produced, you would definitely agree with me… that’s why I’m not adding pictures to this post :-)).

Therefore the topic of this post may seem obvious to the web designers amongst you.

Anyway, here’s what I have noticed some days ago, in the context of a SharePoint 2010 intranet project where some CQWPs display the most recent items (news, etc..), along with a thumbnail image beside the item body.

Well, the final effect was that some of the images were not displayed at all in the rollup page.

After double-checking the publishing status of each item, I could confirm that each picture item was checked-in and approved, so that it should be visible to all authenticated users.

But while navigating to the assets library that contains the pictures as a site owner, the exact same behavior was visible there: even the XSLT list view web part shows the items, with pictures dispayed as a red cross.

Then, Fiddler comes to the rescue. I fired it up, trying to figure out what was the real network traffic behind the picture download. I got an HTTP 200, and the response mime type was correctly set to image/jpeg.

Ok, then there’s some issue with the image itself. I saved the stream locally, then tried to open the image with any kind of picture viewer tools and… the image displays correctly, no matter of the tool I have used.

This is a confirmation that the image type is not well supported by the browser.

It’s a browser issue, so the next step is to navigate to the image url using different browsers and try to spot the difference… and the difference was now quite evident.

IE8 had issues with that specific image, while neither FF nor Chrome nor IE9 suffered any problem.

Then, I just had to google for “IE8 JPG” to find what I was looking for.

I knew that JPG is too vague, since you can get different encodings and internal representations, ending up with a JPG file extension as well.

But I didn’t know that IE8 dropped support for jpeg images saved as CMYK.

Here you can find some information about this issue, and even a web page where you can test how your browser behaves with CMYK JPEGs:

http://www.computerhope.com/issues/ch001283.htm

Browser are sometimes always strange 🙂

Ahhhh, the Ribbon!

Let me say first that I definitely like the Ribbon, especially from a user interaction perspective. You have to get used to it, but we have to admit that this kind of user experience was not introduced with SharePoint 2010!

We got Office 2007 some years ago. We are seeing Windows tools that have been rebranded this way (Paint? Wordpad?). Components vendors are providing a ribbon framework since 3 or 4 years, which means that a crew of developers are releasing Windows Applications with a ribbon on top (even when it is not suggested by official or common-sense guidelines).

That said – and here my complaints start – the ribbon is quite an obtrusive component. And this is especially true when it is used in web applications, where you have a much more fragile control over the final layout your users will be experiencing. I’m a fan of the ribbon, but I still have to struggle a little bit to convince myself that it’s good as well for html rendering.

Let me expand these considerations with a couple of more practical examples.

Imagine you are realizing a public, internet-facing web site. And you do this with SharePoint, right? J

It will take you a couple of hours to realize that the ribbon should be made available to content editors, but you need it to be hidden to anonymous users (or more generally to site viewers).

A ton of articles and tutorials have been written, and it’s not so complicated as it may seem: you can use some trimming controls (SPSecurityTrimmedControl, LoginView, EditModePanel, AuthoringContainer, something you have developed yourself, etc) and just prevent it from rendering.

Will the ribbon be visible? No. Will it take part to the page markup? It depends.

The reason why it depends is strictly related to the way you are hiding the SPRibbon control.

Are you using some CSS attributes (display:none) applied to some container? Ok, go back immediately and try another approach: the markup fragment is there, and it is useless.

Are you using some server-side visibility logic (as suggested above)? Ok, the ribbon markup is not there any longer. Much better! Well done! But…

Have ever noticed that you are emitting tons of javascript code and did you ever wonder where that script code comes from?

Most of the times, ASP.NET controls generate JS code by with the help of some ClientScript.Register<Something> method. If you want to spend some time in front of a decompiler and start investigating how SharePoint controls behave, you’ll find out that many of them contain a bunch of code like the one I’m showing right below:

If (SPRibbon.GetCurrent(Page) != null)

{

// Write 10 KBs of ugly JS

}

Is this harmful? Hopefully not.

Does this execute if you have hidden the ribbon control? Probably yes.

Indeed, many conditional panels (SPSecurityTrimmedControl, for example) apply their conditional logic very late in the page rendering lifecycle (usually during the PreRender phase). And they are just preventing the ribbon to render, they are not eliminating it from the page control tree!

Which means that any control on the page that checks for the existence of the ribbon will succeed in

this check and perform whatever operation it is supposed to do.

Summing it up:

· The ribbon is hidden

· It does not occupy bytes inside the page body by itself

· It has “side effects”, causing other controls to emit extra markup or, more generally, to behave inconsistently

How can you fix this?

You could use some smarter conditional logics (a SmartPanel, if you like the name) that could just “ignore” its contents if the condition is not met. By “ignore” I mean that this panel should not add its child controls to the control tree at all.

While I would suggest you to carefully consider this approach, I would also like to point-out some drawbacks you may face.

If you remember, I had mentioned two side effects at the beginning of this article. So here’s the other one.

The SPRibbon control automatically sets the MaintainScrollPositionOnPostback property on the page to true. Which means that, after a postback, the user navigation is taken back to the same vertical scroll position he had set before.

Is this good or bad?

Well, it depends, of course.

But you have to take care of this behavior, since the sole presence of the Ribbon control may vary this after-postback setting: if you hide or show the ribbon based on the user rights, you end up having users with different rights having a different navigation experience. And… this does not depend, this is bad by definition J

Improving the CQWP Markup with SuppressWebPartChrome

Several SharePoint web parts, the ContentByQueryWebPart being one of those, expose a property named SuppressWebPartChrome.

When set to true, the web part code strips out the surrounding layout that constitutes the “chrome” of the web part itself.

An example will explain this much better.

Consider the following HTML markup, generated with the SuppressWebPartChrome property set to false (its default):

<table class=”s4-wpTopTable” border=”0″ cellpadding=”0″ cellspacing=”0″ width=”100%”>

     <tr>

          <td valign=”top”><div WebPartID=”00000000-0000-0000-0000-000000000000″ HasPers=”true” id=”WebPartWPQ3″ width=”100%” class=”ms-WPBody noindex” OnlyForMePart=”true” allowDelete=”false” style=”” ><div id=”cbqwpctl00_News_g_ded0dcdb_9aaf_44c3_98b5_6af1963c4f3b” class=”cbq-layout-main”><ul class=”dfwp-column dfwp-list”><li class=”dfwp-item”><div class=”item link-item”><a href=”http://erickson.sharepointjukebox.vmw/News/Pages/Test.aspx” title=””>Test</a></div></li></ul></div></div></td>

     </tr>

</table>

And compare it with the following markup, where the SuppressWebPartChrome property has been set to true:

<div id=”cbqwpctl00_News_g_ded0dcdb_9aaf_44c3_98b5_6af1963c4f3b” class=”cbq-layout-main”><ul class=”dfwp-column dfwp-list”><li class=”dfwp-item”><div class=”item link-item”><a href=”http://erickson.sharepointjukebox.vmw/News/Pages/Test.aspx” title=””>Test</a></div></li></ul></div

In the first snippet I have higlighted the HTML portion that gets stripped out.

This is a huge improvement, especialloy because:

  • The resulting markup is smaller, with a lower network bandwidth consumption as the first consequence
  • You get rid of a surrounding table, which makes your markup more compliant to accessibility requirements (and, more generally, it just makes your markup better from a semantic perspective)

Needless to say, I suggest you to “think in advance” and apply this very early during the development lifecycle, since you may need to adjust your CSS or JS libraries accordingly!

SharePoint 2010 AspMenu and UserSimpleRendering

This new Boolean property has been introduced in order let you opt for a more semantically correct HTML markup (no tables any more!). You get the option (which btw is set to false) because, of course, MicroSoft had to guarantee a backwards compatibility.

Just a small note: some of the properties of the menu (particularly, those which set the styles through ASP.NET styles) do not work on menus where UseSimpleRendering is set to false.