들을 때마다 느낀 거지만 정을수 강사님의 강의 퀄리티가 참 좋은 것 같다.
단순히 태그를 알려주는 것이 아닌 전체적인 웹 플로우와 프론트엔드 개발자가 가져야 할 자세에 대해 느끼게 된다.
부끄러운 말이지만 나는 ol을 한번도 써 본 적이 없다.
대부분의 리스트 원소들은 순서가 없는 형태였고 그랬기 때문에 ul만을 썼었다. 리스트 형태로 구현한 게시판을 예로 들 때 만약 조회수 순서대로 정렬하는 기능이 있다면?
그건 순서가 중요한 리스트라고 볼 수 있다. 문서의 구조를 조금 더 생각해봐야겠다.
h태그는 문서를 대표하는 단어에 사용된다. 검색 엔진에서 h태그의 중요도가 높은 만큼 가장 신경써야 할 태그라고도 할 수 있다.
검색 엔진 최적화를 위해 적절히 h 태그를 사용하자. 계층 구조에 맞게 순서대로 사용하는 게 좋고 웹 접근성을 위해 h1 태그는 한 번만 사용되는 게 권장된다.
header, main, footer 태그는 문서의 구조를 나타낼 뿐 중요도를 주는 태그들은 아니다(무시하자는 표현은 아님).
그럼 어떻게 구조를 나타내야할까?
header는 문서의 header가 될 수 있고 혹은 article의 header가 될 수 있다. header라고 판단되는 곳에 적절히 사용하자.
main은 문서에서 한 번만 사용 가능하다. 이름처럼 주된 내용에 사용하는 게 좋다.
aside와 footer는 얼핏 보면 사이드 바나 하단 바에 위치해야 할 것 같이 생겼다. 하지만 위치상 하단과 사이드가 아닌 의미상 하단과 사이드다.
부가적인 정보를 담는 aside와 날짜, 작성자, 라이센스 등을 담는 footer는 디자인에 따라 어디든지 위치할 수 있다. 옆과 아래라는 고정관념을 버리자.
단순히 레이아웃을 구성하는 용도라면 시맨틱 태그는 필요없다. 모든 걸 div로 해도 해결되기 때문이다. 그럴 거라면 시맨틱 태그는 왜 등장했을까?
HTML 문서는 단순한 PSD 파일의 옮김이 아닌 구조를 만드는 파일이기 때문이다. 검색 엔진 최적화와 웹 접근성을 위해 항상 구조를 생각하자.
프로그래밍을 할 때 코드를 지저분하게 작성하면 안 되는 이유가 뭘까? 작동만 되면 될 텐데 말이다.
이런 의문제기는 협업에서는 말할 것도 없고, 아주 작은 프로그램에서조차 쉽게 안 되는 원인을 찾을 수 있다.
만약 한 달 전에 작성한 코드를 볼 일이 생겼는데 그 코드가 나조차 이해하기 힘들 정도로 지저분하다면 그건 참 곤란한 일일 것이다.
항상 코드를 남이 봐도 한눈에 알아볼 수 있게 작성하자.
분류가 애매해서 일단 여기 적는 내용들이다.