Theming Pinboard

I’ve been inspired by sites like CSS Zen Garden and Adactio: Jeremy Keith’s website to finally tackle a design problem that’ve been dealing with for a couple of months. What really pushed me to do it was a misleading tweet by Jake Archibald:

Pinboard implemented their own simpler layout model & used canvas for the drawing which is GPU-backed.

— Jake Archibald (@jaffathecake) February 23, 2015

Excited, I quickly jumped to my Pinboard tab and hammered the refresh button. Nothing changed. I dug into my account settings looking for a flag to switch on for this newfangled layout, but couldn’t find one. What’s going on?!

(hah, I mean Flipboard, not Pinboard)

— Jake Archibald (@jaffathecake) February 23, 2015

Okay then.

Suddenly annoyed by this fact, I decided I’d once-and-for-all tackle the less-than-ideal design of Pinboard, which I use mostly to archive and bookmark pages on the web I don’t want to lose. You can read more about what Pinboard is useful for here.

The First Step

To begin with, I wanted to find the pain points of Pinboard’s default design and address them in my theme. Most of the problems I have with the design have to do with white-space and poorly distinguished categorisation.

Let’s break down how bookmarks are categorised, at least as far as I use them on Pinboard:

• tags
• public/private
• starred/unstarred

So it was important for me to make these parts distinct in the new design, whilst maintaining a level of minimalism and a muted colour palette.

injection"); DROP TABLE Bookmarks;-- <a href="#injection" class="fragment-anchor" data-slug="injection" title="Permalink: injection"); DROP TABLE Bookmarks;--" rel="bookmark"> </a>

That was a hilarious decent joke, right? And I’m sure you appreciated that moment of tear-filled laughter that I tried.

Anyway, I needed to find a way to inject my CSS into pages on Pinboard, for which I settled on Stylish, a browser plugin (for Chrome, Firefox, and Opera) that lets you easily install [and create] themes and skins for many popular sites.

The gist of the plugin is that you can define CSS styles and apply them to pages you visit on the web, with the option to restrict collections of styles to URLs and/or URL patterns. The styles are injected with JavaScript into a style tag in the head:

<style id="stylish-3" class="stylish">
... {}
</style>

The injected CSS actually refreshes as well, à la LiveReload, so you don’t need to refresh your browser when saving changes. The in-browser code editor isn’t terrible either; it’s running on CodeMirror.

Good old Brass Tacks

You can either write the stylesheets yourself or choose from their vast selection. If you do install a theme from that repository, the styles manager in the Pinboard plugin will actually be able to update from the author at the click of a link. You can even build upon and modify stylesheets which you’ve installed, but I’m unsure what happens if you modify the stylesheet and install an update (please comment if you do).

I took a look at a few of the top plugins available under the Pinboard category to see how other people were accomplishing their designs—what kind of selector overriding might be necessary, how easy is the markup to manipulate, etc.

After tinkering with my own file for a few days and experimenting through daily use, I came up with what I think is a pretty decent, clean design:

Challenges

The CSS that I’ve written isn’t anything for me to brag about; unfortunately, Pinboard’s CSS wasn’t exactly the holy grail of CSS to begin with, so having to work with poor CSS specificity was a challenge that was difficult to get around. Essentially in order to theme any website, you should be prepared to (1) write a lot of overqualified selectors, and (2) use some reactive !importants.

Once you’ve figured out how to navigate around whatever specificity hurdles may be in your way, you’ve also got to figure out what CSS architecture problems exist, namely: is the markup consistent in its use of the CSS; does the CSS follow any naming conventions or methodologies you should maintain and build upon; how often does the architecture itself actually change—will you have to modify your stylesheet every two weeks?

Some of my personal gripes with Pinboard’s CSS specifically included:

• a lot of unnecessary nesting
• over-qualified selectors
• IDs in CSS
• inconsistent use of the CSS in the markup
• inconsistent application of classes/IDs to elements

These factors made it difficult to nail down and style things exactly the way I wanted. It feels awkward for me to write CSS under these restrictions, but it’s always important to remember that although our pursuit of performant CSS is a necessary goal, CSS performance (painting and rendering after load aside) is relatively low on the totem pole.

One avenue I could have investigated, but never did, was a similar browser plugin to modify the HTML of the page in conjunction and to compliment the CSS, but I figured that would result in a heavier performance hit than just injecting a simple stylesheet.

Changes

I made a couple of over-arching changes to the CSS of Pinboard, which affected the rest of the design, those being:

• responsified the layout with media queries
• applying box-sizing: border-box; to the entire document:

html {
    box-sizing: border-box;
}
*, *:before, *:after {
    box-sizing: inherit;
}

• including normalize with @import:

@import url("https://chrisburnell.com/css/normalize.min.css");

• changing the base font-family to Open Sans, hosted by Google Fonts with @import:

@import url("https:/fonts.googleapis.com/css?family=Open+Sans:400italic,400,600");

• changing the base font-size to 16px and changing many properties to be relative to the font-size with ems and rems
• changing a handful of action buttons from textual links to icon links: star, edit, delete, mark as read
  • for this I used a CSS trick to take the element’s text out of the flow and hide it, and instead display a base64-encoded background-image with an arbitary width, height, and background-size

.edit_links a.edit,
.edit_links a.edit:visited,
.edit_links a.delete,
.edit_links a.delete:visited,
.edit_links a.mark_read,
.edit_links a.mark_read:visited {
    background-color: transparent;
    background-position: center;
    background-size: 19px 19px;
    background-repeat: no-repeat;
    opacity: .4;
    width:  19px;
    height: 19px;
    display: inline-block;
    padding: .25rem;
    position: relative;
    overflow: hidden;
    vertical-align: middle;
    text-indent: 100%;
    white-space: nowrap;
    -webkit-transition: opacity .1s ease;
            transition: opacity .1s ease;
}
    .edit_links a.edit:hover,
    .edit_links a.edit:focus,
    .edit_links a.delete:hover,
    .edit_links a.delete:focus,
    .edit_links a.mark_read:hover,
    .edit_links a.mark_read:focus {
        opacity: 1;
    }

...

/* dark colour green */
.edit_links a.edit {
    background-image: url(data:image/svg+xml;base64,PD94bWwgdmVyc2lv...);
}
    /* light colour green */
    .edit_links a.edit:hover,
    .edit_links a.edit:focus {
        background-image: url(data:image/svg+xml;base64,PD94bWwgdmVyc2lv...);
    }

• modified the colour palette to match my styleguide
• implemented hooks with IFTTT to create bookmarks for specific events: Github stars, Twitter favourites, tweets by me with links, etc.

You can view the final stylesheet that I’m using on Github Gist:

Conclusion

I’m not trying to point any fingers, but there’s a lesson in there: that it’s our job as developers to eliminate trifling work like this. We need to educate our peers, colleagues, and fellow developers on subjects we’re strong with, building towards the goal of creating a better web for everyone.

I think the ideas discussed in Rik Schennink’s article in Smashing Magazine, Design Last, are a great ethos to take on when building websites. Content is king. If we understand first how we want to present and differentiate content from one another, then the design and development stage is much easier, and promotes a component-driven architecture.

If all we’re doing is changing a few colours, fonts, and sizes of elements on websites we use everyday, and finding it to be a cumbersome task, imagine the difficulty the developers of these websites face when updating their own websites. This isn’t the foundation for the web I want to use and build for in the future. We can do better.