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 borders from several UI elements #1017

Closed
saschanaz opened this issue Oct 18, 2019 · 14 comments
Closed

Remove borders from several UI elements #1017

saschanaz opened this issue Oct 18, 2019 · 14 comments

Comments

@saschanaz
Copy link

image

Currently several borderless elements e.g. .markdown-body code, .merge-pr-more-commits, .commit-ref etc. are bordered. This seems to be from older GitHub styling, maybe we should update them?

@saschanaz saschanaz added the bug 🐛 Something isn't working label Oct 18, 2019
@the-j0k3r
Copy link
Member

the-j0k3r commented Oct 20, 2019

@saschanaz I believe those are intentional and not an opinionated intrusive change.
That said, if this is something you rather not see, feel free to use something like this.

/* ==UserStyle==
@name           GitHub Border Elements
@namespace      StylishThemes
@version        1.0.1
@description    Remove borders added to opinionated borderless GitHub elements.
@author         StylishThemes

@var checkbox enableBorders "Enable borders" 1

@preprocessor stylus
==/UserStyle== */
@-moz-document regexp("^https?://((gist|guides|help|lab|launch-editor|raw|resources|status|developer)\\.)?github\\.com/((?!generated_pages/preview).)*$"), domain("githubusercontent.com"), domain("graphql-explorer.githubapp.com"), domain("www.githubstatus.com") {
  if ( enableBorders == 0 ) {
    html body .markdown-body code,
    html body .merge-pr-more-commits,
    html body .commit-ref,
    html body .commit-link tt {
			border: 0 !important;
		}
	} else { 
    html body .markdown-body code,
    html body .merge-pr-more-commits,
    html body .commit-ref,
    html body .commit-link tt {
			border: inherit;
		}
	}
}

If you find any more selectors please let me know so I can add them to the style.

@the-j0k3r the-j0k3r added wontfix 💔 custom style posted 🎨 and removed bug 🐛 Something isn't working labels Oct 20, 2019
@saschanaz
Copy link
Author

I'm not saying it's opinionated, I said it's likely to be from older GitHub style and then not updated later. (Because older GitHub style indeed had the exact same border.)

@the-j0k3r
Copy link
Member

the-j0k3r commented Oct 20, 2019

Could very well be but it seems purposeful though old a44670f + gives the elements more contrast and I like that symmetry.,in any case you have an optional out by using the style posted, I rather keep this as is here

@saschanaz
Copy link
Author

Hmm, okay. Feel free to close this then.

@the-j0k3r
Copy link
Member

the-j0k3r commented Oct 20, 2019

Sure, but the offer still stands, if you find particular selectors you would like to follow the default style post them. These styles we create like the one posted inline above, to service our users needs will have a home and will be maintained be auto updatetable etc.

See the tags and #1008

@Mottie
Copy link
Member

Mottie commented Oct 20, 2019

Hmm, I feel like we should keep the design consistent. I personally would remove the border. What do you think @silverwind?

@xt0rted
Copy link
Member

xt0rted commented Oct 20, 2019

I'm all for keeping this style as close to the original as possible, but doing that with these elements makes them much harder to see, at least with the current colors being used (even worse at night when using f.lux/nightlight/night shift).

I don't recall the branch labels ever having a border with the default style. As far back as 2014 these were light blue without a border (there was a drop shadow though) and before that they were black.

Inline code blocks used to have a border but I don't see value in removing it now. I've actually updated mine so they use a different text color which helps them stand out even more.

@the-j0k3r
Copy link
Member

I'm all for keeping this style as close to the original as possible, but doing that with these elements makes them much harder to see

Yes thats the issue exactly, I say keep it as is, my eyesight isnt 20/20 and also with cheaper screens the contrast will be even worst.

@saschanaz
Copy link
Author

doing that with these elements makes them much harder to see

For inline code blocks, background color #2a2a2a seems to work for my screen with night light.

@the-j0k3r
Copy link
Member

For inline code blocks, background color #2a2a2a seems to work for my screen with night light.

Key words, for your screen

@saschanaz
Copy link
Author

Key words, for your screen

Exactly. What do you think?

@the-j0k3r
Copy link
Member

the-j0k3r commented Oct 21, 2019

I think I would make the code blocks darker than the comment background and keep the borders as is for added contrast. Contrast is key.

On My desktop I have a great 27inch 4K screen running 2560x1440, I dont really have issue on this screen, but my laptop doesnt have a nice expensive screen and its 1920x1080 not only are things much smaller and colors more washed out (as its not IPS screen) for a 14 inch screen , so even at best much of the contrast of these and other elements is almost lost as is.

While I normally am all for keeping things close to default styles as possible, in some cases like this its better to improve on the original design and make it better.

@the-j0k3r
Copy link
Member

@saschanaz updated inline style to workaround style not showing in stylus popup depending on checkbox value.

@the-j0k3r
Copy link
Member

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

No branches or pull requests

4 participants