Today is the deadline for all Microsoft MVPs to update their profiles with their latest contributions, before the annual renewal cycle begins. It’ll be my first time through the rigorous process, and only time will tell if I’ll make the cut for another year!
If you’ve somehow been following blog.NOVALISTIC since the launch of NOVALISTIC 5.0 “Veldin” back in the tail end of 2015, you may have noticed two things:
Posts have been extremely sporadic, averaging out on a rather low frequency over the course of 24 months.
Posts have so far remained sporadic, but with a noticeable change in topics frequently covered, over the last quarter.
That’s me broadening my horizons as a newly awarded Microsoft MVP after having focused all my efforts solely on Stack Overflow (not at its expense though, don’t worry!). It’s been a very slow start, for sure. I’m still adjusting to the process. Writing compelling content is not easy, but very rewarding especially when you are passionate about the subject matter.
But, I’m told, even when I’m starting small, every post counts. That’s why I’m still listing every technical post I’ve published on my MVP profile, even though I only really started this quarter. In fact, I’m listing this very entry too, since it’s about my site, and it does contain some technical content, so I figured I’d let Microsoft decide if it counts!
Anyway I digress. NOVALISTIC, on a fundamental level, is a personal site, a showcase for not only the work I’ve done and my passion in all things web, but also my other hobbies and interests, tech-related or otherwise. And blog.NOVALISTIC is an extension of that, not the other way around. In the nearly 11 years I’ve been blogging at this domain, I’ve always written about whatever I felt like writing at the time, because I had something to say about it. And if I didn’t feel like writing at all, I’d just… not write.
But that’s writing on a whim about anything I feel like; not writing concrete content to be consumed, learned from, and shared by a specific target audience, which is what I need to be doing if I want my technical content to be discovered and perused.
I spent the last week reflecting, reading articles online, and of course talking to fellow MVPs, and here’s what I’ve come to realize and embrace: I don’t need to sacrifice sharing about my other interests in favor of writing compelling technical content. Yes, it’s probably still a million times better if I can keep all my technical content on a separate domain or something. But running multiple separate sites is a pain especially for the expectations I have of my blog, which are not astronomical (remember, it’s a secondary aspect of my online presence, not the primary aspect).
I don’t care about having a large number of subscribers, I’m not going to try and eke out every last drop of SEO juice from each post (although I’m planning some significant changes to the overall layout to aid in that), and I don’t have to let other topics get in the way because individual posts reside in their own URLs for search engine crawlers to index, and for the good folks at Microsoft my technical content will always be aggregated on and accessible from my MVP profile.
For starters, I can afford to keep throwaway off-topic fluff to a minimum, because I kinda already do that. Years ago I used to make really short posts, known in the WordPress blogosphere as “asides” (to the extent that some themes, including one I made, even came with special formatting for them). You don’t really see those anywhere anymore, other than on Matt Mullenweg’s blog. Ask any web developer in this day and age what an “aside” is and they’ll tell you all about the HTML aside element.
What matters most to me is putting out content that’s useful to others, while still retaining my multi-disciplinary individuality that my site, and my blog, were meant to embody. Because these two goals don’t have to be mutually exclusive. The “content is king” mantra doesn’t have to be restricted to one category of topics. Any topic, work or play, can be made either an entertaining and/or educational read, or a waste of time.
And because my passion for all things web is one of the things that make me who I am. Both “just one” and “very much one”, if that makes sense. My tribute to Internet Explorer from 2016 is as heartfelt as it sounds, and HTML and CSS have been my lifeblood since I was little. But I’m more than just someone who loves the web platform. I love the web platform, I love sharing about it, and then some. That’s what, I feel, makes me an MVP, and I hope Microsoft agrees.
By the way… one of the emails I received from my regional MVP lead regarding the renewal cycle reminded me of a very timely coincidental thing I’ll be blogging about very soon (see what I did there?). Here’s a clue for fellow MVPs reading this: it has to do with Betsy Weber, or at least, one of her interests. Stay tuned!
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 WordPress.com 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 @ WordPress.com. 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 WordPress.com 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 don’t have anything against OAuth 2.0. I think it’s a great protocol and you’re cool for implementing it. OpenID Connect itself is based on OAuth 2.0. But it’s an authorization protocol, not an authentication protocol. A site has you log in to a third-party site (authentication), and give it permission to use your existing credentials (authorization) to identify yourself and/or light up integrated features that wouldn’t work (as richly or at all) without an account on the third-party site. You still actually need the third-party account, otherwise you won’t be able to use those features, or the entire site in the case of sites that completely rely on your identity with that particular third-party site…
… which was exactly the problem OpenID was trying to solve, and why I still strongly disagree with tying accounts on one site to only one other site via OAuth 2.0. There are hundreds of email providers out there, and no independent site I’m aware of requires you to use exactly one or even two known email providers (obviously Google has every reason to restrict any of its services to Google Accounts, Microsoft to Microsoft accounts, and Apple to Apple IDs, as they see fit), so I don’t see why decentralized identities and authorization is such a big ask. I’m not asking for hundreds of sites — even two providers would be a good start. But I feel that only one arbitrary provider is too restrictive, no matter how much you think that everybody should have an identity on that site already.
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?).
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.
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!):
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.
Two spaces before the first *, which is not a big deal, but still an unusual sight.
One space after the first *, before the :not() pseudo-class. That’s a big deal.
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:
#id.cls
*.cls
*:not(.cls)
Removing the space results in
a selector matching any element with both the respective ID and class name,
a selector matching any element with the respective class name, and
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.
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: