Primer – CSS toolkit and guidelines that power GitHub

by hswolff • 11 years ago

256 86 11 years ago

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

From the blog post: "Primer isn’t another large front-end framework, though. It’s rather limited in functionality and isn’t intended to replace something like Bootstrap. It will always be GitHub’s internal toolkit first, designed to help build GitHubby things. That said, we love to share."

That was kinda my take away, too. It's pretty minimalist overall.

lbotos• 11 years ago

It looks to be pretty tied to git terms:

http://primercss.io/states/

techpeace• 11 years ago

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/

hswolff• 11 years ago

armandososa• 11 years ago

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

bmelton• 11 years ago

https://github.com/primer/primer/blob/master/scss/_tooltips....

swah• 11 years ago

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

baddox2• 11 years ago

Primer is the basecoat...

That's an interesting confusion within the analogy.

magic_beans• 11 years ago

They seem to have missed the opportunity for a great pun here.

smt885• 11 years ago

"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".

BerislavLopac• 11 years ago

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

blackant• 11 years ago

mdo mentions this in his recent talk: http://jqueryuk.com/2015/videos.php?s=mdo-ular-css

tl;dr; It makes for cleaner grep results.

oneeyedpigeon3• 11 years ago

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.

bshimmin2• 11 years ago

Sometimes I hate web development. Comparing the 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

baddox2• 11 years ago

I use Chrome, and GitHub's button text alignment has always bugged me. I chuckled when I noticed that this CSS framework of theirs has the same issue.

sorahn2• 11 years ago

The real problem here is using vertical paddings.

One solution I've found to getting vertical heights the same across browsers is to use no vertical padding, and large line-heights.

mdo10• 11 years ago

Absolutely no problem with vertical padding—this particular problem is a Chrome bug.

mdo10• 11 years ago

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.

bshimmin2• 11 years ago

This is great to know - thank you! And keep up the good work.

greggman• 11 years ago

Did you file a bug?

saurik• 11 years ago

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.

tambourine_man• 11 years ago

Text is consistently better in Safari in subtle ways.

It's one of the reasons why I still use it, even though it keeps getting worse with every release (crashing tabs, DNS resolution issues and that dreadful new inspector to name a few). Such a shame, it used to be a great browser.

bigiain• 11 years ago

Is it just me, or is expecting pixel-perfect identical rendering between different browsers a guaranteed way to set yourself up for disappointment?

If you aren't prepared to put up with differences that slight, perhaps web development isn't the right field for you. (Though I recall back in the day not being able to reliably reproduce film proofs for printing without occasional expensive differences showing up between proofs produced with Quark vs PageMaker... The more things change … )

mantasm3• 11 years ago

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.

currysausage• 11 years ago

Reminds me of @hsivonen's wonderful "HOWTO Spot a Wannabe Web Standards Advocate": https://hsivonen.fi/wannabe/

Edit: Curious why this is being downvoted. Is humor (intelligent humor in this case IMO) really that frowned upon at HN? Or did someone think I was calling the parent commenter a "Wannabe Web Standards Advocate"? (I certainly wasn't. Quite the opposite.)

k__2• 11 years ago

AFAIK you shouldn't get this problem if you use the sass/less sources of these frameworks directly.

But I didn't find any good tutorials on this.

Also, I don't know how this should change the html-elements needed by stuff like the bootstrap components.

smt885• 11 years ago

No tutorial needed.

1. Create your HTML using only semantics. If you're tempting to create a class called, say, "column" or "left-container", stop yourself. If you have multiple items that will be presented the same way, give them the same class. For a shopping site, for example, a class might be "product".

2. Use a CSS preprocessor to inherit non-semantic classes from your framework of choice into the classes you created in step 1. You might use the framework's classes as they are or modify them a little.

ZeroGravitas2• 11 years ago

Its not as bad because table had another meaning that was being abused because there was nothing else. That's not the case for grids. Also grids are presentation, not semantic.

oneeyedpigeon3• 11 years ago

I share your frustration, but a general purpose css framework can't really avoid using this approach to support layout. What possible alternative semantic classes could they use that would provide the level of flexibility they're catering for?

mantasm3• 11 years ago

It's very doable, but Sass or similar is necessary.

For example: http://neat.bourbon.io/

jordanlev5• 11 years ago

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.

mantasm3• 11 years ago

class="two-thirds columns" enforces a strong coupling between the HTML and how it is presented.

To change how wide a column is, you change its class. To change how wide an image is, you go into the CSS. To change how wide a column's border is, you go to the CSS. Doesn't changing the class seem a little out of place?

In theoretical terms, the class is semantically the category to which the component belongs. a <section class="cart"> is perfectly reasonable, whereas <div class="two-thirds columns"> is not. The <div> and it's children are not tied to the notion of how wide the div is. The fact that a section has class "cart" is important in understanding it's children.

jonahx• 11 years ago

"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.

arvinsim• 11 years ago

I got tired of using CSS frameworks where classes are used to define widths. Now, I much prefer frameworks that support semantic style like Susy.

http://susy.oddbird.net/

smt885• 11 years ago

If you use SCSS or LESS, you can inherit the widths into semantic classes. So Bootstrap can be as semantic as you want it to be.

jfroma• 11 years ago

Agree, I really like this one http://semantic.gs/

ZeroGravitas2• 11 years ago

Nicolas Gallagher wrote a pretty thorough rebuttal to this popular idea (at least popular in comment sections, as you note none of the frameworks that have taken the web by storm recently pay any attention to it).

http://nicolasgallagher.com/about-html-semantics-front-end-a...

Conclusion:

"When you choose to author HTML and CSS in a way that seeks to reduce the amount of time you spend writing and editing CSS, it involves accepting that you must instead spend more time changing HTML classes on elements if you want to change their styles. This turns out to be fairly practical, both for front-end and back-end developers – anyone can rearrange pre-built “lego blocks”; it turns out that no one can perform CSS-alchemy."

pearjuice• 11 years ago

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 {}

mdo10• 11 years ago

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.

beatboxrevival2• 11 years ago

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.

mdo10• 11 years ago

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?

mrottenkolber2• 11 years ago

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.

beatboxrevival2• 11 years ago

Sorry for the rant, you're completely right.

jbeja• 11 years ago

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

jordanlev5• 11 years ago

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

gcb02• 11 years ago

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• 11 years ago

Say what?

gcb02• 11 years ago

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

quoiquoi• 11 years ago

hold middle mouse button, drag

andreash3• 11 years ago

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• 11 years ago

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/ AUI: https://docs.atlassian.com/aui/latest/

andreash3• 11 years ago

I think the "Pixels vs ems" was a bit short. Anyone?http://primercss.io/guidelines/

speg• 11 years ago

Yeah, I thought rems were the new thing?

mdo10• 11 years ago

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.

tracker1• 11 years ago

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

mcenedella• 11 years ago

Terrific and very useful.

Primer – CSS toolkit and guidelines that power GitHub

Related Stories