So much for “the venerable OpenID”


Remember just three weeks ago I was ranting about how MDN assumes you use GitHub and forces you to use it to log in without providing any alternatives? Remember I mentioned “the venerable OpenID”?

Turns out it wasn’t so venerable after all. OpenID 2.0 was superseded by OpenID Connect (which is based on OAuth 2.0, a different kind of “auth”) some years ago, and providers have slowly been removing support for OpenID 2.0 over the last couple of years. Yesterday Stack Exchange was the latest to announce that they were dropping OpenID 2.0 support:

Stack Overflow was an early and strong supporter of OpenID. We built our sign up/log in flow around it. We were idealistic and had high hopes, but these hopes weren’t realized. Over the years people have wondered if OpenID is dead. We’ve had to remove support as OpenID providers pulled support or shut down.

The time has come to part ways. The reality is OpenID support has created a ton of complexity in our codebase and the number of users actively using OpenID simply don’t justify that cost. Users have spoken with their actions. You prefer Google, Facebook and Stack Exchange (aka email/PW) based account auth.

To be fair, even I don’t use OpenID to authenticate with Stack Exchange anymore. But that’s because several years ago, I switched from using my OpenID to authenticate with Stack Exchange, to using Stack Exchange as my primary OpenID provider. So, in a weird twist of irony, I’m impacted not in my access to Stack Exchange, but in my access to other sites via Stack Exchange OpenID.

Note that my change of provider had nothing to do with OpenID 2.0’s already ongoing demise; it was just a matter of moving to a provider I felt was more appropriate for my needs, since I’d stopped actively blogging @ I would continue using Stack Exchange OpenID for as long as OpenID 2.0 remained around, because Stack Exchange stated they’d continue supporting it for as long as they remained in existence as a company.

Of course, things are different now. With the OpenID 2.0 protocol being made obsolete by the OpenID Foundation itself, there really is no obligation for Stack Exchange to continue supporting their OpenID service. So I’m not going to accord them any blame. It’s entirely my fault for somehow completely missing the memo on this whole thing. Perhaps Stack Exchange’s decision to drop OpenID was the wake-up call I needed after all.

Good thing I’ll have the next quarter to work on migrating my accounts on sites where I’m using Stack Exchange OpenID to authenticate. I know that I can just switch back to OpenID, but let’s face it, it’s only a matter of time before Automattic follows suit.

Before I go, let me be clear on my views of all this:

I finally joined GitHub

You read that right: I’m finally on GitHub, after about a decade of inaction (yes, it’s been around that long). This must come as a very strange shock to you, seeing how every other self-respecting developer and their rubber duck has a GitHub account. How could I not?

Simple: I just never felt a need to make one. I’ve never had any open source projects to host using Git (I’ve historically been a Subversion and Mercurial user in the last decade), the one and only Git project I do maintain is privately hosted on VSTS, and I’ve never been compelled to make a pull request.

So why now? Well, recently I was getting tired of MDN being blatantly wrong on certain things (I’ve had to correct it about a dozen times on Stack Overflow), so I decided I’d finally take matters into my own hands and edit it myself. That’s when I discovered that a GitHub account was required, I kid you not, to sign into MDN because Mozilla had discontinued Persona.

Yes, a “reason” to make a GitHub account that had literally nothing to do with GitHub itself, let alone Git. Needless to say, I didn’t make an account there and then, because I thought that was incredibly asinine (what ever happened to distributed SSO solutions like the venerable OpenID?).

But now I have one, because I remembered last night that CodePlex had shut down last December and I had totally forgotten to migrate the one and only project I had on there. So I spent the better part of today migrating my WPF sample WPFDraggableFrame to GitHub (it’s still archived on CodePlex, but I still have my local working copy so that’s what I used). In other words: doing actual Git and GitHub things on GitHub.

Because CodePlex’s Mercurial servers have been taken offline, I wanted to see if I could host my repository on my site so I could use GitHub Importer to automate the process. Unfortunately, this resulted in many wasted hours for something that could have easily been done in 10 minutes. The binaries were there on my server, I could do things on the command line via SSH, I could clone the repository off of my site by having Mercurial fall back to static HTTP, but of course that wasn’t a Mercurial server. My host A Small Orange then told me that their KB article claiming that Mercurial is available on shared servers is outdated, which is a shame, but it’s shared hosting so I’m not super bummed about it.

So I ended up doing everything manually. Since I use Mercurial via TortoiseHg, hg-git, which TortoiseHg comes with, makes light work of the process of actually converting the Mercurial repository into a Git one. I did, however, have to run the Git repository through git filter-branch to change the author details for all the commits so as to ensure they’d be tied to my GitHub account when pushed. As expected, these two steps were done in 10 minutes. I now have an 18-hour-old GitHub repository with commits dating back more than 5 years.

