DEV Community: Ken Bellows

String.prototype.search(): a method I wish I knew about a long time ago

Ken Bellows — Tue, 23 Jun 2020 17:13:03 +0000

tl;dr: String.prototype.search() is basically .indexOf() but with regexes. It's been supported in every browser since IE 4, but ES6 made it more powerful with Symbol.search.

I have been writing JavaScript for just about 18 years. I started sometime in 2002, when IE 6 was king, Firefox was just being released, and Chrome did not exist.

I've been writing JavaScript for almost two decades, and I've always been someone who loves digging into the docs, learning every feature available, every method of every object in the browser. But sometimes... sometimes I still, after all this time, find something that's been around for a long time and I just didn't know about.

Today I discovered one such method: String.prototype.search(). And man, I wish I had known about this one a loooong time ago.

What it does

The .search() string method is pretty straightforward: as I mentioned in the tl;dr, it's basically .indexOf(), but with one crucial difference: it uses regular expressions!

Here's the demo from the MDN page. It demonstrates how you would find the first non-whitespace, non-alphanumeric character in a string:

const paragraph = 'The quick brown fox jumps over the lazy dog. If the dog barked, was it really lazy?';

// any character that is not a word character or whitespace
const regex = /[^\w\s]/g;

console.log(paragraph.search(regex));
// expected output: 43

console.log(paragraph[paragraph.search(regex)]);
// expected output: "."

This blew my mind when I saw it. Not because it's necessarily that crazy, but just because I never knew it was available to me. I have hacked together this method countless times over the years using the clunkier, less readable String.prototype.match(). This method works, and it's my go-to solution when I want capture groups and all that, but for simply finding the index of the first instance of a certain pattern in a string, .search(regex) is just so clean. For one, to me at least, it's immediately obvious what's happening here, whereas the .match() method always took me a minute to understand. For another, .match() requires extra processing, because it has three kinds of return values:

