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

Questions regarding strong and em #23

Closed
alexjab opened this issue Mar 18, 2017 · 2 comments · Fixed by #24
Closed

Questions regarding strong and em #23

alexjab opened this issue Mar 18, 2017 · 2 comments · Fixed by #24

Comments

@alexjab
Copy link

alexjab commented Mar 18, 2017

Hi,

I'm trying to wrap my head around an issue I'm encountering with **strong** and *emphasised* texts: they are just rendered as vanilla paragraph text on my system, instead of the expected strong and italic text.

I've noticed that the css rules specifically reset the font property of the strong and em tags (in css/base.css, and also later on for strong), and use bold and italic fonts instead (Open Sans Bold, and Open Sans Italic). While this works well on the Mapbox API page because the aforementioned fonts are served to the visitor, I'm afraid most developers would not want to do the same.

I'm not sure I understand the reason behind this choice, rather than just using vanilla properties of the tags.

Several tweaks may do the trick:

  • don't reset rules for strong and em (or maybe do font-family: inherit instead of font: inherit),
  • remove the font-weight: normal for .strong.

What do you think ?

BR

tmcw added a commit that referenced this issue Mar 18, 2017
This fixes a bug that remains in base.css, where it used explicit font family names and classes

instead of relying on the browser to associate faces with styles.

Fixes #23
@tmcw
Copy link
Owner

tmcw commented Mar 18, 2017

Yeah, sorry about this. This is the result of an still-present bug in base.css, where it used web fonts incorrectly, in a systematic way that spread the problem around.

I've just implemented #24, which should fix this issue - can you check it out and see if it resolves the problem?

@alexjab
Copy link
Author

alexjab commented Mar 18, 2017

Done ! LGTM !

@tmcw tmcw closed this as completed in #24 Mar 18, 2017
tmcw added a commit that referenced this issue Mar 18, 2017
This fixes a bug that remains in base.css, where it used explicit font family names and classes

instead of relying on the browser to associate faces with styles.

Fixes #23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants