-
-
Save cballenar/4277585 to your computer and use it in GitHub Desktop.
| /* --------------------------------------------------- | |
| Production Versions ( Minified ) | |
| --------------------------------------------------- */ | |
| /* Background */ | |
| /**/ .baseline{font-size:1em;background:none;background-image:-webkit-linear-gradient(rgba(0,0,0,0.2) 1px,transparent 1px);background-image:-moz-linear-gradient(rgba(0,0,0,0.2) 1px,transparent 1px);background-image:linear-gradient(rgba(0,0,0,0.2) 1px,transparent 1px);background-size:100% 1.5em;background-origin:content-box;background-attachment:local} | |
| /**/ .baseline *{background:none !important;outline:1px dashed rgba(100%,0%,0%,.5)} | |
| /* Overlay + Hover switch */ | |
| /**/ body{position:relative}body:hover:before{width:100%;height:100%;display:block;content:"";position:absolute;z-index:9999;pointer-events:none;background-size:100% .75em;background-origin:content-box;background-attachment:local;background-image:-webkit-linear-gradient(rgba(0,255,255,.75) 1px,transparent 1px);background-image:-moz-linear-gradient(rgba(0,255,255,.75) 1px,transparent 1px);background-image:linear-gradient(rgba(0,255,255,.75) 1px,transparent 1px)} | |
| /**/ body:hover *{background:none !important;outline:1px dashed rgba(100%,0%,0%,.5)} | |
| /* --------------------------------------------------- | |
| Background Baseline - Dev | |
| --------------------------------------------------- */ | |
| .baseline { | |
| font-size: 1em; | |
| background: none; /* Removes any pre existing background */ | |
| background-image: -webkit-linear-gradient(rgba(0,0,0,0.2) 1px, transparent 1px); | |
| background-image: -moz-linear-gradient(rgba(0,0,0,0.2) 1px, transparent 1px); | |
| background-image: linear-gradient(rgba(0,0,0,0.2) 1px, transparent 1px); | |
| background-size: 100% 1.5em; /* line-height */ | |
| background-origin: content-box; /* regardless of padding, background will begin in the corner of the box */ | |
| background-attachment: local; /* for scrolling */ | |
| } | |
| /* For Debugging */ | |
| .baseline * { | |
| background: none !important; /* Remove all backgrounds */ | |
| outline:1px dashed rgba(100%,0%,0%,.5); /* Add a dashed outline around elements to view where they begin/end in relationship to baseline. */ | |
| } | |
| /* --------------------------------------------------- | |
| Overlay Baseline + Hover switch - Dev | |
| - Thanks to mhulse for the overlay update! | |
| --------------------------------------------------- */ | |
| body { position:relative; } | |
| body:hover:before { | |
| width: 100%; height: 100%; /* sizes element */ | |
| display: block; content: ""; /* displays element */ | |
| position: absolute; z-index: 9999; /* positions element */ | |
| pointer-events:none; /* click through overlay */ | |
| background-size: 100% .75em; /* sets baseline height */ | |
| background-origin: content-box; /* for correct display of grid */ | |
| background-attachment: local; /* for scrolling */ | |
| background-image: -webkit-linear-gradient(rgba(0, 255, 255, .75) 1px, transparent 1px); | |
| background-image: -moz-linear-gradient(rgba(0, 255, 255, .75) 1px, transparent 1px); | |
| background-image: linear-gradient(rgba(0, 255, 255, .75) 1px, transparent 1px); | |
| } | |
| /* Debugging */ | |
| body:hover * { | |
| background: none !important; /* removes all backgrounds */ | |
| outline:1px dashed rgba(100%,0%,0%,.5); /* red dashed outline around elements */ | |
| } | |
| /* --------------------------------------------------- | |
| Deprecated | |
| ------------------------------------------------------ | |
| Shifts lines to bottom of type. { background-position: 0 -0.6em; } | |
| */ |
Quick question: When you say:
When working with boxes, containers, and other elements I try to keep paddings, borders, and margins in relationship to the baseline (multipliers or halves) that way no matter what you add, elements will always maintain the rhythm.
What would be an example of "halves"? So, if my base line-height is 1.5, and my default font-size is 1em... Then half of 1.5 is .75 for a target font size of 1em. Does that mean you apply half a margin to the top and bottom, or just top or just bottom? Seems like if you apply just a half of the margin, then you're throwing yourself off of the baseline grid?
I assume you mean that you apply both a top and bottom half margin (which equals a whole line-height)?
Examples:
Math:
(base
line-height(1.5) / targetfont-size(1.375) = 1.090909) / 2 = .545454
h5 {
font-size: 1.375em; /* 22px */
line-height: 1.090909;
margin: .545454em 0;
}A simpler example:
h6 {
font-size: 1em; /* 16px */
line-height: 1.5;
margin: .75em 0;
}In other words, do you apply the half the margin to the top and bottom? Seems like if you apply only a half to top or bottom, then you're on a sub-baseline (which is something I have yet to explore).
I hope that makes sense.
Thanks!
M
How have you handled margin collapse on a baseline grid? I'm just now running into that with my headings... Wondering if I should use padding instead?
Yes, normalize.css sits behind all this code. Mainly because it comes as part of the HTML5 Boilerplate but I would use it regardless of the project. It gets rid of a lot of bugs and inconsistencies.
Regarding the halves. This is something I have started doing and I'm not sure what your thoughts will be. I kept running into one particular issues, sometimes the a line-height of 1.5em is too much, but if I were to use only half, some of the content WILL be out of the baseline. What if instead of using a strict baseline, we were to use half of it. All content would still line up to something but it would give us some flexibility for those times where we need it.
With that in mind, yes, I apply half the line height to the top and bottom padding of a wrapper.
One thing that i have started doing is adding the margin only to the bottom of text elements, e.g. h1, h2, p, etc. This has been working really well for me for the most part.
Now, regarding your last post, that depends, are you talking about margin on a text element or a wrapper?
For text elements I only apply the bottom margin, for wrappers, I'll combine a main wrapper with an inner wrapper, depending on the situation. The main wrapper will contain a bottom margin same as the text elements, e.g. separate header from body. While the inner wrapper will contain the padding and background if any. This is particularly useful for the content area where you need your copy to stay away from the edges.
This may be a bit confusing so let me know if it doesn't make sense. I gotta get back to work for now :P
Also, Smashing Magazine just posted this. I haven't had a chance to read it but it may help us clear some of the questions. http://coding.smashingmagazine.com/2012/12/17/css-baseline-the-good-the-bad-and-the-ugly/
@cballenar Thanks again for the replies, I really appreciate it! :)
Yes, normalize.css sits behind all this code. Mainly because it comes as part of the HTML5 Boilerplate but I would use it regardless of the project. It gets rid of a lot of bugs and inconsistencies.
Definitely! I agree. I hadn't put two and two together when you mentioned H5BP earlier. :D
The reason why I pointed out normalize, specifically this line, is that they are using a line-height of 0... You had mentioned using 0 for your code; I figure if normalize.css is using 0, then it must be a good idea (or, should I say, solution). :)
Regarding the halves. This is something I have started doing and I'm not sure what your thoughts will be. I kept running into one particular issues, sometimes the a line-height of 1.5em is too much, but if I were to use only half, some of the content WILL be out of the baseline. What if instead of using a strict baseline, we were to use half of it. All content would still line up to something but it would give us some flexibility for those times where we need it.
I'm still new to this, but that sounds like a solid approach to me. :)
Thanks for explaining your thinking in more detail. Now that I get what you're saying, I'd like to experiment with it myself.
Actually, and maybe this is what you/other folks do, but I've been playing around with "local" baseline on "modules". For example:
<body>
Main column: Sidebar:
+-----------+ +-----------+
| module | | module |
| with | | with |
| baseline | | baseline |
+-----------+ +-----------+
+-----------+ +-----------+
| module | | module |
| with | | with |
| baseline | | baseline |
| | | |
+-----------+ | |
+-----------+ +-----------+
| module | +-----------+
| with | | module |
| baseline | | with |
+-----------+ | baseline |
+-----------+ +-----------+
| module |
| with |
| baseline |
| |
| |
+-----------+
+-----------+
| module |
| with |
| baseline |
+-----------+
</body>
Not sure if that makes sense... I know that in print, the whole point of a baseline is to line up all/most content on a global baseline; but, on the web, for a content-heavy site (like one I'd like to use this technique on), I could see myself going crazy trying to align to a <body> baseline... That's why I like the thought of "local" baselines on content "modules".
With that in mind, yes, I apply half the line height to the top and bottom padding of a wrapper.
Cool! Yah. That makes sense as well.
One thing that i have started doing is adding the margin only to the bottom of text elements, e.g. h1, h2, p, etc. This has been working really well for me for the most part.
Interesting, I'll play with that (and your idea of adding half the line-height).
Now, regarding your last post, that depends, are you talking about margin on a text element or a wrapper?
Well, I guess I'm refering to anywhere margins meet (thus, causing margin collapse).
This person does a good job at explaining a situation where margin collapse can be a pain:
See: Getting around vertical margin collapse in browsers
The way I usually combat margin collapse is by applying padding.
For containers:
/**
* Contains child margins.
*
* @see rgne.ws/JAoGck
*/
.force {
margin-top: -1px;
margin-bottom: -1px;
padding: 1px 0;
}Or, in the case of <h*> tags, and the baseline, converting margins to padding stops margin collapse as well.
It looks like the author in the above article just doubles the bottom margin... I've played with this, but it feels hacky to me.
For text elements I only apply the bottom margin, for wrappers, I'll combine a main wrapper with an inner wrapper, depending on the situation. The main wrapper will contain a bottom margin same as the text elements, e.g. separate header from body. While the inner wrapper will contain the padding and background if any. This is particularly useful for the content area where you need your copy to stay away from the edges.
Interesting! I'll play around with that. :)
Thanks for tips!
This may be a bit confusing so let me know if it doesn't make sense. I gotta get back to work for now :P
No, makes perfect sense! Thank you!
Off topic: I wish Github would send me an e-mail when you reply to this thread... Sorry for my late reply. :(
Oh, and tahnks for that smashing mag link too! Looks like a good article. :)
Happy Holidays!
Cheers,
Micky
Hey Micky,
Off topic: I wish Github would send me an e-mail when you reply to this thread... Sorry for my late reply. :(
Don't worry about it, I feel the same way here. Thanks for the continuing the thread.
It looks like the author in the above article just doubles the bottom margin... I've played with this, but it feels hacky to me.
I think so too, but I also feel that the .force solution is a bit hacky and is more of a band-aid as opposed to a solution. At the end one would end up with a plane that has a lot of patches to it but not a solution to the real problem. However, I could be wrong, and this could be THE solution. At the moment I think that there has to be a magic formula as to how, where and when to use margins and paddings; so far I seem to keep running into some issues and, well, I guess there will always be some exceptions. Maybe we just need to do a coding session to figure it out. :P
I get what you are saying with the local baseline, and to a certain degree I agree with this technique I think there are certain cases where one just can't get around having to do this, e.g. tables. However, objects/modules are the reason I suggested the half baseline example. Once you set a half baseline, it is much easier to control elements like this. I don't have a live project for this yet but if I can get it running over the weekend I'll send you some examples.
One more thing you will want to experiment with and this is something I started recently but I'm fairly thrilled about. Use advanced CSS selectors to refine margins and paddings. For example, and this is not a great example, let's say that you want your h1 and p to be separated by a 2em margin, but if your h1 is followed by any other heading OR if your p is preceded by any other heading they should be separated by only 1em. In this case you can do something like this.
h1,
h2,
p { margin: 0 0 1em; }
h1 + p { margin-top:2em; }Now, this is just a very simple example. You can target things such as:
/* prevent bottom margin if .content already has padding */
.content > p:last-child { margin-bottom:0; }
/* Offset H1 if it's the first element inside a module */
.content .module h1:first-child { margin-top: -6px }Anyway, there are endless ways to further improve spacing.
Keep me posted on your progress, I'll check back later.
Happy Holidays to you as well!
Carlos
P.S.: Perhaps we should collaborate on a bigger project at some point, blog entry perhaps?
In case you want to learn more about sibling selectors:
http://css-tricks.com/child-and-sibling-selectors/
Updated Gist - added some debugging features
Doh! Sorry for my late reply. :(
I'm hoping at some point GitHub will add notifications to gists like they have for normal repositories.
Today is the first day since the last time we talked that I've been able to get back to this project. Thanks for getting back to me and sharing more of your wisdom and experience. :)
I think so too, but I also feel that the .force solution is a bit hacky and is more of a band-aid as opposed to a solution.
Oh, for sure. I probably should have clarified… That's just a utility class I typically have in my CSS for when I need to combat unwanted margin collapse (I did not mean to suggest that class is something I would apply to headings or paragraphs to fix the baseline grid margin collapse scenario).
Here's a better, more real-world example:
body {
font: 100.01%/1.5 Arial, sans-serif; /* Serif: Cambria, Georgia, serif; */
color: #000;
min-height: 100%;
-webkit-font-smoothing: antialiased;
font-smoothing: antialiased;
text-rendering: optimizeLegibility;
}
/**
* Heading elements implement six levels of document headings, `<h1>` is the most important and `<h6>` is the least.
* A heading element briefly describes the topic of the section it introduces.
*
* Note: The `.h1`-`.h6` classes should be used to maintain the semantically appropriate heading levels.
* Attention: Classes NOT for use on non-headings.
*
* @see https://groups.google.com/d/topic/object-oriented-css/GE1uzU2Bu48/discussion
* @see http://www.stubbornella.org/content/2011/09/06/style-headings-using-html5-sections/
* @see https://github.com/stubbornella/oocss/blob/master/core/heading/heading.css
* @see http://csswizardry.com/2012/02/pragmatic-practical-font-sizing-in-css/
*/
h1, .h1, h2, .h2, h3, .h3, h4, .h4, h5, .h5, h6, .h6 { margin: 0; }
h1, .h1 {
font-size: 2.875em; /* 46px */
line-height: 1.043478;
}
h2, .h2 {
font-size: 2.5em; /* 40px */
line-height: 1.2;
}
h3, .h3 {
font-size: 2.125em; /* 34px */
line-height: 1.411764;
}
h4, .h4 {
font-size: 1.75em; /* 28px */
line-height: 1.714285;
}
h5, .h5 {
font-size: 1.375em; /* 22px */
line-height: 1.090909;
padding: .545454em 0;
}
h6, .h6 {
font-size: 1em; /* 16px */
line-height: 1.5;
padding: .75em 0;
}As you can see, the last two heading classes use padding instead of margin; I guess the nice thing here is that the margins don't collapse (because they're not there) and the baseline grid is still maintained (i.e. there's no extra math needing to be done or double margins needing to be added).
On the flip side, it does feel a bit strange using padding in place of margin for things like headings and paragraphs. :(
Maybe we just need to do a coding session to figure it out. :P
Totally! I'd love to see what you've been working on. I'm in the process of building a style guide of my own (based on all of the great stuff you shared with me here). Maybe in the next week or two we could swap demo pages. :D
I get what you are saying with the local baseline, and to a certain degree I agree with this technique I think there are certain cases where one just can't get around having to do this, e.g. tables. However, objects/modules are the reason I suggested the half baseline example. Once you set a half baseline, it is much easier to control elements like this. I don't have a live project for this yet but if I can get it running over the weekend I'll send you some examples.
Yah, for the site I'd like to implement this on (a newspaper site) I think we'd go crazy trying to maintain a global baseline on the <body> (considering all the unknown amounts of content coming and going from day to day)… That's why my focus has been on local baselines for modules.
I really like that Idea of a half baseline and I can't wait to experiment. I'm going to play with things today and I'll post back my findings later to get some peer/pro feedback (from you). :D
One more thing you will want to experiment with and this is something I started recently but I'm fairly thrilled about. Use advanced CSS selectors to refine margins and paddings. For example, and this is not a great example, let's say that you want your h1 and p to be separated by a 2em margin, but if your h1 is followed by any other heading OR if your p is preceded by any other heading they should be separated by only 1em. In this case you can do something like this.
Anyway, there are endless ways to further improve spacing.
That's a great idea! I'm constantly in situations where I need subheads to be "tighter" to the bottom of the main heading, but when subheadings aren't there (i.e. for the sites I work on, subheads are optional) then I have to figure out a way to account for the difference in margin. Your suggestion sounds like the perfect fix (especially when dealing with a baseline grid).
(For the longest time, I've avoided certain advanced CSS selectors and/or CSS3 techniques because I try to fully support IE6/7/8… But, who's it going to hurt if there's an extra bit of spacing or something in older browsers… The site should still be accessible without the perfect (baseline grid) spacing.)
Keep me posted on your progress, I'll check back later.
Ditto! Thanks again for sharing all of your expertise, I really appreciate it. :)
P.S.: Perhaps we should collaborate on a bigger project at some point, blog entry perhaps?
Wow, I'd be pretty stoked to collaborate with you on that level, though, I'm don't think I'm the greatest writer in the world (as you can probably tell). To be honest, I think you're way ahead of me in terms of the baseline grid and other things… I'm not sure if I'd be able to contribute anything that you wouldn't be able to cover on a more professional level. :D
Either way, let's continue our back-and-forth here and see where it goes! ;)
In case you want to learn more about sibling selectors: http://css-tricks.com/child-and-sibling-selectors/
Awesome! I'll be experimenting with that over the next few days. Much appreciated.
Updated Gist - added some debugging features
Oooh, love the debug class! That's a great idea!!!!
Also, I see that you dropped the background-position... I was having troubles getting that to line up with the baseline as well. I think you're right to comment it out.
Thanks again Carlos, I really appreciate all of your help and advice!
Cheers,
Micky
EDIT:
I forgot to mention that the verison of the .baseline class that I'm using doesn't set have the font-size: 1em;. Because your .baseline sets the font-size, I don't think you'd need to worry about using rem.
For my latest tests, I wanted to be able to apply the .baseline class to modules without it affecting a font-size that might already be set on said module. :)
With that said, my below comments will probably make more sense.
What do you think about using rem for:
background-size: 100% 1.5rem;Here's a situation where I found the rem unit to be helpful:
CSS:
(Using normalize.css to normalize everything) and then:
/**
* Indicates that its content is preformatted and that this format must be preserved.
*
* @see https://github.com/twitter/bootstrap/blob/master/less/code.less
*/
pre {
font: .813em/1.845018 Monaco, Menlo, Consolas, "Courier New", monospace;
color: #333;
background-color: #ddd;
background-color: rgba(0, 0, 0, .1);
border-width: 1px; /* .063em */
border-style: solid;
border-color: #ccc;
border-color: rgba(0, 0, 0, .15);
margin: 1.782018em 0;
padding: .922509em;
display: block;
-webkit-border-radius: 4px;
-moz-border-radius: 4px;
border-radius: 4px;
word-break: break-all;
word-wrap: break-word;
white-space: pre;
overflow: auto;
}HTML:
<pre class="baseline">
var q2 = oMQ.addQuery({
context : ['small', 'medium'],
call_for_each_context : false,
match : function() { console.log('MATCH: small/medium'); },
unmatch : function() { console.log('UNMATCH: small/medium'); }
});
</pre>From what I can tell, using rem made it so the "local" .baseline on the <pre> isn't affected by the <pre>'s font size.
I suppose this would be a minor change to your code… Also, this would not be an issue if one was not using the "local" baseline grid approach.
What do you think?
Cheers,
Micky
Another update:
Inspired by your comment found in this Gist's description:
Perhaps an overlay version can be developed from this.
I quickly slapped this together:
/**
* Baseline grid class.
* It simulates a baseline grid based on `em`/`rems` which will allow you to size according to your site's `font-size`.
*
* @see https://gist.github.com/4277585
* @see http://advent2012.digitpaint.nl/13/
* @see http://stackoverflow.com/a/8905262/922323
* @see http://css-tricks.com/browser-support-pseudo-elements/
*/
.baseline { position: relative; }
/* Grid overlay: */
.baseline:before {
background-image: -webkit-linear-gradient(rgba(0, 255, 255, .75) 1px, transparent 1px);
background-image: -moz-linear-gradient(rgba(0, 255, 255, .75) 1px, transparent 1px);
background-image: linear-gradient(rgba(0, 255, 255, .75) 1px, transparent 1px);
background-size: 100% 1.5rem; /* Match base `line-height`. */
background-position: 0 0; /* Put line adjustments here. */
background-origin: content-box; /* Regardless of padding, background will begin in the corner of the box. */
background-attachment: local; /* For scrolling. */
width: 100%;
display: block;
position: absolute;
top: 0;
bottom: -1px; /* Allows for the bottom-most border to show. */
z-index: 999; /* Above all other content. */
content: "";
pointer-events: none; /* The element is never the target of mouse events. */
}
.baseline.half:before { background-size: 100% .75rem; } /* Half base `line-height`. */
.baseline.double:before { background-size: 100% 3rem; } /* Double base `line-height`. */
/* Add a faux border to child elements to view where they begin/end in relationship to baseline: */
.baseline * {
-webkit-box-shadow: inset 0 0 0 1px rgba(255, 0, 0, .5);
box-shadow: inset 0 0 0 1px rgba(255, 0, 0, .5);
}I haven't had a chance to cross-browser test (just been using Firefox 17.0.1 on Mac 10.8.2).
What do you think?
As I've said before, my version is a tad different than yours... As you can see, I removed the font-size: 1em; and background: none; properties from the .baseline class.
I was also playing with the .baseline * class... Just experimenting box shadows... It's not a dashed line, but I kinda like how it looks (I wish it were easy to apply an inset box-shadow to the top and bottom only).
Anyway, what do you think?
Micky
Hey!
Sorry if I miss a few things, been kinda busy lately.
I'll start by saying that the overlay baseline is awesome. I didn't think it'd be that easy. I played with similar ideas before but always ran into issues, i.e. the box with the baseline would not take the full height or would stop at the end of the screen. But this seems to be working really well (Chrome v23 on Mac). Like you said it still needs to be tested in other browsers. I'll play with it a little more and give you some feedback.
Now, since you brought up CSS3 support for IE. Be sure to check out http://selectivizr.com/ we use it at work and it allows me to use CSS3 features with almost no worries. However keep in mind that it uses JavaScript and requires an additional library such as jQuery.
Also, I liked the concept of creating identical classes for headings. I'll have to experiment with that it may solve some issues I've seen. When do you use it? Did you learn about it online? I'd like to know if there's any background info.
I was also wondering about the 100.01% font size. why the .01 ?
I haven't had the chance to play with rems yet but I'll try to look into that in the near future.
I think after the first week of January I'll have a little more time to focus on writing a post, I'll let you know!
Alright, gotta go for now but I'll get back to you soon.
Take care!
Carlos
Sorry if I miss a few things, been kinda busy lately.
No worries at all! I completely understand. :)
I'll start by saying that the overlay baseline is awesome.
Lol, thanks! Honestly, I don't deserve any credit, I just made a mashup of your .baseline and this technique here (I've most recently made use of that technique in a column border class that I created for a simple responsive "grid system" I built for my day job); but yah, it's definitely a cool and useful technique… The only drawback is that it's only compatible with IE > 7 (without any sort of JS polyfill).
I didn't think it'd be that easy. I played with similar ideas before but always ran into issues, i.e. the box with the baseline would not take the full height or would stop at the end of the screen. But this seems to be working really well (Chrome v23 on Mac). Like you said it still needs to be tested in other browsers. I'll play with it a little more and give you some feedback.
Cool! Glad to hear it's working for you too! :)
I would not be surprised if you found some bugs though…
For example, I noticed a spacing issue when I applied it to the <pre> class that I posted in my previous comment (I think it had to do with the padding applied to the <pre>). Unfortunately, I haven't had time to try and fix. Fortunately, the way I've been using the :before version of .baseline is on the <div> or <section> wrappers around my "local" modules; typically, for me, these wrappers don't have any, or very little, styling applied so I'm not so worried about the weirdness I discovered with the <pre> styles.
I've also tested it on the <body> and it seems to work pretty well there too, though I do have these global styles applied:
html {
height: 100%; /* Expand to height of browser window. */
overflow-y: scroll; /* Force scrollbar in non-IE. */
}
body {
/* Initial height of `<html>`, but will expand taller if necessary: */
min-height: 100%; /* Compliant browsers. */
_height: 100%; /* IE6 treats `height` as `min-height`. */
}Now, since you brought up CSS3 support for IE. Be sure to check out http://selectivizr.com/ we use it at work and it allows me to use CSS3 features with almost no worries. However keep in mind that it uses JavaScript and requires an additional library such as jQuery.
Thanks for linkage! I'll play around with that. :)
I usually try to avoid extraneous libs, but selectivizr seems pretty useful (I've seen it talked about over the last couple years, but never used it for any projects).
Also, I liked the concept of creating identical classes for headings. I'll have to experiment with that it may solve some issues I've seen. When do you use it? Did you learn about it online? I'd like to know if there's any background info.
Oh, for sure. Again, I can't take any credit. That's an OOCSS technique/concept.
I've updated that code with a CSS comment doc block that helps to explain the code via descriptions and linkages. For your convenience, here's the links:
- Headings question: Basic concept/usage?
- Don’t Style Headings Using HTML5 Sections
- OOCSS:
heading.css - Pragmatic, practical font sizing in CSS
I was also wondering about the 100.01% font size. why the .01 ?
Oh, sure! It's an older technique that I've been using off and on recently. Here's some links:
- Is using font-size: 100.01% still needed, and for what browsers?
- body { font-size: 100.01%; } vs body { font-size: 100%; }?
- Internet Explorer Win Bugs: Inheritance
With that said, I don't think there's a huge need for 100.01% these days, so I may switch back to using font-size: 100%.
I haven't had the chance to play with rems yet but I'll try to look into that in the near future.
Yah, the rem (root + em) unit is interesting. Here's some links:
- Type study: Sizing the legible letter
- Font sizing with rem
- Preserving vertical rhythm with CSS and jQuery
- Gridlover is the tool to establish a type system with modular scale and vertical rhythm to build upon.
Note: The last two links above are examples of folks using rems for vertical rythm.
I think after the first week of January I'll have a little more time to focus on writing a post, I'll let you know!
Awesome! I'm totally looking forward to reading what you post! :)
Alright, gotta go for now but I'll get back to you soon.
Ditto! See you next year!
Happy New Year!!!
Cheers,
Micky
btw, this is mostly a note to myself.
In the past i had a baseline with a css3 switch. i'll work on adding that.
CSS3 switch sounds interesting! :)
I've updated my overlay version with a new property pointer-events... Without this property, links below the overlay aren't clickable. Unfortunately this property is not totally cross-browser compliant... I was thinking about maybe hiding the grid overlay or setting its grid z-index to a negative value on :hover. On the other hand, maybe I'm making a mountain out of a molehill here? :D
I was gonna suggest the same. Pointer events is awesome but as you mentioned it is not fully supported. After thinking more about it I think the css3 switch may not be such a good idea, it'd be cool but it would have to be added as markup as well making this grid solution more annoying. However one option would be to turn it on/off via :hover.
I've done some modifications to your grid which adapt to the way I work
/* Overlay Baseline */
body { position:relative; }
body:hover:before {
width: 100%; height: 100%; /* sizes element */
display: block; content: ""; /* displays element */
position: absolute; z-index: 9999; /* positions element */
pointer-events:none; /* click through overlay */
background-size: 100% .75em; /* sets baseline height */
background-origin: content-box; /* for correct display of grid */
background-attachment: local; /* for scrolling */
background-image: -webkit-linear-gradient(rgba(0, 255, 255, .75) 1px, transparent 1px);
background-image: -moz-linear-gradient(rgba(0, 255, 255, .75) 1px, transparent 1px);
background-image: linear-gradient(rgba(0, 255, 255, .75) 1px, transparent 1px);
}
/* Debugging */
body:hover * {
background: none !important; /* removes all backgrounds */
outline:1px dashed rgba(100%,0%,0%,.5); /* red dashed outline around elements */
}The biggest change is the switch from .baseline to simply body. The way I'm using it now is by dropping the class in the stylesheet, or in the Dev tools, and commenting it on/off. However I understand that the way you're using it is more modular so that it can be dropped in different elements; in which case I do agree that having the baseline class, along with the line-height classes, is the way to go.
While testing it at work the bottom: -1px was adding an empty pixel at the bottom which I found a little annoying. I guess if the height of the page matches the grid then it would make sense but overall I didn't think it was necessary. Now, since those properties were setting the height I had to add height:100% I don't know how this will affect other browsers yet.
This version includes the on hover switch. I'm still getting used to it, it's not all that versatile since every time I scroll it shows the grid even if I don't want to, unless I use the keyboard. However it is very nice not having to switch on/off the grid via comments, I simply hover out of the window and it's gone. I'll continue using it for now.
Oops, Just saw your other comment. Thanks for the links!
Hi Carlos!
I was gonna suggest the same. Pointer events is awesome but as you mentioned it is not fully supported. After thinking more about it I think the css3 switch may not be such a good idea, it'd be cool but it would have to be added as markup as well making this grid solution more annoying. However one option would be to turn it on/off via :hover.
Yah, that seems to make sense to me too! Thanks updated code snippet, that's pretty cool! I'm going to play with it now. :)
The biggest change is the switch from .baseline to simply body. The way I'm using it now is by dropping the class in the stylesheet, or in the Dev tools, and commenting it on/off. However I understand that the way you're using it is more modular so that it can be dropped in different elements; in which case I do agree that having the baseline class, along with the line-height classes, is the way to go.
Interesting! I haven't completely committed my workflow to "modules"… I'm kinda trying to build something I can use for a simple personal site, to something that I can adapt to a larger newspaper website with lots of coming/going news content… For my personal site, the <body> approach makes a lot of sense, but for my work's site, the modular approach seems way more sane. :D
While testing it at work the bottom: -1px was adding an empty pixel at the bottom which I found a little annoying. I guess if the height of the page matches the grid then it would make sense but overall I didn't think it was necessary. Now, since those properties were setting the height I had to add height:100% I don't know how this will affect other browsers yet.
That makes sense… I had added the extra pixel because the last line of the baseline would not show when applying it to "modules" on the page. I had not tested thoroughly on the <body> tag. :(
This version includes the on hover switch. I'm still getting used to it, it's not all that versatile since every time I scroll it shows the grid even if I don't want to, unless I use the keyboard. However it is very nice not having to switch on/off the grid via comments, I simply hover out of the window and it's gone. I'll continue using it for now.
That's cool! I was kinda getting tired of commenting out the CSS (or adding an x in front of the class name).
I'm looking forward to testing your code. :)
Idea: Multiple colored baselines. Say you want to have the .75em baseline but would like to see how the elements line up to the true 1.5em bl.
Check it out:
In this case I've added 1/4, 1/2 and the full baseline. I think one can work on improving the colors but you get the idea.
In this case I've added 1/4, 1/2 and the full baseline. I think one can work on improving the colors but you get the idea.
WHOA! That's AWESOME!!!!!!!!!!!!!!
Carlos, you ROCK!!!! :)
I can't wait to test the latest version of your code (thanks for updating the gist).
The following is mostly a rant that i need to get out of my head regarding the concept of a baseline grid on the web.
I need some more feedback on the overall idea of baselines in websites. I love the concept but perhaps it's too impractical. I think it may be worth the amount of work it takes but I don't think it's something that can be easily implemented into any site. And while creating a boilerplate such as BaselineCSS.com is a noble idea I often find myself needing more options which are often limited by a boilerplate. Perhaps a boilerplate for something such as this is just not justifiable. Maybe all we can do is give advice on how to do certain things and some steps to follow but not a modular solution that can be just copy n pasted.
Programs such as InDesign make the idea of a baseline easy as it automatically shifts the text to sit ON the baseline, but unless this is possible via JS, one would resort to a faux baseline where elements don't actually sit on it OR a few hours of work to figure out how much each element should be offset, e.g. top:.15em. Now, offsetting the text will only work when the design stays as it was delivered which may not be ideal in all situations, say if you worry about people zooming in/out, there may be some discrepancies. Now perhaps that's going too far and it's unnecessary, idk. I can see someone making the argument that it should always work; which, as we know, it's sometimes nothing more than wishful thinking in our world.
For now I have accepted that obeying a true baseline is not practical. However we CAN resort to a one half/third/quarter sub-baseline. Where we can make sure that the spacing between elements follows AT LEAST some pattern and will at some point, depending on the length of the page, fall back within the 'true' baseline.
I would like to emphasize the idea of a 1/3 sub-baseline (let's call it that for now) Perhaps this allows some more flexibility in some cases and it works fairly well if one uses a 24px baseline.
Nonetheless an implementation of this kind will require some researches and deep involvement with the site. Taking an existing site and updating it to follow a baseline may(most likely) not be possible overnight and in some cases it will require some deep reconfiguration of the CSS which, in turn, will result into a whole lot of work depending on the number of pages.
Thoughts?
SATURDAY REPLY:
Hi Carlos! Just FYI, I'll be back later tonight with some thoughts. :)
MONDAY UPDATE:
Ugh, sorry Carlos, the weekend got away from me. :(
I plan on replying more thoroughly as soon as I can find some time to break away from my day job duties... In the meantime, I was wondering if you have a demo, or demos, of the BLG experiments you've been working on? I'd like to see where you've been successful vs. where you think you haven't (or, at least see examples of the sticking points you've run into).
Also, not sure if this will be of any help, but I've recently realized that some folks are using "modular scale" instead of a baseline grid. Some links/examples:
Baseline grid or modular scale? Both? Neither?
Specifically, Joni's reply:
I use both of them. Here's how.
- I pick a base font-size and line-height.
- I create a baseline grid based on the line-height.
- I create a modular scale based on the font-size.
- I round (or "snap") the results from the modular scale to fit the baseline grid, much like Gridlover does.
Two special things I do with the baseline grid:
- I rarely use just line-height as the unit. Instead, I split it: (line-height/2), (line-height/3) or (line-height/4). I think of this as changing the "resolution" of the baseline grid. Here's an example of Aen Tan applying this method to iOS: aentan.com
- I use this split baseline grid horizontally too. It's great for determining things like paddings for buttons and widths for columns.
This site offers a useful tool:
From what I have learned:
- Related ALA article here.
- Ignore
% of 13unless you're using YUI fonts/resets (more info here). - Important number:
I’ve found that a variety of things can serve as an important number. The size at which caption text looks best, for instance, or a large number like the width of a piece of media—if the project at hand mandates ads or embedded videos, for instance—ensures that something about those elements resonates with the layout as a whole.
– More Meaningful Typography
Other good reads (found linked to from the modularscale.com website):
With all that said, modular scale is, obviously, not a new term/concept... I just wanted to mention it in this thread of ours, as a "scale" could be used in place of (or, in conjunction with) a baseline grid; the beauty of, from what I understand, using a modular scale is that the focus is more on using numbers that fit on the chosen scale vs. line up on a particular baseline.
Me personally? I still like using a baseline grid. Though, admittedly, my experiments have been focused on lining up "modules" on "local" baselines; I think I'd go crazy if I had to line up elements to a global baseline.
Also, there's something about using just a modular scale that doesn't appeal to me... I can't put my finger on it yet, but my gut is telling me to stick with the baseline (and utilize the modular scale when needed).
The key words (concepts?) for me have been "local" and "modules".
Anyway, not sure if you'd be interested, but here's what I've been working on:
There's not much there as I haven't had a ton of free time to work on it... Day job and all. :D
I have yet to impliment the new version of your baseline CSS, and I've been wanting to change the baseline when I get down to "mobile" sizes. In other words, I have a lot more work to do.
If you scroll down to the bottom of the demo page, you can see an example of a "local" baseline "module".
If you view this css (also posted below), you can see where I was playing with a "local" modular scale for the heading tags (96px being the "important number", which is the largest heading size).
/**
* Represent headings and subheadings. These elements rank in importance
* according to the number in their name. The `<h1>` element is said to
* have the highest rank, the `<h6>` element has the lowest rank, and two
* elements with the same name have equal rank.
*
* Note: The `.h1`-`.h6` classes should be used to maintain the
* semantically appropriate heading levels.
*
* Attention: Classes NOT for use on non-headings.
*
* @see https://groups.google.com/d/topic/object-oriented-css/GE1uzU2Bu48/discussion
* @see http://www.stubbornella.org/content/2011/09/06/style-headings-using-html5-sections/
* @see https://github.com/stubbornella/oocss/blob/master/core/heading/heading.css
* @see http://csswizardry.com/2012/02/pragmatic-practical-font-sizing-in-css/
*/
h1, .h1, h2, .h2, h3, .h3, h4, .h4, h5, .h5, h6, .h6 { margin: 0; }
/**
* (16px = base font size) * (6 heading levels) = (96px = "important number")
* Scale: 1:2 octave.
*
* @see http://modularscale.com/scale/?px1=16&px2=96&ra1=2&ra2=0
*/
h1, .h1 {
font-size: 6em; /* 96px */
line-height: 1.2; /* 7.2 / 6 */
}
h2, .h2 {
font-size: 4em; /* 64px */
line-height: 1.35; /* 5.4 / 4 */
}
h3, .h3 {
font-size: 3em; /* 48px */
line-height: 1.2; /* 3.6 / 3 */
}
h4, .h4 {
font-size: 2em; /* 32px */
line-height: 1.8; /* 3.6 / 2 */
}
h5, .h5 {
font-size: 1.5em; /* 24px */
line-height: 1.2; /* 1.8 / 1.5 */
padding: .6em 0; /* 1.2 / 2 */
}
h6, .h6 {
font-size: 1em; /* 16px */
line-height: 1.8; /* 1.8 / 1 */
padding: .9em 0; /* 1.8 / 2 */
}NOTE TO FUTURE READERS: All of my repository related links, and code, may change over time as I work on things.
I have to get back to work for now. Not sure if any of what I have said is helpful to your endeavors; I mostly wanted to point out the modular scale as an alternative (or, an addition to) baseline grids.
I'll be back if I think of anything else... I'll hopefully have some time this weekend to continue working on my baseline experiments (and, in turn, have something more meaningful to contribute to this conversation). :)
Have an awesome day!
Cheers,
Micky
Hey man, sorry I haven't gotten back to you. I'll try to do so over the weekend.
Hey! No rush at all! I know how that goes. Take your time. :)
Hey Micky,
Thanks a lot for those links, I def agree with Joni's comment. That's exactly what I was going for in my previous comment. Not sure I would call it baseline resolution but that's a minor detail.
I can't say I've been working a lot on this lately. I took some time to work on a small js project but I'm trying to keep an eye on this as well.
Btw, nice job on the bassline project and thanks for putting me in the credits ;) One thing you may want to keep an eye on are the list items. I understand that for baseline purposes it makes sense to make them as even as possible; however from a readability point of view, I think it's better to emphasize the difference between items. This can be achieved by adding top/bottom margin to the lis. In the project I had been working on I added half the baseline which worked nicely with the model I had. At work we made the line height tighter so that we wouldn't need to add as much margin. I think so far you don't have that problem but neither did I at the beginning ;)
Hey did u hear about the new plans for CSS? I can't wait to get my hands on the parent selector.
[http://coding.smashingmagazine.com/2013/01/21/sneak-peek-future-selectors-level-4/]
Anyway, let me know how your project is going.
Oh hey, one more thing. On the hover switch for the baseline, here's something you may wanna try. This will activate the outline from the third child on, leaving the body and top most elements untouched, in some cases it works well, you may wanna add another asterisk.
body:hover * *:hover{background:none !important;outline:1px dashed rgba(100%,0%,0%,.5)}
Thanks a lot for those links, I def agree with Joni's comment. That's exactly what I was going for in my previous comment. Not sure I would call it baseline resolution but that's a minor detail.
Great minds think alike! :)
I can't say I've been working a lot on this lately. I took some time to work on a small js project but I'm trying to keep an eye on this as well.
Ditto. Pretty much the same boat here. I've been back and forth working on various projects myself.
Btw, nice job on the bassline project and thanks for putting me in the credits ;)
Lol, I was hoping you wouldn't mind the shout out.
Not that my repo is useful to anyone other than myself ... I just wanted to make sure anyone stumbling along GitHub would know where (and who) to look for when it comes to all the juicy details. :)
One thing you may want to keep an eye on are the list items. I understand that for baseline purposes it makes sense to make them as even as possible; however from a readability point of view, I think it's better to emphasize the difference between items.
Oh, good tip! Yah, I was having some issues with my lists for sure (especially at the mobile sizes).
This can be achieved by adding top/bottom margin to the lis. In the project I had been working on I added half the baseline which worked nicely with the model I had. At work we made the line height tighter so that we wouldn't need to add as much margin. I think so far you don't have that problem but neither did I at the beginning ;)
Interesting! I think I understand.
Just to clarify, are you saying that you like to put more space between list elements (say, more than the line-height that's applied to <li> items)? Sorry, I guess I'm having a hard time visualizing.
Actually, I ended up boosting my overall font-size/line-height to 16px/28px:
Base font size = 16px or 100% or 1em.
Base line height = 28px or 175% or 1.75em.
... because I was having issues with the 24px line-height for when it cames to things like <code>. I kinda like the airiness of 28px.
Hey did u hear about the new plans for CSS? I can't wait to get my hands on the parent selector.
[http://coding.smashingmagazine.com/2013/01/21/sneak-peek-future-selectors-level-4/]
Oooh, sick! I had not seen that article or read anything about CSS4. Thanks for linkage!
Anyway, let me know how your project is going.
Sure thing. Ditto.
I'm actually going to apply some of these concepts to a larger site over the next few weeks; I have my fingers crossed. I'll let you know how it goes. :)
Btw, not sure if you'd find this interesting, but the 2012 Wordpress template is using vertical rythm:
http://core.trac.wordpress.org/browser/trunk/wp-content/themes/twentytwelve/style.css
Looks like they're using a CSS preprocessor to do some of the math. That's my long-term goal is to convert my bassline project into LESS/SASS/other (and Grunt.js or Yeoman or other), so I can automate the math!!! That would make life so much easier! :D
Keep me posted and I'll do the same.
Cheers,
Micky
I kinda got derailed from ems and baselines:
That's awesome! I'm looking forward to using it in the coming weeks. :)
(P.S. I've tried commenting in the last week and there was something wrong on GitHub's end ... Sorry for my late reply.)
@cballenar: AWESOME!!!! You ROCK!
Thank you so much for the help, replies and links!
Your CSS3 gist/code is the best baseline height background technique I've seen. No images = kick butt.
In fact, I was just playing around with
<hr>using the same technique (thanks to you for the inspiration):With the above code, I was trying to see if I could fit my
<hr>s on a100.1%/1.5em(16px/24)font-size/line-heightbaseline. Seems to work OK, but I haven't tested in any other browsers other than Firefox/Mac.Coincidentally, within the last hour, I just started coding a very similar document to your 4310311 gist! Before starting, I had Googled around looking for a starting point, just like what you had posted! Thanks so much for sharing your code, it'll really save me some thinking time. :)
Thanks for pointing out the
code,subandsupelements... I'll check that out. Seems like I've seen/read about the last two always giving folks troubles (I rarely use those elements myself). Hmm, have you played around withnormalize.css? Whatever the case may be, it seems like a0line-heightwould be a good solution... Heck, if it works, it works!Thanks again for posting code and helping me/others out... It's much appreciated. :)