During a meeting with a customer yesterday, they spotted something amusing that I hadn’t noticed until they pointed it out. Have a look at the following screenshot from Office 365 and see if you can spot the issue as well:

difficons1

 

And, did you discover it? The Edit Item button isn’t using it’s regular icon, but uses the same as the Delete Item button! Here’s how it should look like usually:
difficons2

Now, the issue isn’t caused by Office 365 directly. In this case, we have some  JavaScript that does some smaller DOM manipulations, and replaces the Edit Item button with a different one (but which looks just the same). The code that gets inserted into the DOM contains the image as follows: <img style=”left: -511px; top: -103px;” src=”/_layouts/15/1033/images/formatmap32x32.png?rev=23″ unselectable=”on”>

This works perfectly fine in older versions of SharePoint as well as SharePoint 2013, but in Office 365 you get the Delete icon for the position left: -511px; top: -103px. The correct position in Office 365 is left: -511px; top: -137px. What SharePoint actually does is not to use a separate image file for each icon, put rather “store” all icons in a single image to save on bandwidth and increase performance (to learn more about this, visit your preferred search engine and look for “CSS sprites”). And exactly this image (formatmap32x32.png) is different in SharePoint 2013 (the same for RTM all the way to SP1) and Office 365. How different? Have a look at the animation which shows both version for a second each:

output_geDlNX

 

So, what does all this mean?

Just recently, changes to the DOM of Office 365 pages that made it different from the one in SharePoint 2013 were made by Microsoft, see e.g. the blog posts “Office 365 Update Changes ‘Display Name’ on Required Fields” by Marc D Anderson and “Office 365 Needs to Treat the UX as an API if Our Customizations are to Stay Off the Server” by Andrew Connell (ok, I just have to make a Star Wars reference here: “I am altering the DOM, pray I don’t alter it any further”). In my opinion, this change here falls into a similar category, with Microsoft making a small change in the background that can have a negative effect on customizations that rely on the icons. For example, if you want to use the same icons as default SharePoint, and thus make use of the same code, you now need to be careful that things like the issue I mentioned at the top of this blog post don’t occur in your solutions. So don’t just simply rely on the fact that it may have worked before, but make sure that if you’re using SharePoint icons, the correct one is indeed used.

And as final words,

18 thoughts on “SharePoint 2013 and Office 365 diverge even further – different icon sets”

    1. I already checked SP1, it’s not in there. I’m not quite sure what the other icons are used for and why the two PNGs differ, so there may be a chance that a future update will replace the current on-premises version with the current Office 365 version. However, there were also some recent changes in Office 365 that were very specific (CSS classes with a o365 prefix, if I remember correctly), which obviously won’t be included in on-premises updates. Maybe the icons are a similar case

      1. It seems like it’s a mistake frankly, if you look at the two icon sets, the spot where the edit icon was is the delete icon. It doesn’t look like they would have changed any of the core code on this but rather just changed the icon set image… seems like they made a mistake when they pushed out the update to the image.

  1. What content type and list type was this on? Is this Office 365 Enterprise? I just checked several list types with various content types on my company’s Office 365 (E3) SharePoint sites and I get the correct icon for all of them. I refreshed to make sure I wasn’t using any older cached JS files. Whatever the cause, seeing a delete icon for edit is very disturbing!

Leave a Reply

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