I’m not actually done migrating the sample — if you look closely, the documentation still references CodePlex (God I miss it already)! — but right now I just want to do things other than source control/housekeeping. Maybe dinner, maybe shower, maybe video games. But the migration will definitely be wrapped up before the end of the day.

I don’t expect to be an avid GitHub user by any stretch of the imagination, but now that I have an account, I might as well start using it.

Should you stop using CSS selectors for non-CSS?

After writing about whitespace in CSS selectors on Thursday, I was chatting to my friend Tyler that night about CSS in general when we were reminded of CSS-Tricks, which we hadn’t visited in a while. So we paid it a visit, I scrolled through the home page, and I saw an article linking to a retweet of this tweet of some slides by Julie Cameron about modular CSS (phew, what a mouthful!):

One of the slides says


I like using data attributes…

and my first thought was holy blanket statement. My second thought was well, looks like I have my second article about Selectors already!

Now, like Chris Coyier, I know better than to judge an opinion by two out-of-context slides, but being a huge fan of Selectors, I thought I’d write an article of my own to deconstruct the slides piece by piece and examine their context and the underlying premise they’re advocating, because I think there’s an interesting discussion to be had here.

Before I do that, I recommend reading Chris’s article, as he does a good job explaining the general idea behind the slides objectively. What follows is more in-depth, and certainly more opinionated as well. I’ll also be answering some of the questions he posed in his article.

Be careful with whitespace in CSS selectors

If you know me, you probably know that I love CSS, and you may know that Selectors are my specialty. This is the first of, I guarantee, many articles about Selectors to come.

A number of weeks ago, I came across this question. It contains a line of CSS that looks like this:

.responsive  * :not(.fixedSize,.fixedSize *){max-width:100%;}

Notice the rather sloppy placement of whitespace:

  1. Two spaces before the first *, which is not a big deal, but still an unusual sight.
  2. One space after the first *, before the :not() pseudo-class. That’s a big deal.
  3. The complete and utter lack of whitespace between the selector and declaration block, and within the declaration block, a stark contrast to the mess of whitespace in the selector.

Why is #2 a big deal? Because in selector syntax, whitespace that separates any two simple selectors is a descendant combinator. This includes the universal selector *. Think of it like this: in much the same way that

#id .cls

matches any .cls descendant of #id,

* .cls

matches any .cls descendant of, well, any element. In other words, any .cls element that has an ancestor (effectively excluding :root.cls). And since pseudo-classes are simple selectors just like type, class and ID selectors,

* :not(.cls)

likewise matches any :not(.cls) element that has an ancestor.

Compare the example selectors above with these ones:


Removing the space results in

  1. a selector matching any element with both the respective ID and class name,
  2. a selector matching any element with the respective class name, and
  3. a selector matching any element without the respective class name.

Notice that there’s no mention of ancestors or descendants. That’s because I removed the descendant combinator!

Also, as you might have guessed by comparing the second and third examples, yes, you don’t actually need the * in front of a pseudo-class. Just like class and ID selectors, as well as pseudo-elements, the * can be left implicit.

Which leads me to another interesting point: while the spec does recommend adding the * in some cases to improve readability:

Note: In some cases, adding a universal selector can make a selector easier to read, even though it has no effect on the matching behavior. For example, div :first-child and div:first-child are somewhat difficult to tell apart at a quick glance, but writing the former as div *:first-child makes the difference obvious.

… if you read that note in the context of this article, suddenly it takes on a completely different meaning!

So, be careful with whitespace when writing CSS selectors! Whitespace generally doesn’t change the meaning of a selector anywhere else, but when the syntax expects you to chain your simple selectors as tightly as possible, it means it.

Here are some related Stack Overflow answers of mine you may be interested in:

Migrating to HTTPS

Last November, it was my domain’s sweet sixteen!

As a birthday gift, I got my site its very own SSL certificate, courtesy of DigiCert through their Microsoft MVP offer, and as of this week my site has now been fully transitioned to HTTPS!

SSL (Secure Sockets Layer) is an Internet security standard that enables encrypted communication between your browser and a website, preventing attackers from eavesdropping on or even tampering with information. This is more important for sites that collect sensitive information such as government and e-commerce sites, and less so for personal sites, but as SSL certs become more accessible and affordable I don’t see any reason for me not to secure my site, so, here I am!

In this entry I’ll be sharing my personal experience of obtaining and signing a certificate, setting it up on my server, and migrating both static and dynamic content on both the main domain and its subdomains.

As this is about my own experience, this will not be a comprehensive how-to covering all the various ways of setting up HTTPS on your site (though I’ll cover some ground in the overview), but I hope you learn something about the process in general. This being my first ever experience with SSL certificates as a server administrator, I certainly learned a whole lot!