Use a lighter style for <kbd>

[Xenonym]

What is the purpose of this pull request? (put "X" next to an item, remove the rest)

• [X] Enhancement to an existing feature

Fixes #532.

What is the rationale for this request?
The current style for <kbd> is white on black text, which gives it too much contrast relative to its surrounding content:

What changes did you make? (Give an overview)
The style of <kbd> was changed to use a lighter, black on white style instead:

Provide some example code that this change will affect:

<kbd>Ctrl</kbd> + <kbd>C</kbd>

Testing instructions:

1. Use the <kbd> tag on a MarkBind page. It should render with the new, lighter style.

[yamgent]

Actually, I am not so sure whether it is good to include it in asset/css/markbind.css (which will affect all MarkBind websites), rather than in docs/css/main.css (which will only affect our documentation website).

I am fine with the current way as it is, unless there's some objection similar to above.

[Chng-Zhi-Xuan]

Although not in the scope of this PR, should we support both light and dark themed <kbd>?

I feel its ok to override the <kbd> style in markbind.css since MarkBind websites are initialised with a white background, it blends in with the updated Bootstrap 4 colour styles as well.

[yamgent]

I feel its ok to override the <kbd> style in markbind.css since MarkBind websites are initialised with a white background, it blends in with the updated Bootstrap 4 colour styles as well.

👍

Although not in the scope of this PR, should we support both light and dark themed <kbd>?

That can be considered, although I am not an expert in css so I was wondering what you had in mind for that kind of implementation. I was thinking that if the author is going to use their own styles.css, they will be overriding the <kbd> with their own anyway.

[Xenonym]

@yamgent it would be pretty straightforward to have a white or black class for <kbd> and have the user pick using <kbd class="white">. However, I feel that the default CSS we include in MarkBind should be just providing sensible defaults, and not be including multiple variations for elements. As you say, the user can easily override these defaults on their own.

[acjh]

Theming files might be better. See discussion in #386.

For example, we could put this override in a theme-light.css and include it by default.
However, author should be able to remove it so that one theme file will not affect another.
As mentioned in #386, there should not be much code change as it's just including CSS.