In the first part of this series I showed why Office UI Fabric might not be suitable for every of your projects. Now I like to dig a little bit deeper into the architecture and ideas behind Office UI Fabric. In addition I will give you my personal guidance on using it.
First, let’s take a closer look at the naming convention implemented with Office UI Fabric.
Every framework should have a solid naming convention that can be applied to custom code too in case you need to extend the framework. So does Office UI Fabric has.
I started to develop CSS almost twenty years ago. To be honest, I was surprised when I saw the class names of Office UI Fabric the first time. The main thing that caught my eye was the use of camel case names for classes.
I talked to the project team of Office UI Fabric and learned that this naming convention use something called Suit CSS.
It was first published in 2011 and when I did some research to find blog posts or reference implementations I was a bit out of luck. I might be wrong but hardly found any evidence that is used much.
Most web developer and designer are more familiar with other architectural and more prominent representative ideas with CSS such as ‘Block Element Modifier‘ (BEM), ‘Object Oriented CSS‘ (OOCSS), ‘Scalable Modular Architecture for CSS‘ (SMACCS) and the latest addition ‘Inverted Triangle CSS‘ (ITCSS).
Naming conventions compared to other frameworks
If you used frameworks such as Bootstrap or Foundations you find it hard to get started with this naming convention, but it’s something I recommend you to learn.
Frameworks are great to serve you some basic elements and components, but sooner or later they need to be extended with custom code. If a different naming convention will be used, then the one used by the CSS framework, your code will become messy.
A core requirement of Suit CSS naming convention is to write camel case class names. This camel case class name convention is not commonly used and have cause some negative impact.
In fact, Bootstrap and Foundations, as representatives for popular frameworks, use only lower case class names. They do this for an important reason.
With Suite CSS you always need to make sure that the class names are properly written.
Why case matters?
As mentioned earlier Suit CSS was first introduced in 2011 and at this time it was irrelevant how you write your class name. You was able to write your class names all in upper, lower case or camel case or any other favor. Even to write it differently in HTML was no problem. Browser recognized it correctly. With the introduction of CSS3, this has changed because class names are case sensitive.
HTML 4, as well as HTML 5, are case insensitive by definition. This means you can define elements, attributes and class names as you like. The problem is related to the CSS specifiction. The CSS 2 specification describes:
All CSS syntax is case-insensitive within the ASCII range (i.e., [a-z] and [A-Z] are equivalent), except for parts that are not under the control of CSS.
This basically means that you can define selector and id names as you like. The browser will render it properly independent on how you have written your class names in HTML and CSS.
When CSS3 was introduced in modern browsers the game fundamentally changed. While HTML is still case insensitive CSS cares about proper written class names.
In attributing selectors for HTML documents, attribute names and some attribute values are case insensitive, while other attribute values—most notably the attributes id and class—are case sensitive. As these attributes are case sensitive in HTML, ID selectors and class selectors must always match the case of the id and class attribute values in the document. To find out which attribute values are case sensitive and which aren’t, consult the HTML specification.
In fact, when Suit CSS was released in 2011 the proper writing of a class name was irrelevant in browsers. Now times have changed and newer frameworks use only lower case characters to make it easier to write css classes. It might make it a bit harder to read the class names but it is not so error prone as camel case notation.
The following example shows why case matters.
So when you use Office UI Fabric, always use the correct camel case notation. Otherwise some style won’t be applied.
Challenges with framework
For developers frameworks are an appealing approach to care less on CSS and get user interfaces done right easily and faster.
In case of Office UI Fabric. I see a huge benefit because it serves patterns to make a consistent user experience throughout Office Applications.
Attached to frameworks in general and especially with Office UI Fabric there are some challenges. Here are some things I like to make you aware of for better use in your projects.
Office UI Framework with other frameworks
I won’t recommend to use Office UI Fabric together with other frameworks. Again, the problem comes from the different naming conventions. Mixing Office UI Fabric with other frameworks will end up in messy code.
Keep it straight. Use Office UI Fabric, Bootstrap or Foundations but don’t combine them to avoid problems.
Every CSS framework bloats. This means that the code is might bigger than it used to be. In addition there are many components but only a few used by a specific application.
The recommended approach to trim down the file size of frameworks is to include only the used components. During development it is ok to use the complete framework, but when an application will be brought to production the code of the framework should be limited to onyl the used components.
I think a good comparison is when you look at the .net framework and C# development. No C# developer will include every assembly available in the .net Framework, just because there is a potential use in future.
This will be definitely a good option to have in future release on the Office UI Fabric website. Currently the only way to trim down Office UI Fabric is to create a custom configuration based on the code available on GitHub.
The minified version of Office UI Fabric uses currently 200 kilobytes just for CSS. A size from my perspective a bit too big but it currently contains everything.
What if a new version of the framework will be released? How can you upgrade? How do you handle fundamentally changes? These are valid concerns for every framework. The code is not in your control. It is in the control of the creator of the framework.
Another example was that the table components was changed. Instead of div and span elements, it uses a real HTML table now, that makes some style definitions obvious and can be removed from Office UI Fabric. If in an application an older version is used, it is likely that any table element doesn’t render properly anymore.
Apart from the actual application it is recommended to create a style guide that shows the main screens of your application individually. This makes it easier to test in case you need to upgrade to a newer version.
In addition check the release history of Office UI Fabric. This will give you a lot of information what have been changed between the current versions the add-in uses and current releases of Office UI Fabric.
Office UI Fabric with SharePoint
Many people tend to try any fancy new frameworks and apply it to SharePoint. If you like to add Bootstrap to a SharePoint on Office 365 the master page needs to be highly customised because additional style sheet classes needs to be added. A thing that can be avoided just by using CSS only.
I hope this gave a lot information for proper and successful use of Office UI Fabric. Make yourself familiar with Suit CSS naming convention to add custom code properly.
Create your custom tailored version of Office UI Fabric with only the components need and integrate those in your add-ins. This makes it even easier to upgrade to newer versions and serves a better performance.
In the next post I will show what can be done to use Office UI Fabric more efficiently.
In case you missed first part of this series:
- Why not use Office UI Fabric? – Part 1