Sitecore Front-End Development Best Practices

This article is intended to be a general guide on front-end development best practices for Sitecore solutions. There are a number of practices I’ve learned over the years that apply either because if the use of ASP.NET, or specifically because of how Sitecore operates. The best way to marry good front-end development with a Sitecore solution is for the front-end developer and Sitecore developer to communicate on the requirements. By knowing how pages will be built using modular Sitecore presentation components, a front-end developer can tailor HTML structure to meet the needs of content editors.

Use a `first` CSS Class Instead of a `last` CSS Class on Repeating Elements

When developing repeatable items, such as lists (e.g. ordered or unordered lists) or repetitive blocks (e.g. a consistently repeated set of divs), use a “first” class instead of a “last” class. This is because repetitive items can be developed in a Repeater (<asp:Repeater ...>) and its easier to see if you’re on the first item of a collection than the last item.

For example, say your repeater is bound to an IEnumerable<Item>. Applying the first class in the ItemDataBound method would be as simple as:

if(e.Item.ItemIndex == 0)
    // code to add "first" class

This could then yield:

<ul class="main-nav">
	<li class="first">Home</li>
	<li>Services</li>
	<li>Products</li>
	<li>Contact</li>
</ul>

Doing the opposite with a “last” class would be more expensive because you’d need to determine the count of the collection which can be expensive and compare the current item to that:

if(e.Item.ItemIndex == dataSourceCollection.Count())
    // code to add "last" class

That code could yield something like:

<ul class="main-nav">
	<li>Home</li>
	<li>Services</li>
	<li>Products</li>
	<li class="last">Contact</li>
</ul>

Use Classes Instead of IDs for CSS

Since ASP.NET controls use IDs, the rendered ID of an HTML element may get mangled by .NET’s Web Forms. For example, a Panel like this:

<asp:Panel ID="pnlLogin" runat="server">
  Login form here
</asp:Panel>

May get rendered to the front-end as something like this:

<div id="ctl00_pnlLogin">Login form here</div>

Instead of writing CSS to rely on the ID, which could change, its better to use CSS classes, even for elements that only occur once. This will guarantee the CSS will always apply.

Keep jQuery in an Isolated Scope

Some of the older versions of Sitecore ship with the Prototype JavaScript library in the global scope of the DOM using the $ variable. If you use jQuery, you likely conflict with Sitecore’s use of Prototype when in Page Edit mode. To always ensure you’re not writing jQuery that can break Sitecore’s page edit ribbon, either wrap your code in a self-executing anonymous function like so:

(function($){ //
  $(function(){
    // the DOM is ready, do jQuery stuff
  });
})(jQuery);

Or at the very minimum, make your outer functions use the verbose jQuery function:

jQuery(function($){
  // the DOM is ready, we can use $ in here now
})

Develop HTML and CSS so Modular Components Can Be Moved Around on Pages

It’s important for front-end engineers to understand the modularity of Sitecore. Each individual component or block on the page should be self contained, meaning the CSS and JS should only scope to the structure of that component. This will allow CMS users to easily move components around without them breaking based on their location on the page.

For example, if you’re defining a basic CTA module that is re-usable, this CSS would be bad:

.two-column-layout .sidebar .cta-module .title
{
  /* CSS here */
}

The CSS is too specific and assumes the module is within a certain part of a layout. Instead, de-couple the component from the overall layout of where in the page it will be; make it more self-contained and stand-alone:

.cta-module .title
{
  /* CSS here */
}

There are front-end development frameworks available that can help with this scaffolding too, such as Twitter’s Bootstrap.

Avoid Additional HTML in <p> Tags

Sitecore’s Rich Text Field renders paragraphs automatically in <p> tags. Try to not develop HTML that expects a specific structure within a <p> tag. For example, this is probably going to be hard for content editors unless you define Rich Text Editor snippets:


Lorem <span class="someClass">ipsum</span> dolor sit amet

On the other hand, the following example is fine because these are generic tags that the rich text editor will expose anyway:


Lorem ipsum <strong>doler</strong> sit <em>amet</em>.

The first approach is possible, however it requires additional configuration work on a developer to expose the extra class in the rich text editor.

Avoid Front-Loading HTML for AJAX Functionality if Possible

Sometimes when AJAX-like functionality is desired, there may be an inclination to front-load all of the content on the page, then hide content until it is needed. This can work in some cases, but its important to understand how the content may scale. You may have a small amount of content at first, so it will render fine, but as editors build up more content, this could really slow down the page loads on the front-end and cause flickers. Instead, its important for front-end and Sitecore developers to communicate an approach. For example, Sitecore can easily deliver content to JavaScript in various forms:

  • A Web Service (custom ASMX)
  • An AJAX-like presentation device, e.g. ajax=1
  • A Web Form (custom ASPX; non-layout)
  • An HTTP handler (custom ASHX)

The important part is to consider how content in Sitecore will scale and be delivered to the front-end, hopefully in batches.

Your Best Practices?

Do you have any front-end development best practices that I didn’t list? Of course you do! For any Sitecore developers out there, what other things have you noticed that make development much easier for you on the front-end? Leave your ideas in the comments below.

Posted in Sitecore
7 comments on “Sitecore Front-End Development Best Practices
  1. Sean Kearney says:

    Good list Mark. I covered some of this, and more, a couple of years ago http://seankearney.com/post/Sitecore-friendly-html-css-and-javascript.aspx but it was long overdue to be updated.

  2. Mark Ursino says:

    Ahhhh! I didn’t even see that on your site Sean. Great list!

  3. Vivek says:

    Great Article.

  4. Pieter says:

    Hi Mark,

    We’re considering implementing Sitecore for one of our projects and I wondered whether front-end integration is pretty straightforward in Sitecore or not. Does Sitecore inject a lot of own HTML around the components, like Drupal does for instance, or is it more like Umbraco, where you have full control over your HTML template?

    Cheers,
    Pieter

    • Mark Ursino says:

      Pieter – Sitecore does not add any extra HTML so you have full freedom. In the Page Editor (live WYSIWYG) mode is does add some JSON on the DOM to render custom controls for editing but it won’t add any extra regular HTML tags that you may write CSS against.

  5. Ty Cahill says:

    Using ‘first’ class instead of of ‘last’…

    When users are editing HTML, another advantage to using a ‘first’ class instead of ‘last’ class is that adding elements to the end of the list won’t result with the ‘last’ class no longer being last. Same thing can happen with the ‘first’ element, but it seems to happen more frequently with last.

  6. Umesh says:

    Hi Mark,
    All the dev docs from Sitecore sdn makes use of XSLT specailly because most of them date back to versions 6. Is there a way around it? Can I configure without using it? Any example you can give would be great help.

    Regards,
    Umesh

1 Pings/Trackbacks for "Sitecore Front-End Development Best Practices"
  1. […] Sitecore Front-End Development Best Practices¬†[Mark Ursino] […]

Leave a Reply

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

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>