웹 문서를 만들기 전에 고민해볼 것들
이 글은 HTML에 대해 다시 공부하며 적고 싶은 걸 적는 두서 없는 글입니다.
어떤 사이트가 좋은 웹일까요?
신경 쓸 것들
1. 웹 표준(참고한 사이트)
우리는 웹 표준을 준수하는 웹 페이지를 만들어야 합니다.
그래야 검색엔진에 유의미한 정보들이 수집도 잘되고(SEO 최적화!!) 다른 개발자 또는 기기들이 해석하기 좋습니다. div 태그로만 되어있는데 class명도 자기 마음대로 짠 웹을 고치게 된다고 생각해보십쇼... (사실 처음에 제가 그렇게 많이 했어서 잘압니다. 다신 건드리기 싫습니다.)
HTML의 요소들
요소는 <태그>로 다른 텍스트와 구별합니다.
요소는 대소문자 구분이 없습니다.
<html>태그를 문서의 루트로 둡니다.
문서의 첫 부분에는 항상 <!DOCTYPE html>과 같이 이 문서가 몇 버전의 HTML을 사용하는지 알려주는 DTD(Document Type Declaration)를 넣어줘야 합니다.
그 다음 HTML 문서는 HTML의 루트를 나타내는 태그로 시작합니다. <html>의 속성으로 웹사이트의 언어도 넣어줘야 합니다. 이것도 검색 엔진과 브라우저에게 정보를 제공해주는 역할을 합니다. (참고)
<html>의 첫 번째 요소로는 문서의 메타데이터들을 나타내는 <head>, 다음으로는 문서의 내용을 나타내는<body>가 위치합니다.
[표준 예시]
<!DOCTYPE html>
<html lang="ko">
<head>
<title>HTML 표준</title>
</head>
<body>
<h1>HTML 표준에 대해서 알아보자</h1>
<p>표준적인 HTML은 다음과 같이 구성됩니다. html의 언어 속성은 번역기한테 언어로 해석할지 알려주는 역할도 합니다. /p>
</body>
</html>META에 관해서 :: 메타 데이터 그리고 그 안의 메타 태그
다른 것은 익숙한데 메타 태그는 잘 기억이 안나네욘..
그런 의미로 메타 태그 위주로 알아보겠습니다.
<meta>에는 다음과 같이 메타 데이터들을 넣습니다.
<!DOCTYPE HTML>
<html lang="ko">
<head>
<meta charset="UTF-8">
<title>HTML 표준</title>
<script src="usethis.js"></script>
<meta name="google-analytics-id" content="asdaf3r3rfewf3">
</head>
...
</html>meta 태그는 위에 있는 title, script 등의 태그로 표사할 수 없는 데이터를 표현하는데 씁니다. name, http-equiv, charset, itemprop 중 하나의 속성을 가집니다.
예를 들어서 이렇게도 쓰입니다. 구글 애널리틱스를 사용할 때 자기 사이트가 맞는지 확인하기 위해서 특정 메타태그를 넣길 요구합니다. 그런데 쓰이는 것이 보통 메타 태그입니다. (특정 URL에 어떤 텍스트를 넣길 요구하기도 합니다.)
그리고 HTML5 이전에는 (지금도) 다음과 같은 메타 태그를 많이 볼 수 있었습니다.
<meta http-equiv="content-language" content="ko">
<meta http-equiv="X-UA-Compatible" content="IE=edge">읽어보니 이러한 http-equiv 속성이 있는 메타 태그는 pragma-directive이라고 합니다. 저 프라그마-지시문이 뭔 소리인지.. 생각해봤는데 예전에 Visual Studio에서 #pragma로 코드 제일 위에 선언해두면 컴파일러에게 추가 정보를 제공해주는 역할을 했었는데 같은 맥락으로 쓰이는 것 같습니다.
User-Agent(ex. 내 브라우저)도 저 메타태그가 주어지면 저 정보들에 맞게 알고리즘을 수행해서 보여줘야 하는 것입니다. 관습적으로 "X-UA-Compatible: IE=edge" 다음과 같은 메타 데이터는 인터넷 익스플로러에게 좀 더 엄밀하게 명세를 따르도록 한다고 합니다. 하지만 표준에서는 User-Agent는 이 지시문을 무시하도록 요구하고 있습니다.
프라그마-지시문에 대해 더 알고 싶으면 문서를 참고해보세요
-> 프라그마 지시문
2. 접근성(참고한 사이트)
장애에 상관없는 보편적인 웹을 만들어야 합니다.
그리고 신체적인 장애가 없더라도 다양한 상황(작은 화면, 느린 인터넷, 연로)에 있는 사람에게도 도움됩니다.
TAB키를 누르면서 웹 사이트 상에 여러 UI와 버튼을 순회하면서 웹 서핑을 해보신적이 있나요?
TAB키를 눌렀을 때 웹 페이지 링크나 버튼들이 직관적으로 선택되도록 신경 쓴 웹이 있는가하면 그저 클릭을 통해서만 작동하는 사이트도 있습니다. 그런 사이트는 TAB키를 누르면 직관적으로 동작하지 않고 이상한 부분이 선택되곤 합니다. 클릭만 신경 쓴 웹 사이트보다 이런 키보드 네비게이션 기능을 신경 쓴 웹 사이트는 애플 워치와 같은 작은 화면에서도 문서를 살펴보기 좋을 겁니다(아니면 그렇게 구현하기 쉽겠죵).
사실 요즘 크롬 개발툴(ex. LightHouse)이나 프레임워크나 UI 라이브러리 같은 것이 워낙 좋아서 제대로 쓰기만 하면 반은 가는 것 같습니다.
접근성은 제가 고민하면서도 구현하기 까다로워서 어려워하는 부분인데요.. 이런 사소한 부분까지 신경 쓴 웹을 만들어보고 싶은 욕심이 있네요. 키보드 네비게이션, 색 대조의 정도 등 접근성이 좋은 웹은 어디까지 신경 써야 할까요?
제가 나중에 참고할 가이드라인 사이트를 남깁니다.
-> VOX 접근성 가이드
3. 크로스 브라우징
사실 최근에 어떤 교육 사이트에서 강의를 들으면서 복습하고 있는데 웹 사이트를 만들 때 크로스 브라우징도 신경 써야한다고 했습니다.
크로스 브라우징하면 떠오르는 것이 있습니다. 바로 jQuery입니닷.
그래서 JavaScript, jQuery, Axios, 호환성 관련해서 이해하기 위한 웹의 이야기를 해보겠습니다.
jQuery가 개발되기 전의 JavaScript는 브라우저 제조사 별로 표준이 달라서 같은 JavaScript 코드라도 어떤 브라우저에서는 동작하지만 어떤 브라우저에서는 안 돌아가는 경우가 많았습니다. 그래서 개발자에게 JavaScript는 손이 여러모로 가는 정말 골치 아픈 언어였습니다. 특히, 마이크로소프트는 독자적인 노선을 달렸는데 당시 유행하던 브라우저(Netscape)를 뜯어서 분석한 뒤(리버싱) 다시 구현해서 만들어낸 파생 버전인 JScript를 Internet Explorer(3.0)에 내장시켰다고 합니다. 결국, 개발자는 같은 JavaScript라도 브라우저별로 다른 표준을 가졌기 때문에 개발할 때 모든 브라우저에서 동작하도록 대응해주는 귀찮고 비생산적인 작업을 해야 했습니다. 이렇게 모든 브라우저에 대응해주는 것을 크로스 브라우징이라고 합니다.
크로스 브라우징으로 난리일 때 존 레식이라는 분이 크로스 브라우징을 신경 쓰지 않고 개발에만 집중할 수 있도록 해주는 jQuery라는 라이브러리를 개발했습니다. jQuery를 사용하면 알아서 내부적으로 브라우저별로 대응해줍니다. 개발자들은 jQuery의 API만 사용하면 크로스 브라우징을 신경 쓰지 않고 신나게(?) 효율적으로 개발만 할 수 있게 됐습니다. 게다가 당시 순수한 JavaScript로만 짠 코드보다 jQuery의 API를 사용해서 짠 코드가 더 간결하고 직관적이었습니다. 마지막으로 무료(오픈소스)였기 때문에 압도적인 인기를 가지게 됐습니다.
지금은 웹에 무수히 많은 변화가 일어났고 JavaScript도 같이 성장하면서 사용하는 환경도 많이 개선됐습니다.
1996년도 때 웹 브라우저 최강자인 Netscape Communications라는 회사가 ECMA라는 표준화 기관에 맡겨서 1997년 7월에 ECMAScript1(ECMA-262) Specification을 완성했습니다. 하지만 당시의 브라우저 업체들은 이 표준을 잘 지키지 않았습니다. 현재는 다행히도 예전의 브라우저별로 표준이 달랐던 악몽에서 벗어났습니다. 대표적인 브라우저는 모두 ECMAScript라는 표준을 잘 지키고 있습니다.
현재의 JavaScript는 TC39 위원회가 관리하고 TC39 위원회가 명시한 것들을 ECMA에 맡겨서 표준화하고 있습니다. 그리고 2016년부터는 표준화한 언어를 그것을 검토한 연도를 뒤에 합쳐서 부릅니다. 예를 들어서, ECMA에서 표준을 검토한 날짜가 2019년이면 ECMAScript2019(또는 줄여서, ES2019)라고 부릅니다.
요즘은 구세대 Agent를 지원을 해야하는 특수한 상황이 아니고서야 jQuery를 사용하진 않는게 트렌드로 잡힌 것 같습니다. (회사 사정별로 아직 많이 쓰긴 합니다!!) 왜냐하면 jQuery가 크로스 브라우징을 지원하기 때문에 그만큼 무겁다고 합니다.. 그저 표준대로 jQuery API를 사용하는 입장에서는 알아차리기 어렵지만 여러 브라우저에 대응해서 jQuery의 내부적으로 엄청 많은 명령어가 돌아가고 있습니다. 과거에는 크로스 브라우징 작업을 해야 했기 때문에 jQuery를 쓰는 게 더 편했지만, 앞에서 언급했듯이 요즘의 브라우저는 ECMAScript라는 표준을 따르고 있어서 필요성이 많이 줄어들었습니다.
고작 라이브러리 하나인데 성능이 엄청 복잡합 웹이 아니고서야 체감할 정도는 아니라고 할 수도 있습니다. 하지만 부족한 부분만 구현한 가벼운 라이브러리를 쓰면 되지 쓰이지 않을 크로스 브라우징 기능과 다른 것들이 들어 있는 jQuery를 사용해서 굳이 메모리 낭비를 할 필요가 없기도 합니다. 그리고 요즘 트렌드가 바뀐만큼 jQuery에 익숙하지 않은 개발자가 많은데 jQuery의 간결화된 문법을 대충 익혀서 쓰다가 비효율적인 코드를 만들 가능성도 높다고 생각합니다.
그리고 간결한 문법은 다른 라이브러리에서도 찾을 수 있습니다. 저도 기술적인 제약이 있는 것이 아니라면 굳이 다 활용하지 않는 무거운 jQuery를 사용할 것이 아니라 필요한 부분만 있는 라이브러리만 선택해서 사용하는 것이 좋다고 생각합니다.
코드를 비교해봅시다!
[조금 옛날 스타일지도 모르는 JavaScript XMLHttpRequest]
const req = new XMLHttpRequest();
req.open('GET', '/path', true);
req.onreadystatechange = () => {
if (req.readyState === 4) {
if (req.status === 200) success();
else fail();
}
}- 요즘은 fetch로 좀 더 깔끔하게 짤 수 있긴합니다.
[jQuery]
$.ajax('/path').then(success, fail);[Axios]
axios.get('/path').then(success).catch(fail);저는 만약 최신 JS문법의 호환성이나 크로스 브라우징이 신경 쓰인다면 가볍고 검증된 라이브러리를 하나를 쓰지 않을까 싶습니다.
- 엄청난 레거시를 작업하거나 팀이 모두 jQuery에 익숙해서 다른걸 쓰긴 현실적으로 불가능하다면 물론 어쩔 수 없겠지만용..
도구는 도구일뿐!
JavaScript말고 HTML, CSS의 크로스 브라우징에 대해서 생각해봤습니다.
너무 JavaScript 얘기만 했는데 HTML과 CSS는 하위 호환성이 보장되는 JavaScript와 달리 상위 호환성이 보장됩니다.
하위 호환성이 보장되는 JavaScript는 JavaScript 언어의 문법을 업데이트를 할 때 그 모든 변경점들이 JavaScript에 영구적으로 적용된다는 것입니다. 지금 짠 코드가 나중에 업데이트돼서 안 돌아가면 어떡하지? 이런 고민을 할 필요가 (이상적으로ㅎㅎ) 없습니다.
상위 호환성이 보장되는 HTML과 CSS는 반대로 상위 호환성이 보장되기 때문에 새로운 기능을 써서 구현한 문서를 구버전 엔진에서 돌렸을 때 오류가 나서 멈추지 않습니다.
예를 들어서, HTML9가 출시되면서 <iamgroot/>이라는 새로운 태그가 만들어졌다고 합시다. 이걸 구버전 브라우저에서 해석하면 없는 태그라고 오류가 나서 멈추지 않습니다. 마치 우리가 원서를 읽다가 모르는 단어가 나왔을 때처럼 자연스럽게 무시하고 지나갑니다. 태그 안에 만약 텍스트가 있다면 단순히 텍스트만 출력합니다.
티스토리는 HTML로 편집이 가능한데 한번 아래에 비어있는 iamgroot 태그를 삽입해보겠습니다.
->
개발자 도구로 보시면 저기에 iamgroot 태그가 있긴한데 별 역할을 하진 않습니다. 지금 이 페이지가 오류나거나 하나요? 아닙니다. 우리가 HTML, CSS를 할 때 문서의 콘텐트 자체가 보이지 않을까봐 크게 고민할 필요는 없긴합니다. 다만 다 깨져보이거나 예상한 태그가 동작하지 않아서 이상하게 보일 수는 있습니다.
새로운 기능을 쓰고 싶다면 유명한 Can I Use 사이트에서 어떤 브라우저까지 호환이 되는지 확인해야 할 것입니다.
말고도 marquee같이 더 이상 권장하지 않는 태그도 쓰지 말아야 할 것입니다.
- 썸네일 아이콘 출처: Html code icons created by Smashicons - Flaticon