Frontend Guidelines로 HTML, CSS, JavaScript 검토하기

검색 버튼을 눌러 결과가 나오는 것만으로 검색 폼의 검증이 끝나지는 않습니다. 키보드 조작, 긴 안내 문구, 지연된 응답에서도 입력과 결과를 사용할 수 있어야 합니다. HTML의 역할, CSS의 배치, JavaScript의 상태 처리를 각각 확인합니다.

Ben DC의 Frontend Guidelines는 HTML, CSS, JavaScript의 작성 기준을 모은 자료입니다. 아래에서는 이 가이드의 의미 구조와 명시적 레이블 기준을 바탕으로 검색 폼의 제출 동작, 긴 문구 배치, 응답 순서까지 검토합니다. 검색 폼의 상태 예시는 이 글에서 적용한 검토 사례입니다.

요소의 역할과 기본 동작

클릭해서 작업을 실행하는 요소에는 button을 사용합니다. 다른 주소로 이동하는 요소에는 a와 href를 사용합니다. 두 요소는 화면에서 비슷하게 꾸밀 수 있지만 동작은 다릅니다. 링크는 새 탭에서 열 수 있고 버튼은 폼 제출이나 인터페이스 동작을 실행합니다.

div에 클릭 이벤트만 붙이면 이러한 동작을 직접 보완해야 합니다. 키보드로 초점을 이동하고 실행하는 처리도 필요합니다. 기존 요소를 선택하면 구현량이 줄지만 올바르게 사용했는지는 여전히 확인해야 합니다. 폼 내부에서 제출을 의도하지 않은 버튼에는 type="button"을 지정합니다.

입력 필드에는 레이블을 연결합니다. 플레이스홀더는 입력을 시작하면 사라지므로 필드의 이름을 대신하기 어렵습니다. 오류 메시지는 어떤 값이 잘못됐는지와 사용자가 무엇을 고쳐야 하는지 설명해야 합니다.

예를 들어 이메일 입력에는 label의 for 값과 input의 id 값을 같게 지정해 둘을 연결합니다. 입력의 type은 email, 자동 완성의 autocomplete는 email로 지정할 수 있습니다. 저장 버튼은 type="submit"으로 역할을 나타냅니다. 실제 서비스에서는 필수 입력 여부, 오류 표시, 서버 검증을 요구사항에 맞게 추가합니다.

직접 만든 페이지 구조 예시입니다. main·nav·form 같은 의미 구조와 실제 키보드 포커스 위치를 함께 표시했습니다.

긴 문구에도 유지되는 배치

CSS를 수정할 때는 색상과 간격뿐 아니라 내용이 바뀌어도 배치가 유지되는지 확인합니다. 제목 영역의 높이를 짧은 제목에 맞춰 고정하면 긴 제목은 잘릴 수 있습니다. 버튼 안의 문구를 줄여야만 화면이 맞는다면 배치의 제약부터 살펴볼 필요가 있습니다.

반복해서 사용하는 색상과 간격은 프로젝트의 공통 값으로 관리합니다. 같은 배경색을 여러 파일에 복사하면 한 부분만 바뀌어 화면이 어긋나기 쉽습니다. 다만 한 번 사용하는 값을 모두 공통 변수로 만들 필요는 없습니다. 같은 역할에 반복해서 쓰는 값에 이름을 붙이면 개발자가 함께 수정할 위치를 찾기 쉽습니다.

선택자의 복잡도도 확인합니다. 긴 요소 경로에 의존하는 스타일은 HTML 구조가 조금만 바뀌어도 적용되지 않을 수 있습니다. 컴포넌트의 역할을 나타내는 클래스와 필요한 상태를 직접 표현하면 영향을 추적하기 쉽습니다.

응답 순서와 외부 문자열

데이터를 받아 화면을 갱신하는 코드는 요청 중, 빈 결과, 실패, 재시도 상태를 함께 확인합니다. 이전 요청의 응답이 늦게 도착했을 때 최신 검색 결과를 덮는지도 검사합니다.

외부에서 받은 문자열을 일반 텍스트로 표시할 때는 textContent처럼 HTML로 해석하지 않는 방법을 사용합니다. HTML 표현이 필요한 경우에는 허용할 요소와 속성을 정하고 검증된 정제 방법을 적용합니다. MDN의 보안 설명처럼 innerHTML에 신뢰할 수 없는 문자열을 넣으면 공격자가 실행 가능한 코드를 삽입할 수 있습니다.

함수와 변수 이름에는 역할을 적습니다. 개발자는 searchResults를 보면 data보다 어떤 값이 담겼는지 구분하기 쉽고, saveProfile을 보면 handle보다 어떤 일을 실행하는지 알기 쉽습니다. 호출 위치에서 동작을 구분할 수 있는지 기준으로 이름을 검토합니다.

검색 폼을 여러 조건으로 사용하기

외부 가이드의 모든 항목을 그대로 적용하면 기존 프레임워크의 방식과 충돌할 수 있습니다. 먼저 현재 프로젝트의 브라우저 지원 범위, 스타일 관리 방식, 접근성 기준을 확인합니다. 그다음 이번 변경에 영향을 주는 항목을 선택합니다.

검색 폼을 고쳤다면 입력 레이블, 제출 방식, 로딩과 오류 상태, 키보드 조작을 확인합니다. 긴 문구를 넣었을 때 버튼 높이와 주변 배치가 유지되는지도 봅니다.

마우스를 사용하지 않고 입력에서 검색 버튼까지 이동해 실행해보세요. 그다음 요청 중, 빈 결과, 실패 상태를 각각 확인합니다. 요청을 두 번 보냈다면 먼저 시작한 응답이 나중에 끝나도 최신 결과를 덮지 않는지 검사할 수 있습니다.

검사 기록에는 사용한 입력, 조작 방법, 응답 순서와 결과를 남깁니다. 문제가 발견되면 해당 조건으로 수정 전후를 비교하고, 정상 검색의 기존 동작도 유지되는지 확인합니다.