Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jekyll's default font-weight of 300 causes bold/strong text to be indistinguishable from regular text on IE11 and Firefox #4042

Closed
i-give-up opened this issue Oct 17, 2015 · 14 comments · Fixed by #4050

Comments

@i-give-up
Copy link
Contributor

Specs:

  • OS: Windows 8.1 64-bit
  • Jekyll version: 2.5.3 (the current main.scss is also using the same font-weight of 300).
  • Browsers affected: IE11, Firefox 41, Palemoon 25

By "default", I mean the CSS used by the site when you run jekyll new

The issue is that the default browser stylesheet in IE11, Firefox 41, Palemoon 25 (probably other versions too but these are the ones I have) defines the font-weight property of b and strong as bolder. So if the inherited font-weight is 300, that means b and strong will have a font-weight of 400. (c.f. "Meaning of relative weights"). Fonts like Arial doesn't show any visual difference between font-weights 300 and 400.

If inherited font-weight is 400, then bolder would be 700.

Chrome is unaffected because its default stylesheet defines b and strong with font-weight: bold.

I think there are 2 approaches to resolve this issue

  • change default font-weight to 400 in main.scss
  • define the rule font-weight: bold for b and strong in _base.scss
@envygeeks
Copy link
Contributor

Maybe we should use normalize.css which does do that. /cc @jekyll/core

@parkr
Copy link
Member

parkr commented Oct 17, 2015

Not a huge fan of the idea of further bloating this site template with something like normalize.css if we can get around it. If we can't, then ok. How much does it weigh?

@kleinfreund
Copy link

If a font-weight is specified with a numeric value because of certain webfonts being used (e.g. loading the 400 and 700 style of the font), other properties that might be specified by various user agents should be overridden.

One approach for this would be introducing Sass variables like $font-weight-regular: 400 and $font-weight-bold: 700 and use these for b, strong and h[1-6] (if headings are bold in the template) or just hardcode the values.

@parkr
Copy link
Member

parkr commented Oct 18, 2015

Could we use the relative values, like lighter, normal, and bolder instead of the numerical values?

Browsers are the worst, aren't they? 😉

@parkr parkr added the Bug label Oct 18, 2015
@kleinfreund
Copy link

The issue here is that we would be doing some unnecessary guesswork then. We could use normal and bolder, if by chance the resulting value of bolder is the same as if it was specified with a numeric value.

So it's possible, but it's not as straightforward as with numeric values.

@envygeeks
Copy link
Contributor

There is no guesswork to bolder, as long as there is a gap the spec states that bolder is relative to the inherited font-weight. If you set the default font-weight to 900 and leave no gap, that's not guesswork, that's bad design on your part (this is theory -- not fact.) That said, we aren't doing that so there is no problem. We should be using bolder and lighter after we set a default font-weigh and if we choose not to use normalize.css (which I would prefer instead because it will make things cleaner for all.) Then bolder and lighter is what I would personally use.

@alfredxing
Copy link
Member

So after doing a bit of reading, it seems to me that there isn't a solution using bolder and lighter? Those are both relative to their parents, so if we set paragraph styles to lighter, bold text with bolder would still be normal weight... Even then, lighter relative to normal weight is 100 rather than 300 according to MDN.

@envygeeks
Copy link
Contributor

@alfredxing I guess you are right, I just read the font-weight doc just now to double check and font rendering in Firefox is absolutely broken, which is ironic because just above that table that highlights their bad rendering, they clearly state the spec "step one forward or one backward"... I don't even honestly know what to say.

I also just double checked that some how I got the spec wrong but in Chrome if I set the font-weight to 300 and set strong to bolder it sets the font-weight of strong to normal (400) so it is Firefox doing whatever they see fit for some reason.

@envygeeks
Copy link
Contributor

Well... I guess that is unless somehow there is some information missing, like that's how it treats some system fonts which might not have that many weights so it's still working like that. Then it's understandable but should (if it already hasn't?) change.

@alfredxing
Copy link
Member

The best solution at this point (if we aren't considering using a webfont—see #3921) might be to just use 400 as the default font weight.

@parkr
Copy link
Member

parkr commented Oct 22, 2015

@alfredxing Have time for a PR?

@stragu
Copy link

stragu commented Nov 29, 2015

Is there a workaround for people using Jekyll <3.x ?

rvf0068 added a commit to rvf0068/pagina-olimpiada that referenced this issue Dec 3, 2015
@alexconst
Copy link

@stragu A late reply, but I recently came across this very annoying bug myself and this is how I fixed it.
Edit _sass/_base.scss either the one in your project or the one at /var/lib/gems/2.1.0/gems/jekyll-2.4.0/lib/site_template/ and replace the multiple occurrences of font-weight: 300; to font-weight: 400;.

@stragu
Copy link

stragu commented Jan 12, 2016

thank you, @alexconst !

@jekyll jekyll locked and limited conversation to collaborators Feb 27, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants