You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Unlike other browser, Safari seems to create a separate text renderer element for each text node when created with document.createTextNode, with the result that kerning or opentype font features do not get applied to any typed out text. This also means connected scripts (like Arabic) or complex scripts (like Devanagari) will render as individual glyphs instead of properly shaping :(
The subsequent onCreateTextNode cannot be used to circumvent this (e.g. with node.innerText += ...) because the node is created either way.
After typing states:
Arabic in Firefox/Chrome connected properly:
Arabic in Safari rendered as individual letters:
Stylistic set transformations applied in Firefox/Chrome correctly:
Stylistic sets failing to render in Safari because they are evaluated as individual letters:
A "naive" solution would be use of innerText:
if (textNodeToUse) {
if (node) {
node.innerHTML += character;
} else {
_this.state.elements.wrapper.innerHTML += character
}
}
I do not know how or what is the reasoning for using textNodes otherwise, but as long as Safari mistreats the text the current approach is fatal.
The text was updated successfully, but these errors were encountered:
At the very least, output with innerText instead of createTextNode should be an option, or a custom method could be passed to overwrite the default method of appending text to the wrapper node.
Unlike other browser, Safari seems to create a separate text renderer element for each text node when created with document.createTextNode, with the result that kerning or opentype font features do not get applied to any typed out text. This also means connected scripts (like Arabic) or complex scripts (like Devanagari) will render as individual glyphs instead of properly shaping :(
The subsequent onCreateTextNode cannot be used to circumvent this (e.g. with node.innerText += ...) because the node is created either way.
After typing states:
Arabic in Firefox/Chrome connected properly:
Arabic in Safari rendered as individual letters:
Stylistic set transformations applied in Firefox/Chrome correctly:
Stylistic sets failing to render in Safari because they are evaluated as individual letters:
A "naive" solution would be use of
innerText
:I do not know how or what is the reasoning for using textNodes otherwise, but as long as Safari mistreats the text the current approach is fatal.
The text was updated successfully, but these errors were encountered: