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

Bold Code And Normal Code Look The Same #455

Closed
Mehran-Baghi opened this Issue Sep 12, 2017 · 13 comments

Comments

Projects
None yet
3 participants
@Mehran-Baghi

Mehran-Baghi commented Sep 12, 2017

Description

The result of these markdown lines are the same:

**`Bold Code`**
`Normal Code`

Expected behavior

Fresh MkDocs Installation:
mkdocs

Actual behavior

Material for MkDocs:
material

Steps to reproduce the bug

Use the markdown in the description.

Package versions

  • Python: Python 2.7.13
  • MkDocs: mkdocs, version 0.16.3
  • Material: Version: 1.10.0

Project configuration

Not Relevant

site_name: My Docs
theme: 'material'

System information

  • OS: [Debian GNU/Linux]
  • Browser: [Not Relevant]
@facelessuser

This comment has been minimized.

Show comment
Hide comment
@facelessuser

facelessuser Sep 12, 2017

Contributor

Project configuration, specifically extensions, may or may not be relevant. I would post them anyways, at the very least the extension setup, and extra if you adding any custom CSS.

Most likely though, this is how styling is applied. I assume a base style is applied to code blocks and then the provided Pygment's style augments the base. I would provide the config regardless so it can be investigated further in case you are configuring things in an unexpected way.

I'm not sure I would consider wrapping the code block in bold and not getting bold a bug. This may just be due to an assumption that doesn't hold true with this theme. Just because one theme handles things one way, does not mean all themes will handle things the same.

Contributor

facelessuser commented Sep 12, 2017

Project configuration, specifically extensions, may or may not be relevant. I would post them anyways, at the very least the extension setup, and extra if you adding any custom CSS.

Most likely though, this is how styling is applied. I assume a base style is applied to code blocks and then the provided Pygment's style augments the base. I would provide the config regardless so it can be investigated further in case you are configuring things in an unexpected way.

I'm not sure I would consider wrapping the code block in bold and not getting bold a bug. This may just be due to an assumption that doesn't hold true with this theme. Just because one theme handles things one way, does not mean all themes will handle things the same.

@Mehran-Baghi

This comment has been minimized.

Show comment
Hide comment
@Mehran-Baghi

Mehran-Baghi Sep 12, 2017

Thank you @facelessuser for your time.
I have provided my configuration in issue report:

site_name: My Docs
theme: 'material'

That is all of it.
Did you have any problems with reproducing?

I'm not sure I would consider wrapping the code block in bold and not getting bold a bug. This may just be due to an assumption that doesn't hold true with this theme.

It depends on whether that assumption was a conscious choice or not. If the theme author consciously decided to make bold and normal code blocks look the same, I would be just disagree.
Otherwise I would suggest that bold code blocks be rendered as bold code blocks.

Mehran-Baghi commented Sep 12, 2017

Thank you @facelessuser for your time.
I have provided my configuration in issue report:

site_name: My Docs
theme: 'material'

That is all of it.
Did you have any problems with reproducing?

I'm not sure I would consider wrapping the code block in bold and not getting bold a bug. This may just be due to an assumption that doesn't hold true with this theme.

It depends on whether that assumption was a conscious choice or not. If the theme author consciously decided to make bold and normal code blocks look the same, I would be just disagree.
Otherwise I would suggest that bold code blocks be rendered as bold code blocks.

@Mehran-Baghi

This comment has been minimized.

Show comment
Hide comment
@Mehran-Baghi

Mehran-Baghi Sep 12, 2017

Bold code blocks are actually very useful and necessary. For example I'm currently working on converting a book into markdown. There are lots of computer science books that are using typographical conventions. Please take a look at this pdf, page 3, Conventions Used in This Book.

Mehran-Baghi commented Sep 12, 2017

Bold code blocks are actually very useful and necessary. For example I'm currently working on converting a book into markdown. There are lots of computer science books that are using typographical conventions. Please take a look at this pdf, page 3, Conventions Used in This Book.

@facelessuser

This comment has been minimized.

Show comment
Hide comment
@facelessuser

facelessuser Sep 12, 2017

Contributor

That's fine, but all that is happening is that the code block is then wrapped in strong tag. Normally that will make its content bold unless a style is then applied to the code block directly that overrides it. See below. This is inspecting a code block under the Material theme.

screenshot 2017-09-12 12 00 17

This isn't unheard of. The idea of giving each element a known understood base, in this case, code, pre, and kbd have their text styling normalized to a consistent state with a font weight of 400. After that, a language style rule can then apply bold italic or color as dictated by the Pygment's color scheme provided.

So Material seems to intentionally apply a common base font weight to code blocks despite what their parent element may be styled as.

I personally feel the code block being code is emphasis enough. I'm not sure I see the benefit of emphasizing the whole code block further with bold, but that is most likely just me.

I believe this could be forced by appending custom CSS via the mkdocs extra_css option as I believe those appended CSS styling rules would come after the default Material styling.

I'm going to guess that @squidfunk will not remove the default font-weight, but only he can answer that. So I would suggest pursuing some custom CSS overrides when a code block is wrapped with strong.

Contributor

