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

Remove 'variants' #601

Closed
wants to merge 1 commit into from
Closed

Remove 'variants' #601

wants to merge 1 commit into from

Conversation

@raboof
Copy link
Member

@raboof raboof commented Oct 1, 2020

In the sources there are 2 'variants' defined for fonts, and 3 for brightness
(light/dark/darker).

Do we plan to expose those at some point, or would it be a simpler to
get rid of them?

(the background is I'd like to look into self-hosting the fonts, but right now
it's not clear whether it makes sense to port all fonts or just the ones that
are used in 'variant A')

In the sources there are 2 'variants' defined for fonts, and 3 for brightness
(light/dark/darker).

Do we plan to expose those at some point, or would it be a simpler to
get rid of them?
@samueldr
Copy link
Member

@samueldr samueldr commented Oct 1, 2020

See #508 for fonts; the choice hadn't been made yet.

For the time being, since the goal is to self-host the fonts (thanks) just prepare the files for the variant in use, and document any non-straightforward thing you had to do to get self-hosting done. If we end up going over fonts choice (as we should have beforehand) hopefully we (me) can just pick the appropriate files.

Keep the variant-B styles around, if only so we can remember which fonts goes where. Since it's not compiled down into the CSS output it's free except in maintainer cognitive load (and then it's basically not an issue).

@samueldr
Copy link
Member

@samueldr samueldr commented Oct 1, 2020

For any other kind of variants: don't remove any.

(Though I see it's only been done for the navbar.)

They are not present in the compiled CSS (if they are it should be fixed).

This is something you couldn't have known as it came from internal talks about implementing this, but we might end up using variants under some circumstances.

An example might be the Mobile NixOS website would use the same foundation for the site by importing the nixos homepage repository, but configure the darker menu rather than the lighter menu.

Same for the search site, it's not totally decided what is going to happen exactly, but it might be using variants that are not in use on the main site.

@raboof
Copy link
Member Author

@raboof raboof commented Oct 1, 2020

See #508 for fonts; the choice hadn't been made yet.

Yeah, saw that (I'm partial to the 'Source Sans Pro + Open Sans' option myself) - still we don't really need variants for that, we can just change it when we make the decision (possibly prototyping it in a branch).

This is something you couldn't have known as it came from internal talks about implementing this

Yeah, I figured as much - I didn't know where to bring it up and a PR seemed like a reasonable place to do it ;)

it's free except in maintainer cognitive load (and then it's basically not an issue).

I think maintainer/contributor cognitive load is important :) - but if we see a potential use for them in the near(ish) future I'll close this PR 👍

@raboof raboof closed this Oct 1, 2020
@samueldr
Copy link
Member

@samueldr samueldr commented Oct 1, 2020

And for completeness' sake, this was done that way during development to allow other contributors to trivially test the two proposed font stacks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

2 participants