fixing the font does not help those that downloaded the font and won't get the new version. it also does not prevent malicious code from replacing the font on your machine with a version that has the ligature.
in fact this could be a novel attack vector. replace fonts on victims devices to hide the true address of a website. the fix then would have to be to not display any ligatures at all in website addresses, which in my opinion would be a smart change.
Disabling ligature rendering in the omnibox seems significantly more sane and safe than this (why wouldn't you do that already?! URLs need to be displayed clearly - not be "aesthetically pleasing").
> fixing the font does not help those that downloaded the font and won't get the new version. it also does not prevent malicious code from replacing the font on your machine with a version that has the ligature.
Fixing the code doesn't help users that downloaded code and don't get the new version either.
Malicious code that can replace a font can replace a lot more too.
I can imagine a group of excited guys coming up with that idea as something cool, and then the whole thing slowly evolving into a yet another branding tool.
It’s difficult (impossible?) to force a font on the web in a way that can’t be overridden by some users. This must have been a font designed for device-specific applications picked up for other use-cases? Or maybe they just didn’t care that the long tail of users might see the string “googlelogoligature” instead of the logo.
I guess we have to disagree on that. When the Apple private-use code point shows as a box, you have no idea what it is supposed to represent. With the ligature you have the equivalent of an alt text.
The linked article on Unicode is far more interesting actually. I never really cared to think before how Unicode works, but reading the submission letter of beet emoji was the most interesting thing I've read this month so far.
> Fonts can include "ligatures", which let font designers special-case specific combinations of letters ... but the feature has been (ab)used for many other things
Same reason to not use ligatures in your IDE, terminal, etc.
Ligatures that give slightly stylized rendering to stuff like <!-- or even replace a >= with a ≥ in your source code view are much less prone to exploitation than a "ligature" that replaces a 18-letter sequence with the word "Google" in your browser's address bar. It's like comparing the hazardousness levels of a safety pin and of a chainsaw.
My great fear is they will become so popular that the option to disable them will be forgotten. I can’t stand the ligatures that noticeably change and merge the glyphs.
Those historical use cases are fine and important, the problem ones are the ones in monospace fonts that change <= to ≤ and that sort of thing, or even crazier abuses like shown here.
Fortunately, no. They’re increasingly well supported for the user base who think they look nice… like me.
I love the way my code looks in Berkeley Mono on any modern editor version. Seeing `>=` render similar to `≥` makes me smile. It’s a tiny visual tweak that doesn’t even cause anything to move on the screen, because that font’s ligatures are the same width as the characters they replace. I see no downside to it for me.
Personally, I find an extra-wide “≥” more ugly and jarring than “>=“. If anything, I would prefer programming languages to understand the actual Unicode “≥”, and people learning how type that (Compose key, dedicated IDE support, or whatever). It would be nice for more people to appreciate that the characters one can type aren’t limited to the symbols printed on the keyboard.
Every editor and language I use is fine with Unicode in files, but I don’t know if that’s true for everyone I collaborate with. Sure, I can type all those symbols, but can they? Does a screen reader pronounce them reasonably? Do they render correctly in GitHub’s web source code viewers? Will I ever get as fast typing composed characters as just pressing `>=`? Does everyone use a font that supports those codepoints? I don’t know. Probably, but who can tell? I tend to limit non-ASCII text to inside quoted strings and use exclusively ASCII-compatible codes for all identifiers.
But the great part about ligatures is that I can use fonts that support them and enable them in my editors because I think they look pretty. Anyone who doesn’t like their appearance can just not use them. We can both have editors that look nice to ourselves without making the other’s editors look worse. How often can we say that?
This is sort of my point: I would wish for the world to move towards typing Unicode symbols being a normal thing. That would also imply screen readers properly handling those (if they don’t already). What I don’t like is source code being rendered as something different than the actual printable characters it consists of.
I’m not disputing your preference, I was just stating mine. I do prefer “≥” over “>=“, but not in the form of a double-width ligature that is still “>=“ under the hood.
> Will I ever get as fast typing composed characters as just pressing `>=`?
Typing “>=” usually involves pressing three keys. The same can be true with Compose.
That’s not to say that there isn’t some trade-off in some cases. But the frequently used symbols can be prioritized, and it opens up a vastly larger repertoire of characters you can type. I routinely type foreign languages with accents and other non-ASCII letters using Compose, and it has become muscle memory.
The IDE could also do an automated ASCII to Unicode replacement for certain strings of characters if they are supported in a language, similar to how Microsoft Word automatically replaces (R) with ®, or the like.
Exactly. Though in an IDE it should only be done depending on whether the current language supports the Unicode operators in question. And ideally the replacement shouldn't happen when editing string literals. Though perhaps that is asking for too much.
in vim you can make these definitions dependent on the file type, which is also used to detect languages for eg syntax highlighting. so it's certainly possibly to define these only for a specific language. it should even be possible to define it based on the syntax detected: https://superuser.com/questions/487603/abbreviations-overrid...
I've been pushing the limits of emoji/Unicode recognition where I try to input it in an app or while communicating with others, and see what happens.
It's especially fun to use Emoji in the "favorite lists" for rideshare apps. In particular, each of my Favorite Waymo Destinations is accompanied by 3-5 Emoji which identify the unique spot or its category.
The really amusing part is that the Waymo car itself verbally reads off the destination when it gets underway. So the Emojis are translated into English and rattled off uncritically, but accurately, including incidentals like which skin-tones were chosen. It makes me giggle; I haven't found any unpronounceable glyphs yet!
hard disagree. i use monospace fonts with ligatures for programming. primarily i get things like -> rendered as a full arrow or == connected or ... as an actual ellipsis. it's subtle but it's nice.
I've also seen nice use of ligature for markdown formatting.
the idea that ligatures shouldn't be used with monospace fonts would also break monospace in multiple languages as some languages require ligatures to display single characters correctly.
I thought there was something wrong with this blog post that kept writing "googlelogoligature" but no some absolute cretin really added that as a ligature to the font.
Wow it still works.
The issue has been fixed on Chrome: https://issues.chromium.org/issues/391788835
But ligature is indeed still visible on Google search.
https://chromium-review.googlesource.com/c/chromium/src/+/62...
Gotta love that the patch isn't fixing the font, but adding a rule for domain names which contains a substring similar to the ligature name...
fixing the font does not help those that downloaded the font and won't get the new version. it also does not prevent malicious code from replacing the font on your machine with a version that has the ligature.
in fact this could be a novel attack vector. replace fonts on victims devices to hide the true address of a website. the fix then would have to be to not display any ligatures at all in website addresses, which in my opinion would be a smart change.
Disabling ligature rendering in the omnibox seems significantly more sane and safe than this (why wouldn't you do that already?! URLs need to be displayed clearly - not be "aesthetically pleasing").
> fixing the font does not help those that downloaded the font and won't get the new version. it also does not prevent malicious code from replacing the font on your machine with a version that has the ligature.
Fixing the code doesn't help users that downloaded code and don't get the new version either.
Malicious code that can replace a font can replace a lot more too.
right, but a replacing a font is much easier than replacing a browser.
Guess I'll have to come up with a different domain name for my new business MakeLogoLigatures :(
I can imagine a group of excited guys coming up with that idea as something cool, and then the whole thing slowly evolving into a yet another branding tool.
Neat to see how impressed the Google team was at how novel this issue was.
I imagine the overlap between number of people who know about google_logo and that the Omnibar is set it Google Sans is quite small.
And look, a working bug bounty program!
“$10,000 for report of high-quality && high-impact security UI issue + $5,000 bonus for unique, novel cool bug -- this was a very neat discovery!”
OS-dependent? I don't see it on OS X.
It’s difficult (impossible?) to force a font on the web in a way that can’t be overridden by some users. This must have been a font designed for device-specific applications picked up for other use-cases? Or maybe they just didn’t care that the long tail of users might see the string “googlelogoligature” instead of the logo.
any website that supplies its own fonts will work. the number of people that would override the fonts specified in a website is small.
Why didn’t google just use a Unicode private use code point like apple does with U+F8FF? ()
Because that wouldn’t degrade gracefully with a different font.
I mean, “googlelogoligature” degrades just as gracefully as “undefined”, I would say
(Which is to say that it doesn’t)
I guess we have to disagree on that. When the Apple private-use code point shows as a box, you have no idea what it is supposed to represent. With the ligature you have the equivalent of an alt text.
There are many others including "glogoligature".
The linked article on Unicode is far more interesting actually. I never really cared to think before how Unicode works, but reading the submission letter of beet emoji was the most interesting thing I've read this month so far.
> Fonts can include "ligatures", which let font designers special-case specific combinations of letters ... but the feature has been (ab)used for many other things
Same reason to not use ligatures in your IDE, terminal, etc.
Did that trend finally die off?
Ligatures that give slightly stylized rendering to stuff like <!-- or even replace a >= with a ≥ in your source code view are much less prone to exploitation than a "ligature" that replaces a 18-letter sequence with the word "Google" in your browser's address bar. It's like comparing the hazardousness levels of a safety pin and of a chainsaw.
My great fear is they will become so popular that the option to disable them will be forgotten. I can’t stand the ligatures that noticeably change and merge the glyphs.
Have you ever read a book typeset without them? Imagine a dot in fig where the loop of the f conflicts.
Those historical use cases are fine and important, the problem ones are the ones in monospace fonts that change <= to ≤ and that sort of thing, or even crazier abuses like shown here.
I like the dotted i in fig, thank you. Not a big fan of underlines that don't cross descendeds either.
Fortunately, no. They’re increasingly well supported for the user base who think they look nice… like me.
I love the way my code looks in Berkeley Mono on any modern editor version. Seeing `>=` render similar to `≥` makes me smile. It’s a tiny visual tweak that doesn’t even cause anything to move on the screen, because that font’s ligatures are the same width as the characters they replace. I see no downside to it for me.
Personally, I find an extra-wide “≥” more ugly and jarring than “>=“. If anything, I would prefer programming languages to understand the actual Unicode “≥”, and people learning how type that (Compose key, dedicated IDE support, or whatever). It would be nice for more people to appreciate that the characters one can type aren’t limited to the symbols printed on the keyboard.
Every editor and language I use is fine with Unicode in files, but I don’t know if that’s true for everyone I collaborate with. Sure, I can type all those symbols, but can they? Does a screen reader pronounce them reasonably? Do they render correctly in GitHub’s web source code viewers? Will I ever get as fast typing composed characters as just pressing `>=`? Does everyone use a font that supports those codepoints? I don’t know. Probably, but who can tell? I tend to limit non-ASCII text to inside quoted strings and use exclusively ASCII-compatible codes for all identifiers.
But the great part about ligatures is that I can use fonts that support them and enable them in my editors because I think they look pretty. Anyone who doesn’t like their appearance can just not use them. We can both have editors that look nice to ourselves without making the other’s editors look worse. How often can we say that?
This is sort of my point: I would wish for the world to move towards typing Unicode symbols being a normal thing. That would also imply screen readers properly handling those (if they don’t already). What I don’t like is source code being rendered as something different than the actual printable characters it consists of.
I’m not disputing your preference, I was just stating mine. I do prefer “≥” over “>=“, but not in the form of a double-width ligature that is still “>=“ under the hood.
> Will I ever get as fast typing composed characters as just pressing `>=`?
Typing “>=” usually involves pressing three keys. The same can be true with Compose.
That’s not to say that there isn’t some trade-off in some cases. But the frequently used symbols can be prioritized, and it opens up a vastly larger repertoire of characters you can type. I routinely type foreign languages with accents and other non-ASCII letters using Compose, and it has become muscle memory.
The IDE could also do an automated ASCII to Unicode replacement for certain strings of characters if they are supported in a language, similar to how Microsoft Word automatically replaces (R) with ®, or the like.
in vim i can define abbreviations like this:
then, when typing ">=" it will automatically be converted to "≥" as soon as i hit space.Exactly. Though in an IDE it should only be done depending on whether the current language supports the Unicode operators in question. And ideally the replacement shouldn't happen when editing string literals. Though perhaps that is asking for too much.
in vim you can make these definitions dependent on the file type, which is also used to detect languages for eg syntax highlighting. so it's certainly possibly to define these only for a specific language. it should even be possible to define it based on the syntax detected: https://superuser.com/questions/487603/abbreviations-overrid...
> Does a screen reader pronounce them reasonably?
I've been pushing the limits of emoji/Unicode recognition where I try to input it in an app or while communicating with others, and see what happens.
It's especially fun to use Emoji in the "favorite lists" for rideshare apps. In particular, each of my Favorite Waymo Destinations is accompanied by 3-5 Emoji which identify the unique spot or its category.
The really amusing part is that the Waymo car itself verbally reads off the destination when it gets underway. So the Emojis are translated into English and rattled off uncritically, but accurately, including incidentals like which skin-tones were chosen. It makes me giggle; I haven't found any unpronounceable glyphs yet!
Ligatures should not be used in monospaced fonts, for obvious reasons.
hard disagree. i use monospace fonts with ligatures for programming. primarily i get things like -> rendered as a full arrow or == connected or ... as an actual ellipsis. it's subtle but it's nice.
I've also seen nice use of ligature for markdown formatting.
the idea that ligatures shouldn't be used with monospace fonts would also break monospace in multiple languages as some languages require ligatures to display single characters correctly.
If the ligature takes up the same horizontal space as the characters it represents, then I don't see why not.
I would be ok with the equivalent of the "fi" ligature, where two letters would be drawn slightly differently when next to each other.
Why? Monospaced characters fit in their separate cells.
I thought there was something wrong with this blog post that kept writing "googlelogoligature" but no some absolute cretin really added that as a ligature to the font.