|Resolved||Dereckson||T68374 Enable Hovercards on se.wikimedia.org (Swedish chapter wiki)|
|Resolved||Jdlrobson||T70860 [GOAL] Graduate Page Previews feature (Popups extension) out of Beta Feature|
|Resolved||ovasileva||T154635 [EPIC] Deploy page previews to English and German Wikipedia|
|Resolved||ovasileva||T182319 Show HTML summaries on all wikis|
|Resolved||bearND||T187936 List of issues of 1.3.0 summary endpoint results|
|Open||None||T188127 Combined characters appear visually separated on macOS|
Update: the /page/summary endpoint has changed in 1.3.2 to more comprehensively flatten anchor and span elements, when possible into text nodes. I think this issue should be significantly reduced now. We might consider applying the same strategy for the reading content versions.
I'm not closing this because the issue would still exists for direct users of Parsoid, though.
The problem seems to arise when (at least) one of the characters is written as an HTML entity, eg:
Parsoid will wrap a <span> tag around the entity in order to support roundtripping, and that span tag will "separate" the combining character from the character it should apply to, in (broken versions of) webkit.
Two possible workarounds:
- drop the span if the wrapped entity is a combining character. That will make a dirty diff on roundtripping because the entity will be expanded in the wikitext, but selser should cover most of these cases in practice.
- expand the span to cover more than one character, roughly the same way we "expand the range" of templates.
- do nothing and wait for webkit to fix their bug: https://bugs.webkit.org/show_bug.cgi?id=6148
My recommendation is the first, which is probably one conditional in Parsoid plus importing a (hefty) npm library containing the unicode character class database to identify combining characters.