What you should know about SXA Markup and Styles as a Front End and Back End Developer

I've seen front end development be a stress point in SXA projects and most of it is due to not understanding how SXA works and not optimizing your flows and processes to handle it. This post serves as a primer for the basics and things I would expect both front and backend developers to understand if working on SXA components and variants.

Understanding SXA Markup and styling options

Every SXA component wraps their content with two divs:

 <div class="component-name %list of selected styles%">
    <div class="component-content">
      %Component Markup Here%
    </div>
</div>

Accounting for this markup is critical for developing front end styles for a SXA site. The other area to be aware of is how SXA injects markup for placeholders.  When using placeholders SXA will inject a "<div class="row">" inside itself, which will contain the markup for the components placed inside. So if you're leveraging splitters (which you should avoid), or are highly dependent on placeholders in your layout, you'll need to account for the additional markup injected.

Note that this behavior can be configured to emit alternative markup, and there are even extensibility points that allow you to patch configuration to allow certain placeholders to not emit the additional markup. (My slick carousel slide provides an example on how to exclude placeholders as I didn’t want that additional row when inserting slides into the carousel div.)

Understanding SXA styling and grid settings

When a component is added to the page, content authors can configure grid settings and select optional styles by going to component properties. The grid settings will inject the proper css class into the component class to handle responsive grid settings, offsets and more. The classes will be injected based on the selected grid system.

Styling options are based on the style configuration for the site, which allows you to define checkboxes that can be applied to all or specific components and when selected inject those associated classes into the outermost div of the component.

This is important to understand, as you may be used to applying specific style classes to child element of the component. So for example if you have a "fancy" title class that you normally apply directly to the div that displays the title, instead you need to apply the "fancy" title class to the outermost component div, and adjust your css to target the title child of that component to apply to it.

Understanding Variants and Views

In SXA you get your markup into components using one of two methods. When creating custom components, you can define your own cshtml views, making you responsible for handling the SXA plumbing and defining the two div's that SXA needs to work with the grid and custom styles.

If you're using an out of the box component that supports variants, you only need to focus on the markup within the second div, and define the markup using Variant field types. If you don't like having to define each html node as a Sitecore Item, you can leverage the out of the box nVelocity template support or even my Handlebar Variant type to improve productivity.

 Integration Flow approaches

There are generally two flows that can be used with SXA. The proposed flow in the marketing materials is to have Sitecore developers create components and variants and assemble pages (or kitchen sink pages) to export and hand off to the front end team to go style. I've found this problematic on a few projects because creative exchange is flaky, but mostly because I rather have the front end team defining the markup for a component. And when they can’t there will be the need for changes, which will require tighter coordination where the front end dev's need to communicate those changes to the back end team.

The alternate approach is to do the front end markup first. As long as the front end team understands how SXA wraps components and placeholders and accounts for how it manages optional styles, it should be straight forward. I have found this ineffective if your front end team is just creating html from scratch without thinking about how SXA works, but if they hand over markup that has accounted for the SXA structure, it should be straight forward for back end Sitecore developers to integrate with limited need for coordination outside of usual edge cases related to styling.

Understanding Themes and Optimization

Creative exchange provides options for abstracting how css and script files get in the media library, but in the end every sass, css and javaScript file needs to be stored there. The asset optimizer can be configured at global and site level and when enabled will generate a minified css or js file for every folder in the solution. While you can use creative exchange and gulp to get files updated easily, you can also just go to the media library and attach new files to update things if needed.

When you create a site, you should be creating a new Theme that you can apply to your site and extend without impacting the OOB themes. These themes are stored in the Media Library > Themes folder and organized by Tenant. You even get an "Editing Theme" which can be used for styles and scripts that only show up in Experience Editor.

The Themes themselves inherit base themes. Base Themes can be created to have the foundational scripts and styles that support a component or set of components, and can be automatically attached to a Site Theme on feature activation. Ideally, your site theme is only adjusting the foundational styles for that component so that it can be reused and reskinned for different sites.

This theme inheritance is very powerful and complimentary to how CSS works. You can have base themes for your foundation component scripts and styles, Tenant level Themes that aggregate foundational base themes and set some Tenant level styles, with Site specific Themes that customize the colors, fonts and images specific to the site. While this is possible, keep in mind creative exchange is geared toward updating Site themes only, so you'll need to manage base theme front end development with a separate flow, or spend time refactoring out later in your process.