if it doesn't find a match, it returns null
if it finds a match:
- if your regex had the global flag (/.../g, like in MDN's example above), it returns an array of all matches, and there's no way to get their indices
- if your regex did not have the global flag, it returns an object with an index property

So .match() gets complicated.

Another option that I sometimes use is RegExp.prototype.exec(). This has the advantage that it always returns an object with an index property when it finds a match, regardless of the global flag, but the disadvantage that you still need to be careful about the global flag if you want to run it on multiple strings, because it starts searching from the index of the previous match. This can be useful sometimes, but isn't great in the simple case.

Just to drive this point home, here's the side-by-side comparison:

// old way
const match = paragraph.match(regex)
const index = match ? match.index : -1

// new way
const index = paragraph.search(regex)

I don't know. I get really excited about stuff like this. Maybe you don't. But if that didn't excite you, maybe this will:

How ES6 made it even more powerful

The way I came across String.prototype.search() was kind of funny. I was looking over the README for Paul Miller's fantastic polyfill library, ES6 Shim, and I noticed this in the "Caveats" section at the bottom:

Well-known Symbols

In order to make them work cross-realm, these are created with the global Symbol registry via Symbol.for. This does not violate the spec, but it does mean that Symbol.for('Symbol.search') === Symbol.search will be true, which it would not by default in a fresh compliant realm.

If that makes no sense to you, let's do a 30-second crash course on Symbols. If it did make sense, skip the next section.

A brief aside about Symbols

This will be a very quick overview, so if Symbols still don't make a ton of sense to you after this, I highly recommend doing some googling, because they're pretty important for leveling up in JS (IMHO).

Symbols are a new primitive type introduced to JavaScript in ECMAScript 2015, a.k.a. ES6. The basic idea behind them is to create a perfectly unique key to use as an object property name, so that it's impossible for someone else to accidentally clobber your property later by using the same name, especially on shared objects and global window properties. Before Symbols, it was common to see keys on shared objects with lots of leading underscores, stuff like ___myThing, or with a randomly generated prefix, like 142857_myThing. This may seem like a rare edge case if you haven't encountered it, but trust me, this has been a source of frustration many times in JS history.

For your standard, garden-variety Symbols, created with Symbol('foo'), no one but you has access to them unless you pass them around. However, there is a special set of so-called "well-known Symbols" that everyone has access to. You can create your own by registering a name in the global Symbol registry with Symbol.for(), as mentioned in the quote above, but there are also several well-known symbols defined by the browser as properties on the Symbol object. These are used as special property names that enable certain functionality for objects.

Perhaps the most famous is Symbol.iterator, which lets us define custom iteration behavior for our classes, which is then used by the spread syntax and the [for ... of loop] to iterate over our object. I wrote a whole post about ES6 iterators and how they relate to generators a while back, if you're interested in a deep dive on this topic (it gets pretty wild when you dig deep):

The JavaScript Iteration Protocols and How They Fit In

Ken Bellows ・ Dec 27 '18 ・ 12 min read

#javascript #es2015 #es6 #intermediate

Okay, hopefully we all have at least enough understanding to follow the rest of the story here.

Back to the story

After reading the note in the Caveats section of ES6 Shim, my question was, "What the heck is Symbol.search for?" I had never encountered this particular well-known Symbol before, so I read the MDN page on Symbol.search, which in turn led me to String.prototype.search.

I've already gotten a bit long-winded here, so to wrap up quickly, the bottom line is this: when you call myString.seach(x), the engine checks whether the thing you passed in, x, has a method defined under the key [Symbol.search]. If not, it tries to convert to a RegExp by calling new RegExp(x), which only works for strings.

(Side note: The MDN page is misleading here. It says: "If a non-RegExp object regexp is passed, it is implicitly converted to a RegExp with new RegExp(regexp)." But as we'll see next, this is not strictly true; it will not convert to a RegExp if you pass an object with a [Symbol.search] property.)

So what this means for us is that we can write a custom string search function and wrap it in an object. This may seem niche, since you can always just pass the string to the function, and this is certainly true. But something about the syntax feels nice to me:

// Find the index of the first character following a string like:
//    "Name:\t"
const nameFinder = {
  [Symbol.search](s) {
    const result = /Name:\s*/.exec(s)
    if (result) {
      const {0: label, index} = result
      return index + label.length
    }
    else {
      return -1
    }
  }
}

// imagine this was read in from a file
const doc = `Customer Information
ID: 11223344
Name:   John Smith
Address:    123 Main Street
...`

const customerNameStart = doc.search(nameFinder)
const customerName = doc.slice(customerNameStart, doc.indexOf('\n', customerNameStart))

Imagine looping over a directory of customer info files in a Node script trying to extract their names, reusing this same search object each time, even storing the name finder and similar finders for other fields in a separate module and importing them. I think it could be neat! (Just me?)

Conclusion

Honestly, I recognize that this is not super revolutionary or anything, and it probably won't change a lot of workflows. But to me, that isn't the important thing; what's most important to me is to know what tools are available. I honestly don't know when I would use a customer search object like the one above, but I think it's very cool that it's an option. And now that that I know about it, if I ever come across a situation where it really is useful, I'll have it in the back of my head. It's another Batarang on my utility belt.

(Also, I just think metaprogramming stuff like this is really cool 😎)

Endnote

Thanks if you read all this! It's niche, I know, and I get more excited than most devs I know about little things like this. But if you got excited about this article, let me know in the comments, or shoot me a DM!

What's your preferred Node.js testing setup?

Ken Bellows — Thu, 16 Jan 2020 16:13:46 +0000

I'm currently working on building a new Node.js application from the ground up at work. This is the first time I've done this for anything other than a personal side project, and I'd really like to do it right.

In pursuit of that goal, I want to introduce unit and integration tests early on in the process, but I don't have much (read: any) experience with unit tests in Node, so I'm not sure what all is out there. I've used Jasmine for AngularJS apps in the past, and while that was... rough, to say the least, I think that was more Angular's fault than Jasmine's, and I liked working with Jasmine overall. I've also heard good things about Mocha, though I've never done more than a couple toy examples myself. And I guess there's this thing called Jest that has popped up recently as well?

Are these frameworks still applicable in the server-side world? Are there newer, better frameworks I should be aware of?

How about for testing database interactions? I'd like to set up a harness that will run our migration scripts to build a little SQLite database on the fly for testing, something like that; is that the best approach?

I'm relatively new to this kind of testing, and I know we have some very experienced DEVs here, so any advice would be very welcome!

I'd also be happy to read any other articles that have been written on related subjects, so feel free to drop links!

Thanks in advance! 🙏😁

My confusions about TypeScript

Ken Bellows — Fri, 03 Jan 2020 16:23:47 +0000

I have heard endless good things about TypeScript in the last couple years, but I've never really had a chance to use it. So when I was tasked with writing a new API from scratch at work, I decided to use the opportunity to learn TypeScript by jumping into the deep end.

So far, here are my positive takeaways:

I'm a huge fan of the added intellisense in my IDE (VS Code). I've always found the intellisense for regular JavaScript packages to be a bit flaky for some reason, but it's rock solid with TypeScript.
The "might be undefined" checks have definitely saved me some time by pointing out places where I need to add a few null checks after .get()ing something from a Map, etc.
I have always liked being able to spell out my classes in JavaScript; I've often gone to extreme lengths to document JS classes with JSDoc.

But I've run into a few significant frustrations that have really slowed me down, and I'm hoping some of my much more experienced TypeScript DEV friends will be able to help me figure them out! 😎

Class types

I can't figure out how to use or declare class types, especially when I need to pass around subclasses that extend a certain base class. This came up for me because I'm using Objection.js, an ORM package that makes heavy use of static getters on classes. I need to pass around subclasses of Objection's Model class to check relationship mappings and make queries, so I need a way to say, "This parameter is a class object that extends Model". I wish I had something like:

function handleRelations(modelClass: extends Model) ...

The best I've found so far is to use a rather annoying interface and update it every time I need to use another method from Objection's extensive API, like:

interface IModel {
  new(): Model
  query(): QueryBuilder
  tableName: string
  idColumn: string | string[]
  relationMappings: object
  // etc.
}

function handleRelations(modelClass: IModel) ...

This works, but it's rather annoying to have to reinvent the wheel this way. Is there a more explicit way to tell TypeScript, "I mean a class extending this type, not an instance of this type"?

Overriding methods with different return types

This is more a best-practice question than anything else. I've run into some cases where a base class declares a method that returns a particular type, but subclasses need to override that method and return a different type. One example is the idColumn static getter used by Objection models, which can return either a string or a string[].

I've found that if I simply declare the base class as returning one type and the subclass as returning another, I get yelled at:

class Animal extends Model {
  static get idColumn(): string {
    return 'name'
  }
}

class Dog extends Animal {
  static get idColumn(): string[] {
    return ['name', 'tag']
  }
}
/* ERROR
Class static side 'typeof Dog' incorrectly extends base class static side 'typeof Animal'.
  Types of property 'idColumn' are incompatible.
    Type 'string[]' is not assignable to type 'string'.
*/

If I declare the base class with a Union type, that seems to work, although adding another layer of subclass trying to use the original base class's type no breaks because of the middle class:

class Animal extends Model {
  static get idColumn(): string | string[] {
    return 'name'
  }
}

class Dog extends Animal {
  static get idColumn(): string[] {
    return ['name', 'tag']
  }
}

class Poodle extends Dog {
  static get idColumn(): string {
    return 'nom'
  }
}
/*
Class static side 'typeof Poodle' incorrectly extends base class static side 'typeof Dog'...
*/

So I'm now torn. I like to be as specific as I can in my method signatures, but it seems I have two choices here: either always use the full union type string | string[] as the return type of the idColumn getter for all subclasses, or simply don't declare a return type for subclasses, only the base class:

class Animal extends Model {
  static get idColumn(): string | string[] {
    return 'name'
  }
}

class Dog extends Animal {
  // this?
  static get idColumn(): string | string[] {
    return ['name', 'tag']
  }

  // or this?
  static get idColumn() {
    return ['name', 'tag']
  }
}

So my question here is, which is better? Is there an accepted paradigmatic solution here? I don't really like either; the former feels slightly misleading, but the latter feels incomplete. I'm leaning toward the latter in this case since it's immediately obvious what the type of a constant return value is, but in more complex cases involving an actual method with some complicated logic, I'm not sure how I'd handle it.

Dealing with simple objects

Okay, this is a more minor annoyance, but it really bugs me. If I just want to say, "This function accepts/returns a plain ol' object with arbitrary keys and values", the only syntax I can find is:

{ [key: string] : any }

Used once on it's own, that's not the worst thing I've ever seen, but I have a method that accepts an object-to-object Map and returns another one, and the method signature looks like this:

function converter(input: Map<{ [key: string] : any }, { [key: string] : any }>): Map<{ [key: string] : any }, { [key: string] : any }>

That's... that's not okay. I've run into more complex example as well, cases where I'm declaring interfaces with nested objects and such, and this syntax makes them near impossible to read. So my solution has been to declare a trivial interface called SimpleObject to represent, well, a simple object:

interface SimpleObject {
  [key: string] : any
}

And like, that works, but whenever I show anyone my code I have to explain this situation, and it just seems like an oversight that there's apparently no native name for simple objects in TypeScript. Am I missing something?

Conclusion

Thanks to anyone who took the time to read this, and thanks a million to anyone who helps me out or leaves a comment! I'm enjoying TypeScript on the whole, and I'm sure little quirks like this will become natural after a while, but if there is a better way to handle them, I'd love to know! 😁

Chromium and the browser monoculture problem

Ken Bellows — Wed, 12 Jun 2019 11:37:35 +0000

Okay, folks. This is new territory for me. I'm stepping into the world of....

t h i n k p i e c e s 💥🤯💥

I've been thinking a lot about an oooold problem in the web dev community, one that's been the subject of 🔥flamewars🔥 basically since web browsers have existed: "browser monoculture". This topic has flared up again recently as a result of Microsoft dropping their EdgeHTML browser engine and moving Edge to Google's Chromium engine.

I have a crazy idea. I'm not entirely sold on it myself; I'm sure there are aspects I'm not considering. So I want some feedback on it. But first, I need to lay some groundwork.

What does "browser monoculture" even mean, and why should we care?

A "browser monoculture" is when a single browser becomes so dominant that it triggers a chain reaction: it's effectively the only choice, so it's the only browser anyone uses, so it's the only one anyone cares about, so it's the only one developers write code for.

That's one main worry: the concern is that if one browser becomes too dominant, developers may begin to ignore other browsers and just target the set of CSS and JavaScript features supported by the dominant browser, never bothering to test for cross-compatibility in other browsers.

And this isn't unfounded: this is exactly what happened in the early 2000s, at the height of the browser wars: Internet Explorer became so absolutely dominant that devs often specifically targeted IE, and many websites simply didn't work in any other browsers. The worst part was that IE was super quirky, didn't follow the standards, and was very slow to change or improve.

And this is another major concern: when there's really only one player in the market, the push for that browser vendor to follow standards and play by the rules declines; they can effectively do whatever they want. You might think that the developer community would get mad and start moving away from that browser, providing a check to their power, but the thing is, most browser users aren't web developers. Most users don't know or care about this stuff, and they aren't going to start moving to a different browser just because some 🤓nerds🤓 are complaining about "APIs" and "standards".

That said, there is a third, less technical concern that non-developers do care a bit about: when everyone uses a single vendor, that vendor then has access to everyone's user habits, data, etc. This is not exactly unfounded, either; many people have big problems with how Google has handled user privacy issues in the past.

An emerging Chromium monoculture?

And that brings us to recent events. Google Chrome's underlying browser engine is developed as an open source project known as Chromium. It's designed such that it can be used as the basis for new browsers, and many browsers have been built on top of it, including browsers you've heard of. Opera and Samsung Internet both moved to Chromium-based builds in 2013, and of course, as mentioned earlier, the big news this year is that Microsoft Edge will be moving to Chromium as well.

So this is the concern: what if enough of the market share ends up on Chromium based browsers that we end up with a Chromium monoculture?

Looking at current statistics, we do seem to be heading that way:

Browser	% of global usage
Chrome	62.70%
Safari	15.89%
Firefox	5.07%
Samsung Internet	3.38%
UC Browser	3.16%
Opera	2.55%
IE	2.51%
Edge	2.17%
(Others, each <1%)	2.57%

May 2019 global browser usage statistics for browsers with >1% usage
(retrieved June 7, 2019, from statcounter.com)

Chrome alone has over 60% of the global browser market share. Add in Samsung Internet, Opera, and Edge, the top Chromium-based (or soon-to-be-Chromium-based) browsers, and the figure goes up to 70.8%!!! Imagine if Apple decided they were tired of everyone moaning about Safari's missing features (as Safari now tends to lag the furthest behind in implementing cool new web platform APIs) and decided to go the same way as Microsoft. It's unlikely, but I could see it happening.

Many of the new experimental browser projects of the last several years have also been based on Chromium, such as Vivaldi, Brave, and Epic. And this makes sense to me: Chromium is a very well-established, actively maintained, and easily extensible browser engine. The task of creating complete JavaScript, HTML, and CSS engines from scratch is absolutely monumental; Chromium has literally decades of work behind it (considering it's based on a WebKit fork), and catching up seems impossible, especially for an independent startup. Plus, these browsers aren't primarily trying to improve the state of web languages; they're focused on higher level features like security, privacy, etc. I don't fault them for using Chromium as a base and focusing on the features they care about.

And that's kind of the point I want to get to: Chromium is beginning to be positioned as a de facto standard for browser engines, sort of a canonical implementation of W3C specifications. But we'll put a pin in that. 📌

What about Firefox? 🔥🦊

Back in the days of the browser wars, Firefox was the hero we all needed, breaking up the Internet Explorer monopoly and charging gloriously into the new era of browser diversity and cooperative web standards.

But unfortunately, tragically, Firefox usage has been falling over the years, really ever since Chrome came on the scene. I think Mozilla has done heroic work recently with Quantum, and they've often led the charge on implementing new web platform features, especially in CSS (subgrid!!! 😭).

But here's the bottom line: Google is huuuuuuuuge. They just have so many people working there. I don't think Mozilla or the open source community around Firefox has enough manpower or institutional support to keep pace with Google.

And I don't think the right solution is for Google to fire a bunch of their browser team so that Firefox can keep up, either. I love that they're constantly trying cool new things. So what do we do?

Do we have a monoculture?

In an important sense, yes. There seems to be at least a good chance of a browser engine monoculture emerging in the next 5-10 years. At the moment, the two primary opponents to Chromium are Safari and Firefox, who collectively hold about 21% of usage. Chrome's usage numbers have been slowly but steadily increasing for years now, and probably will continue to do so. Now that Edge is Chromium based, I imagine its numbers will go up a bit as well.

Buuuut... here's where I'm going to get controversial. I want to posit that this is a different kind of monoculture than what we saw in the 2000s with Internet Explorer 6, and it has the potential to become a very different kind, one that may not really deserve the name "monoculture". Stick with me here!

Is it bad?

Okay, let's dip our toe into controversial waters. Here's a take I've been developing:

All three of the concerns I laid out earlier are based on a scenario where a single browser becomes dominant, including all the hooks into a specific corporate structure with solitary business priorities and hooks into the company's proprietary ecosystem (e.g. hooking your Google account into your browser). But Chromium is already not that, and it has the potential to be quite the opposite.

To recap, here are the three main concerns I've heard raised in browser monoculture discussions:

One dominant browser will lead developers to target just that one and ignore compatibility with smaller browsers.
When a single browser becomes too dominant, it loses a lot of the motivation to follow and contribute to shared web standards.
The more people use a single browser, the larger the pool of user data and habits available to the company that owns that browser, which raises privacy concerns.

These all change quote a bit when you recognize that we aren't talking about a Chrome monoculture; we're talking Chromium, the underlying browser engine. As it stands, Chromium is the basis for a variety of browsers, not just Google's flagship. From what I can tell (as a non-expert on Chromium's source, so please correct me), the Googley stuff that makes privacy advocates nervous is independent from the core Chromium browser engine. I mean, Microsoft clearly isn't going to ship an Edge with any hooks to Google's ecosystem still in it, so it's gotta be easily separable.

Privacy

For me, this distinction between "browser" and "browser engine" already answers the main concerns about privacy. The engine itself isn't where the privacy issues lie. Heck, two of the Chromium-based experimental browsers I mentioned earlier, Brave and Epic, are all about providing a more secure, privacy-preserving option.

Single Dominant Platform

As for concerns about developers targeting a single web engine if it gets too popular, that's definitely a real thing. Some claim this is happening already with Chrome.

But here's the thing: since it's the base of several different browsers, when Chromium gets a new JavaScript or CSS feature, it's not pushing Chrome ahead of the rest of the pack, it's pushing all of these browsers forward. So when the Verge (in the article linked above) says that Chrome is becoming the new IE, "with web developers primarily optimizing for Chrome and tweaking for rivals later", they should really replace "Chrome" with "Chromium-based browsers". To "optimize for Chrome" is also to optimize for Opera, Vivaldi, Samsung Browser, and soon Edge, because they all use the same engine.

That being said, this is a problem for Firefox, Safari, and anyone else still trying to maintain a parallel implementation. Let me come back to this in a sec.

Web Standards

This one is a big deal. Google has historically been a big player in pushing for and developing web platform standards for everyone to use, but as the Verge rightly points out, they've strayed from that message a bit in the last few years:

Whether you blame Google or the often slow moving World Wide Web Consortium (W3C), the results have been particularly evident throughout 2017. Google has been at the center of a lot of “works best with Chrome” messages we’re starting to see appear on the web. Google Meet, Allo, YouTube TV, Google Earth, and YouTube Studio Beta all block Windows 10’s default browser, Microsoft Edge, from accessing them and they all point users to download Chrome instead. Google Meet, Google Earth, and YouTube TV are also not supported on Firefox with messages to download Chrome. Google has publicly promised to support Earth on Edge and Firefox, and the company is “working to bring YouTube TV to more browsers in the future.”

The Verge, "Chrome is turning into the new Internet Explorer 6"

This isn't great. But from what I can tell, this is isn't always strictly a matter of Google ignoring the standards; it's often a matter of other browsers not keeping up with Google's pace on implementing cutting edge APIs. Again, Google has a massive amount of resources to throw around, so IMO this is somewhat inevitable. But once again, since Google is contributing to Chromium, not just Chrome, all Chromium-based browsers get those benefits.

My crazy idea

Okay, we did it, we laid all the groundwork. And by this point it might be obvious what my idea is. So here we go:

What if the entire web standardized on a single browser engine? What if Chromium became the basis for a reference implementation of web standards, and all browsers converted to be based on it?

Now before you get out the pitchforks, let me elaborate.

A collaborative engine

I hope it's obvious, but I'll say it anyway: I'm not suggesting we cede control of the web to Google. Quite the opposite, actually. My vision is that the developers that currently spend countless hours writing the same code in parallel in different codebases instead are united under a single, common codebase.

Ideally, this codebase would not be controlled by any single company. I'd love to see a common browser engine controlled by an independent nonprofit foundation, like the Python Software Foundation, including (though not primarily made of) a few representatives from each participating browser vendor.

Just imagine with me for a moment: What if Safari and Firefox and everyone else stopped maintaining separate codebases, duplicating a ton of effort and desperately trying to keep up with the pace of the behemoth that is Google's development team, and instead began contributing to a shared codebase? What if everyone benefitted from everyone else's work?

We've seen examples of this. Opera developers have done this in the past, and the Edge team has begun doing this as well, both teams bringing their expertise to benefit Chromium.

I'm currently very frustrated that while CSS Subgrid has been implemented in Firefox Nightly, Chromium has yet to start working on it. Imagine if the Firefox devs' work contributed to Chrome as well! This problem would vanish!

And this is a classic problem on the web platform in general: we all get excited by some awesome demo of a new Web API in a certain browser, but the immediate response is, "Sure, but how soon can I actually use that? How soon will all the other browsers implement it?" Maybe there's an opportunity here to get rid of this problem forever.

What about the lost diversity of implementation?

Here's a possible downside I'm worried about: one thing I love about the variety of browser engines currently in the wild is that they often implement the same feature in different ways, and one is often faster than others. I have to imagine (though to be honest I don't know) that there have been occasions when a Chrome dev has seen how Firefox solved a problem and borrowed an idea or two, and vice versa. Would we be giving this up? How big of a loss would this be?

I have two thoughts here.

First, I note that this isn't a big deal for other platforms; I don't hear much complaint that there's no big competition for CPython (the Python reference implementation) to encourage alternative ways of implementing features. But maybe that's not a counterargument. Maybe that's a bad thing for the Python community, and they would benefit from some competition. I don't know.

Second, though, maybe there's a way to preserve this feature of the web to some degree. Yes, all browsers would be built on the same engine. But maybe the engine could be (or already is? Again, I'm no expert) built in such a way that each browser could build initial implementations of features on top of the core engine. Maybe this could develop into a regular process: when a new API is being discussed, or even after the spec is initially published, maybe each browser that's interested writes their implementation of the feature and tries it out. Maybe we spend 6 months or whatever with a different version of the feature in Firefox, Chrome, and Opera, then a committee at the foundation sits down together and hashes out which implementation should be merged into the master branch.

This is a point I'd love specific feedback on. I'm not sure how it would go down, but it feels like there has to be a way to get it done.

Wrapping up

Okay, that's it. If you've read this far, holy crap, thank you so much. This was a long, rambly one without any practical application, so I really appreciate anyone who gave me that much of their time.

To say it once more, I'd really love feedback on this! The growing disparity between browsers is something that's been on my mind a lot for a while. I don't think the current trajectory is sustainable, and I don't want either for a single browser to win out while still being corporately controlled, nor for browsers that are able to push ahead of the pack because of greater resources to be held back for longer and longer amounts of time while other browsers struggle to catch up, all the while being criticized as "the new IE6".

I think we desperately need a new conversation on this topic. This is my contribution. Now please, give me yours! 😁

More resources

Here's some other people talking about this topic that have informed my own opinion, including some stuff I linked in the article.

The Verge, "Chrome is turning into the new Internet Explorer 6"
@shoptalkshow Podcast (@chriscoyier , Dave Rupert),"Breaking Browser News" segment: "Google updates vs the rest of the industry" - This is what got me started thinking about the aspect of Firefox and other smaller engine teams not being able to keep up with Google's resources
HTTP203 Podcast, "Browser Monoculture" - a somewhat ironic 2015 episode of Google's HTTP203 podcast in which Paul and Jake discuss the time Edge asked the community for suggestions, and the top response was "Stop doing your own thing and use WebKit instead"
Mozilla, "Goodbye EdgeHTML"

AskDev: Real-time group project collaboration tools?

Ken Bellows — Wed, 22 May 2019 15:15:01 +0000

Hey DEV! I'm in grad school, and I'm taking a course for the summer semester all about Education Technology. The class is structured almost like an independent study, where we spend the semester researching a topic of personal interest and producing something (original research, a tool to solve a problem, or some educational content). As a web developer with a long-time interest in accessibility, I'm exploring a few different angles for building a tool to address accessibility issues with online courseware (MOOC platforms, learning management systems, that kinda stuff).

So, I have a question for the community: are you aware of any software/web applications focused on long-distance group collaboration, such as for team projects and stuff? I'm looking for examples with real-time communication capabilities, file sharing (and ideally editing/reviewing) capabilities, shared notes, etc. I haven't had a reason to use this sort of app in the past, so I'm not familiar with any popular platforms or anything. My first thought is the Google suite (Hangouts/Chat + Google Drive basically), but are there more focused platforms out there?

Thanks in advance!

EDIT

To clarify, I'm not looking for a tool to use myself, I'm looking for tools to examine for accessibility, and I'm thinking about building an alternative myself. So I'm especially looking for full-featured combination tools if they exist, especially tools specifically aimed at coursework and student group projects.

And to clarify further, I'm definitely also interested in more general solutions that are often used by student groups for collaboration on school projects (e.g. G Suite, Slack), so let me know what you've used, especially if you're a current student!

What cool ideas have you seen for integrating new team members?

Ken Bellows — Mon, 13 May 2019 18:31:05 +0000

I came across this tweet from a couple days ago and it really struck a chord with me:

// Detect dark theme var iframe = document.getElementById('tweet-1127248044678737921-139'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1127248044678737921&theme=dark" }

"We hired an engineer a few weeks ago who initiated a 1:1 coffee with a different person every day, until she’d met with the whole dev team. I thought this was an awesome idea, that I will definitely try next time I start a new job, and pass the idea on to you!"

Trying to get to know your new team as quickly as you can, and helping them get to know you at the same time, seems like an amazing idea. It's awesome that this person took it upon themself, and it probably would be even better if it was implemented by the team as a normal part of onboarding. The top reply was actually someone saying that their office did exactly that:

// Detect dark theme var iframe = document.getElementById('tweet-1127633821606862848-678'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1127633821606862848&theme=dark" }

This is such a cool notion. Feeling like the new person in the room has often been one of the big barriers for me when I've joined new teams, especially when I was a younger dev on a team full of older and far more experienced people. Being the person in the room with the least experience is already intimidating, and when you don't know anyone on top of it, asking for help can be hard. Plus, no one else in the room knows what your skill level really is, where you need the most help, how they can assist most effectively, all that good stuff.

All that to say, this seems like an awesome idea, and I hope I'll be able to use it myself. It looks like I'll be taking on a lead developer position soon, and will be building up the team from mostly outside hires in the next 6 months or so. This will be my first team lead position, so stuff like this is exactly what I need in my face right now, while I'm thinking about how to be effective in that role.

Since reading this tweet, I've been thinking, and I bet there are plenty of other super cool ideas like this out there, ways to help new team members feel like a part of the group quickly, to integrate both with the people and the work painlessly. So who's got one for me? I'd love to hear them!

"currentColor", the first CSS variable

Ken Bellows — Mon, 29 Apr 2019 13:57:37 +0000

The recent addition to CSS of Custom Properties, a.k.a. CSS variables, was a very welcome addition to the language. It's opened the door for a lot of really cool techniques; there's a lot that you can only do when you can keep track of the state of your system and keep different bits in sync with each other, and variables give you a way to do that.

But here's something that developers newer to CSS may not know, and those who've been around often forget: we've actually had another variable in CSS since long before Custom Properties came on the scene. It's much simpler, and limited in scope, so it can't do everything Custom Properties can do, but it's way better supported, and with a bit of cleverness it can be used to accomplish some pretty cool stuff.

This variable is the special CSS keyword currentColor!

What is it?

The currentColor keyword is basically what it sounds like: it's a special keyword that holds the value of the color property at the location where it's used.

So for a very simple example, you can use it to make a pull quote box with a border that's the same color as the text in the box:



blockquote {
  color: hotpink;
  border-color: currentColor;
}

Snazzy, I think.

Interestingly though, in this particular case, the border-color rule is unnecessary. I always thought that the default border-color value was black, or else was set by the browser, but I recently discovered by accident that it actually defaults to currentColor! So if border-color just isn't specified, it will use hotpink by default!

Several properties actually default to currentColor:

border-color
caret-color
column-rule-color
text-decoration-color
text-emphasis-color
outline-color (sometimes; read the link and read about the invert keyword, which is used if it's supported)

By the way, I didn't know about almost any of those rules before I looked up which rules default to currentColor! I need to read more about text-emphasis; it's really weird and interesting. Man, every time I dive into the docs to find something specific, I end up learning about something unexpected.

Browser support

Of course, the first question you should ask whenever you learn about a cool feature of the web platform that you've never seen before is, "How good is its browser support? Can I actually use it?" Fortunately, the answers for currentColor are "super good" and "yes!"

Support actually goes back a really long time. Taking a look at caniuse.com's overview of support, it's supported in every version of Edge, it's been in Chrome and Safari since version 4 (back then they used the same engine under the hood), and it's been in Firefox since version 2! Heck, it's even in Internet Explorer all the way back to IE 9! So don't worry about using it unless you're writing an intranet application for an organization that still hasn't upgraded past IE 8. (Tragically, I'm very aware that they still exist 😢)

Demo: Badges

Okay, let's get practical.

I discovered currentColor while investigating the best way to implement a design for work. I needed to create a row of colored badges, each with a label on the badge and a numeric counter next to it. The background color of each badge matched the text color of its counter, and the label on each badge was colored to match the site background. For the sake of example, suppose the mockup was something like this:

Each of those badges is identical, but for the color. Seems like a good use case for a reusable component! In a modern browser, you could use a CSS variable for the background of the badge and the foreground text color of its counter. But suppose you want/need to support IE 11, Edge 12-14, or another browser that doesn't support custom properties. Or maybe you already have some utility classes in your CSS to define text colors for various situations, like Bootstrap's contextual color classes, e.g. .text-danger and .text-warning, so the idea of using the color property to set the badge color is super convenient. How might you go about it, armed with your new knowledge of currentColor?

First we'll need a root wrapper element for the component. This is where the color will be set, and it's where you'd add a class to override the color.



<div class="badge">
</div>



.badge {
  display: inline-block;
  color: cornflowerblue;
}

So what needs to be inside the badge component? Well, at first glance there are two regions: the bit with a colored background and white text, which I'll call the title block, and the digits off to the side that are colored to match the title block's background, which we've been calling the counter.

The title block definitely needs its own block in the DOM, since it has a background color, but the counter probably doesn't, since it's just sitting off to the side, which is what inline text does anyway. So lets try this markup:



<div class="badge">
  <div class="title-block">
    Things
  </div>
  12345
</div>

Now the fun part! We want the background of the .title-block to match the color specified on the .badge, so we can use background: currentColor! We also want to set the .title-block's text to white, according to our mockup, so let's add color: white as well. (If you've spotted the problem here, no spoilers!)



.title-block {
  display: inline-block;
  padding: 0.5rem;
  background: currentColor;
  color: white;
}

Great! Let's see how it looks:

Ah. Well. That's not what we wanted at all. The title block seems to be missing... or rather, it's completely white. Why is that?

Well, here's the thing: CSS is a declarative language, not an imperative one: it doesn't run top-to-bottom, keeping and updating state along the way. What this means is that when we write:



.something {
  background: currentColor;
  color: white;
}

the browser doesn't figure out currentColor's value, then set color: white. Instead, setting color: white changes the value of currentColor for the background to white as well! This is a limitation of currentColor that you need to keep in mind.

It's an easy enough fix, if a little annoying. We just need another layer of nesting to encapsulate the color: white rule. CSS rules often inherit downward to children, but never upward to parents, so this lets .title-block inherit its currentColor value from .badge, while being able to change the color within its child.



<div class="badge">
  <div class="title-block">
    <span class="title-block-text">
      Things
    </span>
  </div>
  12345
</div>



.title-block {
  display: inline-block;
  padding: 0.5rem;
  background: currentColor;
}
.title-block-text {
  color: white;
}

Now let's take another look:

Perfect!

Now that we've got our component, all we need to do is repeat it a few times and define a color-override class for each be instance.



<div class="error badge">
  <div class="title-block">
    <span class="title-block-text">
      Errors
    </span>
  </div>
  123
</div>

<div class="warning badge">
  <div class="title-block">
    <span class="title-block-text">
      Warnings
    </span>
  </div>
  45
</div>

<div class="success badge">
  <div class="title-block">
    <span class="title-block-text">
      Successes
    </span>
  </div>
  12345
</div>



.error {
  color: red;
}
.warning {
  color: goldenrod;
}
.success {
  color: green;
}

Awesome! We met the requirement!

And this little badge component is pretty handy; there's still more to play with. We can try different colors, put emoji in the title area, add a background color to the counter area... Lots of possibilities!

What else can you come up with?

Conclusion

To recap: there's a cool, undervalued keyword in CSS, currentColor, that can be used as a variable of sorts for certain use cases. It has much more broad support than CSS Custom Properties (a.k.a. CSS variables), and it is perhaps a bit more intuitive to use when developing a reusable component, since you only need to set the color property to populate it's value, which feels very nice.

However, it's clear that currentColor has limitations. The most glaring when comparing to Custom Properties is that it's only a color value, so it can't be used to store length values, image URLs, or fancy gradients. The other main point of caution is that you can't use an inherited color value in currentColor, say for the background or border color, while also setting your own color for text in the same block; setting color will update the value of currentColor everywhere within that block. You need to introduce a child element to keep your color value in a new scope.

So in short, it has limits and caveats, but I personally have found currentColor to be very useful, and it has let me write much cleaner code in a few tricky situations. My absolute favorite feature is just being able to set color on a root element of a component and see the whole thing update. Give it a try, see what you can do with it!

Do you use a CSS framework based on CSS Grid?

Ken Bellows — Wed, 24 Apr 2019 13:29:57 +0000

Ever since the advent of CSS Grid, I never feel the need to reach for a CSS framework like Bootstrap or Foundation. I find that Grid gives me everything I need out of the box.

But with that said, my day job still supports a large user base with very old browsers, so we're unable to use Grid (for now, though that may be changing soon! 🤞), so I haven't used Grid on a huge scale yet, only for small-to-medium size sites. Maybe there's value in a framework for larger, more nested and complex layouts?

Has anyone here used Grid for larger applications? Do you use a CSS framework that does the Grid stuff for you? Have you tried it and liked/hated it?

Or have you even used one for smaller ones? Did you find it easier than writing Grid rules by hand? Do I need to take a second look?

Why I care about the Semantic Web

Ken Bellows — Mon, 22 Apr 2019 13:15:11 +0000

This one's going to be a bit more personal and a bit less technical than my usual fare. It's based on a response I gave to a comment left on a previous article of mine, and I think it's worth expanding into it's own whole thing.

I wrote an article a few weeks ago all about semantic HTML, encouraging web developers to choose a semantic element over a <div> whenever there's an appropriate one. The article absolutely exploded (at least, way more than anything I've ever written before), which was just so cool.

But after having a few conversations in comments and on Twitter, I realized that a lot of readers seemed to be very excited about and focused on one aspect of semantic tags: how much cleaner semantic code can be than traditional <div> slinging. And to be sure, this is an important aspect, but in my opinion it's not the most important thing.

In particular, one of the conversations I had in the discussion section (the one that prompted this article) was about whether it's a good idea to go beyond the provided semantic tags and using custom non-standard tags to mark up the document with even more readable HTML. In my opinion, this isn't a good idea, and I explained why over there, but this conversation really highlighted for me that if we're not careful, we can focus too much on how markup looks and forget why standards are defined in the first place.

Three reasons

After lots of reflection and discussion, I've found that there are basically three main reasons to write semantic HTML, three things that make it something that everyone who writes HTML for the web should understand and use:

Code ergonomics, a.k.a. it's better for developers - Semantic elements are much easier to read, both as HTML tags and as CSS selectors. Their purpose and meaning are clearly defined, which makes the structure of your document much more apparent. They also often have certain default styles and behaviors that make our lives as developers easier because we don't have to spend time adding them ourselves.
SEO, a.k.a. it's better for business - Search engines like Google pay attention to semantic HTML on your page, especially if you move past just semantic elements and use microdata attributes, also defined as part of HTML5, to call out the data on your page that search engines care about. Google has been paying attention to this stuff since at least 2010, and they use microdata to create those cards that come up when you search for a business.
Accessibility, a.k.a. it's better for users - Many semantic elements play a very important role in helping users navigate and use your site more easily. This applies double to users who interact with your site in a way other than the mouse + keyboard + monitor + colors + speakers method that is far too often the only perspective considered. Assistive technologies that help users often rely heavily on certain semantic elements to understand web documents, including things like headings (<h1>-<h6>), region elements like <section> and <article>, the <nav> element to call out navigation within the document and/or the rest of the site.

Based on the discussion section on my article and some of the conversations I had surrounding it, I think I made a mistake: I focused a bit too much in my article on reason 1, how much nicer the code is for developers to write, read, and maintain. Don't get me wrong, semantic HTML code definitely is way nicer and more maintainable in almost every case, and that's great for developers. But in my opinion, reason 1 is actually the least important of the three. And the most important, as you've undoubtedly guessed from the title of this article, is reason 3, accessibility.

So here's today's thesis statement:

Semantic HTML is not primarily about improving code readability

If the primary motivation of semantic HTML was cleaner code that uses tag names to convey the purpose of a element instead of using CSS classes and HTML attributes, then the W3C could have gone even further: instead of standardizing a very specific and not-all-that-exhaustive set of semantic elements, they could have simply standardized the use of custom tag names devised on the fly, the same way we name CSS classes or JavaScript functions. But they didn't, and I think there are good reasons for that.

To me, the biggest reason is that we need the computer to understand what we're doing. When we talk about the Semantic Web™, we don't just mean that the tags convey semantics to us humans; they hold specific meanings for browsers, which can in turn communicate their meanings out to assistive technologies. But the browser can't do this with non-standard tags, because those tags don't have any defined meanings or behaviors for the browser to communicate.

Custom elements, properly defined with the CustomElementRegistry, allow developers to provide those semantics to the browser, which is pretty cool. Components defined by a web framework with JavaScript and/or a template backing them are tricky, and have to be done right. By default, they're just non-standard tags too, but the component template can add semantic elements attributes, and the JavaScript can add the behaviors needed to provide accessible behaviors.

The bottom line

To reiterate, the Semantic Web isn't just a matter of preference or style or convenience. It has a huge direct impact on the lives of many, many users, those who rely on assistive technology. And assistive technologies in turn rely on the semantics they can parse from the HTML to help those users.

If you've never tried to use the web with a screen reader before, please do. I think every web developer needs to do this periodically in order to better understand how many of their users interact with the web, and how honestly horrible a lot of the web can be for users who rely on assistive tech. On a site built without any semantics, basically all <div>s and <span>s and even non-standard elements, the best a screen-reader can do is read the text top to bottom, with no way to let the user easily navigate the page. But mark it up with semantic elements and the screen-reader can give the user an outline of the page, highlight the important landmarks, and give them handy jump points to move around the page a hundred times more easily.

Forgotten and ignored users

In my experience, there's a tragic lack of attention paid to semantics in web development training, and this knowledge gap actively hurts the users that need it. That's a big part of why I write articles about semantic web technologies and techniques. I want to help spread this information as broadly as possible and make sure every web dev possible finds out about it. Semantic HTML, microdata, ARIA, all these Semantic Web tools are crucial for building a web that's made for everyone. Accessibility should become as foundational to web development training as the difference between a <div> and a <span>.

This stuff directly impacts the lives of many people, much more directly than we often think or talk about. And that's the big point: because this stuff isn't talked about enough, because it isn't taught in HTML 101 as a foundational part of the platform, we forget about it, and we forget about the users that need it. And not only are they forgotten, but when they are remembered, far too often they are intentionally ignored. I've heard and read too many stories from developers that know and care about accessibility of joining a team, asking about the accessibility shortcomings of the application, and recommending improvements, but being shut down because it would take too much development time and effort. I've experienced this myself.

And in honesty, they aren't wrong to say that there's a cost to training an established team on accessibility principles and techniques, and updating a large existing codebase to be more accessible. But that's just another huge reason that accessibility should be taught from the start! There's no cost to building an accessible application from the start, but there is an initial cost to retro-fitting it later. But the fact that it costs something should by no means stop anyone from doing it. If you need business motivations: (1) you'll have access to more users, which means more potential customers, (2) your code will be more maintainable, and (3) you'll have better SEO. But also, it's just the right thing to do, and I don't think we should always frame it in profit terms.

Ultimately, what I'm trying to do by writing about web semantics and accessibility is to play some small part in improving the experiences of one of the most underserved, forgotten, and ignored groups of users on the web.

Rewriting an old project! Part 2: JavaScript

Ken Bellows — Fri, 12 Apr 2019 14:48:51 +0000

Note
This is Part 2 of a miniseries in which I'm revisiting an old weekend hack of mine from college, which I called jSphere (because I was lazy and couldn't come up with anything more interesting).

If you haven't read Part 1, which was all about the HTML and CSS, I recommend giving it a skim, or at least reading the Backstory section at the beginning.

As I said last time, I'm not going to discuss what the code does in this post, just its structure and syntax. But I do plan to write a proper walkthrough and tutorial later.

Last time...

In Part 1, time we went over the markup and styling of , and I already found that pretty interesting. But, I mean, this project is primarily a JavaScript project. It's all about that <canvas>!

For reference, here's what we're rebuilding:

Okay. Where to begin? Man, there was so much to change about this code, and a lot of it was interwoven, which makes it tough to really talk about step-by-step. So what I'll have to do is just... go for it, I guess.

Please, feel free to critique or otherwise comment on the code here! I love feedback and (constructive) criticism, I'm always interested in how other people would approach the same tasks, and I've even been known to enjoy a little bikeshedding now and then.

Minutia: nah.

Let me mention up front here that there are some changes I won't explicitly discuss, because they're too minor. Yes, I changed all the vars to consts and lets, I reordered some functions, I changed all the TitleCasedMethods to normalCamelCase (why did I capitalize the first letter of all my methods? was I insane?). But you don't care about all those things. I'm going to focus on the really large things, the things I found interesting or funny, and the things that really demonstrate how far the language has come in seven years.

Let's start with a funny one.

Bro, do you even loop?

I fixed a spot where I had done something super weird, maybe because I was rushing and didn't think it through. This is in Sphere's constructor, when I'm generating all the Dot instances needed to represent the points on the surface of the sphere. I use a nested for loop to move around the sphere in rings, top to bottom, adding dots to its surface as I went. This is fine, but I wrote the loops in a super weird way:

this.points = new Array();
var angstep = Math.PI/10;
var i = 0;
// Loop from 0 to 2*pi, creating one row of points at each step
for (var angxy=0; angxy<2*Math.PI; angxy+=angstep){
    this.points[i] = new Array();
    var j=0;
    for (var angyz=0; angyz<2*Math.PI; angyz+=angstep) {
        // Loop from 0 to 2*pi, creating one point at each step
        var px  = r * Math.cos(angxy) * Math.sin(angyz) + x,
            py  = r * Math.sin(angxy) * Math.sin(angyz) + y,
            pz  = r * Math.cos(angyz) + z,
            pfg = pz > z;
        this.points[i][j] = new Dot(px,py,pz,pfg);
        j++;
    }
    i++;
}

What's up with the i and j variables there, hanging out outside of the loops? Why aren't they created and incremented within the loops? I definitely knew that a for loop can have multiple variables; why didn't I just do this?

for (var i=0, angxy=0; angxy<2*Math.PI; i++, angxy+=angstep) { ... }

But also, why do I even need those index counters in the first place? Why do I use this.points[i] = and this.points[i][j] = to add to the arrays? Why aren't I just using [].push() to add stuff to the array? And why on Earth did I use new Array() instead of []? How much OOP was I on???

So I got rid of all that nonsense. I also decided to make this.points a single flat list of points, rather than a 2D matrix with rows, because I realized while refactoring some other code that the only way I ever referenced this.points was with a couple of nested loops to reach each point, usually with weird for ... in loops like this:

for (var i in this.points) {
    for (var j in this.points[i]) {
        this.points[i][j]...
    }
}

First, it does work, but using for...in loops on arrays like this is strange, and it's unexpected to say the least. I was very confused when I first saw it, and I imagine any other devs reading it would be thrown off as well.

Second, I never used i or j for anything other than indexing into this.points, which makes this a great candidate for the much more elegant for...of loop, which didn't exist when I originally wrote this code.

I refactored to fix all of these problems, and here's where I wound up. The constructor loops were updated to this (which also includes a change to the Dot constructor that I'll talk about in a bit):

// The angle delta to use when calculating the surface point positions;
// a larger angstep means fewer points on the surface
const angstep = Math.PI/10;
this.points = [];
// Loop from 0 to 2*pi, creating one row of points at each step
for (let angxy=0; angxy<2*Math.PI; angxy+=angstep){
    for (let angyz=0; angyz<2*Math.PI; angyz+=angstep) {
        // Loop from 0 to 2*pi, creating one point at each step
        this.points.push(new Dot({
            x: r * Math.cos(angxy) * Math.sin(angyz) + x,
            y: r * Math.sin(angxy) * Math.sin(angyz) + y,
            z: r * Math.cos(angyz) + z,
            fg: Math.cos(angyz) > 0
        }));
    }
}

And the loops over the elements of this.points now look like this:

for (const point of this.points) {
    point...
}

Ahh... So much better. 😌

Classes!

Since this project was all about this interactive sphere composed of a bunch of dots on its surface, and since I was doing a CS degree in 2012 and the Functional Revolution of the last few years hadn't begun yet, the project is largely composed of two high-level object types:

Dot - represents a single dot on the surface of the sphere
Sphere - represents the whole sphere, with all of its Dots

In 2012, the native class was yet to be standardized, so I wrote everything in the old-school function-as-a-constructor style. For exapmle, here's part of the Sphere constructor:

function Dot(x,y,z,fg,fgColor,bgColor) {
    // Default Values:  { x: 0, y: 0, z: 0, fg: true, fgcolor: #7EE37E, bgcolor: "#787878" }
    this.x = typeof x !== 'undefined' ? x : 0;
    this.y = typeof y !== 'undefined' ? y : 0;
    this.z = typeof z !== 'undefined' ? z : 0;
    this.fg = typeof fg !== 'undefined' ? fg : true;
    this.fgColor = typeof fgColor !== 'undefined' ? fgColor : "#7EE37E";
    this.bgColor = typeof bgColor !== 'undefined' ? bgColor : "#787878";

    this.Draw = function(ctx) {
        // Store the context's fillStyle
        var tmpStyle = ctx.fillStyle;
        // Set the fillStyle for the dot
        ctx.fillStyle = (this.fg ? this.fgColor : this.bgColor);
        // Draw the dot
        ctx.fillCircle(x,y,this.fg?10:5);
        // Restore the previous fillStyle
        ctx.fillStyle = tmpStyle;
    }
}

Now, there's another issue here, which probably had to do with my limited understanding of JS prototypes: every instance of Dot defines its own copy of the Draw function, rather than referring to a class method. What I should have written is this:

function Dot(x,y,z,fg,fgColor,bgColor) {
    // ...
}
Dot.protoype.Draw = function(ctx) {
    // Store the context's fillStyle
    var tmpStyle = ctx.fillStyle;
    // Set the fillStyle for the dot
    ctx.fillStyle = (this.fg ? this.fgColor : this.bgColor);
    // Draw the dot
    ctx.fillCircle(x,y,this.fg?10:5);
    // Restore the previous fillStyle
    ctx.fillStyle = tmpStyle;
}

This declares a single copy of the function, rather than wasting memory on a new function every time.

But that's a side issue anyway, since the native classes introduced in ES2015 (aka ES6) handles that under the hood!

But before we get to that, let mention one more thing: ES2015 also introduced object destructuring, function parameter default values, and using both of those things together to basically get the equivalent of named parameters with default values, as seen in languages like Python and Ruby!

Aaaaand one more thing: ES2015 also introduced Object.assign(), which I like to use to initialize this with properties much more succinctly than the traditional one-by-one method. (Man, ES2015 was some good stuff!)

Using these two techniques together, I can eliminate this nasty snippet from the the Dot constructor:

// Gross 🤢
this.x = typeof x !== 'undefined' ? x : 0;
this.y = typeof y !== 'undefined' ? y : 0;
this.z = typeof z !== 'undefined' ? z : 0;
this.fg = typeof fg !== 'undefined' ? fg : true;
this.fgColor = typeof fgColor !== 'undefined' ? fgColor : "#7EE37E";
this.bgColor = typeof bgColor !== 'undefined' ? bgColor : "#787878";

Putting all these improvements together, I can rewrite the Dot like this:

class Dot {
    constructor({x=0, y=0, z=0, fg=true, fgColor='#7EE37E', bgColor='#787878'}={}) {
        Object.assign(this, {x, y, z, fg, fgColor, bgColor});
    }

    draw(ctx) {
        // Store the context's fillStyle
        var tmpStyle = ctx.fillStyle;
        // Set the fillStyle for the dot
        ctx.fillStyle = (this.fg ? this.fgColor : this.bgColor);
        // Draw the dot
        ctx.fillCircle(x, y, this.fg ? 10 : 5);
        // Restore the previous fillStyle
        ctx.fillStyle = tmpStyle;
    }
}

So much cleaner!

Re-separating my concerns

As I was rewriting my classes as I just described, I started to find places where Dots were doing stuff that was better handled by Sphere, and Sphere was repeatedly performing operations on each Dot that could be much more cleanly handled internally by each of them.

First, that Draw method of the Dot class up there? Yeah, it was never actually being called. It turned out that I needed some context from the Sphere about each Dot in order to draw it correctly, namely where it was located on the surface of the sphere and how the sphere was currently rotated. And rather than pass all that context around to each Dot, it was much cleaner to do all my drawing right from the Sphere class. So... I deleted the Draw method on Dot, as well as the fgColor and bgColor properties that went with it.

Second, there are two major ways that the Dots are changed to move the Sphere around: they're translated (moved around), and they're scaled (grown or shrunken). I had a bunch of repeated code in my event handlers where each Dot's properties were being manually recalculated and updated in the same way, so I figured I'd DRY up my code and move the logic to change a Dot into the Dot class itself. I gave Dot two new methods: scale and translate.

After all that, my Dot class looks like this:

class Dot {
    constructor({x=0, y=0, z=0, fg=true}={}) {
        Object.assign(this, {x, y, z, fg});
    }

    /**
     * Scale this dot's position by multiplying all coordinates by the given scale factor
     * @param {Number} scaleFactor
     */
    scale(scaleFactor) {
        this.x *= scaleFactor
        this.y *= scaleFactor
        this.z *= scaleFactor
    }

    /**
     * Move this dot to a new position indicated by the given x, y, and z distances
     * @param {Number} [x=0]
     * @param {Number} [y=0]
     * @param {Number} [z=0]
     */
    translate({x=0, y=0, z=0}) {
        this.x += x
        this.y += y
        this.z += z
    }
}

Don't mess with the prototype!

I made several changes that came from experience. Before I left college, I really had little to no knowledge of accepted community best practices, or why they were important. For example, I have a few utility functions for drawing on the canvas. In my old code, I added them to the CanvasRenderingContext2D prototype directly, as follows:

Object.getPrototypeOf(ctx).fillCircle = ctxFillCircle;

This is not ideal. Suppose a real ctx.fillCircle were added to the spec one day, and it was different from my code. In this minor demo it probably doesn't matter much, as I'm the only one working with the code, but in a project with multiple authors, it could be very confusing to come across a standardized method that looks different than it should. Even future me might be confused!

So I refactored: a ctx parameter was added to each function, all references to this in the functions were changed to ctx, I removed the above lines that modified the CanvasRenderingContext2D prototype, and I changed the code to call the functions directly and pass ctx as the first argument rather than calling them as a method of ctx.

Removing jQuery

Finally, jQuery. I love it, it did a lot of good for the web, but in most cases, including mine, it's no longer needed.

I basically used jQuery for three things in this project, two of which are trivially replaced:

I used the $(function() { ... }) wrapper to delay code execution until the page loaded. As I discussed in Part 1, this is unnecessary if you add the defer attribute to any <script> tags that need to wait. (Thanks again, @crazytim!)
I used the classic $() selector function in several places to get elements. This is now (and actually was then, though I was unfamiliar with it) a native part of the platform with document.querySelector and document.querySelectorAll.
The tough one: I used the jquery.events.drag plugin to handle mouse-based interactivity. This one takes slightly more doing to replace.

The first two are super basic, and I won't bother showing them. Instead, I'll focus on that third one: the jquery.event.drag event plugin.

Here's how I was using it:

$("#canvas")
    .drag("init", function(e){
        startX = e.clientX;
        startY = e.clientY;
    })
    .drag(function(e){
        if (e.ctrlKey) {
            if (e.altKey) sphere.HiddenFun2(e.clientX-startX,e.clientY-startY);
            else sphere.Zoom(e.clientX-startX, e.clientY-startY, -1);
        } else if (e.shiftKey) {
            if (e.altKey) sphere.HiddenFun1(e.clientX-startX,e.clientY-startY);
            else sphere.Pan(e.clientX-startX,e.clientY-startY);
        } else {        
            sphere.Rotate(e.clientX-startX,e.clientY-startY);
        }
        startX = e.clientX;
        startY = e.clientY;
    });

So when dragging begins, store the starting position of the cursor, then when dragging continues, perform certain actions based on the modifier keys used, and update the cursor position for the next movement.

So how would we do this with regular old mouse events?

I implemented it in three stages: drag start, drag, and drag end. The drag start event is mousedown; we'll record the starting position of the cursor, and add the drag and drag end event listeners. The drag event will be mousemove; here we'll do all the logic to check for modifier keys and actually manipulate the sphere. Finally, I'll use two events for drag stop: mouseup and mouseout. That way, we don't get that weird case where you move your mouse out of the window and then let go, and the app is stuck in the dragging state until you click again. Those events just remove the event handlers registered on drag start.

I decided to add mousemove, mouseup, and mouseout to the window so that you can move your mouse around the page after clicking. And I had to suppress the mouseout event on the canvas and body elements using event.stopPropagation() to prevent prematurely triggering the drag stop when moving your mouse in and out of the canvas.

Here's what all that looks like:

let dragOrigin;
canvas.addEventListener('mousedown', dragStartHandler)
function dragStartHandler(e){
    dragOrigin = {
        x: e.clientX,
        y: e.clientY
    };
    document.addEventListener('mousemove', dragHandler);

    window.addEventListener('mouseup', dragStopHandler);
    window.addEventListener('mouseout', dragStopHandler);

    canvas.addEventListener('mouseout', stopPropagation);
    document.body.addEventListener('mouseout', stopPropagation);
}

function dragHandler(e){
    if (e.ctrlKey || e.metaKey) {
        if (e.altKey) sphere.hiddenFun2(e.clientX-dragOrigin.x, e.clientY-dragOrigin.y);
        else sphere.zoom(e.clientX-dragOrigin.x, e.clientY-dragOrigin.y, -1);
    }
    else if (e.shiftKey) {
        if (e.altKey) sphere.hiddenFun1(e.clientX-dragOrigin.x, e.clientY-dragOrigin.y);
        else sphere.pan(e.clientX-dragOrigin.x, e.clientY-dragOrigin.y);
    }
    else {
        sphere.rotate(e.clientX-dragOrigin.x, e.clientY-dragOrigin.y);
    }
    dragOrigin.x = e.clientX;
    dragOrigin.y = e.clientY;
}

function dragStopHandler(e) {
    document.removeEventListener('mousemove', dragHandler);
    document.removeEventListener('mouseup', dragStopHandler);
    document.removeEventListener('mouseout', dragStopHandler);

    canvas.removeEventListener('mouseout', stopPropagation);
    document.body.removeEventListener('mouseout', stopPropagation);
}

function stopPropagation(e) {
    e.stopPropagation();
}

So even that wasn't too bad! But then I realized I had forgotten about...

Touch support for mobile 😭

After implementing my updated code, I visited the page on my phone; nothing worked. Then it hit me: phones don't have mouses! 🤦

Some quick research reminded me of the relatively recent pointer events (pointermove, pointerup, etc.), which are made to unify lots of different kinds of pointer-ish interactions: mouse, touch, stylus, new stuff we haven't thought of yet. The problem (for now) is that mobile support is spotty: pointer events work on Chrome for Android, Opera Mobile, Android Browser, Samsung Browser, and IE Mobile (???), but not Firefox for Android, iOS Safari, or most other mobile browsers..

The other problem is that the controls to do anything other than spin the sphere currently require modifier keys on the keyboard to be pressed (Shift+drag to pan, Ctrl+drag to zoom). So pointer events on their own will only enable rotating, nothing else.

A proper solution would be to learn about touch events and how to implement gestures like pinch-zoom and 2-finger-pan, but I'll be honest, I looked into it a little and it's so complex! More than I want to get into right now. So the pointer events will have to do as a half-measure that only fixes rotating and only works on some mobile devices. And I'm not thrilled about it 😞

Anyway, here's what all of that looks like. I'm testing for pointer event support by checking whether the <body> has an onpointermove property, and if not I fall back to mouse events, since there are desktop browsers that don't support pointer events, too (looking at you, Safari 😡).

// Prefer 'pointer' events when available
const pointerEvent = (
  'onpointermove' in document.body
    ? 'pointer'
    : 'mouse'
);
// Shorthands for 'mouse' or 'pointer' events
const [downEvt, upEvt, moveEvt, outEvt] = (
  ['down', 'up', 'move', 'out']
    .map(evtType => pointerEvent + evtType)
);

// Drag events
let dragOrigin;
canvas.addEventListener(downEvt, dragStartHandler)
function dragStartHandler(e){
    dragOrigin = {
        x: e.clientX,
        y: e.clientY
    };
    document.addEventListener(moveEvt, dragHandler);

    window.addEventListener(upEvt, dragStopHandler);
    window.addEventListener(outEvt, dragStopHandler);

    canvas.addEventListener(outEvt, stopPropagation);
    document.body.addEventListener(outEvt, stopPropagation);
}

function dragHandler(e){
    if (e.ctrlKey || e.metaKey) {
        if (e.altKey) sphere.hiddenFun2(e.clientX-dragOrigin.x, e.clientY-dragOrigin.y);
        else sphere.zoom(e.clientX-dragOrigin.x, e.clientY-dragOrigin.y, -1);
    }
    else if (e.shiftKey) {
        if (e.altKey) sphere.hiddenFun1(e.clientX-dragOrigin.x, e.clientY-dragOrigin.y);
        else sphere.pan(e.clientX-dragOrigin.x, e.clientY-dragOrigin.y);
    }
    else {
        sphere.rotate(e.clientX-dragOrigin.x, e.clientY-dragOrigin.y);
    }
    dragOrigin.x = e.clientX;
    dragOrigin.y = e.clientY;
}

function dragStopHandler(e) {
    document.removeEventListener(moveEvt, dragHandler);
    document.removeEventListener(upEvt, dragStopHandler);
    document.removeEventListener(outEvt, dragStopHandler);

    canvas.removeEventListener(outEvt, stopPropagation);
    document.body.removeEventListener(outEvt, stopPropagation);
}

function stopPropagation(e) {
    e.stopPropagation();
}

By the way, while working on this I discovered that Chrome's dev tools are very nice for emulating mobile devices with touch events!

Oh, one final thing. I had to add a CSS rule to the canvas to make touch work properly: touch-action: none;. This basically prevents the browser from capturing touch events to try and scroll the page, and lets me use them in my JavaScript.

Finished product

It was a lot of iteration, and to be honest I tweaked it a bunch more while writing this article, but it's out there! Here's what it looks like with all the updates:

Conclusion

There are still things I'd like to fix. The biggest issue I have is that it's not mobile friendly, really at all. Not only do zoom and pan not work on mobile, but the webpage itself is almost completely non-responsive. I'd like to add some CSS to handle especially small page sizes more cleanly. Maybe I'll tweak it some more after this 🤔 As I said at the top, I'd love any feedback you might have! Heck, if you're feeling generous, make a PR against the repo!

But here's my overall takeaway: HTML, CSS, and JavaScript have improved a ton in the last 7 years, and so have I as a developer. Experience is an amazing thing!

In the final part of this series, which I'll write...eventually, I'll walk through the JavaScript itself and talk about how it works. That one will really be a standalone tutorial on how to build a thing with <canvas> in vanilla JavaScript, not really dependent on these previous two posts.

Rewriting an old project! Part 1: HTML & CSS

Ken Bellows — Mon, 08 Apr 2019 20:52:32 +0000

Backstory

I'm a guy who's been around the web for a while. I learned JavaScript at age 12 (talking 2003 here, IIRC) when I found Steven W. Disbrow's JavaScript Weekend Crash Course on my dad's bookshelf, sat down with it at the Windows 95 machine my dad had rescued for me from the trash heap at his corporate IT job, opened Notepad and IE6, and started hacking away. As I recall, this is roughly the code that got me hooked:

for (var i=0; i<10000000000000; i++) {
    document.write(i + ' ');
}

And of course, the reason it got me hooked was that, when I added enough zeroes to the number in the conditional, it crashed my browser. And that meant I was a

..................................................................................
..................888.....................888.....................................
..................888.....................888.....................................
..................888.....................888.....................................
..................88888b...8888b....d8888b888..888..d88b..888d888.................
..................888."88b...."88bd88P"...888..88Pd8P..Y8b888P"...................
..................888..888.d888888888.....888888K.88888888888.....................
..................888..888888..888Y88b....888."88bY8b.....888.....................
..................888..888"Y888888."Y8888P888..888."Y8888.888.....................
..................................................................................
.............._____________________________________________________...............
....._,aad888P""""""""""Y888888888888888888888888888888P"""""""""""Y888baa,_......
....aP'$$$$$$$$$$$$$$$$$$$$$`""Ybaa,.........,aadP""'$$$$$$$$$$$$$$$$$$$$$`Ya.....
...dP$$$$$$$$$$$$$$$$$$$$$$$$$$$$$`"b,.....,d"'$$$$$$$$$$$$$$$$$$$$$$$$$$$$$Yb....
...8l$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$8l_____8l$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$8l...
..[8l$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$8l"""""8l$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$8l]..
...8l$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$d8.......8b$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$8l...
...8l$$$$$$$$$$$$$$$$$$$$$$$$$$$$$dP/.......\Yb$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$8l...
...8l$$$$$$$$$$$$$$$$$$$$$$$$$$$,dP/.........\Yb,$$$$$$$$$$$$$$$$$$$$$$$$$$$$8l...
...8l$$$$$$$$$$$$$$$$$$$$$$$$,adP'/...........\`Yba,$$$$$$$$$$$$$$$$$$$$$$$$$8l...
...Yb$$$$$$$$$$$$$$$$$$$$$,adP'...................`Yba,$$$$$$$$$$$$$$$$$$$$$dP....
....Yb$$$$$$$$$$$$$$$$,aadP'.........................`Ybaa,$$$$$$$$$$$$$$$$dP.....
.....`Yb$$$$$$$$$$,aadP'.................................`Ybaa,$$$$$$$$$$dP'/.....
.......`Ybaaaaad8P"'.........................................`"Y8baaaaadP'........
..................................................................................

hacker 😎
(btw, ascii art lifted from here and here, with some modifications)

Anyhow. Fast forward like 8 or 9 years. I'm at college, senior year, 2012 I think, avoiding work. I've never lost my love for the web, though I'm a little closeted about it, given that it was the height of the "JS Sucks" movement. But I often spent a portion of my procrastination hours hacking on small JS projects to get my hit. I ran across a tutorial (probably this one, though I'm not sure) talking about the relatively new HTML5 <canvas> and how to make a little faux-3D sphere using dots with varying shades of gray to simulate depth. And I thought the result was cool, so I decided to try and figure it out on my own without reading the tutorial.

I did, and I was pretty happy with the result. I even added some interactivity that the original didn't have, which was fun to figure out. Here it is, copy-pasted into a CodePen:

Looking back at the code now, it's still not terrible for the time. But man, it needs some updating. 2012 was a long time ago, and both I and the web have significantly improved since then.

So I thought I'd update the code, and it seemed like a fun idea to write it up as I go, to see what's changed in our wonderful web world (www) since 2012.

If you want to follow along, the repo is here: https://github.com/kenbellows/jsphere/
And the demo is here: https://kenbellows.github.io/jsphere/

The repo now has the new code pushed to the master and gh-pages branches, but I'll keep around the prior state of things in a branch named gh-pages__old, so check there for the complete previous code that went basically untouched for around 7 years.

Important: I'm not going to be discussing the content of the code here, what the code does or anything, just how I've updated the structure and syntax and such. However, I do plan to write a final post that discusses what the code actually does, and walks through it in proper tutorial style.

HTML

So first. That HTML. Not great. Here's the structure, very slightly abbreviated:

<html>
    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
        <script type="text/javascript" src="./js/jquery-1.7.1.min.js"></script>
        <script type="text/javascript" src="./js/jquery.event.drag-2.0.min.js"></script>
        <script type="text/javascript" src="./js/sphere.js"></script>
        <link rel="stylesheet"...>
    </head>
    <body>
        <!-- github link banner omitted -->

        <div id="header">
            <h1 id="header-title">jSphere</h1>
            <h2 id="header-subtitle">Just to see what I could do.</h2>
        </div>
        <div id="controls">
            <h3 id="controls-title">Controls</h3>
            <div id="controls-body">
                <p id="c-1">Rotate:  Click and drag</p>
                <p id="c-2">Pan:     Hold shift, click and drag</p>
                <p id="c-3">Zoom:    Hold ctrl, click and drag</p>
            </div>
        </div>
        <div id="content">
            <canvas id="canvas" width="800" height="700"></canvas>
            <p id="psst">Psst. There are a couple (that's 2) hidden key combos that do some things that I found by accident, so play around.</p>
        </div>
    </body>
</html>

Okay. Reflections:

~~No need to put the script tags in the header. Just drop them at the end of the body. This removes the need for the jQuery $(function(){ ... }) wrapper.~~ Update: As pointed out in a comment by @crazytim, this approach is also pretty outdated! <script>s at the end of the <body> can't start downloading until the rest of the HTML is parsed and dealt with, which slows things down, and there's a standard solution to this: the defer attribute, which tells the browser to download the file so it's ready, but wait until the DOM is fully parsed before running it. Exactly what I need! So I should really keep my script in the <head>, but use <script defer ...>, which sill gets rid of the $(function(){ ... }) wrapper. Thanks Tim!
Also, we don't need jQuery anymore. It made the world a ton easier back in the day, but these days it's just not necessary, especially for a project as small as this one. I'm pretty sure I only imported it to use the $() element selector function and the jquery.event.drag plugin, both of which can be eliminated now.
Semantic HTML! I will never write another <div id="header"> again. Just use <header>! Same for <div id="content">: that's basically just <main>.
Man I loved ids! Every single element in the body has an id! That's so unnecessary. We have a rich CSS selector syntax (and did back then, too) to take care of finding the right things on the page.

So, here's how I'm restructuring the page. I've collapsed id="controls" and id="content" within the <main> block and significantly rearranged its insides, and that will be reflected in the CSS as well, but we'll get there next:

<html>
    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
        <link rel="stylesheet" type="text/css" href="./css/sphere.css">
        <link rel="stylesheet" type="text/css" href="./css/fonts.css">
        <script defer type="text/javascript" src="./js/sphere.js"></script>
    </head>
    <body>
        <!-- github link banner omitted -->

        <header>
            <h1>jSphere</h1>
            <h2>Just to see what I could do.</h2>
        </header>
        <main>
            <section id="controls">
                <h3>Controls</h3>
                <ul id="controls-listing">
                    <li>Rotate:  Click and drag</li>
                    <li>Pan:     Hold shift, click and drag</li>
                    <li>Zoom:    Hold ctrl, click and drag</li>
                </ul>
            </section>
            <canvas id="canvas" width="800" height="700"></canvas>
            <p class="psst">Psst. There are a couple (that's 2) hidden key combos that do some things that I found by accident, so play around.</p>
        </main>
    </body>
</html>

The big changes:

~~Moved the script to the end of the body~~ (see note above) Added the defer attribute to the <script> tag to eliminate the need for any onready type event handlers.
Removed jQuery. I'll have to redo the mouse interaction code that relied on the jquery.event.drag plugin, but that's okay; it's much easier these days anyhow.
Refactored the markup to use the semantic elements <header>, <main>, and <section>. Restructured the code to be more semantic. The previous structure was heavily influenced by the CSS layout modes available at the time (or lack thereof), so it's going to be a lot simpler to do what I want now.
On that note, got rid of almost every id. The only one I left is the one for the <section> tag, and I do think that sections need labels; there's often more than one, and they often need to be specifically selected in CSS, so they have value IMO.

Okay, now for the CSS to match.

CSS

Here's the old stuff. Remember that it goes with the first HTML sample above. I'm skipping the font and color stuff, as it's all pretty standard and stayed the same. The interesting bits are the layout and selectors related to the refactored HTML from above.

#header {
    position: relative;
    width: 100%;
}
#header-title, #header-subtitle {
    width: 500px;
}
#header-subtitle {
    font-style: italic;
}

#content {
    padding: 0px;
    width: 810px;
    height: 900px;
    margin: 0px auto;
    position: relative;
    top: -50px;
}

#canvas {
    border: 2px solid black;
    z-index: 2;
}

#controls {
    width: 810;
    height: 200px;
    margin-left: auto;
    margin-right: auto;
    margin-top: 60px;
    margin-bottom: -50px;
    z-index:1;
    position: relative;
}
#controls-title {
    width: 75px;
    margin-bottom: 15px;
}
#controls-body {
    width: 100%;
    position: relative;
    margin: 0px;
}

#c-1 { /* Rotate */
    position: absolute;
    left: 0px;
    top: 0px;
    margin: 0px;
}
#c-2 { /* Pan */
    position: relative;
    width: 200px;
    text-align: center;
    margin: 0px auto;
    right: 10px;
}
#c-3 { /* Zoom */
    position: absolute;
    right: 10px;
    top: 0px;
    margin: 0px;
}

#psst {
    font-style: italic;
}

Hoo that's a lot of absolute positioning and fixed lengths. Now, I do want to emphasize that this was a little weekend hack that I didn't want to spend a lot of time on, and I didn't have all the layout methods available to me that we have now, but still... seems unnecessary. I was rushing, I think.

Of particular interest are the three <p> tags describing the Rotate, Pan, and Zoom controls. I gave them each an id, #c-1, #c-2, and #c-3, and positioned them absolutely to get the alignment I wanted. I think this was caused by the difficulty of centering one item and side-aligning the other two at the time. You could do it with tables, but... tables for layout were taboo even in 2012. I wouldn't dare except as an absolute last resort. Absolute positioning was definitely better in my mind.

(In retrospect, this was very silly of me, and a quick CSS table (I think those were supported at the time?) or even an HTML table would have been a much cleaner solution.)

Nowadays, we have two more options for layout: Flexbox and Grid. My first instinct when rewriting was just to lay down a quick flex container with a justify-items: space-between, since it's fewer lines. But I remembered after implementing that this is a classic corner-case where Flexbox acts slightly differently than you might expect, unless you really understand how it works.

Don't get me wrong, it behaves in a totally fine and predictable and useful way, just not how I thought it did. I initially wrote up an explanation of that distinction here, comparing it to CSS Grid, but it turned out super long, so I published it in its own post here: Flex items are not grid columns

The outcome of that post is that I used the following CSS on the parent <ul> element from the new HTML above:

ul#controls-listing {
    grid-auto-flow: columns;  /* automatically place new items in new columns */
    grid-auto-columns: 1fr;   /* auto-columns should be 1fr wide */
}

I used the auto-flow method rather than, say, grid-template-columns: 1fr 1fr 1fr,
because I like to future-proof my code as long as it doesn't add much work, and this method neatly handles any number of items, so I can add more controls later if I want to.

I also used a couple text-align rules on the grid items to center-align them by default, then left-align the first item and right-align the last one:

ul#controls-listing > li {
    text-align: center;
}
ul#controls-listing > li:first-child {
    text-align: left;
}
ul#controls-listing > li:last-child {
    text-align: right;
}

The rest of the CSS changes are mostly updated selectors to (1) take into account the HTML restructuring and (2) use element selectors where possible instead of all those #id references. Her's the full final result:

header > h2 {
    font-style: italic;
}

main {
    max-width: 810px;
    margin: 0px auto;

    display: flex;
    flex-direction: column;
    align-items: stretch;
}

#controls > h3 {
    text-align: center;
    margin-bottom: 15px;
}

ul#controls-listing {
    /** removing the default ul padding*/
    padding: 0;

    /* flexbox fallback if grid is not supported */
    display: flex;
    justify-content: space-between;

    display: grid;
    grid-auto-flow: column;
    grid-auto-columns: 1fr;
}
ul#controls-listing > li {
    list-style: none;
    text-align: center;
}
ul#controls-listing > li:first-child {
    text-align: left;
}
ul#controls-listing > li:last-child {
    text-align: right;
}

canvas {
    border: 2px solid black;
}

.psst {
    font-style: italic;
}

That's a whole lot less CSS, and I hope you'll agree it's a whole lot cleaner and more readable. Flexbox and Grid have really made a difference in that area, and I'm very happy about the future of the web.

Cliffhanger

So that's it for the HTML and CSS. The JavaScript is a whole other ball of wax, and requires its own post for sure. So I'll leave it here. I hope you've enjoyed this; it's definitely a bit cathartic to tear apart old code and congratulate myself on having improved as a developer in the last 7ish years, but it's also very exciting to see how much easier even very simple layouts like this one are in the new era of CSS layout methods.

See you next time!

Flex items are not grid columns

Ken Bellows — Mon, 01 Apr 2019 16:59:53 +0000

We often talk about Flexbox's growy-shrinky rules, like flex-grow and justify/align-content/items, as working basically identically to the fr unit introduced with CSS Grid. That works as an introduction to frs for devs who are familiar with Flexbox, but it's not really true. There's a subtle but very important difference that sometimes shows up.

Scenario: Three differently-sized text items in a row

Let me lay down a scenario, as I love to do. This is a specific case of a general scenario that I have encountered pretty often, and it was a common frustration that's solved neatly by CSS Grid.

Consider a case where we have 3 inline elements, e.g. text labels, buttons, or images, of different sizes that need to be displayed neatly in a row. We want the first label to be left-aligned, the last one to be right-aligned, and the middle one to be centered on the page.

Here's an example of this that comes from an old weekend project of mine from college (that I hope to write more extensively about in future articles, but that's beside the point). This project was an experiment with the HTML5 <canvas> element, and it had an element of keyboard and mouse interaction. There were three primary controls, and I had three text labels above the canvas listing these controls:

So that's the goal. The most important requirement, the one that will cause problems, is that the middle item must be centered on the page: its center line should match the center line of the page. (In some cases, "page" is just "container", but "page" is easier to demonstrate.) I've included the heading above the labels to give a useful visual landmark to compare against.

Old school cool

Back in college, in the pre-flexbox days of 2012(ish), I solved this with some very brittle HTML+CSS that used a lot of absolute positioning:

I've absolutely positioned the first and last labels to be on the same line as the middle element, stuck to the left or right. This... works, of course, but could be disrupted by certain changes to the surrounding layout, is very non-reactive, is pretty unreadable, and is inflexible: if you wanted to add a fourth control, everything would become a lot more complex.

Flexbox

If we were going to write this with modern CSS, the first thought might be to use Flexbox. It was certainly my first thought; this is a 1-d layout situation, which is what Flexbox is best at. Plus, I was pretty sure I could do it in two lines of CSS:

#controls-body {
    display: flex;
    justify-content: space-between;
}

Done! Right?

... Nope.

While we do have three items, with one pulled left, another pulled right, and the other floating between them, you should see right away that the middle item is not centered properly; namely, instead of being centered on the page, it's centered between the other items. This would work fine if the items on the end are always the same size, but otherwise it's a no-go.

Another thing you might try is to not use justify-contents on the parent, but instead give all columns flex-grow: 1, then add some text-align rules to each. But this turns out to have exactly the same visual result:

Why don't these work? Well, we'll get to that in a minute. First, we'll look at something that does work.

Grid

Let's take the intuition from the second Flexbox attempt, to give each inline item its own "column" and make those "columns" the same size, and translate it over to CSS Grid, where we can drop the quotes: we'll literally define a column in a grid for each item and give them the same size using the fr unit introduced with Grid.

There are two ways to do this. The most obvious is to define three explicit columns:

#controls-body {
    grid-template-columns: 1fr 1fr 1fr;
}

Nice and clean. But I like to future-proof my code, as long as it doesn't add much work or complexity. So instead of explicitly defining a set of columns, let's use Grid's auto-flow rules to handle any number of items, in case I want to add more controls to my demo later on:

#controls-body {
    grid-auto-flow: columns;  /* automatically place new items in new columns */
    grid-auto-columns: 1fr;   /* auto-columns should be 1fr wide */
}

Combine these rules with the text-align rules above, and we get a winner:

So a grid with three 1fr columns works, but a flex container with three flex-grow: 1 items, or with justify-content: space-between, doesn't. Why? What's the difference?

The difference

So here's the thing. We often talk about Flexbox's flexy "distribute space evenly" rules, like flex-grow and justify-content: space-between, as being effectively the same as the fr unit introduced with CSS Grid. That works as an intuitive explainer of frs for devs who are familiar with Flexbox but new to Grid, but it's not really true. There's a subtle but very important difference that sometimes shows up, and it will explain the discrepancy here.

In Flexbox, space-between, flex-grow, etc. divide up the remaining space after all items are placed into the area. So if you have a 100px container with justify-content: space-between, as we do here, and three items of sizes 10px, 40px and 20px, Flexbox does the following calculation (roughly):

remainder = available space - total used space
          = 100px - (10px + 20px + 40px) = 100px - 70px
          = 30px
space between items = remainder / (# children - 1)
                    = 30px / (3-1) = 30px / 2
                    = 15px

The resulting layout is:

10px item | 15px space | 40px item | 15px space | 20px item

And the problem is that centering is not maintained. That 40px item's center point falls at 10px + 15px + (40px/2 = 20px), which is 45px. So it's 5 pixels off from the true center of the container, which is at 50px.

Grid's fr unit is different. It lays out the total space given to a grid item before considering the size of the item. So if we make our 100px container a grid-container with grid-template-columns: 1fr 1fr 1fr, Grid does the following calculation before it even considers the contents of the grid-items:

remainder = available space - (fixed size column widths)
          = 100px - 0
          = 100px
pixels per fr = remainder / (how many frs used across all column widths)
              = 100px / (1fr + 1fr + 1fr) = 100px / 3
              = 33.333px

So each `1fr` column gets 33.333px, an even third of the space. This means the center of the second column will fall at `33.333px + (half of 33.333px = 16.667px)`, which is a nice round `50px`!

> One very important thing that I totally didn't explain up there is the `fixed size column widths` variable, which in our case is `0`. This is the sum of any columns with values defined in a fixed unit, like `px`, `rem`, `in` (yeah, you can use inches in CSS! Nice for print layouts), or even `%`, which is fixed for the current size of the browser window. So for example if we used the rule `grid-template-columns: 30px 1fr 1fr`, then the calculation changes to this:
>```

python
remainder = available space - (fixed size column widths)
          = 100px - 30px
          = 70px
pixels per fr = remainder / (how many frs used across all column widths)
              = 70px / (1fr + 1fr) = 70px / 2
              = 35px

So in this case, each 1fr column gets 35px.

Conclusion

Hopefully this gives some more insight into how Flexbox works, and gives someone who's still been holding out a reason to reconsider looking into Grid. It's shocking to me how many people I still encounter who are deeply skeptical of Grid.

As a final note, I want to be clear on something here: I am not saying that the fr unit is superior to Flexbox's behaviors. There are absolutely cases where Flexbox's behavior is exactly what you want. In many, many cases, it's more important to evenly divide the remaining space among siblings than to keep them all sitting in the same amount of space. Flexbox also allows for a lot more complexity around how items grow and shrink ("flex") based on the container. Maybe I'll write a thing about that at some point. Anyway, my point here is by no means to say that Grid's fr units are better than Flexbox, only that they are easier for this specific case. I still love Flexbox 💕💕💕

Endnote: tables

Sigh. Yes, yes, I know: you can do it with tables. Pretty cleanly, actually, especially if you use CSS tables instead of actual tables:


css
#controls-body {
  width: 100%;
  display: table;
  table-layout: fixed;
}
p {
  display: table-cell;
}

That plus the text-align rules gives us another winner:

And honestly, this would have been much a better solution for me in 2012, even if I had to use actual tables because of limited browser support for CSS tables.

But here's my big problem with this. It's not just the oft-repeated, rarely-explained wisdom to "never use tables for layout" (although, seriously, now that we have Grid, never use tables for layout). This really is a decent enough solution in a pre-Grid context; it's clean, it's robust enough to handle adding extra items, and the code is readable, as long as you know what CSS tables are.

No, my problem comes in one word: responsiveness. Because it's not responsive, especially with an HTML table, and CSS tables aren't much better . Sure, you could drop the items into a single column for the mobile view. But suppose you had 4 columns, and wanted a 2x2 layout at an intermediate range. How would you do it with tables? You'd be hard pressed to do it without falling back to absolute positioning shenanigans again.

I won't say it's impossible; I can think of a couple options already, but they're not pretty, and they all have drawbacks. And most importantly, most, if not all, are specific to the current number of items, which makes for brittle code.

Grids, on the other hand, are amazingly responsive. It's trivial to redefine a grid's rows and columns, or to place things on a grid differently, so at minimum a media query breakpoint would be easy. (I wrote a whole article raving about Grid Areas, a feature that makes breakpoints that much more useful: CSS Grid Areas are amazing.) But in many cases, a breakpoint is unnecessary; Grid was built from the ground up with responsiveness in mind, and has many feature that support it, like repeat(auto-fill, ...) and minmax().

For more on all this, I highly recommend checking out Rachel Andrew's gridbyexample.com and Jen Simmons' Layout Land.

DEV Community: Ken Bellows

String.prototype.search(): a method I wish I knew about a long time ago

What it does

How ES6 made it even more powerful

A brief aside about Symbols

The JavaScript Iteration Protocols and How They Fit In

Ken Bellows ・ Dec 27 '18 ・ 12 min read

Back to the story

Conclusion

Endnote

What's your preferred Node.js testing setup?

My confusions about TypeScript

Class types

Overriding methods with different return types

Dealing with simple objects

Conclusion

Chromium and the browser monoculture problem

What does "browser monoculture" even mean, and why should we care?

An emerging Chromium monoculture?

What about Firefox? 🔥🦊

Do we have a monoculture?

Is it bad?

Privacy

Single Dominant Platform

Web Standards

My crazy idea

A collaborative engine

What about the lost diversity of implementation?

Wrapping up

More resources

AskDev: Real-time group project collaboration tools?

What cool ideas have you seen for integrating new team members?

"currentColor", the first CSS variable

What is it?

Browser support

Demo: Badges

Conclusion

Do you use a CSS framework based on CSS Grid?

Why I care about the Semantic Web

Three reasons

Semantic HTML is not primarily about improving code readability

The bottom line

Forgotten and ignored users

Further reading

Rewriting an old project! Part 2: JavaScript

Last time...

Minutia: nah.

Bro, do you even loop?

Classes!

Re-separating my concerns

Don't mess with the prototype!

Removing jQuery

Touch support for mobile 😭

Finished product

Conclusion

Rewriting an old project! Part 1: HTML & CSS

Backstory

HTML

CSS

Cliffhanger

Flex items are not grid columns

Scenario: Three differently-sized text items in a row

Old school cool

Flexbox

Grid

The difference

Conclusion

Endnote: tables