Sitecore provides companies all the capabilities  of a CMS solution mixed with analytics abilities integrated into content presentation interface. Personalized content is shown to visitors based upon their actions and location, and any goals that are triggered. In this article I will explain how frontend development goes hand in hand with the Sitecore platform. The markup structure that we use on the frontend must be tailored to suit the requirements of content editors, while also considering Sitecore’s abilities. 

Here is a list of useful practices for  creating markup for the Sitecore platform. 



1) Avoid using custom HTML and custom classes in rich text fields

Sitecore has rich text editor options that are used by content editors when inserting and editing the content. Usually, when developers want content from a Sitecore rich text field to be displayed, they use sitecore controls in this way:

<h2>@Html.Sitecore().Field("Title", Model.ArticleItem)</h2>
@Html.Sitecore().Field("Content", Model.ArticleItem)

The output of this will look like this:

<p>Line of text</p>
<p>Another line of text</p>

Best practice is to avoid adding more custom classes into HTML in paragraphs because this is hard to replicate by content editors.

An example of this would be:

<p>Just some <span class="bold">line of text</span>.</p>

As a Sitecore developer, it is possible to write Rich Text Editor HTML code for content editors, but it would require more of the developer’s development time, both for development and to educate content editors.

Best practice is to use standard HTML tags, because these are visible to the content editors:

An example of this would be:

<p>Just some <span><b>line of text</b></span>.</p>



2) Create HTML and CSS as modular components

Sitecore is designed to be very modular. Each individual component on the page should be self contained.  There are many methodologies in practice today for how to name blocks or logically organized structures. Without going into detail, best practice in my experience is to create a module - submode structure. In this case, I’ve also found it to be better to use generalizations, because overly specific module names are not useful and can easily fall out of context. 

Bad examples would be:
.sitecore-left-sidebar-module {}
.sitecore-left-sidebar-module .title {}
.sitecore-left-sidebar-module .subtitle {}
.sitecore-left-sidebar-module .content {}
Good examples would be: 
.sitecore-module {}
.sitecore-module .title {}
.sitecore-module .subtitle {}
.sitecore-module .content {}

In this way the CSS is not too specific and is easily translated to another part of a layout, such as a component’s styling. For example, a module named to indicate that it is used in the left sidebar won’t make any sense if the module is transferred into the footer, so this type of naming could be confusing.



3) Avoiding loading all HTML to simulate AJAX functionality

It's important to understand how the content can scale if we load all of the content on the page at once, and then hide it until needed.
At first, you can have a small amount of content loaded on the page and it will render fine. However, as editors create more content this could drastically slow down page loading on the front end and cause flashing and blinking. It's important for Sitecore and frontend developers to communicate the right content loading strategy. 

Here are a couple of approaches that can be used to deliver content to the front-end at the exact time it is needed: 

-A web service
-AJAX presentation device
-Web Form
-HTTP handler

You should always consider how the content in Sitecore will scale and be delivered to the frontend; the best option is to deliver it in clusters or batches.



4) Use classes instead of IDs in markup

Using IDs is not a good idea, as the rendered IDs of any HTML element may get mangled by .NET web forms for example:

<input name=”q” id=”q” type=”text” /> 
Gets transformed into:
<input name=”ctl00_Main_q” id=”ctl00_Main_q” type=”text” /> 

To guarantee that the CSS will always apply, it’s better to use CSS classes even for elements that only occur once.



5) Don’t use first and last definitions for elements in a list

Sometimes to additionally identify the first and last elements in a list, frontend developers use identifying classes for “first” and “last” element in the list. For example:

<ul class=”module-list”>
<li class=”module-first”></li>

This practice is not well suited  for use in Sitecore because it places much more demand  on the server than defining the elements differently in CSS by using the :first-child and :last-child identifiers.



6) Don’t hardcode things

This is nothing new when creating frontend code, but nevertheless it’s an important thing to mention. It is better not to hardcode things like message alerts (such as an indicator that an email format is not valid) in JavaScript. If you do it this way, and don’t  hardcode them, they can be retrieved from the page when required. You can add additional attributes to the markup to achieve a much better result. For example:

<input type=”email” data-warning=”Enter valid email”>



To sum it all up, Sitecore has its own specific rules but there are also general frontend rules that can be applied to any framework regardless of the technology. In our case when using Sitecore, frontend developers should be mindful of how to create markup that is both easily used by content editors and does not collide with any Sitecore rules.

We hope that you find this blog post series interesting and useful. If you have any questions feel free to contact us!