Mike Taylr Dot Com Web Log

A new, new logo for the W3C

Mike Taylor — Sat, 25 Oct 2025 00:00:00 -0400

In an effort to pivot this site into a full on graphic design side business after 2 blog posts about logos in a row (hit me up exclusivly on FB to request a consultation), I thought I would reveal my new, new logo for the W3C.

It turns out they recently launched a new one, but some folks don’t love it. As an artist, it’s not my job to critique other art, but instead to offer my own compelling vision for the web.

I shouldn’t have to explain why I went with the classic dark blue and asparagus colors—that much is obvious. And of course, turning c into a file extension as a reminder that NCSA Mosaic was written in C (I didn’t go with WorldWideWeb because that was written in Objective C and .m kinda messes it all up).

The origins of the WHATWG Compat Standard logo

Mike Taylor — Fri, 27 Sep 2024 00:00:00 -0400

Note from the future (Oct 20, 2025): I just opened my editor and found this half-written draft. Might as well publish it.

It’s a bit awkward that I haven’t blogged in some 19 months so, as owner and author of the best blog about broken websites on the internet. I guess I’ve been busy, or lacking motivation to write, or perhaps both. Who can really say.

But this morning I was just sitting at a table on the 5th floor of the extremely under construction Hilton Anaheim (location of the 2024 W3C TPAC) telling Dom Farolino about the origin of the WHATWG Compat Standard logo.

Today, it lives at https://un5pn558caqx75mtmf2verhh.julianrbryant.com/logo-compat.svg. If you check out the source, you should see something like:

<svg xmlns="https://umn0mtkzgkj46tygt32g.julianrbryant.com/2000/svg" viewBox="0 0 100 100">
  <rect width="90"
        height="90"
        fill="#fff"
        x="5"
        y="5"
        stroke="#3c790a"
        stroke-width="10"
        style="-webkit-border-radius: 10px"/>
  <path d="(omitted)" fill="#3c790a"/>
</svg>

There’s clearly a hilarious joke in the inline style. Please clap.

If you dig into the history of the spec, though, you’ll notice Karl Dubost’s first stab at the logo as the repo’s first commit. Which is certainly one way to begin the commit history of a nascent standard. Thankfully that version only lasted a day, and a little more than a week later that was replaced by the current square logo.

Remember when the IE 11 User-Agent forced Mozilla to freeze part of its User-Agent string (last week)

Mike Taylor — Thu, 29 Dec 2022 00:00:00 -0500

If you happen to be using Firefox Beta 109 on an overpriced MacBook Pro that has a sticky letter s today (the 29th of December, 2022), this is what the User-Agent string looks like:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/109.0

And as of last week, the UA string in Firefox for versions 110 and higher looks like so:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/110.0

If you managed to visually discover the difference (I guess in the world’s lamest “Spot the Difference” game), congrats. If you didn’t, take note that rv:109.0 did not change in the second one—but Firefox/110.0 did.

So why did Mozilla just freeze rv:109.0 in the User-Agent string? Perhaps forever, or just perhaps until Firefox 120 is released?

Presumably in an attempt to unburden itself from a legacy of UA-sniffing-driven workarounds for a browser that hadn’t historically supported a lot of useful things (like WebGL, or some ES5 or ES6 stuff - I don’t really remember and can’t be bothered to look it up), the IE team decided to change up their User-Agent string back in 2013.

Here’s the IE10 UA, which followed the same-ish predictable pattern they had since IE 2.0:

Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; Trident/6.0)

And here’s an IE11 UA:

Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; AS; rv:11.0) like Gecko

Basically they were trying to solve the problem of “now that we’ve invested seriously in web standards, how do we get access to content that makes use of those features, and still have a detectable version number for analytics (or whatever). And it doesn’t not makes sense to borrow Firefox’s rv: convention to accomplish that (slapping an extra “like Gecko” in there for good luck can’t hurt, I suppose (but more realistically, there was probably some bank or government site that sniffed for Safari’s like Gecko token)).

And then cut to today, about 9 years later where a handful of sites (including popular ones like bestbuy and cvs) tell Firefox users to upgrade to a modern browser, because there’s probably something really clever like var isIE = /rv:11/i.test(navigator.userAgent);.

That’s obviously lame, and hence, Mozilla has frozen another part of its UA string for compatibility. Anyways, happy new years, especially to the folks working to make sure the web is still usable in Firefox.

How to get the Chrome major version from the User-Agent or UA-CH headers

Mike Taylor — Mon, 24 Oct 2022 00:00:00 -0400

Over the weekend frontend-firebrand Alex Russell tweeted that it’s confusing these days to know how to get the major version of a Chromium browser, either via the User-Agent header (given User-Agent Reduction), or from User-Agent Client Hints.

(btw, I asked DALLE2 Alex’s question “Can you make hide or hare of this?”, and yeah, it mostly can.)

Before I spend any energy improving the docs (thanks for the bug, Alex), let me try to give the simplest answer to the question: how do I find out what major version of Chromium a user is on in the year 2022+?

There’s two ways to go about this.

User-Agent

In Chrome 101, we shipped the terribly named “Phase 4” (that’s on me) part of the User-Agent Reduction project. Prior to version 101, you would see something in the User-Agent (either via HTTP or reflected by navigator.userAgent) that looks like so:

"Chrome/100.0.4896.75"

In Phase 4, we reduced the MINOR.BUILD.PATCH portions of the version to the constant “0.0.0”:

"Chrome/101.0.0.0"

But in terms of browser version changes coming to the UA string, that’s it. So if your use case is simple and you just need the major version of the browser, you can continue to parse the UA string as before (hopefully using an actively maintained project like ua-parser)—it will continue to be updated for each new major version update (as I write this, my browser reports Chrome/106.0.0.0).

User-Agent Client Hints

If you want to get slightly fancier, and ditch your existing UA parsing library dependency (but maybe pick up a structured headers parsing library dependency), you can get the Chrome version from the new Sec-CH-UA header.

Sec-CH-UA: "Chromium";v="106", "Google Chrome";v="106", "Not;A=Brand";v="99"

Admittedly, it looks kinda weird. But the good news is you don’t have to care about Client Hints to receive the header—it’s sent by default. Feel free to consult https://un5xmzagg340.julianrbryant.com/migrate-to-ua-ch/ if you do have to care about those.

The other cool thing is you can use the new navigator.userAgentData.brands API to get the equivalent of Sec-CH-UA header and do something like the following (maybe working around a known bug) and it will work in Chrome, Chromium, Edge, Opera, Brave, etc.

navigator.userAgentData.brands.some(
  item => item.brand == "Chromium" && item.version > 105
)

So that’s it. If you need the major version of a Chromium browser you can keep using User-Agent, or use Sec-CH-UA.

But if you need the full version of the browser, or the OS, that’s a different blog post I’ll get to once someone tweets their way onto my TODO list.

Chrome 100 Breakage Playbook

Mike Taylor — Mon, 21 Mar 2022 00:00:00 -0400

If you somehow found this blog post because you googled or binged “site not working Chrome 100”, well, congrats my SEO trap worked successfully.

Also, don’t panic.

The quickest way to test if your site is broken due to a 3-digit version parsing bug is to temporarily enable the chrome://flags/#force-major-version-to-minor flag and restart the browser. This will change the version that Chrome reports in the User-Agent string and header from 100.0.4896.45 (or whatever the real version number will be) to 99.100.4896.45. If the site works again, you know you have a UA string parsing bug. Congrats again!

(Also, test your site in Firefox Nightly - not all three digit parsing bugs will affect both Chromium browsers and Firefox, but it’s good to verify in case you need to fix your bugs in multiple places.)

At this point, please file a bug at crbug.com/new. That will automatically cc me. Or just feel free to tweet at me or email me. Swing by the house if you want, but we have dinner around 6pm. After dinner is better.

Or, best yet, just fix your site bugs without me being in the loop and I will be so proud of you.

How to delete your jQuery Reject Plugin in 1 easy step.

Mike Taylor — Fri, 01 Oct 2021 00:00:00 -0400

In my last post on testing Chrome version 100, I encouraged everyone to flip on that flag and report bugs. It’s with a heavy heart that I announce that Ian Kilpatrick did so, and found a bug.

(⌣_⌣”)

The predictable bug is that parks.smcgov.org will tell you your browser is out of date, and recommend that you upgrade it via a modal straight out of the year 2009.