facelessuser commented Sep 12, 2017

That's fine, but all that is happening is that the code block is then wrapped in strong tag. Normally that will make its content bold unless a style is then applied to the code block directly that overrides it. See below. This is inspecting a code block under the Material theme.

screenshot 2017-09-12 12 00 17

This isn't unheard of. The idea of giving each element a known understood base, in this case, code, pre, and kbd have their text styling normalized to a consistent state with a font weight of 400. After that, a language style rule can then apply bold italic or color as dictated by the Pygment's color scheme provided.

So Material seems to intentionally apply a common base font weight to code blocks despite what their parent element may be styled as.

I personally feel the code block being code is emphasis enough. I'm not sure I see the benefit of emphasizing the whole code block further with bold, but that is most likely just me.

I believe this could be forced by appending custom CSS via the mkdocs extra_css option as I believe those appended CSS styling rules would come after the default Material styling.

I'm going to guess that @squidfunk will not remove the default font-weight, but only he can answer that. So I would suggest pursuing some custom CSS overrides when a code block is wrapped with strong.

@squidfunk

This comment has been minimized.

Show comment
Hide comment
@squidfunk

squidfunk Sep 12, 2017

Owner

Hey guys, I intentionally defined the code block the same weight as normal text and only load the 400 weight via Google fonts. We can also append weight 700 to the loading directive, didn't think someone wants to use it.

Owner

squidfunk commented Sep 12, 2017

Hey guys, I intentionally defined the code block the same weight as normal text and only load the 400 weight via Google fonts. We can also append weight 700 to the loading directive, didn't think someone wants to use it.

@Mehran-Baghi

This comment has been minimized.

Show comment
Hide comment
@Mehran-Baghi

Mehran-Baghi Sep 12, 2017

Thank you both.
@squidfunk that makes sense. I guess loading another weight through the google fonts increases the page load time.

Mehran-Baghi commented Sep 12, 2017

Thank you both.
@squidfunk that makes sense. I guess loading another weight through the google fonts increases the page load time.

@squidfunk

This comment has been minimized.

Show comment
Hide comment
@squidfunk

squidfunk Sep 12, 2017

Owner

That was my initial concern, but we can add it, as it should be cached anyways.

Owner

squidfunk commented Sep 12, 2017

That was my initial concern, but we can add it, as it should be cached anyways.

@Mehran-Baghi

This comment has been minimized.

Show comment
Hide comment
@Mehran-Baghi

Mehran-Baghi Sep 12, 2017

I don't think it worth it. I'll try to find some workaround for emphasizing the code blocks.

Mehran-Baghi commented Sep 12, 2017

I don't think it worth it. I'll try to find some workaround for emphasizing the code blocks.

@Mehran-Baghi

This comment has been minimized.

Show comment
Hide comment
@Mehran-Baghi

Mehran-Baghi Sep 12, 2017

I set the

extra:
  font: false

option and still got the problem. shouldn't turning the google fonts off fix the problem?

Mehran-Baghi commented Sep 12, 2017

I set the

extra:
  font: false

option and still got the problem. shouldn't turning the google fonts off fix the problem?

@squidfunk

This comment has been minimized.

Show comment
Hide comment
@squidfunk

squidfunk Sep 13, 2017

Owner

Hmm, theoretically yes. I have to check when I find the time.

Owner

squidfunk commented Sep 13, 2017

Hmm, theoretically yes. I have to check when I find the time.

@squidfunk

This comment has been minimized.

Show comment
Hide comment
@squidfunk

squidfunk Sep 14, 2017

Owner

Fixed in 1.10.1, but there's currently some problem on Travis with the release that I have to go into before I can release it.

Owner

squidfunk commented Sep 14, 2017

Fixed in 1.10.1, but there's currently some problem on Travis with the release that I have to go into before I can release it.

@squidfunk squidfunk reopened this Sep 14, 2017

@Mehran-Baghi

This comment has been minimized.

Show comment
Hide comment
@Mehran-Baghi

Mehran-Baghi Sep 14, 2017

I'm not sure whether this is relevant or not but I had some issues with yarn start and yarn run build. Also I wasn't able to commit because of a githook that executes the yarn run flow. I have investigated the problem and I found out that yarn bin returns nothing if get executed inside of a script that yarn run executes. So my workaround was to execute the scripts manually and also editing the githook

Mehran-Baghi commented Sep 14, 2017

I'm not sure whether this is relevant or not but I had some issues with yarn start and yarn run build. Also I wasn't able to commit because of a githook that executes the yarn run flow. I have investigated the problem and I found out that yarn bin returns nothing if get executed inside of a script that yarn run executes. So my workaround was to execute the scripts manually and also editing the githook

@squidfunk

This comment has been minimized.

Show comment
Hide comment
@squidfunk

squidfunk Sep 14, 2017

Owner

No, it was some problem with urllib, a dependency of twine which is used to upload the release to PyPI. It is fixed now and released.

Owner

squidfunk commented Sep 14, 2017

No, it was some problem with urllib, a dependency of twine which is used to upload the release to PyPI. It is fixed now and released.

@squidfunk squidfunk closed this Sep 14, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment