I don't normally get so excited about the day a new browser version comes out, except the prior version of Chrome broke the ability to bold system fonts on Macs.
When this happened, the DEV team was really busy and we just sort of accepted not bothering any fancy workarounds, and we just waited for the next browser version. Bold temporarily not working all of a sudden is just not a scenario we prep for in our tech plannings. Not all sites use system fontsโwe prioritize performance and don't load custom fonts.
Stable is set for release on May 19th.
There are some other good features shipping in Chrome 83, like Trusted Types for DOM Manipulation, but fixing bold is definitely what I'm looking forward to the most. ๐ญ
Thank you to the hard working developers behind Chrome, everyone makes mistakes and I hope you all learned a lot in dealing with the issue.
Happy coding โค๏ธ
Top comments (9)
I didn't know about this. I've since looked into it and found out that the Chrome team knew about the bug before shipping. How is this acceptable?
How can such an integral part of font rendering not be a blocker for a release? I'm shocked.
Plenty of software ships with bugs. If you waited for the time you had zero bugs, you'd wait a long time.
my favourite example is here. trello.com/b/ZVrHV38P/apex-tracker
Respawn are open about bugs and you can see when they get fixed.
Perhaps number of users on autoupdate to chrome 81 on macs, who'd notice the font issue and complain was a small enough number to not delay the release by another day. Never know what the PM on the chrome team is arguing for/against.
Thanks for your comment, Matt. I agree that bugs are unavoidable and it's a part of the software. So I'm with you on that one. I'm super excited by the things being accomplished by the Chrome dev team and I think they're the main reason the web is so important today. Full credit to their ingenuity and hard work.
However, I'm sure you'd agree that some bugs/ aren't acceptable for publishing and should be 'blockers'. So now the question is, what is acceptable and what isn't?
Font rendering is a huge part of the browsing experience. Getting that right should be a priority. The Chrome team was aware of the bug before publishing (therefore it was avoidable). That fact alone makes this bug worth discussing because it wasn't found after publishing.
Since it was avoidable and I'd love to know the reasons why it wasn't considered as a blocker. From what I've seen. There has been no explanation. If there was I'd probably be happy and move on. Maybe I'm wrong. Maybe this doesn't affect accessibility and it fits within a margin of error. But I'd like to see that first before deciding.
I understand that there are pressures etc but Chrome is 65% + of the browser market share. That's a huge responsibility. All I'm asking is some clarity and openness on why that decision was made.
Yeah, maybe I'm being too nice to them. This was an incredibly frustrating situation.
Yeah, I'm thinking about writing an article about it since it shouldn't go unanswered by the Chrome team. I doubt they'll read my silly little article but it is serious enough to talk about as a community.
I mean, what about accessibility? As a community we talk all the time about making text legible, this seems like the antithesis of that.
/me laughs in firefox
More like laughs in firefox ๐
Yes, indeed. The Chrome team had to reschedule their release cadence due to the unforeseen consequences of lockdown measures.
Chrome 81 was significantly delayed. By the time Chrome 81 was released, there were only three or so weeks left before the originally scheduled stable release of Chrome 82, so the Chrome team decided to just skip Chrome 82 and move the Chrome 83 release at an earlier date.
On paper, nothing much should have changed in the release cadence except for the omission of Chrome 82.
This would explain why I wasted 2 hours trying to figure out why my entire site lost its bold fonts. I'd just compiled webpack and was furiously hunting down every package author thinking it was one of them!