(Full Disclosure: I added the FarmVille bit so you can get back into a 2009 headspace, don’t sue me Zynga).

The bug is as follows:

r.versionNumber = parseFloat(r.version, 10) || 0;
var minorStart = 1;

if (r.versionNumber < 100 && r.versionNumber > 9) {
  minorStart = 2;
}

r.versionX = r.version !== x ? r.version.substr(0, minorStart) : x;
r.className = r.name + r.versionX;

Back when this was written, a version 100 was unfathomable (or more likely, the original authors were looking forward to the chaos of a world already dealing with the early effects of climate change, and now we have to deal with this?, a mere 11 years later) so the minorStart offset approach was perhaps reasonable.

There’s a few possible fixes here, as I see it:

I. Kick the can down the road a bit more:

if (r.versionNumber < 1000 && r.versionNumber > 99) {
  minorStart = 3;
}

I don’t really plan on being alive when Chrome 999 comes out, so.

II. Kick the can down the road like, way further:

r.versionX = Math.trunc(parseFloat(r.version)) || x;

According to jakobkummerow, this should work until browsers hit version 9007199254740991 (aka Number.MAX_SAFE_INTEGER in JS).

III. (Recommended) Just remove this script entirely from your site. It’s outlived its purpose.

Also, if you happen to work on any of the following 1936 sites using this script, you know what to do (pick option Roman numeral 3, just to be super clear).

Testing Chrome version 100 for fun and profit (but mostly fun I guess)

Mike Taylor — Tue, 21 Sep 2021 00:00:00 -0400

Great news readers, my self-imposed 6 month cooldown on writing amazing blog posts has expired.

My pal Ali just added a flag to Chromium to allow you to test sites while sending a User-Agent string that claims to be version 100 (should be in version 96+, that’s in the latest Canary if you download or update today):

I’ll be lazy and let Karl Dubost do the explaining of the why, in his post “Get Ready For Three Digits User Agent Strings”.

So turn it on and report all kinds of bugs, either at crbug.com/new or webcompat.com/issues/new.

Slack is optimized for Firefox version 520

Mike Taylor — Mon, 15 Mar 2021 00:00:00 -0400

Last week my pal Karl sent me a link to web-bug 67866: which has the cool title “menu buttons don’t work in Firefox version 100”. It turns out that Mozilla’s Chris Peterson has been surfing the web with a spoofed UA string reporting version 100 to see what happens (because he knows the web can be a hot mess, and that history is bound to repeat itself).

The best part of the report, IMHO, is Chris’ comment:

I discovered Slack’s message popup menu’s buttons (such as “Add reaction” or “Reply in thread”) stop working for Firefox versions >= 100 and <= 519. They mysteriously start working again for versions >= 520.

(I like to imagine he manually bisected Firefox version numbers from 88 to 1000, because it feels like something wacky that I would try.)

<aside> + spoiler The bug described below is a slightly different class of bugs than the typical “regexp expected a fixed set of integers and fell on its face, which is where the famous Bill Gates quote “9 major browser versions ought to be enough for anybody” came from (see also Opera version 10 drama, and macOS version 11 drama, etc). And still a different class of bugs from the even more fun and possibly not true explanation for Windows 10 coming after Windows 8 (because software was sniffing for strings that started with “Windows 9”) and going down paths assuming Windows 95 or Windows 98).

</aside>

Broken website diagnosis wizard Tom Wisniewski followed a hunch that Slack was doing string comparison on version numbers, and found the following code:

  const _ = c.a.firefox && c.a.version < '52' ||
            c.a.safari && c.a.version < '11'
              ? h
              : 'button',

(We’re just going to ignore what h is, and the difference between that and button presumably solving some cross-browser interop problem; I trust it’s very clever.)

So this is totally valid JS, but someone forgot that comparison operators for strings in JS do alphanumeric comparison, comparing each character between the two strings (we’ve all been there).

So that’s how you get the following comparisons that totally work, until they totally don’t:

> "10" < "1"
false // ok

> "10" < "20"
true // sure

> "10" < "2"
true // lol, sure why not

So, how should you really be comparing stringy version numbers? Look, I don’t know, this isn’t leetcode. But maybe “search up” (as the kids say) String.prototype.localeCompare or parseInt and run with that (or don’t, I’m not in charge of you).

