modularscale / modularscale-sass

Modular scale calculator built into your Sass
http://www.modularscale.com
MIT License
1.98k stars 132 forks source link

Possible Bug: Using ems or rems when body font-size is 100% #118

Closed jackmcconnell closed 8 years ago

jackmcconnell commented 8 years ago

I can't be sure if this is a bug yet or not but I thought I'd post here anyway and see if we can't work out what's going on together.

Basically, I'm trying to follow some best practices and have applied a font-size of 100% to the body with a line-height of normal as recommend in this article.

I've always used pixels for my modular scales but wanted to change to rems as I feel browser support is pretty good these days. Choosing ems or rems (it makes no difference at this point) to set my sizes using a modular scale, I opted for testing this with a rather boring scale starting at 1em using the ratio of 1.125. This should equate to 1em equally to the 100% body font-size set earlier which is set by the browser (Safari on Mac in my case) at 16px. Nice and straight-forward. The 'normal' line-height that the browser uses equates to 18px, which is 16px x 1.125 (co-incidentally my chosen modular scale ratio).

I'm using a mixin on the html tag that overlays a baseline grid of the desired line-height onto the page. My desired line-height is ms(4) or 1.602rem (25.629px), where my desired font-size is ms(1) 1.125rem (18px) which I set on the p tag along with a bottom margin of ms(4) (1.602rem, 25.629px) so that the next paragraph starts neatly on the next baseline.

It all sounds good: the maths add up (to me anyway) and everything should just fall into place. Coupled with ems in media queries, this should make for a nicely responsive site with a root on the body font size.

Unfortunately, the baseline grid just doesn't line up. I've tried every permutation of scales, changing margins and line-heights, etc. and the only time I can get the paragraphs to line up is when I manually input 1.65rem as the margin and line-height on them - a number which doesn't exist on my scale. I have found however, that everything works perfectly when I use 16px as my $ms-base font-size instead of 1em. When I change it to this, everything lines up and of course, my em media queries don't change because the root is still 16px (1em).

As a test, to ensure the the scale is being generated correctly, I have outputted all of the sizes and they are identical on both my site and the modular scale website (although my site shows more decimal places).

The only thing I can think of, unless I am totally missing something crucial to this idea, is that there's a bug in the modular-scale sass plugin.

Do you have any ideas on why this might be happening? Am I missing something?

Thanks for any help in advance, Jack

scottkellum commented 8 years ago

I usually advise against the use of baseline grids in web design as it is the path to madness. There are a few, but very few, cases where they are actually useful.

Second, just so we are on the same page, is this similar to what you have? http://www.sassmeister.com/gist/d8765b69ff243cafee8b

I can say is that there will be rounding errors on rounded things, although that might not explain the extent of the issues you are seeing.

jackmcconnell commented 8 years ago

Hi @scottkellum - thanks for your reply.

After some experimentation, it certainly looks like browser rounding has a part to play here. I think that each time a value is being rounded, it's compounding the problem. An absolute unit (such as a pixel) is giving accurate measurements every time however.

After playing around with the function found on this Stack Overflow thread, I'm getting things to line up better. Not perfect, but certainly closer to what I'm expecting.

Is it worth implementing a similar function in the modular-scale Sass plugin so that it displays results that align with those shown on modularscale.com? I.e. values with 3 decimal places only?

scottkellum commented 8 years ago

@voltronik You can adjust rounding precision in your compiler. I’ll think about including a precision setting in the plugin itself.

Is there any particular reason you need everything to be pixel-perfect to match your baseline grid? As I said in my first response, I’m not a big fan of them on the web as they are almost always totally useless for a variety of reasons.

jackmcconnell commented 8 years ago

Thanks @scottkellum. Ok, I've just tested this by rounding to 1 decimal place and the whole thing is still way out. It shouldn't be that far out being that the whole thing, when converted to px units, works perfectly so i can't see why rounding is the issue here.

In fact, when taking some screenshots, I'd say it looks more aligned with more decimal places than less. In Safari anyway.

I've always used a baseline grid to help when building sites in code. I never expect pixel perfection when moving from Sketch to Safari but I do try and do the closest job that I can.

scottkellum commented 8 years ago

@voltronik If you still think it’s a bug and can replicate it in code I’d love to see what you are working with. Unfortunately I can’t make numbers with infinite decimal places work but if you think the problem is deeper than that please provide a code example so that I can replicate the issue.

kaelig commented 8 years ago

Have you tried using calc to define the font-size in IE? It fixed rounding errors for me in the past.

Edit: here's the code that fixed the bug in the past:

html {
  font-size: 112.5%;
  font-size: calc(1em * 1.125);
}
jackmcconnell commented 8 years ago

@kaelig Not sure how this would help as I'm using Safari? Also not sure how practical or maintainable it would be to do all font-sizes across the Sass file like this either.

@scottkellum I suppose I'm having a hard time understanding how rem or em units that have a directly translatable pixel value are causing rounding issues when using those converted pixel values aren't? Does the browser interpret an em value differently to how I'm expecting?

scottkellum commented 8 years ago

@voltronik Some notes on number rounding in the context of grids: http://ejohn.org/blog/sub-pixel-problems-in-css/

As soon as you round a number it looses it’s direct relation to a pixel counterpart and has to be rounded to get close to the nearest pixel, hopefully it aligns with the one you want. While ms(1) is a pixel value other values on your scale will not be integers and thus subtle differences may tip them to round either up or down when rendered on your page.

Again, I would love to replicate this to gut check if it’s an issue in my code as opposed to rounding but the formula for calculating values is simple and straightforward so that is why I am hesitant to blame that logic for the issue.

jackmcconnell commented 8 years ago

Thanks @scottkellum. After much trial and error, it looks like it is indeed a rounding issue but not in modular-scale - in the browser.

I experimented with easily translatable rem / em units with a px baseline and, using a calculator, inputted numbers until I started to notice things go out and sure enough, as soon as a decimal place is introduced, things started moving out of alignment.

After spending so much time in Sketch making everything look nice and lining up, you kind of want your build to go the same way. I know it's all relative, but by the end of a long page, the spacing can be significantly out, adding several hundred pixels to the bottom. Not ideal but something I'll have to live with if I want to switch from px to rem (which I do) I guess.

Thanks very much for your help in trying to work out what the issue was - pleased it's not a bug with modular-scale 😊 An update on #93 would be good though!

kaelig commented 8 years ago

@kaelig Not sure how this would help as I'm using Safari? Also not sure how practical or maintainable it would be to do all font-sizes across the Sass file like this either.

Ah, sorry. This is what fixed rounding issues for me on theguardian.com when we were overriding the root font size.

jackmcconnell commented 8 years ago

@kaelig Ah, I see. Thanks.