mir.pe (일반/밝은 화면)
최근 수정 시각 : 2024-12-07 19:29:04

HTML



파일:나무위키+유도.png  
은(는) 여기로 연결됩니다.
나무위키에서의 HTML에 대한 내용은 나무위키:문법 도움말/심화 문서
를
의 12번 문단을
의 부분을
, 에 대한 내용은 문서
를
의 번 문단을
의 번 문단을
의 부분을
의 부분을
, 에 대한 내용은 문서
를
의 번 문단을
의 번 문단을
의 부분을
의 부분을
, 에 대한 내용은 문서
를
의 번 문단을
의 번 문단을
의 부분을
의 부분을
, 에 대한 내용은 문서
를
의 번 문단을
의 번 문단을
의 부분을
의 부분을
, 에 대한 내용은 문서
를
의 번 문단을
의 번 문단을
의 부분을
의 부분을
, 에 대한 내용은 문서
를
의 번 문단을
의 번 문단을
의 부분을
의 부분을
, 에 대한 내용은 문서
를
의 번 문단을
의 번 문단을
의 부분을
의 부분을
, 에 대한 내용은 문서
를
의 번 문단을
의 번 문단을
의 부분을
의 부분을
, 에 대한 내용은 문서
를
의 번 문단을
의 번 문단을
의 부분을
의 부분을
참고하십시오.
HTML
HyperText Mark-up Language
파일:HTML5 로고.svg
<colbgcolor=#ffffff,#1f2023><colcolor=#000000,#ffffff> 개발자 팀 버너스리
개발 1990년
종류 마크업 언어
파일:홈페이지 아이콘.svg
파일:q48nDmx.jpg
마셜 제도에서 팀 버너스리 경을 기리며 발행된 특별우표.

1. 개요2. 예시3. 설명4. 태그5. 버전6. HTML 문서 저장 방법7. 트랜스 컴파일러8. 외부 링크9. 둘러보기

[clearfix]

1. 개요


웹사이트의 모습을 기술하기 위한 마크업 언어.

프로그래밍 언어가 아니라 마크업 정보를 표현하는 마크업 언어로[1] 문서의 내용 이외의 문서의 구조나 서식 같은 것을 포함한다. 보면 알겠지만 애초에 이름 HTML의 ML이 마크업 언어라는 뜻이다. 웹사이트에서 흔히 볼 수 있는 htm이나 html 확장자가 바로 이 언어로 작성된 문서다.

최초 제안자는 CERN의 물리학자 티머시 J. 버너스리이다. URL, HTTP, WWW의 전신인 Enquire 등도 그가 세트로 개발하고 제안했다. TCP/IP 통신규약을 만든 빈턴 G. 서프(Vinton Gray Cerf)와 함께 인터넷의 아버지로 불린다.