Obsolete RFCs and obsolete Cookie Path checking comments

Mike Taylor — Mon, 08 Feb 2021 00:00:00 -0500

The other day I was reading Firefox’s CookieService.cpp to figure out how Firefox determines its maximum cookie size (more on that one day, maybe) when the following comment (from 2002, according to blame) caught my eye:

The following test is part of the RFC2109 spec.  Loosely speaking, it says that a site cannot set a cookie for a path that it is not on.  See bug 155083.  However this patch broke several sites -- nordea (bug 155768) and citibank (bug 156725).  So this test has been disabled, unless we can evangelize these sites.

Note 1: Anything having to do with broken websites is wont to catch my attention, especially olde bugs (let’s face it, in 2002 the internet was basically the High Middle Ages. Like yeah, we were killing it with the technological innovation on top of windmills and we’re getting pretty good at farming and what not, but it’s still the Middle Ages compared to today and kind of sucked).

Note 2: The two sites referenced in the Firefox comment are banks (see 155768 and 156725). And one of the axioms of web compatibility is that if you break a bank with some cool new API or non-security bug fix, game over, it’s getting reverted. And I’m pretty sure you can’t legally create test accounts for banks to run tests against and Silk Road got taken down by the feds.

But at the time, the now obsolete rfc2019 had this to say about cookies Path attributes:

To prevent possible security or privacy violations, a user agent rejects a cookie (shall not store its information) if any of the following is true:

  * The value for the Path attribute is not a prefix of the request-URI.

Well, as documented, that wasn’t really web-compatible, and it’s kind of a theoretical concern (so long as you enforce path-match rules before handing out cookies from the cookie jar. ¯\_(ツ)_/¯). So Firefox commented out the conditional that would reject the cookie and added the comment above in question. As a result, people’s banks starting working in Firefox again (in 2002, remmeber, so people could check their online balance then hit up the ATM to buy Beyblades and Harry Potter merch, and whatever else was popular back then).

My colleague Lily pointed out that Chromium has a similar comment in canonical_cookie.cc:

The RFC says the path should be a prefix of the current URL path. However, Mozilla allows you to set any path for compatibility with broken websites.  We unfortunately will mimic this behavior.  We try to be generous and accept cookies with an invalid path attribute, and default the path to something reasonable.

These days, rfc6265 (and 6265bis) is much more pragmatic and states exactly what Firefox and Chromium are doing:

…the Path attribute does not provide any integrity protection because the user agent will accept an arbitrary Path attribute in a Set-Cookie header.

Never one to pass up on an opportunity to delete things, I wrote some patches for Firefox and Chromium so maybe someone reading Cookie code in the future doesn’t get distracted.

Aside 1: Awkwardly my moz-phab account has been disabled, so I just attached the patch file using Splinter like it’s 2002 (more Medieval code review tech references).

Aside 2: Both of these comments have two spaces after periods. Remember that?

The Mike Taylor method™ of naming git branches

Mike Taylor — Fri, 22 Jan 2021 00:00:00 -0500

I thought I would document how I do branching in git because it’s clearly ~~the best~~ a perfectly acceptable way to do it, especially if you use GitHub.

Step 1: git checkout -b <bug-number>/<rev>

(That’s it.)

<bug-number> maps to the GitHub (or Bugzilla, or Chromium, or Roblox customer support, etc.) issue number.

<rev> is an integer, and maybe 99% of the time it’s just 1 for me. But if, for whatever reason, you want to get wild and pivot off into a totally different direction, or set a new <start-point>, you just increment that integer and still have some kind of transparent relationship with the bug task at hand.

For example:

git checkout -b parsing_html_with_regex_in_the_year_2021/2

(edit: It’s been out to me that this example does not follow my own advice because there’s no <bug-number>, but instead <mike_trying_to_make_a_joke>. Oops.)

As a side benefit, when you go to write a commit message you don’t have to go hunting for the bug number in your N² + 1 open tabs (where N is the number of hours you’ve been working on the patches), because it’s in the branch name.

(For no good reason, for GitHub issues I like to prefix it with issues/, I guess I just like the symmetry with the GitHub URL.)

I started doing this about 10 years ago when I worked at Opera. I don’t know if it was a widely used convention, or I just copied it off someone, but it’s pretty good, IMHO.