fun bug in chrome: codepen.io/jsscclr/pen/oN second character of ligature has same styles applied as whatever the first character has, despite being in a different dom node. can address by turning off ligatures
Conversation
firefox approach for comparison
2
I believe this was mentioned first in this post: robert.ocallahan.org/2006/10/partia I'm not sure if it relies on the ligature caret positions: docs.microsoft.com/en-us/typograp or if it still behaves as mentioned in the above post.
1
1
1
This seems like the spot where the partial ligatures are drawn: searchfox.org/mozilla-centra. It is then called here: searchfox.org/mozilla-centra
My code comprehension is pretty bad (especially with C++), but it doesn't seem to be using the caret positions.
2
1
At any rate, while I think Firefox's approach is kind of cute, my boss has kind of convinced me that a better solution is to force a ligature break when there's is a change to the inline style. So both Chrome and Firefox are probably doing it wrong. 😅
2
1
safari!
1
1
This is how you do it! 🙌
1
Replying to
Ah yeah, seems like the same thing. The style change breaks the glyph substitution for myanmar, which you can read more about here here:
Although in linking that doc, Safari is probably using Core Text – which *might* use an alternate standard for shaping Myanmar. Can't remember the specifics though. Regardless, the relevant bit is that scripts like this do glyph substitutions, and Safari is breaking those.
2
1
In this case you are seeing the “dotted-circle placeholder” where the dependent vowels and combining marks are being rendered in isolation (search for those keywords in the opentype-shaping docs I linked for more information). This seems understandable to me!