
Primer – CSS toolkit and guidelines that power GitHub - hswolff
http://primercss.io/
======
bshimmin
Sometimes I hate web development. Comparing the buttons
([http://primercss.io/buttons/](http://primercss.io/buttons/)) between Chrome
and Safari on my Mac, the text is a pixel further up in Chrome and thus looks
slightly wonky to me.

Here's a screenshot of the two side-by-side (Chrome left, Safari right),
zoomed to 500% in Photoshop with a 1px grid:
[http://imgur.com/dhZrxFH](http://imgur.com/dhZrxFH)

~~~
mdo
This is due to a Chrome bug with how they render Helvetica. We could hack it
ourselves, but it's a regression on their end and it'd just be more work for
us.

~~~
saurik
Are you sure it is a bug, and not just a difference in the way the vertical
spacing is calculated? Apple changed the way Helvetica's height is calculated
in iOS 3.x and for a while had a "legacy font metrics" that were available for
their apps, which included MobileSafari until they pulled the trigger in iOS
4.x. I have found every browser and operating system and often different
versions of each to calculate these metrics differently, even for a specific
given font. I talked to some people at WebKit and on Safari about this, and
they absolutely do not consider it a bug.

~~~
mdo
Yup, see my comment above or below this. I'd find the tweets about it, but
blah, Twitter search.

------
mantasm
I'm surprised at the lack of semantic meaning in most popular grid frameworks.

Years ago, we moved away from layout with tables because <table><tr> is a
horrible way to separate presentation from content but <div class="two-thirds
columns"> is just as bad.

~~~
jordanlev
What exactly do you mean by "semantic meaning"? Meaning to who? For what
purpose?

Classes on elements exist for the purpose of styling via CSS, not for users to
see or screen readers to read or googlebots to classify. So if you want your
css classes to "mean something" (which is what "being semantic" is), you want
them to mean something to the STYLE of your page! Hence, using class="two-
thirds columns" is perfectly semantic towards the purpose of visually styling
the page.

Did you have some other interpretation of "semantic" that you think should
apply instead? Perhaps you mean "the structure of the content"? That's not
what classes are for -- that's what the elements themselves are for. Or
perhaps you mean for visually-impaired folks to be able to easily navigate the
content? That's not what classes are for either -- that's what ARIA roles are
for. SEO perhaps? It's possible that google uses class names for this, but
that's just black magic voodoo that us mere mortals can have no knowledge
about (and even if we did, it could change tomorrow).

Here's the thing about using tables for layout... the table element actually
has a defined meaning in HTML... it is for tabular data. The div element
however does not imply any meaning (other than "arbitrary division of the
page"). So using a div here with the classes that imply meaning to the CSS is
quite "semantic" in this case.

~~~
jonahx
"Semantic" in the sense he's complaining about means, roughly, "what the thing
_is_ " rather than "how the thing _looks_ ". So instead of 'class="one-third
column left"' you would write 'class="left-navigation"' or, if you want to be
more pure 'class="category-navigation"', which acknowledges that being on the
left or right is itself a presentation choice that should be controlled in
CSS. Behind the scenes, of course, you can use SASS or similar to apply the
styles of left, one-third width, etc, to your semantically-named class,
without changing the name "category-navigation" or your markup at all.

Markup written this way is, imo, indeed more readable, maintainable, and less
likely to change. Whether you agree with that or not, that's the meaning of
"semantic" in CSS arguments.

The argument here is similar to the argument for writing declarative code, or,
in OO, for ensuring that your objects, and their names, match natural domain
concepts. The rates of change of such concepts are generally much slower than
the rates of change of their concrete manifestations in views.

~~~
jordanlev
I respectfully / slightly disagree. The "thing" we're referring to here is a
div whose _sole purpose_ is for the grid layout.

The way I see it, that thing __is __a boundary for the grid. In fact, I bet if
you narrow your screen, that "thing" changes the way it looks entirely and is
no longer a "column" but rather stacks above or below its counterparts within
the same grid "row". If you used the class "left-navigation", to me that's
describing how it looks even _more_ than saying it's a "grid column" (because
the navigation won't be on the "left" on narrow screens)!

Of course your example of class="category-navigation" does not suffer from
this problem, but again my point is that sure it's more "pure" from the
perspective of describing the element's place in the overall structure of the
page, but this is not the purpose of the 'class' attribute! The HTML5 elements
are for structuring the content... but classes are hooks for styling the
content. As long as the styles themselves are not intermingled within the
HTML, I think it's no more or less "semantic" to use words that imply meaning
to the css versus the content itself.

Finally, in my experience building tons and tons of CMS-based sites over the
years, the "meaning" of the content that exists in a particular location of
the page changes a lot more frequently than the visual layout of the page. So
I'd argue that it's more likely (in my experience, for the kinds of sites I
tend to build) that using "column" as a class name will keep its intended
meaning for much longer than using something like "category-navigation"
(because one day someone in marketing is going to want to put a CTA button or
more social links in that spot that you originally intended to be for
"category navigation").

------
hswolff
Related blog post: [http://markdotto.com/2015/03/23/introducing-
primer/](http://markdotto.com/2015/03/23/introducing-primer/)

------
baddox
> Primer is the basecoat...

That's an interesting confusion within the analogy.

~~~
smt88
"Primer is the primer" is accurate but unclear. I wonder if most people even
know what primer is, especially considering most paints are now supposedly
"self-priming".

------
ChikkaChiChi
@mdo is one of the maintainers. Is this a spiritual successor to Bootstrap?

~~~
lbotos
It looks to be pretty tied to git terms:

[http://primercss.io/states/](http://primercss.io/states/)

~~~
techpeace
Indeed. From the announcement blog post: "It will always be GitHub’s internal
toolkit first, designed to help build GitHubby things. That said, we love to
share." [1]

[1]: [http://markdotto.com/2015/03/23/introducing-
primer/](http://markdotto.com/2015/03/23/introducing-primer/)

------
BerislavLopac
I like it, as it's much more semantically oriented than Bootstrap. But why do
the buttons still need the "BTN class?

~~~
blackant
mdo mentions this in his recent talk:
[http://jqueryuk.com/2015/videos.php?s=mdo-ular-
css](http://jqueryuk.com/2015/videos.php?s=mdo-ular-css)

tl;dr; It makes for cleaner grep results.

~~~
oneeyedpigeon
Without having watched the video, that sounds like a weak justification at
best. I'm sure best practises could be ignored in many scenarios with the
effect of slightly more greppable source, but that would normally be
counterproductive. I guess we need better command-line search tools, really,
ones that understand the structure of the file they're inspecting beyond a
line-by-line representation.

~~~
mdo
That is one of the reasons—you can view the slides also at
[https://speakerdeck.com/mdo/at-mdo-ular-css](https://speakerdeck.com/mdo/at-
mdo-ular-css) if you don't want to watch the video.

I like to use prefixes and base classes. It's faster for browsers to paint,
leads to fewer rules overall, reduces selectors, and helps prevent unnecessary
overrides.

~~~
oneeyedpigeon
My aesthetic senses have always led me to a preference for button {} over .btn
{}, class="foo bar" over class="foo-bar", etc. But I realise I'm in the
minority and I need to get pragmatic. The slides have convinced me to check
out the video tomorrow, which will be a start.

codeguide.co also looks well worth checking out. At the risk of derailing the
conversation further, what's the reason for leaving a trailing slash out of
self-closing elements? I recognise it's optional, but including it gives you
the option of XML-parsing your HTML; is there a non-aesthetic advantage?

------
andreash
I think the "Pixels vs ems" was a bit short.
Anyone?[http://primercss.io/guidelines/](http://primercss.io/guidelines/)

~~~
speg
Yeah, I thought rems were the new thing?

~~~
mdo
All of GitHub is basically in pixels, save for our Markdown styles—for easy
modification across devices, we use `em`s. It'd be a huge project to update
that to `rem`s anytime soon.

~~~
andreash
If you'd make it from scratch today, what technique would you use? html {font-
size:62.5% } with REM?

~~~
mdo
Set an HTML font-size—likely 16px—and use body { font-size: 1rem; }. Allows
for easy media query scaling of type.

------
gcb0
why would i want a css toolkit from a site that can't even show usable scroll
bars in a text area?

it is simply impossible to see diffs with slightly longer lines without
scrolling all the way to the bottom of the page, away from the line you want
to read, so you can reach the horizontal scroll bar.

meh.

~~~
91bananas
Say what?

~~~
gcb0
i take you don't use github for code review...

------
armandososa
I loved the tooltips implementation. I'd like to grab just that.

~~~
swah
What did you love? I was checking it and the text seems strangely positioned
on OSX.

------
andreash
Love this. What other companies have released their CSS/HTML guidelines?

I much prefer to read guidelines like this, than using a full framework.

~~~
marcins
It's not down to the code style level, but Atlassian has the Atlassian Design
Guidelines (ADG) and Atlassian UI (AUI).

ADG is the general patterns and UX stuff, AUI is a UI library which covers
both CSS and JS components and implements the patterns in the ADG.

ADG:
[https://design.atlassian.com/latest/](https://design.atlassian.com/latest/)
AUI:
[https://docs.atlassian.com/aui/latest/](https://docs.atlassian.com/aui/latest/)

------
tracker1
I'm looking forward to seeing their GFM styles... that's probably the most
compelling to me.

------
jbeja
Why do I have to put 3 divs in order to make work the grid?

~~~
jordanlev
How else would you do it (assuming you wanted to use floats)?

------
mcenedella
Terrific and very useful.

------
beatboxrevival
This just seems kinda boring - visually and technically. Do we really need
another CSS toolkit with an almost replicated feature set.

Every year, I think github is going to somehow release a long awaited product
that blows me away with all the talent they have. Every year, I'm surprised at
how little they change, and how all the opportunities that seem obvious slip
to the wayside.

~~~
mdo
Might be boring to you, but it isn't to us. This is (part of) our job :).

When I stopped to think about it, there was honestly no reason to _not_ open
source Primer. If the goal of open source is the share and learn and improve,
then what does it matter what we release? Especially as open source?

~~~
mrottenkolber
Not to piss on the pie BUT: The GitHub CSS breaks when one sets a minimum
font-size (as required for high DPI screens). Heck every web page based on
bootstrap or most "modern" CSS frameworks breaks the same way.

How about you "CSS experts" get your shit together and start respecting the
fucking standard. Assuming being able to force a font size (other than
relative) is UNPORTABLE. It always has been and (hopefully) it WILL ALWAYS BE.
I am NO GOD DAMN DESIGNER. I just know CSS because its fucking 2015. I knew
this bug since fucking 2010. Only because I fucking PLAYED WITH CSS.

Why is that the GitHub (successful company, right?) CSS team makes mistakes I
stopped making when I was in high school and CSS based layouts were a new
thing?

Now wait for it: "But minimum font size is not a default setting in any
browser. You're less than 1% of out userbase. We don't care."

/end unforgivable vulgar rant. No harm intended. Consider it comedy. But
seriously: CSS people are so wrong right now. I should be the pope of web
design and I don't even care about it.

mdo: It's not your fault. I am barking at the wrong tree. In fact there are
more pressing issues I have that GitHub ignores. It just vulcanoed out of me.
If you have any influence in the CSS scene, please try to address this common
mistake.

~~~
ubercow
Would you mind elaborating on what you mean by minimum font-size? You've got
me curious.

~~~
lstamour
At first glance I'd assume the idea is that a browser can choose to ignore
author stylesheet font sizes if they are smaller than a certain size, ensuring
text is always a minimum size of say, 16px. This is in contrast to approaches
that vary the text size consistently -- either by scaling text alone to
larger, constant sizes, or by using a "zoom" property. I can imagine that
without JavaScript, a minimum font size would be harder to support and still
maintain compatibility. This is why for most retina screen use cases, scaling
is employed instead of font-size changes.

Getting back to minimum font size, I assume the point is that we shouldn't use
em or rem to base our designs solely on font sizes, but instead on a
combination of those and percentage-based units. Also, I imagine all layouts
must "flow" to accommodate larger font sizes. Really, the biggest issue is
that every browser and device supports "zoom" for text in different ways --
look at Android, for example -- and it's hard enough accommodating screen
readers and multiple platforms to then take into account how browsers can
change the page. To some extent, it's like complaining that your websites
don't fit on my 800x600 CRT unless I make the text really tiny. Yes, it's a
legitimate complaint, but maybe there's another browser out there or extension
that can handle it -- e.g. "Readability" or Safari and how it can pull body
text from a page. Or the ability to "zoom in" on sections of a page, e.g. with
a magnifier.

------
pearjuice
With this, the updated rankings are in:

new JavaScript frameworks this month: 24

new CSS frameworks this month: 21

Will front-end developers be able to catch up to JavaScript's score or is it
going to be the third month in row JavaScript gets more frameworks out there
than CSS? With less than 10 days left on the clock, avid front-enders will
have to give everything they have to release at least 3 more frameworks. And
as you know, unless it is a MAJOR update according to the semver standard,
current framework updates don't count!

.satire {}

~~~
mdo
The number of frameworks of any kind has no bearing on the willingness of more
people to share their knowledge and experience with the open source community.
I'd write 10 more CSS frameworks if it helped just one more person make
something they loved on the web.

