좋아, 내 텍스트 편집기는 직접 만들겠다

브라우저 텍스트 편집기를 <canvas>, contenteditable, <textarea> 순으로 실험하면서, 모든 동작을 직접 구현하기보다 네이티브 편집 기능과 접근성을 활용하는 편이 현실적임을 확인함 <canvas>는 렌더링 자유도가 높지만 선택, 실행 취소·재실행, 여러 줄 붙여넣기, 스크롤을 직접 구현해야 하고 근본적으로 접근성이 부족함 contenteditable="plaintext-only"는 네이티브 선택과 실행 취소 기록을 제공하지만, 일정 문자 수를 넘으면 브라우저별로 예측하기 어려운 성능 저하가 나타남 <textarea>는 긴 텍스트에서 더 빠른 대신 CSS 구문 강조를 직접 적용할 수 없어 별도 표시 계층이 필요하고, 하이라이트가 많아지면 다시 병목이 생김 적은 기능으로 편집기 외형의 90%를 구현했지만 들여쓰기와 가상 스크롤 같은 세부 작업이 남았으며, UTF-16 텍스트 범위도 버그를 만들기 쉬워 프로젝트를 보류함 <canvas>로 시작한 편집기 첫 실험에서는 모든 텍스트를 <canvas>에 그렸으며, 화면은 정적으로 보여도 CPU가 초당 60~120프레임으로 계속 렌더링함 우선 다음과 같은 최소 동작을 구현함 포인터를 눌러 텍스트 커서 배치 방향키로 커서 이동 현재 줄 강조 키보드 텍스트 입력 커서 애니메이션 <canvas>가 편집 기능을 기본 제공하지 않아 다음 기능은 빠져 있었음 텍스트 선택 실행 취소·재실행 기록 여러 줄 붙여넣기 오버플로 스크롤 사용자 정의 탄성 스크롤바를 만드는 대신, 숨겨진 <div>에 브라우저의 네이티브 오버플로를 적용함 <div> 크기를 캔버스 텍스트에 맞춤 스크롤 위치로 <canvas>의 렌더링 오프셋을 계산함 기능을 계속 추가할 수는 있었지만 <canvas>의 근본적인 접근성 문제를 해결하기 어려워 다른 방식을 검토함 contenteditable로 네이티브 편집 기능 활용 캔버스 대신 오버플로 <div>에 텍스트를 직접 렌더링하고 contenteditable을 적용함 contenteditable="plaintext-only"를 사용하면 코드에 적합한 일반 텍스트 편집 영역을 만들고, 모든 내용을 하나의 텍스트 노드에 유지할 수 있음 <div contenteditable="plaintext-only" autocapital...