|
HTML(Hypertext Markup Language)
HTML(Hypertext Markup Language,하이퍼텍스트 마크업 언어)는 프로그래밍 언어는 아니고, 우리가 보는 웹페이지가 어떻게 구조화되어 있는지 브라우저로 하여금 알 수 있도록 하는 마크업 언어입니다.
HyperText Mark-up Language
"Hyper Text Mark-up Language" 의 약자. 웹 페이지의 모습을 기술하기 위한 규약. 프로그래밍 언어가 아니라 마크업 언어다. 헷갈리지 않도록 하자. 웹사이트에서 흔히 볼 수 있는 htm이나 html 확장자가 바로 이 언어로 작성된 문서다.
최초 제안자는 CERN의 물리학자 티머시 J. 버너스리이다. URL, HTTP, WWW의 전신인 Enquire 등도 그가 세트로 개발하고 제안했다. TCP/IP 통신규약을 만든 빈턴 G. 서프(Vinton Gray Cerf)와 함께 인터넷의 아버지로 불린다.
나무위키에서는 다음과 같이 내용을 집어넣어 HTML을 적용시킬 수 있지만 도움말에 의하면 지원 종료 가능성이 있는 비권장 문법이므로 나무위키에서는 HTML 태그를 사용하지 않는 것을 추천한다.
HTML은 문법 오류에 관대한 편이다. 그래서 닫는 태그를 누락한다든가 태그에 오타가 난다든가 하는 오류가 발생해도 어느 정도는 씹어먹고 작동할 수 있다. 물론 '어느 정도'까지만. <div> 태그 등 중요한 태그에서 오타가 난다면 사이트 레이아웃이 홀랑 깨져버리기도 한다. 위에 있는 HTML5 표준 형식 HTML이 아니더라도, 그냥 <h1>Hello World!라고만 써도(<!DOCTYPE> 선언문 누락, <html> 선언 태그 누락, <head>, <body> 태그 누락, 닫는 태그 </h1> 누락) 어지간해서는 의도한 바대로 출력이 된다. 물론 디버그 모드로 보면 이 부분이 잘못되었다고 에러가 떠 있을 것이다. HTML 최상단의 <!DOCTYPE> 선언이 누락될 경우에는 이야기가 많이 달라지는데, 이 경우 브라우저는 해당 HTML 문서를 호환성 모드(Quirks mode)로 해석하여 렌더링 한다.
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에서 처음으로 나왔다. 수학 수식을 사용하는 태그를 완전히 제외하고, 넷스케이프의 비주얼 관련 태그를 수록했다. <b>나 <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.3을 마지막으로 W3C의 HTML 표준은 폐지된다.
HTML 5
2014년
10월 28일
문서 참고.
HTML 5.1
2nd Edition
2017년
10월 3일
이름은 2nd Edition이지만, HTML 5의 차기작이라는 의미다. HTML 5.1 1st Edition은 없다는 의미.
HTML 5.2
2017년
12월 14일
HTML 5.3
2018년
2월 6일
W3C가 발표한 HTML의 마지막 버전. 이 이후로 HTML 표준은 WHATWG의 HTML Living Standard로 일원화된다.
그러나 HTML은 서버에서 보내오는 정보대로 페이지를 그려내는 것에는 강하지만 반대로 사용자의 입력에 민감하게 반응하여 페이지를 그리는 것에는 약한 편이다. 또한 동적인 화면 구성이 힘들다는 약점도 있다. 이러한 면을 보완하기 위하여 JavaScript 등의 각종 스크립트의 도움을 받으며, 요즘 유행하는 AJAX도 그런 면을 보완하기에 적합하다. 그 외에 멀티미디어 지원을 위하여 외부 프로그램을 불러올(embedding) 수 있다. 다만 이는 브라우저 의존적인 면이 강하여, 이 브라우저로 잘 표시되는 페이지가 다른 브라우저로는 완전 엉망이 되는 경우도 있다. HTML5는 비디오/오디오 처리를 위한 별도의 <video>, <audio> 태그를 추가하고 동적인 그래픽은 <svg>와 <canvas> 태그를 통해 사용할 것을 권고하고 있으며 외부 플러그인은 가급적 사용하지 않으려 하고 있다. 그래도 아직은 <embed> 태그와 <object> 태그를 통해 외부 플러그인(플래시 등)을 제한적으로 실행할 수는 있다. 하지만 2021년부터 어도비가 플래시 지원을 종료해서 사용하지 않을 것을 권고한다. 어차피 플래시로 하던 기능을 HTTP,CSS,JavaScript (혹은 Node.js) 등으로 통폐합 시키게 된다. 공부하면 "아 옛날이여" 소리가 절로 나온다.
HTML 문서를 작성한 후 메모장에서 저장할 시, 다른 이름으로 저장을 선택한 뒤, 파일 형식을 '모든 파일 (*.*)'로 지정하고 파일명 끝에 .html이나 .htm을 추가하면 HTML 문서가 된다. 이렇게 하지 않으면 그냥 메모장으로 열린다.
.html로 바꾸고 난 이후에 수정하고 싶다면, .html 확장자 파일을 오른쪽 클릭 후, 연결 프로그램을 선택하고 Notepad(메모장)을 선택하거나, .html 파일을 메모장에 끌어다 놓기 해주자. 다시 확장자를 .txt로 바꿔도 된다. 참고로 윈도우즈의 메모장으로 HTML 문서를 편집하면, 각 줄마다 CRLF가 달라붙어서 문제가 되기도 한다. 웬만하면 Editplus나 vim, Notepad++ 같은 에디터로 편집하도록 하자. 맥이라면 Xcode를 쓰면 된다. 이런 에디터의 경우 HTML이나 서버 사이드 스크립트 코딩에 최적화되어 있기 때문에 구문에 따라 색상 구분도 되는 등 여러 가지 장점이 있다.
HTML 파일 형식의 확장자는 .html이며, '.htm'이라고도 쓸 수 있다. 이는 도스 시절 확장자가 3글자로 제한되었기 때문이다. 윈도우즈 95로 넘어오면서 이 제한이 없어져서 지금은 거의 .html로 쓰는 편이다. 또한 HTML의 인코딩은 현재 거의 UTF-8로 통일되었다. 정말 오래된 사이트는 EUC-KR을 사용한다. 참고로 일본 쪽의 오래된 사이트는 SHIFT-JIS 가 가장 보편적이고 EUC-JP도 간간이 보인다. 두 나라 모두 최신 사이트는 모두 UTF-8 사용.
작성하는 방식은 크게 텍스트 에디터를 이용해 직접 코드를 편집하는 방법과 WYSIWYG 편집기를 사용하는 방법이 있다. WYSIWYG 방식은 드림위버와 나모 웹에디터가 지원하는데 현재는 WYSIWYG 방식은 거의 온라인 에디터로 대체되었으며, 본격적인 웹 개발에는 사용하지 않는다. 구조화된 HTML을 강조하는 HTML5와는 영 심각하게 궁합이 안 맞기 때문이다. 심지어 멀쩡히 손코딩(?)으로 작성한 HTML 문서를 이들 위지윅 에디터에서 열면 자기 맘대로 소스 코드를 조작하고 임의의 메타데이터를 삽입하거나 태그를 추가하는 등의 뻘짓(!)을 해서 코드를 망가뜨려 놓기도 한다. 특히 XHR을 통해 동적인 기능을 수행하는 홈페이지는 이들 위지윅 에디터로 열어보기만 해도 해당 동적인 기능들이 일제히 망가져서 복구 불가능한 피해를 입을 수 있다. 정적인 기능조차 CSS 적용에 문제가 생겨 레이아웃이 뒤틀려버릴 수 있다. 사실 PHP만 사용하려 해도 이들 위지윅 에디터는 전혀 쓸 수가 없고 모든 코드를 텍스트 에디터로 작성해 넣어야 한다.
제로보드 스킨 등을 만들거나 혹은 기타 다른 홈페이지용 게시판을 자신의 홈페이지에 맞게 만들기 위해서 필요한 PHP나 CGI 파일의 이미지 수정을 위해서는 VSCODE 등의 텍스트에디터로 HTML을 구성하는 능력이 필요하다.
참고로, .txt 확장자 파일도 웹 브라우저에서 파일 → 열기를 해서 웹 브라우저 안에 내용을 띄울 수 있다. 하지만 txt 파일의 특성상 태그는 적용되지 않으니 주의.
마지막으로, 이렇게 저장한 .html 파일을 더블클릭해서 실행할 경우 HTML 파일 내부에서 다른 외부 리소스들을 불러오는 데 제약이 가해진다. 사실상 HTML 파일 하나만 로딩되는 수준인데 이는 브라우저의 보안 모델이 로컬 컴퓨터의 리소스(파일)를 읽지 못하게 제약을 걸었기 때문으로, 이 문제를 피하려면 웹 서버를 실행해서 http://localhost 또는 http://127.0.0.1 로 접근해야 한다. 그냥 더블클릭했을 때의 URL은 file:// 로 시작하는 걸로 구분할 수 있다. 간단한 페이지를 만든다면 로컬 웹 서버를 실행하는 것보다는 싼 가격의 웹호스팅 계정을 개설한 뒤에 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 프레임워크와도 궁합이 좋은 편이다.
첫댓글 2000년도 중반까지 HTML이 인기가 좋아서 많은 사람들이 이것을 사용했는데 HTML 저작권자가 사용료를 내라하면서 이에 포털회사에서 이를 거부해서 서비스가 중단되었습니다.