I too thought I was going crazy when I noticed it this morning... Funny, but that shade (or one very much like it) is forever etched into my brain as "porn blue" thanks to a k10k issue back in the day when the internet was still referred to as the information super highway and nobody knew what we were doing. Here's an excerpt from the first "lesson":
You must never use this colour.
You can like it as much as you want.
You can buy a dress in this colour for your girlfriend.
Your mum might have it as the colour of her eyes.
Feel free to paint your house like it.
But never use it on a website. Never.
This colour is the porn colour.
You must never copy the porncolours.
2005 wasn't that long ago. I thought the press stopped using the term "information super highway" in the 90s. But in case thanks for share that, it was an amusing read.
I think that particular issue is older though, I'd guess 1999 or 2000. If I recall correctly people were still going on about the information super highway around that time, along with very literal illustrations of "surfing the web." 2005 is just when the snapshot is from I think.
I believe that's the reference right there. Porn sites, along with most other sites, were usually not quite as spiffy as they are these days. Aside from some creative hot spots that really overdid it with the GIFs (geocities 4 life!) most sites were typically just browser defaults with perhaps some changes to background colors, maybe add a nifty tiled background image and such. Web design (not to mention development) was quite different back in the late nineties, early naughts, than what it's like now – the default blue link color was everywhere.
This whole issue is effectively a sarcastic response to that lack of design, and referring to the default blue as "the porn color" I read to mean "don't be cheap and stick with the defaults; don't be a porn site."
The joke doesn't age very well, but it was really funny back then.
It's "blueprint blue" - a reference to the cheap printing process used to make the posters for pornographic films, and also the reason they got the nickname "blue movies."
I don't share the disgruntled feeling toward the color.
The new color is #0366D6, while the old color is #7FA5CF. The new blue color is far more saturated and is much less light, but is actually still a pretty big step down from ultra-hard blue #0000FF. IMO, it's much more readable than the previous blue and stands out nicely.
I think we should give it a few months to see if the fact that it doesn't look good is inherent to the color or just because we've become accustomed to it looking one way for so long. I can't count the number of interface redesigns I've seen in services I used that I hated at first and now I look back at the old design and can't fathom how I ever thought it was better.
And if colorblind people aren't inconvenienced (and don't have to navigate to a menu to de-inconvenience themself) then that's enough of a reason for me.
Side note: I'm surprised there isn't a specific header browsers could send for something like colorblindness. That would allow sites to react to that header and serve up a different stylesheet.
Isn't that what the accept header is for? Telling the server what content types you're willing to accept, including relevant parameters. Something like:
Accept: text/css; color-blind=trichromatic
Of course no server would recognize this today, since afaik the CSS media type doesn't define any parameters other than perhaps `charset`, but the mechanism is there at least. Also any self respecting web server would just ignore the parameter so it shouldn't break anything, just cost a few more bytes of bandwidth I guess. No need to invent a new header I don't think.
Why not have colorblind mode be the default? Much more courteous to make the nitpickers change their mode than casual browsers who just want to be able to use the site.
In the same way that turning up the volume helps people who are hard of hearing to hear. Colorblindness is a spectrum, not a switch; many people who suffer from it simply have reduced sensitivity to a color. I'm mildly colorblind myself; I can see green, but I can't see it as well as you can.
I'm slightly grey-green colorblind, and if you make text standard CSS green (#008000) I sometimes have trouble telling that it's actually green and not dark grey. If you make it just a little more green (say #00A000) it's much easier for me to see.
That's not how colorblindness works. Green things aren't invisible to colorblind people. They just can't discriminate some colors from others as well. I would guess that this color is more different from the body text in some color channel that's extra useful for contrast for colorblind people.
That and the eye-seering blue draw too much attention for what they are. Content is de-emphasized. Whole page is slightly harder to read. I don't understand these changes at all.
SSO is important for enterprise.. but github presents a challenge where devs usually have pre-existing personal accounts which are added to company github accounts, rather than the company account being used.
Well, won't that require a different identity? My personal email account is funny-nickname@gmail but my work email is my-real-name@work. Github used to allow/encourage multiple identities but then changed it because it was super confusing and hard to manage. Maybe they've fixed that now. :/
They fixed some awkward "custom routing" screens a while ago. I've been using my single account with different companies for years now. I just make sure my git `config.email` is set right, set GitHub to route notifications for work repos to my work email, and it's done.
I've also been the admin on those Business accounts. It's easy.
That's what people used to do before because there were no good options to provision separate work accounts for people. With the new for business model I'm guessing we'll see people being issued work accounts and keeping their personal GitHub accounts completely separate, which might be a good thing.
Developers have the same identity no matter who they work for.
It makes sense to separate access ("this person has access to Example Corp's repos only as long as they work for Example Corp") from identity ("this person owns this account").
Introducing single-sign-on as one way to simplify login, and potentially as a second-factor for gaining access to repositories run by the business, makes sense. Making developers create entirely separate accounts doesn't.
But it's not just about having access to example corp. If I log in to GitHub from my work laptop then my company technically has access to my personal GitHub account and the repos of any other organization I happen to belong to. It goes the other way around to. If an attacker hacks my personal laptop and I'm logged into GitHub then they have access to all of my companies repositories.
There are perfectly valid reasons for segregating accounts so that there is complete separation between them.
It does if I am logged in on a company laptop and they control access to that laptop. (This is hypothetical in this case, I happen to know that the particular company I work at does not have any backdoors on my laptop).
It is the first scenario not the second. The person is gaining access to the GitHub organization via SAML SSO. They are bringing their own identity and do not lose access.
I would really just love to be able to group my repositories. Either logically in folders, or in another structure that cleans everything up. Tags help, but it is not enough.
I am happy that they continue to add features like this, but I feel like some of the more common wishlist items are not being addressed.
Yes - and there's also the fact that you have to get everyone on the same page with tags. It isn't as simple as just moving something where it belongs.
the new "topics" feature is basically just tags as far as i can tell.
you can use the "user:" search operator + the name of the topic to filter your repos and then just bookmark the searches that youll be using often. its better than nothing for now
It's a little frustrating to see that Github is holding SAML hostage with a more expensive business plan. SAML integrations should be par for the course with any SaaS solution.