Dois defeitos de geometria entre o textarea transparente (desenha caret e
seleção) e o overlay #hl (desenha o texto visível):
1. Largura: no Windows/Chrome o scrollbar clássico do textarea (~15-17px)
reduz sua área de texto; o overlay (overflow:hidden) não — cada linha
quebrava em colunas diferentes e a seleção ficava com 'buracos' e
deslocamento progressivo. Agora: scrollbar-gutter:stable no textarea
(largura constante, sem saltar ao cruzar 1 tela) + --sbw medido por JS
espelhado no padding-right do overlay a cada render.
2. Negrito sintetizado: tk-h/tk-strong/tk-mark usavam font-weight 700; sem
face bold na fonte monoespaçada, o Chrome alonga os glifos (~1-2px/char)
e o overlay acumulava offset por linha (visível no print: seleção parava
no fim do trecho negrito). font-synthesis:none no overlay + pseudo-negrito
por text-shadow (.35px) — peso visual preservado, avanço idêntico.
Também: renderEditorVisual reassincroniza scrollTop/scrollLeft de hl/gutter
após replaceChildren (antes o Enter em nota longa zerava o scroll do overlay
— 'Enter não atualiza a visualização').
Verificado headless: com scrollbar clássico simulado (15px), largura de texto
textarea==overlay (1078==1078), seleção contínua até o fim correto da linha
quebrada; Enter com doc rolado mantém ta/hl/gutter em 5000; wysiwyg/preview
sem regressão. sw v14.
lgcosta
82417d2e79