There is a minor style bug in SharePoint 2013 (including SharePoint Online). The error message on a required DateTime field is not displayed in a manner consistent with other control validation errors. No it’s not just you, and no it’s not due to some conflicting CSS – it is a SharePoint bug.
Specifically I am referring to the page layout edit experience. A user fails to provide a value for a required DateTimeField control and the validation message is shown in the default text colour – ‘You must specify a value for this required field.’
For all other validation messages the SharePoint controls add the ms-formvalidation which sets a CSS rule to set the red colour. This is the only rule which the ms-formvalidation class sets and as such this is the only rule that should be applied to fix the issue.
I use the following CSS selector to resolve this issue:
If you have a global navigation with more than a few second level items then the fly-out nature of the menu may cause some page content to be hidden while the menu is being interacted with by users. This is expected and acceptable behaviour.
I have found that sometimes (in IE only) the navigation fly-out falls behind page elements and cannot be used correctly. This is the case when iFrames are present in the content area. This issue came to my attention when using the Yammer Embed API to provide users with Yammer feeds from SharePoint.
The global navigation fly-out is being hidden by a Yammer Embedded feed (rendered as an iFrame)
The simplest way to resolve this is with CSS. The following CSS snippet should resolve this issue for you. We all know about z-index but the position:relative is also required for it to be applied correctly in IE.
N.B. The below snippet is specifically for Yammer Embed iFrames, if you would like to target all iFrames then the id selector should be removed (i.e. iframe#embed-feed becomes iframe).
When you import an image to use as a background image as part of a composed look in SharePoint Online, the image is re-scaled to 1024 x 768 and compressed as low quality jpg. If you have an image which still looks reasonable after these modifications then please continue to use composed looks as the ensures that the page weight is kept to a minimum.
A full HD imageThe same image as above after being processed by the Composed Look framework. Admittedly the compression is pretty good in this example.
SharePoint provides no configuration around this that I am aware of and even you provide a background image URL in the composed look to a non-compressed image, the image will be compressed and the compressed image will be referenced when the composed look is applied.
The only way to support a high resolution background image is to reference it in CSS, overriding the composed look background image. I have found that the best way to do this is with the following two CSS rules. The second prevents the background being used in dialogs which occasionally don’t use the transparent overlay and can become unusable otherwise.
If the image needs to be changed later, a new image with the same name can uploaded to replace the current one. The issue with this approach is that client browsers may have cached the background image and will continue to use the cached image until the cache expires (could be years, if hosted outside of SharePoint, or will be 24 hours if hosted in the Style Library) or the user manually clears their browser cache. In order to force the browser to re-fetch the image a query string value should be appended (or amended, in the current example we are using ‘v=1.0’).
Note that if you are using theme-able CSS you may need to reapply the theme in order to apply changes to the CSS.
