문의 폼에 길게 답을 쓰던 고객이 어느 순간 입력창 안에서 마우스 휠을 굴리고 있다. 정성껏 쓴 문장의 절반이 좁은 칸 안에 숨고, 무엇을 적었는지 확인하려면 위아래로 끌어올려야 한다. 이 사소한 불편이 작은 회사의 사이트에서 전환을 놓치는 가장 흔한 이유 중 하나다.
왜 textarea는 30년 동안 늘어나지 않았나
웹의 입력창은 거의 30년 가까이 고정된 사각형이었다. 콘텐츠가 길어지면 사각형은 그대로인 채 내부에서만 스크롤이 생긴다. 디자이너가 원하는 "글이 길어지면 입력창도 함께 부드럽게 늘어나는" 흐름을 만들려면, 키 입력이 일어날 때마다 자바스크립트로 높이를 다시 계산해서 갱신해야 했다.
가벼워 보이는 기능이지만 막상 짜보면 의외로 까다롭다. 한글 IME 입력 중에는 이벤트가 다르게 발생하고, 자동완성이 채워질 때는 input 이벤트가 누락되며, 모바일에서는 안드로이드와 iOS의 줄바꿈 처리가 미묘하게 다르다. 결국 라이브러리 한 줄을 더 부르거나, 수십 줄짜리 우회 코드를 떠안게 된다.
field-sizing: content가 하는 일
최근 표준에 들어온 CSS 속성 field-sizing: content는 이 모든 우회를 한 줄로 정리한다. 적용된 입력 요소는 안의 내용에 맞춰 스스로 늘어나고 줄어든다. textarea뿐 아니라 input, select에도 동일하게 동작한다.
- textarea { field-sizing: content; } — 줄이 추가될 때마다 높이가 자연스럽게 자란다
- input { field-sizing: content; } — 입력한 글자 길이만큼 가로폭이 늘어난다
- select { field-sizing: content; } — 선택된 옵션 길이에 맞춰 폭이 조정된다
키 입력 이벤트도, 높이 계산 코드도, IME 분기도 필요하지 않다. 브라우저가 이미 알고 있는 "내용의 크기"를 그대로 사용한다.
실무에 그대로 적용하기 전에 챙겨야 할 세 가지
한 줄짜리 속성이지만, 곧바로 적용하면 의도하지 않은 화면이 나오는 경우가 있다. 다음 세 가지는 함께 짚고 가야 한다.
1) min-height와 max-height의 짝
아무런 제한 없이 풀어두면 한 줄짜리 답변에는 입력창이 너무 작아 보이고, 긴 답변에는 화면을 가득 채워 어색해진다. min-height로 첫 모습의 크기를, max-height로 화면 절반쯤에서 멈추는 한계선을 잡아주는 편이 안전하다. 모바일에서는 max-height를 살짝 작게 잡아 키보드와 충돌하지 않도록 한다.
2) rows·cols 속성과의 관계
HTML의 rows, cols 속성은 field-sizing이 적용되면 초기 크기 힌트로만 동작한다. 그래도 무시해도 되는 값이 아니라, 디자이너가 원하는 첫 화면을 결정하는 값으로 의식적으로 채워두는 편이 좋다. rows="1"로 시작했다가 늘어나는 입력창은 인터랙션이 가장 가볍게 느껴진다.
3) 폴백은 굳이 만들지 않아도 된다
현재 Chrome, Edge, 그리고 Safari 최신 버전이 이미 지원하고, Firefox도 도입을 진행하고 있다. 지원하지 않는 브라우저에서는 이 속성이 그저 무시될 뿐, 입력 자체에는 아무 문제가 없다. 점진적 향상(progressive enhancement) 관점에서, 별도의 자바스크립트 폴백 없이 그대로 적용해도 큰 무리가 없다.
왜 지금 다시 입력 폼을 들여다봐야 하는가
웹사이트에서 가장 자주 닳는 부품은 입력 폼이다. 문의, 견적 요청, 회원가입, 후기 작성. 가장 많은 손이 닿는 자리이지만, 동시에 가장 오랫동안 사소한 불편을 그대로 두어 온 자리이기도 하다. field-sizing 같은 새 표준은 그 사소함을 한 줄로 정리해주는 흔치 않은 기회다.
CYAN 에이전시는 작은 회사의 문의 폼 하나에서도 이런 디테일을 챙긴다. 입력하는 사람의 손끝이 답답해지지 않도록, 코드와 디자인 양쪽에서 가장 가벼운 길을 먼저 찾는다. 우리 회사의 입력 폼이 고객을 한 문장 더 쓰게 만드는지, 아니면 중간에 떠나게 만드는지를 한 번 점검해보는 것이 시작이다.