나무위키에서는 아래와 같이 내용을 집어넣어 HTML을 적용시킬 수 있지만 도움말은 권장하지 않는 문법이고, 지원 종료 가능성이 있는 문법이므로 나무위키에서는 HTML 태그를 사용하지 않는 것을 추천한다.
{{{#!html (내용)}}}

2. 예시

#!syntax xml
<!DOCTYPE html>
<html>
    <head>
        <meta charset="utf-8">
    </head>
    <body>
        <p>Hello, artists!</p>
    </body>
</html>

3. 설명

HTML은 문법 오류에 관대한 편이다.[2][3] 그래서 닫는 태그를 누락한다든가[4] 태그에 오타가 난다든가 하는 오류가 발생해도 어느 정도는 씹어먹고 작동할 수 있다. 물론 '어느 정도'까지만이다. <div> 태그 등 중요한 태그에서 오타가 난다면 사이트 레이아웃이 홀랑 깨져버리기도 한다. 위에 있는 HTML5 표준 형식 HTML이 아니더라도, 그냥 <h1>Hello World!라고만 써도(<!DOCTYPE> 선언문 누락, <html> 선언 태그 누락, <head>, <body> 태그 누락, 닫는 태그 </h1> 누락) 어지간해서는 의도한 바대로 출력이 된다. 물론 디버그 모드[5]로 보면 이 부분이 잘못되었다고 에러가 떠 있을 것이다. HTML 최상단의 <!DOCTYPE>[6] 선언이 누락될 경우에는 이야기가 많이 달라지는데, 이 경우 브라우저는 해당 HTML 문서를 호환성 모드(Quirks mode)[7]로 해석하여 렌더링한다.

그러나 HTML은 서버에서 보내오는 정보대로 페이지를 그려내는 것에는 강하지만 반대로 사용자의 입력에 민감하게 반응하여 페이지를 그리는 것에는 약한 편이다. 또한 동적인 화면 구성이 힘들다는 약점도 있다. 이러한 면을 보완하기 위하여 JavaScript 등의 각종 스크립트의 도움을 받으며, 요즘 유행하는 AJAX도 그런 면을 보완하기에 적합하다. 그 외에 멀티미디어 지원을 위하여 외부 프로그램을 불러올(embedding) 수 있다. 다만 이는 브라우저 의존적인 면이 강하여, 이 브라우저로 잘 표시되는 페이지가 다른 브라우저로는 완전 엉망이 되는 경우도 있다. HTML5는 비디오/오디오 처리를 위한 별도의 <video>, <audio> 태그를 추가하고 동적인 그래픽은 <svg>와 <canvas> 태그를 통해 사용할 것을 권고하고 있으며 외부 플러그인은 가급적 사용하지 않으려 하고 있다. 그래도 아직은 <embed> 태그와 <object> 태그를 통해 외부 플러그인( 플래시 등)을 제한적으로 실행할 수는 있다. 하지만 2021년부터 어도비가 플래시 지원을 종료해서 사용하지 않을 것을 권고한다. 어차피 플래시로 하던 기능을 HTTP, CSS, JavaScript (혹은 Node.js) 등으로 통폐합 시키게 된다.

수많은 기술 블로그에서 HTML을 두고 계층 구조로 알려주지만 이는 사실과 다르다. 모질라닷컴의 HTML 소개에서도 계층이라는 단어는 존재하지 않는다. HTML은 계층처럼 보일 뿐이며, 브라우저에서 태그대로 그대로 그려낼 뿐이다. 진짜 트리 구조는 HTML이 아닌 자바스크립트의 Document Object Model, 통칭 DOM이다.

4. 태그

파일:상세 내용 아이콘.svg   자세한 내용은 HTML/태그 문서
를
의 번 문단을
의 부분을
참고하십시오.
HTML을 기술하기 위하여 사용하는 명령어의 집합을 태그(Tag)라고 한다. 태그는 기본적으로 여는 태그와 닫는 태그로 구성되며, 닫는 태그 없이 단독으로 이용하는 태그도 있다. 태그에 주는 다양한 옵션은 모두 여는 태그에 지정하며, 닫는 태그는 태그 효과가 적용되는 범위의 끝을 나타내는 기능만 한다.

그런데 태그 종류가 수십 가지가 넘는 데다, 지정가능한 옵션까지 일일이 열거하면 책 한 권 분량이 된다. 따라서 일반인은 사용빈도가 높은 일부 태그만 암기하고, 나머지는 '태그사전(또는 레퍼런스)'이라고 하는 도움말 파일을 참고하는 편이다. 물론 암기 범위는 고급 사용자 내지는 프로페셔널(흔히 웹 퍼블리셔라고 하는 사람들)로 갈수록 넓어진다.

태그는 HTML의 근간이기 때문에, HTML 기반 채팅 프로그램에서도 사용할 수 있다. 대표적인 예가 cafe24 채팅. 다만 보안상 문제와 수많은 테러 때문에 현재는 대부분의 태그를 막고, 일부 태그만 허용하는 상태. 그림 삽입이나 페이지 링크, 음악 삽입, <marquee> 정도가 허용된다. 대부분의 PHP 기반 웹 게시판에서도 원칙적으로 글 제목과 내용에 태그를 적용시킬 수 있다. 다만 채팅과 같은 이유로 그 사용을 제한하는 경우가 많다. 특히 제목 부분에는 어떤 태그도 허용하지 않는 것이 일반적.

HTML 4와 XHTML에서의 태그 사용 방식이 약간 다르다. 여는 태그와 닫는 태그가 별도로 존재하지 않는 태그 (<img>, <br>, <hr> 등)의 경우 XHTML에서는 XML의 표준 표현법에 따라 <img /> 등으로 닫는 부등호 앞에 /를 달아준다. 덧붙여 <img/>보다 <img />(/ 앞에 공백이 있음)을 쓰는 것이 오래된 브라우저와의 호환성을 보장하는 방법이다. HTML 5에서는 HTML 4의 방식(<img>)으로 다시 돌아갔다.

웹 퍼블리셔, 웹 디자이너, 웹 프로그래머는 기본 소양이라고 할 수 있다. '태그 사전'의 도움을 받으면, 약간의 교육만으로 누구나 간단한 웹 사이트는 만들 수 있다. 물론 복잡한 사이트는 경험이 필요하기 때문에 입문자는 만들기 힘들다.

사실 HTML 규격에는 HTML이 어떻게 표시돼야 할지에 대해서 큰 틀만 정해져 있고 구체적으로는 설명하지 않고 있다. 예를 들어 테이블의 경우 선을 이용해서 줄과 칸을 구별하는 식으로 정해져 있지만, 선의 모양을 구체적으로 정의하지는 않은 것이다. 애초에 HTML은 화면 구성보다는 의미 표현에 치중하고 있기 때문이다. 결국 한 HTML 파일도 브라우저마다 다르게 보이는 경우가 존재한다. 이로 인해 최근의 추세는 HTML에는 표시하고자 하는 문서의 구조를 중심으로 기술하고, 구체적인 표시 방법은 CSS에서 정의하는 방향으로 나아가고 있다(하지만 이 CSS도 브라우저마다 표시하는 방법이 달라서 골치를 썩이는 경우가 있다. 이것은 전적으로 브라우저 책임. 특히 IE6 같은 옛날 브라우저는 문제가 심각하다). 이 때문에 Acid2 Test와 Acid3 Test[8], HTML5Test[9] 등의 브라우저가 얼마나 표준을 잘 지키는가를 확인하는 테스트도 등장하였다.

5. 버전

<rowcolor=#fff> 버전 공개일 내용
HTML 1.0 1991년 최초의 HTML. 팀 버너스리가 월드 와이드 웹을 발표하면서 내놓은 버전이다. 처음에는 버전이 붙지 않았으나 나중에 보강된 2.0 버전이 나오면서 붙은 이름. 80년대에 존재하던 SGML이라는 마크업 언어를 참조하여 만들어졌다.
HTML 2.0 1995년
11월 24일 		HTML 사상 최초로 표준으로 지정되었다. HTML 1.0에서 파일 업로드 양식과 프레임, 테이블, 이미지맵, 국제화 기능이 추가된 것으로, 팀 버너스리와 여러 다른 사람의 노력으로 표준화되었다. 인터넷의 대중화가 시작되면서 이때부터 HTML도 널리 알려지기 시작했다. 하지만 동시에 HTML의 문제점 역시 두드러졌던 시기이다. 95년대 브라우저 전쟁 시기 웹페이지 관리자는 IE를 위한 페이지와 넷스케이프를 위한 페이지를 따로 만들어야 했었다. 그러하여 그것을 보완하기 위해 W3C에서 보완한 것이 HTML 3.2.
HTML 3.2 1997년
1월 14일 		표준화 작업을 담당하는 W3C에서 처음으로 나왔다. 수학 수식을 사용하는 태그를 완전히 제외하고, 넷스케이프의 비주얼 관련 태그를 수록했다. 나 <font> 태그가 들어간 것이 이 버전.
HTML 4.0 1997년
12월 		Strict, Transitional, Frameset의 세 가지 문서 형태를 지원하는 것이 가장 큰 변화이다. Strict는 비표준이나 비권장 태그를 절대 허용하지 않는 엄격한 문서이고, Transitional은 비표준이나 비권장 태그도 허용하는 융통성 있는 문서, Frameset은 웹브라우저 화면을 나눈 프레임 문서에 쓰는 것이다.
HTML 4.01 1999년
12월 		2014년 10월 28일 HTML5의 최종 권고안이 확정되면서 구버전이 되었다. 비주얼 태그가 모두 비권장으로 지정된 것이 가장 큰 변화이다. 기존 비주얼 태그는 CSS로 빼서 사용할 것을 권장하고 있다.
XHTML 1.0 2000년
1월 26일 		HTML 4.01과 함께 가장 많이 사용되는 표준이다. 내용상의 변화는 거의 없고, HTML 4.01을 XML 형식으로 포팅한 버전. 따라서 HTML 4.01의 내용을 거의 그대로 가지고 있다. 이 때문에 2013년 지금까지도 HTML 4.01과 함께 가장 많이 사용되고 있다.
XHTML 1.1 2001년
5월 31일 		XHTML의 가장 최신 버전이지만, 거의 사용되지 않는 실정이다. XHTML 1.0까지 있었던 Transitional 형식이 빠지면서 비표준이나 비권장 태그와의 호환성이 사라져 버렸다. 이 때문에 지나치게 엄격하다는 지적과 함께 사용되지 않게 되었다. 이어 2014년 10월 28일 HTML5의 최종 권고안이 확정되면서 구버전이 된 상태.
XHTML 2.0 2009년 말에 논의가 중단된 XHTML의 버전이다. 원래 XHTML 1.1을 잇는 차기버전으로 이야기가 되고 있었지만 2008년 HTML 5로 방향을 선회하면서 중단되었다.
HTML Living Standard 2011년 1월 ~ WHATWG는 HTML5라는 이름 대신 HTML Living Standard라는 이름을 사용하기로 하였고, W3C의 HTML5 표준은 이 표준의 스냅샷이 되는 것으로 합의하였다. 그러나 이후 스펙의 불일치가 발생하게 되고, 결국 HTML5.2를 마지막으로 W3C의 HTML 표준은 폐지된다.
HTML 5 2014년
10월 28일 		문서 참고.
HTML 5.1 2016년 11월 1일 단, 이 표준은 오류가 발견되어 2017년 10월 3일에 HTML 5.1 2nd Edition으로 대체되었다.
HTML 5.2 2017년
12월 14일
HTML 5.3 - W3C에서 제시할 표준안이었지만, W3C와 WHATWG의 합의로 HTML 표준은 WHATWG의 HTML Living Standard로 일원화되었다.

6. HTML 문서 저장 방법

HTML 문서를 작성한 후 메모장에서 저장할 시, 다른 이름으로 저장을 선택한 뒤, 파일 형식을 '모든 파일 (*.*)'로 지정하고 파일명 끝에 .html이나 .htm을 추가하면 HTML 문서가 된다. 이렇게 하지 않으면 그냥 뭔가 내용이 다 깨진 메모장으로 열린다.

.html로 바꾸고 난 이후에 수정하고 싶다면, .html 확장자 파일을 오른쪽 클릭 후, 연결 프로그램을 선택하고 Notepad(메모장)을 선택하거나, .html 파일을 메모장에 끌어다 놓기 해주자. 다시 확장자를 .txt로 바꿔도 된다. 참고로 윈도우즈의 메모장으로 HTML 문서를 편집하면, 각 줄마다 CRLF가 달라붙어서 문제가 되기도 한다. 웬만하면 VS Code나 vim, Notepad++ 같은 에디터로 편집하도록 하자. 맥이라면 Xcode를 쓰면 된다.[10][11] 이런 에디터의 경우 HTML이나 서버 사이드 스크립트 코딩에 최적화되어 있기 때문에 구문에 따라 색상 구분도 되는 등 여러 가지 장점이 있다.

HTML 파일 형식의 확장자는 .html이며, '.htm'이라고도 쓸 수 있다. 이는 도스 시절 확장자가 3글자로 제한되었기 때문이다. 윈도우즈 95로 넘어오면서 이 제한이 없어져서 지금은 거의 .html로 쓰는 편이다. 또한 HTML의 인코딩은 현재 거의 UTF-8로 통일되었다.[12] 정말 오래된 사이트는 EUC-KR을 사용한다. 참고로 일본 쪽의 오래된 사이트는 SHIFT-JIS 가 가장 보편적이고 EUC-JP도 간간이 보인다. 두 나라 모두 최신 사이트는 모두 UTF-8 사용.

작성하는 방식은 크게 텍스트 에디터를 이용해 직접 코드를 편집하는 방법과 WYSIWYG 편집기를 사용하는 방법이 있다. WYSIWYG 방식은 드림위버와 나모 웹에디터가 지원하는데 현재는 WYSIWYG 방식은 거의 온라인 에디터로 대체되었으며, 본격적인 웹 개발에는 사용하지 않는다. 구조화된 HTML을 강조하는 HTML5와는 영 심각하게 궁합이 안 맞기 때문이다. 심지어 멀쩡히 손코딩(?)으로 작성한 HTML 문서를 이들 위지윅 에디터에서 열면 자기 맘대로 소스 코드를 조작하고 임의의 메타데이터를 삽입하거나 태그를 추가하는 등의 뻘짓(!)을 해서 코드를 망가뜨려 놓기도 한다. 특히 XHR을 통해 동적인 기능을 수행하는 홈페이지는 이들 위지윅 에디터로 열어보기만 해도 해당 동적인 기능들이 일제히 망가져서 복구 불가능한 피해를 입을 수 있다. 정적인 기능조차 CSS 적용에 문제가 생겨 레이아웃이 뒤틀려버릴 수 있다. 사실 PHP만 사용하려 해도 이들 위지윅 에디터는 전혀 쓸 수가 없고 모든 코드를 텍스트 에디터로 작성해 넣어야 한다. 이 문제 때문에 나모 웹에디터는 망했고, 드림위버는 소스 코드를 직접 입력하는 텍스트 에디터에 더 중점을 두고 JavaScript, PHP 등 웹에서 쓰는 여러 프로그래밍 언어를 지원하는 일종의 웹 IDE로 전환했다.

제로보드 스킨 등을 만들거나 혹은 기타 다른 홈페이지용 게시판을 자신의 홈페이지에 맞게 만들기 위해서 필요한 PHP나 CGI 파일의 이미지 수정을 위해서는 VSCODE 등의 텍스트에디터로 HTML을 구성하는 능력이 필요하다.

참고로, .txt 확장자 파일도 웹 브라우저에서 파일 → 열기를 해서 웹 브라우저 안에 내용을 띄울 수 있다. 하지만 txt 파일의 특성상 태그는 적용되지 않으니 주의.

마지막으로, 이렇게 저장한 .html 파일을 더블클릭해서 실행할 경우 HTML 파일 내부에서 다른 외부 리소스들을 불러오는 데 제약이 가해진다. 사실상 HTML 파일 하나만 로딩되는 수준인데 이는 브라우저의 보안 모델이 로컬 컴퓨터의 리소스(파일)를 읽지 못하게 제약을 걸었기 때문으로, 이 문제를 피하려면 웹 서버를 실행해서 http://localhost 또는 http://127.0.0.1 로 접근해야 한다. 그냥 더블클릭했을 때의 URL은 file:// 로 시작하는 걸로 구분할 수 있다. 간단한 페이지를 만든다면 로컬 웹 서버를 실행하는 것보다는 월 500~1000원 정도의 싼 가격의 웹호스팅이나 무료 웹호스팅[13] 계정을 개설한 뒤에 FTP를 통해 이용하는 방법이 더 간단하므로 이 편을 추천한다. 웹 서버는 설정 과정이 필요한데 초보자들에게는 설정 파일을 직접 편집해야 하는 등 간단하지 않은데, 웹호스팅은 이 설정 과정을 업체에서 해 준다.

7. 트랜스 컴파일러

2016년 즈음부터는 웹 환경이 나날이 대형화되고 복잡해짐에 따라 웹 사이트의 근간을 이루는 HTML, CSS, JavaScript는 모두 대안 언어나 기술이 존재한다. HTML은 열고 닫는 태그를 일일이 오타 없이 쓰는 게 불편하고 마크업 언어인 탓에 템플릿 지원이 되지 않고 객체 지향적으로 작성이 불가능한 등의 여러 단점이 있다. 그래서 이것을 극복하고자 Pug(구 JADE)라는 컴파일러(트랜스컴파일러)가 만들어졌다. 들여쓰기로 블럭을 구분하고 변수나 템플릿 기능을 추가하고 자주 사용하는 id, class 속성을 특수 문법을 통해 간편하게 지원하는 등 여러 편의 기능을 제공한다.

그렇지만 Pug 자체는 컴파일러이고 컴파일 결과가 HTML로 나오는 것이라서 Pug만으론 홈페이지에 동적인 기능을 삽입하기 곤란하다. 어디까지나 정적 HTML 문서를 만들어내는 데 특화된 언어 및 유틸리티이다. jQuery 와 궁합이 잘 맞는 편이다. jQuery를 사용할 때에는 class 속성을 매우 자주 쓰게 되는데 Pug에서는 점 하나만 찍으면 클래스 지정이 가능하고 들여쓰기를 강제하는 문법 구조 때문에 태그의 부모자식 관계를 파악하기도 쉽다. 또한 결과물이 평범한 HTML 문서이기 때문에(사용자가 작성하지 않은 어떠한 메타데이터도 추가하지 않는다) 업무를 인수인계할 때 받을 사람이 Pug를 도저히 사용할 수 없다고 판단되면 마지막으로 컴파일한 HTML 파일을 대신 전달해주어도 아무 문제가 없다. 서버 사이드 렌더링 기능을 사용하지 않고 순수하게 트랜스컴파일러만 사용해 정적 HTML을 생성하는 프로젝트 한정. 물론 이때는 minify 옵션을 꺼서 사람이 읽을 수 있는 HTML을 생성하게 해 줘야 한다.

그리고 Pug는 트랜스컴파일러이지 Virtual DOM의 일종이 아니다. 그래서 최종 결과물인 홈페이지의 렌더링 속도를 가속해주지는 못한다. 엄격하게 구조화된 HTML을 생성하기 때문에 HTML 문서 자체의 파싱 속도는 빠르지만 DOM 조작 속도를 개선하지는 못한다는 소리다.

Pug 홈페이지에서는 서버 사이드 렌더링 언어로 Pug를 소개하고 있는데 정적 컴파일도 가능한 언어이다. 또한 node.js에서 돌아가는 라이브러리인 탓에(컴파일러 겸 라이브러리) express 프레임워크와도 궁합이 좋은 편이다.

8. 외부 링크

9. 둘러보기

프로그래밍 사이트 선정 프로그래밍 언어 순위 목록
{{{#!wiki style="margin: 0 -10px -5px; word-break: keep-all"
{{{#!wiki style="display: inline-table; min-width: 25%; min-height: 2em;"
{{{#!folding [ IEEE Spectrum 2024 ]
{{{#!wiki style="margin: -5px 0" 		<rowcolor=#fff> 스펙트럼 부문 상위 10개 프로그래밍 언어 직업 부문 상위 10개 프로그래밍 언어
1 Python 1 SQL
2 Java 2 Python
3 JavaScript 3 Java
4 C++ 4 TypeScript
5 TypeScript 5 SAS
6 SQL 6 JavaScript
7 C# 7 C#
8 Go 8 HTML
9 C 9 Shell
10 HTML 10 C++
}}}
}}}
}}}
[ Stack Overflow 2024 ]
[ TIOBE 2024 ]
||<tablewidth=100%><width=9999><-4><bgcolor=deepskyblue><tablebgcolor=#fff,#222> 2024년 8월 기준 검색어 점유율 상위 20개 프로그래밍 언어 ||
1 Python 11 MATLAB
2 C++ 12 Delphi / Object Pascal
3 C 13 PHP
4 Java 14 Rust
5 C# 15 Ruby
6 JavaScript 16 Swift
7 SQL 17 Assembly language
8 Visual Basic 18 Kotlin
9 Go 19 R
10 Fortran 20 Scratch
{{{#!wiki style="margin: 0 -10px -5px; min-height: calc(1.5em + 5px);"
{{{#!folding [ 21위 ~ 50위 펼치기 · 접기 ]
{{{#!wiki style="margin: -5px -1px -11px" 		21 COBOL 36 Scala
22 Classic Visual Basic 37 Transact-SQL
23 LISP 38 PL/SQL
24 Prolog 39 ABAP
25 Perl 40 Solidity
26 (Visual) FoxPro 41 GAMS
27 SAS 42 PowerShell
28 Haskell 43 TypeScript
29 Dart 44 Logo
30 Ada 45 Wolfram
31 D 46 Awk
32 Julia 47 RPG
33 Objective-C 48 ML
34 VBScript 49 Bash
35 Lua 50 Elixir
}}}}}}}}} ||
[ PYPL 2024 ]

}}} ||
프로그래밍 언어 목록 · 분류 · 문법
[1] 하도 혼동하는 사람이 많아서인지 구글에 html is a programming language를 치면 관련된 밈들이 수두룩하게 나온다. [2] XHTML 제외. XHTML은 XML의 부분집합이라 문법에 엄격하다. [3] 대신 컴파일러가 없으므로 오류를 확인 할 수 없다. [4] 예를 들어 <body>,<html>,<head> 등등. 다만 오류가 날 수 있으므로 모두 닫는 것을 추천한다. [5] 브라우저의 개발자 모드 Console 탭 [6] HTML 문서를 읽을 때, 이 문서는 HTML 문서이고 어떤 버전을 사용했으며 그 버전에 맞는 방법으로 해석하라고 브라우저에게 알려주는 선언문. [7] HTML 표준에서 벗어난 웹 브라우저의 독자적인 렌더링 모드다. 표준을 따르지 않으므로 브라우저간의 호환성은 많이 떨어진다. 굳이 이 모드에 대응하는 IE 5와 똑같이 하지 않는 이유는 말 그대로 어른의 사정 때문( 엣지의 등장으로 IE를 버렸다고는 하지만, 아직 11버전만의 보안 패치를 하고 있기 때문에 어밴던웨어가 아니다). [8] 2011년 12월 현재는 상황이 매우 좋아져서 IE9를 포함한 대다수의 브라우저들이 Acid3 테스트를 99%에 가깝게 통과한다! 다만 웹 표준이 계속 바뀌면서 최신 브라우저임에도 100점을 받지 못하는 경우가 있다. 참고로 Acid3의 경우 제목의 'A' 자를 클릭하면 어떤 테스트를 실패했는지, 어떤 테스트에서 시간이 오래 걸렸는지 확인할 수 있다. [9] 이쪽은 2019년 1월 시점에서도 만점을 받은 브라우저가 없다. 최고 점수는 크롬의 528점. 2018년 이후로 점수가 갱신된 바가 없다. [10] HTML 문서의 경우 웹 브라우저가 해석하니 별 문제가 없긴 하지만 CGI 프로그램의 경우 LF(Line Feed)가 아닌 CRLF(Carriage return & Line Feed)가 붙으면 인터프리터의 주소를 찾지 못하는 문제가 생긴다. CGI 프로그램이 돌아가는 환경이 유닉스나 리눅스가 대부분이기 때문이다. 윈도우 환경에서 돌아가는 CGI라면 해당없다. [11] FTP를 이용해서 올릴 때 ASCII 모드로 올리면 저장될 때 자동으로 서버의 OS 환경으로 맞춰준다. [12] 단, 브라우저가 자동으로 UTF-8로 인식하는 것은 아니고 <head> 태그 안에 <meta charset="UTF-8">을 넣어야 한다. [13] 계정이나 트래픽 용량이 보통 100~200메가, 많아봤자 500MB 수준으로 낮아서 실사용이 어려운 경우가 대부분인데 테스트용으로는 무료도 상당히 쓸만하다.

분류