Skip to main content Skip to navigation

Styling around the WSU Spine with custom CSS

The WSU Spine was built to provide a consistent brand framework for use throughout the University. It exists in sort of a balancing act trying to allow great flexibility while maintaining a familiar look and feel for visitors to WSU web properties.

The Spine is structured as such:

Screen Shot 2015-06-05 at 5.46.58 PM

The primary site navigation and brand elements are inserted as part of the #spine container. All content appears in the main element.

It is important to keep this page structure in mind when styling a page through CSS. The Spine provides default styles for many different elements to establish the initial consistent look and feel. It also relies on some of these styles to properly display a consistent experience in the Spine area itself.

Screen Shot 2015-06-05 at 6.00.36 PM

If you look at anchor (a) elements specifically, you’ll see a few default styles in the Spine. The above two are pulled directly from spine.css. All anchors are set by default to have no text decoration and to be crimson. Anchors inside the #spine container are set to be gray, but they retain the other default property applied to all anchors on the page of text-decoration: none.

A common custom style here is to add underlines or other properties with the intent of changing the anchor elements in the page content. When dealing with general elements such as anchor, some specificity is required to make sure only the intended styles are modified.

Screen Shot 2015-06-05 at 5.58.06 PM

Prefixing the rule with main applies the intended style and leaves the #spine container as is. Not prefixing the container causes the Spine to lose its default display properties with unintended consequences.

If you’re targeting a specific page, let’s say this current post, you can still use main in addition to other body classes.

Screen Shot 2015-06-05 at 6.07.53 PM

Anchors in the Spine will remain without underline, those in the main content area will have an underline, and those in the main content area of single pages will have a dashed underline and a lighter font.

Being aware of the Spine structure and targeting elements with the appropriate specificity will go a long way in maintaining the consistent look and feel that visitors expect. We’ll also continue working to provide more explicit defaults for crucial parts of the Spine to help prevent accidental overrides.

If you’d like to dive any deeper on this or have thoughts to share, we meet weekly on Friday mornings for open lab where this discussion would be perfect. 🙂

May 9th Open Lab Recap

first-open-lab

Today we held the first open lab in what we hope will be a long series of sessions. A handful braved the first session and we had quite a few great discussions.

I will admit that this is coming a week late and the topics are not fresh in my head. We’ll do a better job of recapping in detail in the future. 🙂

Topics discussed and bugs found

Spine Theme: Explain “bookmark” behavior for posts and pages and categories. The bookmark of the spine is the top right area by default. Quite a lot of thought has gone into what headers should appear there for each view. We talked through a few of the scenarios and how to change the default behavior in CSS. More changes around this will come in the future.

WSUWP Platform: Taxonomies need to be added to pages and media in order to categorize things properly. This includes site level categories and the University wide taxonomy that will be enabled on all sites. See issues #126 and #127 on GitHub to track progress here.

WSUWP Platform: A feature request to protect posts so that they can be visible to only those with a WSU Network ID. This is now technically possible, as a post can be marked private and require authentication. It would be interesting to see how we can make this process easier in the future. This will go hand in hand with page level roles and permissions. Track issue #29 on GitHub.

Spine Theme: It is possible that the site tagline is wrapping unexpectedly on mobile displays. This is something that we’ll need to explore. I’ve opened issue #72 on GitHub for this.

WSUWP Platform: Previewing custom CSS changes results in a broken URL. This was resolved on issue #3 and pushed to production.

WSUWP Platform: We discussed the idea of having CSS instructions for hiding next/previous post links. This later turned into an idea to provide various blocks of commented out CSS in the CSS editor so that common customizations could be made or areas altered with a few line changes.

WSUWP Platform: We briefly discussed the upcoming page builder feature.