목차: 1. HTML 언어 소개 HTML 언어 소개. 2. HTML 생성의 역사 HTML 생성의 역사. 3. HTML 언어의 기본 개념HTML 언어의 기본 개념 4. 웹 문서의 구조.웹 문서의 구조. 5. 주석 삽입 주석 삽입 6. HTML 문서의 예 HTML 문서의 예. 7. 텍스트 서식 태그.텍스트 서식 태그. 8. 웹 페이지의 모양을 제어하기 위한 태그 웹 페이지의 모양을 제어하기 위한 태그 9. 태그 태그 10. 배경 및 텍스트 색상 배경 ​​및 텍스트 색상 11. 목록 목록 12. 그래픽 개체가 포함된 웹 페이지. 사물.

HTML 언어 소개 HTML은 웹 환경의 문서 마크업 언어입니다. 인터넷에서 페이지를 볼 때 표시되는 내용은 HTML 텍스트에 대한 브라우저의 해석입니다. 브라우저가 예제 텍스트의 서식을 올바르게 표시합니다. 단락, 강조 표시된 인용문, 제목, 목록 등으로 나누었습니다. 그는 이것이 제목이고 이것이 단락이라는 등의 말을 어떻게 든 들어야합니다. 이것이 바로 HTML 언어가 하는 일입니다. 인터넷 페이지의 HTML 코드를 보려면 해당 페이지를 마우스 오른쪽 버튼으로 클릭하고 드롭다운 메뉴에서 소스 보기(또는 "HTML 코드 보기")를 선택하세요. 콘텐츠

HTML(Hyper Text Markup Language) 생성의 역사 일부 날짜: 1945: 1945: 미국 과학자, Vannevar Bush 대통령의 과학 고문이 하이퍼텍스트에 대한 아이디어를 표현했습니다. 연도: 1968: Douglas Engelbart가 하이퍼텍스트 링크 작업을 시연합니다. 워드 프로세서를 만들었습니다. 콘텐츠

1960년대: 1960년대: IBM 직원은 IBM 제품군 컴퓨터에서 사용하기 위한 GML(General Markup Language) 언어를 만들었습니다. GML 언어는 나중에 확장되어 80년대에 ISO(국제 표준화 기구)에 의해 표준화되었습니다. SGML(Standard General Markup Langugage)이라고 불리는 이 강력하고 다재다능한 마크업 모드는 1980년대 미 국방부에서 기술 문서화를 위해 사용되었습니다. 물리학자 Tim Berners-Lee는 CERN(유럽 핵 연구 센터)의 직원이었습니다. 개발된 언어의 기초는 SGML 언어와 하이퍼텍스트 작업 기술이었는데, 이것이 그가 만든 언어의 이름인 HTML이 연결된 이유입니다. 새로운 언어는 SGML의 기본 구성을 사용하여 문서와 하이퍼텍스트 링크를 설명했습니다. 일부 날짜: 목차

하이퍼텍스트라는 용어는 1969년 테드 넬슨(Ted Nelson)에 의해 처음 만들어졌습니다. 하이퍼텍스트는 다른 문서에 대한 링크를 포함하는 전자 문서입니다. 콘텐츠

웹 문서의 구조. ..., 인터넷 페이지 파일의 전체 내용은 ... 이 텍스트가 HTML 문서이고 브라우저가 식별, 인식 및 해석해야 하는 태그를 포함할 수 있음을 브라우저에 나타내는 컨테이너에 포함되어 있습니다. 일반적인 인터넷 페이지(HEAD)(BODY) 일반적인 인터넷 페이지는 헤더(HEAD)와 본문(BODY)의 두 부분으로 구성됩니다. 콘텐츠

웹 문서의 구조. HTML 문서 컨테이너 시작 헤더 컨테이너 줄 시작 컨테이너 - 페이지 제목 ...페이지 제목 줄 줄 끝 컨테이너 - 페이지 제목 제목 끝 컨테이너 페이지 시작 본문 컨테이너 ...페이지 본문(모든 내용) 끝 페이지 본문 컨테이너 HTML 문서 컨테이너 끝 이 기본 구조는 가장 간단한 형태로 명확하게 표시될 수 있습니다.

웹 문서의 구조. 지정한 제목 문자열은 이 페이지를 볼 때 브라우저 창의 제목에 표시될 뿐만 아니라 (페이지가 인터넷에 게시된 후) 검색 서버에서 제공하는 목록에도 표시됩니다. 콘텐츠

텍스트 서식 태그. 텍스트를 굵은 글꼴로 표시합니다. 텍스트를 기울임꼴로 표시합니다. 텍스트를 밑줄 친 글꼴로 표시합니다. 텍스트를 가로선으로 표시합니다. 텍스트의 레이블이 없는 부분보다 큰 글꼴로 텍스트를 표시합니다. 텍스트를 나머지 텍스트보다 작은 글꼴로 표시합니다. 텍스트를 줄 수준 아래로 이동하고 더 작은 글꼴로 표시합니다. 수학 색인 인쇄에 권장됩니다. 텍스트를 줄 수준 위로 이동하고 더 작은 글꼴 크기로 표시합니다. 이 태그는 숫자의 거듭제곱을 지정하는 데 사용할 수 있습니다.

태그 태그를 사용하면 브라우저가 웹 페이지를 볼 때 사용하는 글꼴을 변경할 수 있습니다. 태그에는 다음 매개변수가 있을 수 있습니다. FACE – 텍스트가 표시될 글꼴의 이름을 지정합니다. SIZE – 1(최소)부터 7(최대)까지 일반적인 단위로 글꼴 크기를 설정합니다. 일반적으로 일반 글꼴 크기는 값 3에 해당하는 것으로 인정됩니다. COLOR – 표준 이름이나 16진수 집합을 사용하여 지정할 수 있는 글꼴 색상을 설정합니다. 콘텐츠

배경 및 텍스트 색상 텍스트 색상을 변경하는 방법을 이미 알고 있지만 이를 위해서는 글꼴 태그로 묶어야 했으며 이것이 항상 편리한 것은 아닙니다. 때로는 전체 문서의 텍스트 색상을 설정하는 것이 더 좋습니다. 배경 이미지를 설정할 수도 있습니다. 필수 속성은 다음과 같습니다. BACKGROUND – 배경을 "채우기" 위한 이미지를 정의합니다. 값은 전체 URL 또는 GIF 또는 JPG 형식의 이미지가 포함된 파일 이름으로 지정됩니다(자세한 내용은 나중에 설명). BGCOLOR – 문서의 배경색을 정의합니다. TEXT – 문서의 텍스트 색상을 정의합니다. 모두 BODY 요소에 등록되어 있습니다. 색상 값은 RGB 16진수 값 또는 16가지 기본 색상 중 하나로 지정됩니다. 콘텐츠

배경 및 텍스트 색상 예: 이 텍스트는 BODY 태그의 텍스트 색상을 변경했기 때문에 빨간색이 됩니다. 이제 페이지의 모든 텍스트는 기본적으로 빨간색으로 표시됩니다. 적절한 색상입니다. 이제 텍스트가 다시 빨간색이 됩니다.

목록 각 목록 요소는 태그로 시작됩니다. HTML 언어는 다음 유형의 목록 형식으로 정보를 표시하기 위한 특수 태그 세트를 제공합니다. 번호 매기기(/); 정의 목록(/). 용어. 그 정의는... 목차

그래픽 개체가 포함된 웹 페이지입니다. 이미지는 인터넷상의 모든 웹사이트에서 필수적인 부분입니다. 그들은 모든 곳에서 사용되므로 무엇이 무엇인지 알아 봅시다. 페이지에 삽입할 수 있는 이미지 파일에는 세 가지 유형이 있습니다. GIF(Graphics Interchange Format) JPG/JPEG(Joint Photographic Experts Group) PNG(Portable Network Graphics)

그래픽 개체가 포함된 웹 페이지입니다. 형식에 대한 몇 마디: GIF - 256가지 색상만 사용하므로 음영 수가 적은 그림에 더 적합합니다. 이 형식은 이미지 투명도를 지원합니다. JPEG는 최대 백만 가지 색상을 사용하는 이미지 형식입니다. 일반적으로 사진 및 고품질 그래픽(많은 음영 포함)에 사용됩니다. PNG는 비교적 새로운 형식입니다. 수백만 가지 색상과 효율적인 압축 등 여러 면에서 JPEG 및 GIF를 능가합니다. 투명성도 지원합니다. 이미지를 어떤 형식으로 촬영할지는 귀하에게 달려 있지만 최소 크기로 최대 품질을 얻으려고 노력하십시오. 콘텐츠

그래픽 개체가 포함된 웹 페이지입니다. HTML 문서에 이미지를 배치하려면 SRC 매개변수가 이미지 파일의 위치를 ​​지정하는 태그를 사용하십시오. 예: - picture.gif 파일에 있는 이미지는 HTML 문서에 배치됩니다. - 이미지는 HTML 문서와 동일한 폴더에 있는 Images 폴더에 있는 Tile.bmp 파일에 있는 HTML 문서에 배치됩니다. 콘텐츠

그래픽 개체가 포함된 웹 페이지입니다. 문서에 그래픽을 포함할 때 텍스트나 다른 페이지 요소를 기준으로 해당 위치를 지정할 수 있습니다. 이미지 정렬 방법은 태그의 ALIGN 매개변수 값으로 지정됩니다. 다음은 이 매개변수에 사용할 수 있는 몇 가지 값입니다. LEFT 이미지를 창의 왼쪽 여백에 맞춥니다. 텍스트가 오른쪽 이미지 주위를 둘러쌉니다. RIGHT 이미지가 창의 오른쪽 여백에 눌려집니다. 텍스트가 왼쪽 이미지 주위를 둘러쌉니다. 콘텐츠

레슨 1

주제: “나의 첫 번째 인터넷 페이지”

HTML이란 무엇입니까? 창조의 역사.

시작하기 전에 HTML이 무엇이며 무엇이 필요한지 알아 보겠습니다. HTML(HyperText Markup Language)은 World Wide Web(WWW)에 게시된 문서 또는 더 간단하게는 HTML 문서의 마크업 및 디자인을 위한 것입니다. 마크업은 화면에 표시되지 않지만 문서의 구조와 구조 단위의 모양을 결정하는 서비스 정보로 이해되어야 합니다. 제작자는 이 언어가 플랫폼 독립적인지 확인했습니다. 어떤 운영 환경에서도 작동할 수 있습니다. HTML 언어의 주요 요소는 설명자(또는 태그)입니다. 즉 이름이 꺾쇠 괄호로 묶인 연산자입니다. 이 언어를 사용하여 마크업된 문서는 HTML 언어의 구조적 요소를 "이해"하고 올바르게 처리한다는 사실로 인해 대부분의 경우 최종 사용자 브라우저에서 동일한 방식으로 렌더링됩니다. 소스 코드는 설명자를 사용하여 형식화된 텍스트이며 이러한 요소는 웹 페이지 방문자에게 표시되지 않고 문서에 미치는 영향의 결과만 표시됩니다.

HTML의 아버지는 웹 브라우저를 통해 정보를 볼 수 있는 하이퍼텍스트 문서 형태로 인터넷에 정보를 전송할 것을 제안한 Tim Berners-Lee로 간주됩니다. HTML은 모든 컴퓨터가 이해할 수 있는 보편적인 언어로 설계되었습니다. HTML 문서는 마크업 언어 요소가 포함된 일반 텍스트 문서입니다. 따라서 메모장과 같은 텍스트 편집기를 사용하여 HTML 문서를 만들 수 있습니다.

HTML 언어의 특징은 실제로 언어의 특정 요소를 해석하는 방법에 대해서만 브라우저에 권장 사항을 제공한다는 것입니다. 저것들. 동일한 언어 요소가 브라우저마다 다르게 표시될 수 있습니다. 또한 브라우저 개발자들은 브라우저에서만 인식되는 새로운 요소를 도입하기 시작했습니다. 그리하여 소위 "브라우저 전쟁"이 시작되었습니다. 따라서 전문 개발자는 어려운 작업에 직면합니다. 전문적으로 제작된 웹사이트는 다양한 유형의 브라우저에서 볼 때 동일하게 보여야 합니다. 이렇게 하려면 작성 프로세스 중에 문서를 "테스트"해야 합니다. 오늘날 가장 인기 있는 브라우저는 Windows 운영 체제에서 실행되는 Internet Explorer, Netscape Navigator, Mozilla, Opera입니다.

동시에 HTML 개발자들은 언어의 보편성을 높이기 위해 끊임없이 노력하고 있습니다. 현재 국제 비영리단체인 월드와이드웹컨소시엄(W3C)이 HTML 개발을 담당하고 있다. 컨소시엄은 HTML 언어의 세 가지 버전, 즉 HTML3.2(1997년 1월 채택), HTML4.0(1997년 12월 채택), XHTML(2002년 1월 채택)을 개발했습니다.

번역: 블라드 메르제비치(Vlad Merzhevich)

나는 최근 표준 개발을 둘러싼 긴장에 대해 Mozilla 개발자들의 인용문을 접했습니다.

구현과 사양은 우아한 춤으로 함께 흘러야 합니다. 사양이 완료되기 전에 구현이 발생하는 것을 원하지 않습니다. 사람들이 구현 세부 사항에 의존하게 되고 이로 인해 사양이 지연되기 때문입니다. 그러나 구현 전에 사양이 완료되는 것을 원하지 않을 경우 작성자는 피드백이 필요할 때 구현 실험을 시작할 것입니다. 여기에는 피할 수 없는 긴장감이 있지만, 우리는 끝까지 선택의 여지가 없을 뿐이다.

이 인용문을 마음 속에 간직하고 HTML5의 등장에 대해 설명하겠습니다.

MIME 유형

이 책은 이전 버전의 HTML이나 XHTML 버전에 관한 것이 아니라 HTML5에 관한 것입니다. 그러나 HTML5의 역사와 그 뒤에 숨은 동기를 이해하려면 먼저 몇 가지 기술적 사항을 이해해야 합니다. 특히 MIME 유형.

브라우저가 페이지를 요청할 때마다 웹 서버는 실제 페이지 코드를 보내기 전에 "헤더"를 보냅니다. 이러한 헤더는 일반적으로 보이지 않지만 관심이 있는 경우 표시할 수 있는 웹 개발자 도구가 있습니다. 헤더는 브라우저에 페이지의 마크업을 해석하는 방법을 알려주기 때문에 중요합니다. 가장 중요한 헤더는 Content-Type이라고 하며 다음과 같습니다.

콘텐츠 유형: 텍스트/html

"text/html"은 페이지의 "콘텐츠 유형" 또는 "MIME 유형"이라고 합니다. 이 헤더는 리소스가 실제로 무엇인지, 그리고 이를 표시하는 방법만 정의합니다. 이미지에는 고유한 MIME 유형이 있습니다(JPEG의 경우 image/jpeg, PNG의 경우 image/png 등). JavaScript 파일에는 고유한 MIME 유형이 있습니다. CSS에는 자체 MIME 유형이 있습니다. 모두 고유한 MIME 유형을 가지고 있습니다. 인터넷은 MIME 유형으로 실행됩니다.

물론 실제로는 모든 것이 훨씬 더 복잡합니다. 1세대 웹 서버(1993년 이후의 웹 서버에 대해 이야기하고 있음)는 Content-Type 헤더가 없었기 때문에 보내지 않았습니다(1994년까지는 발명되지 않았습니다). 날짜를 1993년으로 되돌릴 때 호환성상의 이유로 일부 인기 있는 브라우저는 특정 상황에서 Content-Type 헤더를 무시합니다(이를 "콘텐츠 스니핑"이라고 함). 그러나 일반적으로 웹에서 본 모든 것(HTML 페이지, 이미지, 스크립트, 비디오, PDF 등)은 Content-Type 헤더에 특정 MIME 유형으로 제공됩니다.

지금은 모자를 옆으로 치워두세요. 이에 대해서는 나중에 다시 다루겠습니다.

표준이 어떻게 만들어지는지에 대한 긴 여담

요소를 사용하는 이유 ? 이것은 매일 듣는 질문이 아닙니다. 분명히 누군가가 만든 것입니다. 이런 것들은 갑자기 나타나는 것이 아닙니다. 지금까지 사용해 본 모든 요소, 모든 속성, 모든 HTML 기능 등 누군가가 이를 만들고 작동 방식을 결정하고 모두 작성했습니다. 이 사람들은 신도 아니고 흠도 없습니다. 그들은 평범한 사람들입니다. 똑똑한 사람들이라고 확신합니다. 하지만 그냥 사람들이에요.

오픈 소스 표준의 가장 큰 장점 중 하나는 시간을 거슬러 올라가 다양한 질문에 답할 수 있다는 것입니다. 토론은 일반적으로 보관되어 공개적으로 이용 가능한 메일링 리스트를 통해 이루어집니다. 그래서 나는 "왜 우리는 요소를 사용하는가?"라는 질문에 답하기 위해 약간의 "우편 고고학"을 하기로 결정했습니다. ?. 월드와이드웹컨소시엄(W3C)이라는 조직이 존재하기 전으로 돌아가야 한다. 나는 두 손과 발가락 한 쌍으로 웹 서버의 수를 셀 수 있었던 웹 초기 시대로 돌아왔습니다.

다음 인용문에는 오타가 많습니다. 나는 역사적 정확성을 위해 그것들을 그대로 두기로 결정했습니다.

새로운 추가 HTML 태그를 제안하고 싶습니다.

필수 인수 SRC="url"

이는 웹을 통해 이를 가져와 이미지로 해석하려는 브라우저의 비트맵 또는 그래픽 파일 이름이며, 태그가 생성될 때 텍스트에 포함되어야 합니다.

(여기에는 닫는 태그가 없으며 단지 단일 태그일 뿐입니다.)

브라우저는 지원하는 그래픽 형식이 유연해야 합니다. 예를 들어 Xbm과 Xpm은 잘 지원됩니다. 브라우저가 주어진 형식을 해석할 수 없는 경우 원하는 대로 무엇이든 할 수 있습니다(X 모자이크는 기본적으로 비트맵을 자리 표시자로 출력합니다).

이를 위해서는 X 모자이크의 기능이 필요하며, 이는 우리에게 적합하며 적어도 내부적으로는 사용했습니다. 물론 저는 이것이 HTML에서 어떻게 처리되어야 하는지에 대한 제안을 환영합니다. 제안된 것보다 더 나은 아이디어가 있다면 알려주시기 바랍니다. 이미지 형식에 대해 막연하게 썼다는 것을 알고 있지만 "브라우저가 할 수 있는 일을 하게 놔두세요"라고 말하고 완벽한 솔루션(MIME, 언젠가는)을 기다리는 것 외에는 다른 대안이 없습니다.

이름이 모두 다르고 추가 NAME="name" 인수가 있다는 점을 제외하면 Midas 2.0(여기 SLAC에서 사용되었으며 이번 주에 공개 예정)과 비슷한 것이 있습니다. 예를 들어 제안한 IMG 태그와 기능이 거의 동일합니다.

name 매개변수 뒤에 숨은 아이디어는 브라우저가 "내장된" 이미지를 설치할 수 있도록 허용합니다. 이름이 "포함된" 이미지와 일치하면 이미지를 가져오는 대신 해당 이미지가 사용됩니다. 이름은 "라인 모드" 브라우저에 대한 힌트 역할을 하여 이미지 위치에 일부 문자를 넣을 수도 있습니다.

매개변수나 태그 이름에는 크게 신경 쓰지 않았지만 동일한 것을 사용하는 것이 합리적일 것입니다. 나는 약어에 별로 관심이 없으므로 IMAGE= 및 SOURCE=는 사용하지 않는 것이 좋습니다. 나는 여전히 IMAGE보다 단순하고 작아야 하기 때문에 ICON을 선호하는데, 아마도 ICON이 과부하된 단어가 아닐까?

Midas는 X 모자이크와 동시대의 또 다른 초기 브라우저입니다. 크로스 플랫폼이며 Unix와 VMS에서 실행됩니다. SLAC는 스탠포드 선형 가속기 센터(Stanford Linear Accelerator Center, 현재는 SLAC National Accelerator Laboratory)를 의미하며, 이 연구소는 최초의 미국 웹 서버(실제로는 유럽 이외 지역 최초의 웹 서버)를 운영했습니다. Tony가 이 게시물을 썼을 때 SLAC는 무려 441일 동안 웹 서버에서 5페이지를 호스팅하면서 WWW에서 가장 오래된 회사였습니다.

토니는 계속해서 이렇게 말합니다.

새로운 태그에 관한 주제를 다루는 동안, Midas 2.0에서 지원하고 싶은 비슷한 태그라는 또 다른 아이디어가 있습니다. 기본적으로 다음과 같습니다.

이 태그가 발생한 위치에서 두 번째 문서가 첫 번째 문서에 삽입된다는 아이디어입니다. 원칙적으로 해당 문서는 무엇이든 될 수 있지만 주요 목표는 이미지(이 경우 임의 크기)를 문서에 포함할 수 있도록 하는 것입니다. 다시 말하지만, HTTP2의 출현으로 포함된 문서의 형식은 별도로 논의될 것이라는 생각입니다.

Tony가 메시지를 보낸 지 몇 시간 후에 Tim Berners-Lee가 응답했습니다.

나는 일러스트가 다음과 같이 제시될 것이라고 생각했습니다.

삽화

여기서 비율 값은 다음을 나타냅니다.

EMBED 가능한 경우 여기에 삽입하세요.
PRESENT 원본 문서가 제시될 때 표시

이들의 다양한 조합이 있을 수 있으며 브라우저가 둘 중 하나를 지원하지 않는 경우에도 브라우저가 손상되지 않습니다.

[I]는 이것이 중첩된 링크를 통해 아이콘을 선택하는 방법으로 사용되는 것을 볼 수 있습니다. 흠. 하지만 나는 특별한 태그를 좋아하지 않습니다.

이 제안은 구현되지 않았지만 rel 속성은 여전히 ​​여기에 있습니다.

콘텐츠 유형을 지정하는 방법이 있다면 좋을 것입니다.

그러나 나는 파일 확장자로 콘텐츠 유형을 지정해야 한다는 요구 사항을 기꺼이 준수하고 있습니다.

이 제안은 구현되지 않았지만 Netscape는 나중에 요소에 미디어 객체를 삽입하기 위한 지원을 추가했습니다. .

이미지는 내 위시리스트의 최상위에 있고 WWW 브라우저의 유형 중간에 있지만 미디어별 후크를 한 번에 하나씩 추가해서는 안 된다고 생각합니다. MIME 메커니즘을 사용하려는 열정은 어떻게 되었나요?

이는 곧 표준 문서 메커니즘으로 사용되는 MIME을 대체하는 것이 아닙니다. MIME에 관계없이 필요한 기능을 간단하고 간단하게 구현합니다.

일시적인 문제라면 지금은 MIME을 잊어버리세요. 나의 반대는 "미디어 전반에 걸쳐 인라인 이미지를 어떻게 지원할 것인가"보다는 "인라인 이미지를 어떻게 지원할 것인가"에 대한 논의였습니다.

그렇지 않으면 일주일 안에 누군가가 '새 태그 삽입'을 제안할 것입니다. " 오디오용입니다.

일반적인 것에서 전환할 때 비용이 많이 들지 않아야 합니다.

돌이켜보면 Jay의 우려는 정당한 것으로 보입니다. 일주일 조금 넘게 걸렸지만, 드디어 HTML5에 새로운 요소가 추가되었습니다.

Jay의 원래 게시물에 대해 Dave Ragett는 다음과 같이 말했습니다.

정확히! 형식에 대한 논의와 함께 가능한 예술 유형 이미지/라인의 전체 범위를 살펴보고 싶습니다. Tim은 이미지 내부의 클릭 가능한 영역에 대한 지원에 대해 언급했는데, 이는 또한 중요합니다.

실제로 아이콘, 이미지, 텍스트 등에 첨부된 임의의 하이퍼링크를 삽입할 수 있는 범용 절차적 그래픽 언어에 대해 생각해야 할 수도 있습니다. 이와 관련하여 Intermedia의 기능을 본 사람이 있습니까?

Andrew와 Slate와 같은 (아주 가치 있는) 개념을 가진 다른 시스템을 확인해 보세요. Andrew는 _inserts_로 구축되었으며 각 삽입물에는 텍스트, 비트맵, 그래픽, 애니메이션, 메시지, 스프레드시트 등과 같은 몇 가지 흥미로운 유형이 있습니다. 임의 재귀 중첩이라는 개념이 존재하므로 어떤 종류의 삽입이라도 중첩을 지원하는 다른 종류에 중첩될 수 있습니다. 예를 들어 삽입은 텍스트 위젯의 텍스트, 그리기 위젯의 직사각형 영역 또는 스프레드시트의 셀 어디에나 삽입될 수 있습니다.

내 의견은 다음과 같습니다. WWW에서 이미지를 렌더링하는 가장 좋은 방법은 MIME을 사용하는 것입니다. 나는 PostScript가 이미 MIME 하위 유형 지정을 지원하고 있으며 텍스트와 그래픽을 결합하는 데 매우 훌륭한 작업을 수행한다고 확신합니다.

그런데 클릭이 안 된다고 하던데요? 그래 네가 맞아. 이에 대한 대답은 이미 Display PostScript에 있는 것 같습니다. 표준 PostScript에 추가되지 않더라도 이는 사소한 일입니다. URL을 지정하고 현재 경로를 버튼의 닫힌 영역으로 사용하는 링크 명령을 정의합니다. PostScript는 경로를 잘 다루기 때문에 사용자 정의 버튼을 만드는 것은 쉽지 않습니다.

Display PostScript는 Adobe와 NeXT가 공동 개발한 화면 렌더링 기술입니다.

이 제안은 구현되지 않았지만 HTML을 수정하는 가장 좋은 방법은 HTML을 완전히 다른 것으로 바꾸는 것이라는 생각이 여전히 가끔 떠오릅니다.

HTTP2를 사용하면 등록된 MIME 유형뿐만 아니라 사용자가 작업할 수 있다고 말한 모든 유형을 문서에 포함할 수 있습니다. 그래서 실험해 볼 수 있습니다. 네, 하이퍼텍스트가 포함된 PostScript의 경우가 있다고 생각합니다. Display PostScript로 충분한지 모르겠습니다. 저는 Adobe가 링크가 있고 자체 뷰어로 읽을 수 있는 자체 PostScript 중심 "PDF"를 만들려고 노력하고 있다는 것을 알고 있습니다.

내 생각에는 링크용 공통 오버레이 언어(Hytime 기반?)를 사용하면 하이퍼텍스트와 그래픽/비디오 표준이 별도로 발전할 수 있어 두 가지 모두에 도움이 될 것입니다.

IMG 태그에 INCLUDE를 포함하고 임의의 문서 유형을 참조하도록 합니다. 또는 INCLUDE가 cpp include처럼 들리면 EMBED를 사용하여 사람들이 의도한 대로 SGML 소스 코드를 한 줄씩 구문 분석할 수 있도록 제공할 수 있습니다.

다시 인라인 이미지로 돌아가기 - 앞서 언급한 대로 GIF 및 XBM 이미지를 지원하는 모자이크 0.10 출시가 가까워졌습니다...

현재로서는 INCLUDE/EMBED를 지원할 준비가 되지 않았습니다. 따라서 아마도 다음과 같이 할 것입니다. (모든 인라인 이미지를 아이콘이라고 부를 수는 없으므로 ICON이 아닙니다.) 현재 인라인 이미지에는 콘텐츠 유형이 명시적으로 포함되지 않습니다. 앞으로는 (일반적인 MIME 적응과 함께) 이를 지원할 계획입니다. 실제로 현재 우리가 사용하는 이미지 읽기 루틴은 형식을 즉석에서 파악하므로 파일 확장자는 그다지 중요하지 않습니다.

연속선

나는 거의 17년에 걸친 대화의 모든 측면에 대해 극도로 열정적이며, 이로 인해 지금까지 게시된 거의 모든 웹 페이지에 사용된 HTML 요소가 만들어졌습니다. 다음을 고려해보자:

• HTTP는 여전히 존재합니다. HTTP는 0.9에서 1.0으로, 그리고 이후 1.1로 성공적으로 발전했습니다. 그리고 그것은 아직도 발전하고 있습니다.
• HTML은 여전히 ​​존재합니다. 이것은 기본적인 데이터 형식입니다. 라인 이미지도 지원하지 않습니다! - 2.0, 3.2, 4.0에서 성공적으로 개발되었습니다. HTML은 연속된 줄입니다. 확실히 구부러지고, 엉키고, 얽힌 선입니다. 진화계통에는 "죽은 가지"가 많이 있었는데, 표준적인 사고를 하는 사람들이 자신보다 앞서가는(그리고 작가와 공연자들을 능가하는) 곳이었습니다. 그러나 그럼에도 불구하고. 우리는 2010년에 살고 있지만 1990년의 웹페이지는 여전히 최신 브라우저에 표시됩니다. 방금 최신 Android의 휴대폰 브라우저에 하나를 로드했는데 "레거시 형식을 가져오는 동안 기다려 주십시오..."라는 메시지도 표시되지 않았습니다.
• HTML은 항상 브라우저 개발자, 작성자, 표준 전문가 및 방금 나타나서 꺾쇠 괄호에 대해 이야기하고 싶어하는 다른 사람들 사이의 대화였습니다. HTML의 가장 성공적인 버전은 세상을 따라잡으면서 올바른 방향으로 나아가려고 노력하는 "복고 사양"이었습니다. HTML이 "깨끗"해야 한다고 말하는 사람(아마도 브라우저 개발자나 작성자 또는 둘 다 무시)은 잘못된 정보를 갖고 있는 것입니다. HTML은 결코 깨끗하지 않았으며 이를 정리하려는 모든 시도는 눈에 띄게 실패했으며 이를 대체하려는 시도에 의해서만 일치합니다.
• 1993년 이후 어떤 브라우저도 인식 가능한 형태로 존재하지 않습니다. Netscape Navigator는 1998년에 폐기되었으며 처음부터 다시 작성되어 Mozilla Suite를 만들었고 이후 Firefox는 파생되었습니다. Internet Explorer는 "Microsoft Plus!"의 소박한 "시작할 곳"으로 시작되었습니다. Windows 95용"에는 일부 데스크탑 테마와 핀볼 게임이 번들로 제공되었습니다.
• 1993년의 운영 체제 중 일부는 여전히 존재하지만 그 중 어느 것도 현대 웹과 관련이 없습니다. 대부분의 "숙련된" 사람들은 Windows 2000 이상을 실행하는 PC, Mac OS X를 실행하는 Mac, 맛있는 Linux를 실행하는 PC 또는 iPhone과 같은 휴대용 장치에서 인터넷에 액세스합니다. 1993년에 Windows는 버전 3.1(OS/2와 경쟁)이었고 Mac은 System 7을 실행했으며 Linux는 Usenet을 통해 배포되었습니다.
• 어떤 사람들은 우리가 지금 간단히 "웹 표준"이라고 부르는 것에 여전히 참여하고 있습니다. 이제 거의 20년이 지났습니다. 그리고 일부는 1980년대 이전으로 거슬러 올라가 HTML의 전신에 관여했습니다.
• 전임자에 대해 말하면... HTML과 웹의 엄청난 인기로 인해 현대 형식과 시스템의 디자인을 형성한 사람들을 쉽게 잊을 수 있습니다. 앤드류? 중개자? 하이타임? 그리고 HyTime은 홍수 이전의 연구 프로젝트가 아니라 ISO 표준이었습니다. 군용으로 승인되었습니다. 빅비즈니스였습니다. 그리고 그것에 대해 직접 읽어볼 수도 있습니다...

하지만 이 중 어느 것도 원래 질문인 요소를 사용하는 이유에 대한 답은 없습니다. ? 왜 요소가 아닌가? ? 또는 요소 ? include 속성이나 rel 값의 일부 조합이 있는 하이퍼링크는 왜 안 되나요? 요소가 필요한 이유 ? Marc Andreessen이 이를 구현했고 구현된 코드가 승리했기 때문에 매우 간단합니다.

이는 구현된 모든 코드가 승리했다는 의미는 아니며, 결국 Andrew와 Intermedia 및 HyTime도 구현되었습니다. 코드는 필요하지만 성공을 위해서는 충분하지 않습니다. 표준이 발표되기 전에 코드를 구현하는 것이 최선의 해결책이라고 말하는 것은 아닙니다. 엘리먼트 브랜드 기본 그래픽 형식을 정의하지 않습니다. 텍스트가 주위에 어떻게 흘러야 하는지 지정하지 않습니다. 이전 브라우저에 대한 대체 텍스트 또는 대체 콘텐츠를 지원하지 않습니다. 그리고 17년이 지난 지금도 우리는 여전히 콘텐츠 스니핑으로 어려움을 겪고 있으며 이는 여전히 엄청난 보안 취약점의 원인입니다. 그리고 17년 전, 브라우저 대전쟁을 통해 1993년 2월 25일 Marc Andreessen이 아무렇지도 않게 "MIME, 언젠가는 아마도"라고 말하고 무슨 일이 있어도 자신의 코드를 구현했던 때까지 거슬러 올라갈 수 있습니다.

1997년부터 2004년까지 HTML 개발의 타임라인

1997년 12월 W3C(World Wide Web Consortium)는 HTML 4.0을 발표하고 HTML 워킹 그룹을 즉시 폐쇄했습니다. 두 달도 채 지나지 않아 별도의 W3C 워킹 그룹이 XML 1.0을 발표했습니다. 그로부터 3개월 후, W3C를 운영하는 사람들은 'W3C가 HTML을 버렸는가?'라는 질문에 답하기 위해 'HTML의 미래 형성'이라는 워크숍을 열었습니다. 그들의 대답은 이랬습니다.

논의 과정에서 HTML 4.0을 XML 애플리케이션으로 변환하는 것처럼 HTML 4.0의 추가 확장은 어려울 것이라는 결론이 나왔습니다. 제안된 경로는 XML 태그 세트를 기반으로 하는 차세대 HTML로 새로운 삶을 시작하는 데 제한을 두지 않을 것입니다.

W3C는 이 "XML 태그 세트"를 생성하기 위해 HTML 작업 그룹을 다시 시작했습니다. 1998년 12월의 첫 번째 단계는 새로운 요소나 속성을 추가하지 않고 HTML을 XML로 간단히 재작업하는 임시 사양의 초안을 작성하는 것이었습니다. 이 사양은 나중에 "XHTML 1.0"으로 알려졌습니다. XHTML 문서에 대한 새로운 MIME 유형(application/xhtml+xml)을 정의했습니다. 그러나 기존 HTML4 페이지의 마이그레이션을 용이하게 하기 위해 "XHTML 문서를 기존 HTML 사용자 에이전트에서 렌더링하려는 작성자를 위한 디자인 지침을 요약한" 부록 C도 포함했습니다. 부록 C에서는 소위 "XHTML" 페이지의 작성자가 여전히 MIME 유형 text/html 을 사용하여 페이지를 제공할 수 있도록 허용한다고 설명합니다.

다음 목표는 웹 양식이었습니다. 1999년 8월, 동일한 HTML 작업 그룹이 XHTML 확장 형식의 첫 번째 초안을 발표했습니다. 그녀는 첫 번째 단락에서 기대치를 설정했습니다.

신중하게 고려한 후 HTML 작업 그룹은 차세대 양식의 목표가 이전 버전의 HTML용으로 설계된 브라우저와의 하위 호환성을 유지하는 것과 동일하지 않다는 결론을 내렸습니다. 우리의 목표는 명확하게 정의된 요구사항 세트를 기반으로 새로운 양식 모델(XHTML 확장 양식)의 순수성을 보장하는 것입니다. 이러한 요구 사항은 이 문서에 설명되어 있으며 다양한 양식 응용 프로그램에 대한 경험을 바탕으로 합니다.

몇 달 후 "XHTML Extended Forms"는 "XForms"로 이름이 바뀌고 자체 작업 그룹으로 이동되었습니다. 이 그룹은 HTML 작업 그룹과 병행하여 작업했으며 마침내 2003년 10월에 XForms 1.0의 첫 번째 릴리스를 발표했습니다.

한편, 완전한 XML로의 전환과 함께 HTML Working Group은 "차세대 HTML"을 만드는 데 목표를 세웠습니다. 2001년 5월에는 XHTML 1.0에 몇 가지 사소한 기능만 추가한 XHTML 1.1의 첫 번째 개정판을 발표했지만 "부록 C" 허점도 해결했습니다. 버전 1.1부터 모든 XHTML 문서는 application/xhtml+xml MIME 유형으로 제공되어야 합니다.

XHTML에 대해 당신이 아는 모든 것이 잘못되었습니다

MIME 유형이 왜 그렇게 중요한가요? 나는 왜 계속 그들에게 돌아오는 걸까요? 세 단어: 엄격한 오류 처리. 브라우저는 항상 HTML에 관대했습니다. HTML 페이지를 생성했지만 태그를 잊어버린 경우, 브라우저는 계속 페이지를 표시합니다(일부 태그는 암시적으로 완료를 유발함). 그리고 시작 ). 태그가 계층적으로 중첩되어 있다고 가정해야 합니다. 태그는 역순으로 닫혀 있습니다. 그러나 다음과 같은 코드를 생성하면 , 브라우저는 이를 어떤 식으로든 처리하고 오류 메시지를 표시하지 않고 계속 진행합니다.

예상할 수 있듯이 깨진 HTML이 브라우저에서 작동한다는 사실로 인해 작성자는 깨진 HTML 페이지를 만들 수 있었습니다. 깨진 페이지가 많습니다. 일부 추정에 따르면 오늘날 웹에 있는 HTML 페이지의 99% 이상이 적어도 하나의 오류를 포함하고 있습니다. 그러나 이러한 버그는 브라우저에 눈에 띄는 오류 메시지를 표시하도록 강요하지 않으므로 아무도 이를 수정하지 않습니다.

W3C는 이를 웹의 근본적인 문제로 보고 이를 수정하기 시작했습니다. 1997년에 출판된 XML은 클라이언트를 용서하는 전통을 깨고 XML을 사용하는 모든 프로그램이 소위 "구문" 오류를 치명적인 오류로 처리해야 한다고 선언했습니다. 첫 번째 실수에 실패한다는 개념은 "드라코니안 오류 처리"로 알려졌는데, 이는 자신의 법을 조금만 위반해도 사형을 선고한 그리스 지도자 드라코와 유사합니다. W3C는 HTML을 XML 어휘로 재구성할 때 새로운 MIME 유형인 application/xhtml+xml과 함께 전송되는 모든 문서에 엄격한 오류 처리를 적용하도록 규정했습니다. XHTML 페이지에 구문 오류가 하나 이상 있는 경우(예: 태그 잊음)또는 잘못 중첩된 시작 및 종료 태그 - 브라우저는 처리를 중지하고 최종 사용자에게 오류 메시지를 표시하는 것 외에는 선택의 여지가 없습니다.

이 아이디어는 모든 곳에서 인기가 없습니다. 기존 페이지의 약 99% 오류율, 최종 사용자에게 오류가 표시될 가능성이 널리 퍼져 있음, XHTML 1.0 및 1.1의 새로운 기능 부족으로 인해 작성자는 비용을 정당화하기 위해 application/xhtml+xml을 대부분 무시합니다. 그러나 이것이 그들이 XHTML을 전체적으로 무시했다는 의미는 아닙니다. 아, 절대 그렇지 않습니다. XHTML 1.0 사양의 부록 C는 전 세계 저자들에게 다음과 같은 허점을 제공했습니다. "XHTML 구문처럼 보이는 것을 만들되 MIME 유형 text/html로 전달되도록 하십시오." 그리고 이것이 바로 수천 명의 웹 개발자가 한 일입니다. 그들은 XHTML 구문으로 "업그레이드"했지만 계속해서 text/html MIME 유형으로 렌더링했습니다.

오늘날에도 수백만 개의 웹페이지가 XHTML을 주장하고 있습니다. 첫 번째 줄에서 XHTML 문서 유형으로 시작하고, 소문자 태그 이름을 사용하고, 속성 주위에 따옴표를 사용하고, 다음과 같은 빈 요소 뒤에 슬래시를 추가합니다.
그리고

---

. 그러나 이러한 페이지 중 극히 일부만이 엄격한 XML 오류 처리를 포함하는 application/xhtml+xml MIME 유형으로 제공됩니다. 문서 유형, 구문 또는 인코딩 스타일에 관계없이 MIME 유형 text/html로 전달된 모든 페이지는 관대한 HTML 파서에 의해 구문 분석되며, 페이지가 기술적으로 오류가 있더라도 모든 마크업 오류를 자동으로 무시하고 최종 사용자(또는 다른 사람)에게 경고하지 않습니다. 고장난.

XHTML 1.0에는 이 허점이 포함되어 있었지만 XHTML 1.1은 이를 해결했으며 미완성 XHTML 2.0에서는 엄격한 오류 처리를 요구하는 전통을 이어갔습니다. 이것이 XHTML 1.0이라고 주장하는 수십억 개의 페이지가 있고 XHTML 1.1(또는 XHTML 2.0)이라고 주장하는 페이지가 소수에 불과한 이유입니다. 그렇다면 실제로 XHTML을 사용하고 있습니까? MIME 유형을 확인하세요(실제로 어떤 MIME 유형을 사용하고 있는지 모른다면 text/html 도 사용하고 있다고 거의 보장할 수 있습니다). MIME 유형 application/xhtml+xml 을 사용하여 페이지를 전달하지 않는 한 소위 "XHTML"은 이름만 XML입니다.

경쟁적 비전

2004년 6월, W3C는 웹 애플리케이션과 복합 문서에 관한 워크숍을 개최했습니다. 이번 워크숍에는 브라우저 3개사, 웹 개발사 대표, 기타 W3C 회원사 대표들이 참석했다. Mozilla Foundation 및 Opera Software를 포함한 이해 관계자 그룹은 웹의 미래에 대한 경쟁 비전을 설명했습니다. 기존 HTML 4 표준의 발전에는 최신 웹 애플리케이션 개발자를 위한 새로운 기능이 포함됩니다.

다음 7가지 원칙은 우리가 이 작업에 대해 가장 중요한 요구 사항으로 간주하는 사항을 반영합니다.

이전 버전과 호환되고 명확한 마이그레이션 경로 웹 애플리케이션 기술은 작성자에게 친숙한 기술을 기반으로 해야 하며 HTML, CSS, DOM 및 JavaScript를 포함해야 합니다. 웹 애플리케이션의 핵심 기능은 현재 IE6의 동작, 스크립트 및 스타일시트를 사용하여 수행되어야 작성자가 명확한 마이그레이션 경로를 가질 수 있습니다. 필요한 플러그인 없이 현재 사용자 에이전트에서 사용할 수 없는 솔루션은 아마도 성공할 수 없습니다. 웰니스 오류 처리 웹 애플리케이션의 오류 처리는 사용자 에이전트가 자체 오류 처리 메커니즘을 개발하거나 다른 사용자 에이전트를 리버스 엔지니어링해서는 안 되는 세분성 수준에서 정의되어야 합니다. 사용자에게 고유한 오류가 발생해서는 안 됩니다. 사양에서는 가능한 모든 오류 시나리오에 대해 정확한 복구 동작을 지정해야 합니다. 오류 처리는 명백하고 치명적인 오류(XML과 같은)보다는 점진적인 오류 복구(CSS와 같은) 측면에서 대부분 정의되어야 합니다. 실제 사용 웹 애플리케이션의 사양에 들어가는 각 기능은 실제 사용을 통해 정당화되어야 합니다. 그 반대가 항상 참인 것은 아닙니다. 모든 사용 사례가 반드시 새로운 기능을 보장하는 것은 아닙니다. 저자가 이전에 제한을 우회하기 위해 잘못된 솔루션을 사용한 실제 사이트를 기반으로 한 주장을 사용하는 것이 좋습니다. 스크립트는 남아 있지만 편리한 마크업을 사용할 수 있는 경우에는 피해야 합니다. 스크립트는 특정 장치에서 가능한 한 오랫동안 중립적으로 표시되어야 합니다(예: XBL에 포함되지 않은 경우). 장치별 프로필은 피해야 합니다. 작성자는 동일한 사용자 에이전트의 데스크톱 및 모바일 버전에서 수행되는 동일한 기능에 의존할 수 있어야 합니다. 개방형 프로세스 웹은 개방형 환경에서 개발되었기 때문에 유익했습니다. 웹 애플리케이션은 웹의 핵심이 될 것이며 개발자는 개방적이어야 합니다. 메일링 리스트, 아카이브, 사양 초안은 대중에게 영구적으로 공개되어야 합니다.

비공식 여론조사에서 워크숍 참가자들은 다음과 같은 질문을 받았습니다. “W3C는 HTML 및 CSS의 선언적 확장을 개발하고 전체 OS의 복잡한 API와는 달리 중간 계층 웹 애플리케이션의 요구 사항을 해결하기 위해 반드시 DOM을 확장해야 합니까? (Opera Software의 Ian Hickson이 제안함)." 투표 결과는 찬성 11표, 반대 8표였습니다. 워크숍 요약에서 W3C는 다음과 같이 썼습니다. "현재 W3C는 현재 W3C 헌장에 따라 개발된 기술 외에 제3자 비공식 조사 주제인 웹 애플리케이션용 HTML 및 CSS 확장에 대한 리소스를 제공할 의도가 없습니다. W3C 워킹 그룹."

이러한 결정에 직면하여 HTML 및 HTML 양식 개발을 제안한 사람들에게는 두 가지 선택밖에 없었습니다. 포기하거나 W3C 외부에서 작업을 계속하는 것입니다. 그들은 후자를 선택하고 whatwg.org 도메인을 등록했고, 2004년 6월 WHAT 워킹 그룹이 탄생했습니다.

어떤 실무그룹인가요?

도대체 WHAT 워킹 그룹이 뭐죠? 나는 그들이 스스로 설명하도록 하겠다:

WHAT 실무 그룹은 브라우저 공급업체와 이해관계자가 함께 참여하는 무료, 비공식, 공개 협력체입니다. 이 그룹은 표준 조직 결과 제공을 목표로 상호 운용 가능한 웹 애플리케이션 배포를 촉진하기 위해 HTML 및 관련 기술을 기반으로 하는 사양을 개발하는 것을 목표로 합니다. 이 조항은 표준 과정의 공식 HTML 확장 작업의 기초를 형성합니다.

이 포럼의 창설은 각 기술의 사양에 관해 수개월간 개인적인 서신을 주고받은 후에 이루어졌습니다. 기존 콘텐츠와의 하위 호환성을 유지하면서 작성자가 요청한 기능을 지원하기 위해 HTML4 양식을 확장하는 데 중점을 두었습니다. 이 그룹은 이러한 사양의 향후 개발을 제공하기 위해 만들어졌으며 공개 아카이브와 액세스 가능한 메일링 목록을 통해 완전히 공개됩니다.

여기서 핵심 문구는 "이전 버전과의 호환성을 유지하면서"입니다. XHTML(부록 C 허점 제외)은 HTML과 하위 호환되지 않습니다. 해당 MIME 유형으로 전송되는 모든 콘텐츠에 대한 엄격한 오류 처리를 포함하는 완전히 새로운 MIME 유형이 필요합니다. XForms는 새로운 XHTML MIME 유형으로 제출된 문서에서만 사용할 수 있기 때문에 HTML 양식과 호환되지 않습니다. 즉, XForms에는 엄격한 오류 처리도 포함되어 있습니다. 모든 길은 MIME으로 통합니다.

WHAT 실무 그룹은 10년이 넘는 HTML 투자를 포기하고 기존 웹 페이지의 99%를 사용할 수 없게 만드는 대신 브라우저가 실제로 사용하는 "관용적인" 오류 처리 알고리즘을 문서화하는 다른 접근 방식을 취하기로 결정했습니다. 브라우저는 항상 HTML 오류를 용서하지만, 그 누구도 HTML 오류가 어떻게 발생했는지 정확히 기록하려고 노력하지 않았습니다. NCSA 모자이크는 깨진 페이지를 처리하기 위한 자체 알고리즘을 갖고 있으며 넷스케이프는 이를 일치시키려고 노력했습니다. Internet Explorer는 Netscape와 경쟁을 시도합니다. 그런 다음 Opera와 Firefox는 Internet Explorer와 경쟁을 시도합니다. Safari는 Firefox와 경쟁을 시도합니다. 등등, 바로 현재까지. 그 과정에서 개발자들은 자신의 제품이 경쟁사와 호환되도록 만들기 위해 수천 시간을 소모했습니다.

이것이 엄청난 양의 작업처럼 들린다면 그것은 사실이기 때문입니다. 아니면 오히려 그랬습니다. 5년이 걸렸지만 WHAT 워킹 그룹은 기존 웹 콘텐츠와 호환되는 방식으로 HTML을 구문 분석하는 방법을 성공적으로 문서화했습니다. 최종 알고리즘에는 HTML이 처리를 중지하고 최종 사용자에게 오류 메시지를 표시해야 한다는 단계가 없습니다.

리버스 엔지니어링이 진행되는 동안 WHAT 워킹 그룹은 조용히 다른 작업을 진행하고 있었습니다. 그 중 하나는 처음에 Web Forms 2.0을 복제하고 HTML 양식에 새로운 필드 유형을 추가한 사양이었습니다(Web Forms에 대한 자세한 내용은 에서 배우게 됩니다). 또 다른 초안 사양은 "웹 애플리케이션 1.0"으로, 직접 그리기를 위한 캔버스와 플러그인 없이 기본 오디오 및 비디오 지원과 같은 많은 새로운 기능을 포함했습니다.

W3C로 돌아가기

2년 반 동안 W3C와 WHAT 워킹 그룹은 대체로 서로를 무시했습니다. WHAT 워킹 그룹이 웹 양식과 새로운 HTML 기능에 초점을 맞춘 반면, W3C HTML 워킹 그룹은 XHTML 버전 2.0으로 바빴습니다. 그러나 2006년 10월이 되자 WHAT 워킹 그룹이 상당한 추진력을 얻었지만 XHTML 2는 여전히 초안 형태로 머물러 있었고 어떤 브라우저에서도 구현되지 않았다는 것이 분명해졌습니다. 2006년 10월, W3C의 창립자인 Tim Berners-Lee는 W3C가 WHAT 워킹 그룹과 협력하여 HTML을 개발할 것이라고 발표했습니다.

몇 년이 지나면 어떤 것들은 분명해집니다. HTML을 점진적으로 개발하는 것이 필요합니다. 속성 값 주위의 따옴표와 빈 태그 및 네임스페이스의 슬래시를 포함하여 XML로 이동하여 세상을 얻으려는 시도가 한꺼번에 작동하지 않습니다. HTML을 중심으로 형성된 거대한 대중은 움직이지 않았습니다. 주로 브라우저가 불평하지 않았기 때문입니다. 일부 대규모 커뮤니티에서는 전환을 이루어 구문적으로 올바른 시스템의 이점을 누리고 있지만 전부는 아닙니다. HTML을 점진적으로 지원하고 구문적으로 올바른 세계를 향해 계속 나아가며 그 세계에서 더 많은 노력을 기울이는 것이 중요합니다.

완전히 새로운 HTML 그룹을 구성할 계획이 있습니다. 이전 그룹과 달리 HTML과 XHTML을 동시에 점진적으로 개선할 예정입니다. 다양한 경영진과 직원이 있을 것입니다. HTML과 XHTML에서 함께 작동합니다. 우리는 브라우저 개발자를 포함하여 우리가 이야기한 많은 사람들로부터 이 그룹에 대한 강력한 지지를 받고 있습니다.

양식을 다루는 작업도 있을 것입니다. 기존 HTML 양식과 XForms는 양식 언어이기 때문에 이는 어려운 영역입니다. HTML 양식은 널리 배포되며 XForms의 구현과 사용자도 많습니다. 한편 WebForms는 HTML 양식으로 지능적으로 확장됩니다. WebForms를 HTML 양식의 확장으로 구성할 계획입니다.

새로 형성된 W3C HTML 워킹 그룹이 가장 먼저 한 일 중 하나는 "웹 ​​애플리케이션 1.0"의 이름을 "HTML5"로 바꾸기로 결정한 것입니다. 그래서 우리는 HTML5에 대해 알아봅니다.

추신

2009년 10월 W3C는 XHTML 2 작업 그룹을 폐쇄하고 결정을 설명하는 성명을 발표했습니다.

W3C가 2007년 3월 HTML 및 XHTML 2 작업 그룹을 발표했을 때 우리는 XHTML 2 시장을 계속 모니터링할 것이라고 밝혔습니다. W3C는 HTML의 미래에 대한 커뮤니티의 중요하고 명확한 신호를 인식하고 있습니다.

우리는 수년에 걸쳐 XHTML 2 작업 그룹의 중요성을 인식하고 있지만 회원들과 논의한 후 W3C 리더십은 2009년 말에 만료되는 작업 그룹 헌장을 갱신하지 않기로 결정했습니다.

이를 구현한 사람들은 이로 인해 혜택을 받았습니다.

HTML 개발의 역사

1989년에 Tim Berners-Lee는 국제 고에너지 센터(CERN)의 지도부에 그가 월드 와이드 웹(WWW)이라고 부르는 분산 하이퍼텍스트 시스템 프로젝트를 제안했습니다. 시스템의 원래 아이디어는 하이퍼텍스트 탐색 시스템을 사용하여 CERN의 많은 정보 자원을 모두 단일 정보 시스템으로 결합하는 것이었습니다. 이 기술은 매우 성공적이어서 세계에서 가장 인기 있는 글로벌 정보 시스템 중 하나의 개발을 촉진했습니다. 거의 대부분의 글로벌 컴퓨터 네트워크 인터넷 사용자의 마음 속에는 이 네트워크 자체가 세 가지 주요 정보 기술과 연관되어 있습니다.

· 전자 메일(이메일);

· FTP 파일 아카이브;

· 월드 와이드 웹.

더욱이 최신 기술이 점차 선두로 옮겨가고 있습니다.

월드 와이드 웹(World Wide Web) 기술의 성공은 단순성과 인터넷의 기초가 되는 TCP/IP 계열의 인터네트워킹 프로토콜(전송 제어 프로토콜, 인터넷 프로토콜)의 사용이라는 두 가지 주요 요소에 의해 결정됩니다.

거의 모든 인터넷 사용자는 World Wide Web에 게시된 정보 자료의 작성자 및 독자로서 자신을 시험해 볼 기회를 동시에 가졌습니다. 그러나 인터넷 자체의 인기는 주로 월드 와이드 웹(World Wide Web)의 출현에 기인합니다. 월드 와이드 웹은 다양한 네트워크 리소스에 액세스할 수 있는 간단하고 현대적인 인터페이스를 사용자에게 제공한 최초의 네트워크 기술이기 때문입니다. 단순성과 사용 편의성으로 인해 사용자 수가 증가했습니다. WWW상업시설의 주목을 끌었습니다. 그러다가 사용자 수가 눈사태처럼 늘어나는 과정이 오늘날까지 계속되고 있습니다.

동시에 기술 자체도 초기 단계에서는 매우 간단했습니다. 사실은 기술의 다양한 구성요소(HTML 하이퍼텍스트 마크업 언어, 하이퍼텍스트 정보 교환 프로토콜 HTTP, CGI 응용 소프트웨어 개발 사양 등)를 개발할 때 정보 자원 및 해당 컴퓨터 장비 작성자의 자격이 다음과 같은 것으로 가정되었습니다. 최소화하세요.

월드 와이드 웹에서 분산 하이퍼텍스트 시스템을 만드는 기술의 구성 요소 중 하나는 표준 일반화 마크업 언어(SGML)를 기반으로 Tim Berners-Lee가 개발한 하이퍼텍스트 마크업 언어 HTML이었습니다. Daniel W. Connolly는 이에 대한 문서 유형 정의(Document Type Definition)를 작성했습니다. 이는 SGML 용어로 HTML 구문을 공식적으로 설명하는 것입니다.

HTML 개발자는 두 가지 문제를 해결할 수 있었습니다.

· 문서를 생성하는 간단한 수단을 하이퍼텍스트 데이터베이스 디자이너에게 제공합니다.

· 하이퍼텍스트 데이터베이스의 사용자 인터페이스에 대한 당시의 기존 아이디어를 반영할 만큼 강력하게 이 도구를 만듭니다.

첫 번째 문제는 문서 설명을 위한 태깅 모델을 선택하여 해결되었습니다. 이 모델은 인쇄용 문서를 준비하는 시스템에 널리 사용됩니다. 이러한 시스템의 예로는 American Mathematical Society에서 제안한 잘 알려진 TeX 과학 문서 마크업 언어와 이를 해석하는 프로그램이 있습니다.

HTML 언어화면에 표시되는 전자 문서에 인쇄 수준의 디자인을 표시할 수 있습니다. 결과 문서에는 다양한 레이블, 일러스트레이션, 오디오 및 비디오 조각 등이 포함될 수 있습니다. 이 언어에는 다양한 수준의 제목, 글꼴 선택, 다양한 목록, 표 등을 생성하기 위한 개발된 도구가 포함되어 있습니다.

HTML의 운명에 영향을 미치는 두 번째 중요한 점은 일반 텍스트 파일이 기본으로 선택되었다는 것입니다. 선택은 다음 요소의 영향을 받아 이루어졌습니다.

· 이러한 파일은 모든 운영 체제 환경의 모든 하드웨어 플랫폼에 있는 모든 텍스트 편집기에서 생성될 수 있습니다.

· HTML이 개발될 무렵에는 네트워크 정보 시스템 개발을 위한 미국 표준인 Z39.50이 있었는데, 여기에는 LATIN1 인코딩의 단순 텍스트 파일이 US ASCII에 해당하는 저장 단위로 지정되었습니다.

따라서 하이퍼텍스트 데이터베이스 개념은 WWW정보 표시(마크업)의 형식과 이러한 파일과 기타 정보 리소스(하이퍼텍스트 링크) 간의 연결 구조를 결정하는 HTML로 마크업된 텍스트 파일 세트입니다. 텍스트 문서 간의 연결을 설정하는 하이퍼텍스트 링크는 점차적으로 사운드 및 비디오를 포함한 다양한 정보 리소스를 통합하기 시작했습니다. 그 결과 하이퍼미디어라는 새로운 개념이 등장했습니다.

이 접근 방식은 기술의 또 다른 구성 요소인 언어 통역사의 존재를 전제로 합니다. World Wide Web에서 인터프리터 기능은 하이퍼텍스트 데이터베이스 웹 서버와 사용자 인터페이스로 구분됩니다. 서버는 문서에 액세스하고 하이퍼텍스트 링크를 처리하는 것 외에도 문서의 사전 처리 기능을 제공하는 동시에 사용자 인터페이스는 정보 표시와 관련된 언어 구성을 해석합니다.

언어의 첫 번째 버전(HTML 1.0)은 언어 자체를 표현하는 것을 목표로 했으며, 그 기능에 대한 설명은 본질적으로 다소 권고적이었습니다. 언어의 두 번째 버전(HTML 2.0)은 해당 구문을 사용하는 방법을 기록했습니다. 버전 ++(HTML++)에는 HTML 태그 세트를 확장하여 과학적 정보와 표를 표시하고 이미지와 텍스트의 레이아웃 스타일을 개선하는 새로운 기능이 도입되었습니다. 버전 3.2에서는 모든 혁신을 간소화하고 기존 관행과 조화시킬 수 있었습니다. HTML 3.2를 사용하면 테이블을 사용하고, Java 코드를 실행하고, 그래픽 주위에 텍스트를 배치하고, 위 첨자와 아래 첨자를 표시할 수 있습니다.

이제 HTML의 새 버전을 설명하기 위한 문서를 준비하고 배포하는 국제 조직인 W3C(World Wide Web Consortium)는 이미 HTML 4.01 사양에 대한 자료를 게시했습니다. 이전 버전의 HTML에 이미 존재했던 텍스트 마크업, 멀티미디어 및 하이퍼텍스트 연결 기능 외에도 버전 4.01에는 추가 멀티미디어 도구, 프로그래밍 언어, 스타일 시트 및 이미지와 문서 인쇄를 위한 단순화된 도구가 포함되어 있습니다. JavaScript, Java 및 VBScript와 같은 스크립트 언어를 사용하여 웹사이트 탐색 스크립트(World Wide Web에서 호스팅되는 하이퍼텍스트 데이터베이스)를 관리할 수 있습니다.

HTML의 복잡성이 증가하고 프로그래밍 언어의 출현으로 인해 웹 사이트 개발이 매우 전문적인 문제가 되었으며 활동 영역의 전문화와 새로운 웹 기술에 대한 지속적인 연구가 필요해졌습니다. 그러나 인터넷의 힘 덕분에 HTML의 기본을 아는 사용자는 큰 비용을 들이지 않고도 자신의 웹 사이트를 만들고 호스팅할 수 있습니다. 제안된 코스는 이러한 사용자를 위해 설계되었습니다.

강의 2. 기초HTML. 가능성HTML5.

1. HTML 언어 개발의 역사

1989년에 Tim Berners-Lee는 국제 고에너지 센터(CERN)의 지도부에 그가 월드 와이드 웹(WWW)이라고 부르는 분산 하이퍼텍스트 시스템 프로젝트를 제안했습니다. 시스템의 원래 아이디어는 하이퍼텍스트 탐색 시스템을 사용하여 CERN의 많은 정보 자원을 모두 단일 정보 시스템으로 결합하는 것이었습니다.

World Wide Web에서 분산 하이퍼텍스트 시스템을 만드는 기술의 구성 요소 중 하나는 하이퍼텍스트 마크업 언어입니다. HTML (하이퍼텍스트마크업언어– 표준 일반화 마크업 언어(SGML)를 기반으로 Tim Berners-Lee가 개발한 하이퍼텍스트 문서 마크업 언어). Daniel W. Connolly는 이에 대한 문서 유형 정의(Document Type Definition)를 작성했습니다. 이는 SGML 용어로 HTML 구문을 공식적으로 설명하는 것입니다.

HTML 개발자는 두 가지 문제를 해결할 수 있었습니다.

하이퍼텍스트 데이터베이스 설계자에게 문서를 생성하는 간단한 수단을 제공합니다.

하이퍼텍스트 데이터베이스의 사용자 인터페이스에 대한 현재의 이해를 반영할 수 있을 만큼 강력하게 이 도구를 만듭니다.

첫 번째 문제는 문서 설명을 위한 태깅 모델을 선택하여 해결되었습니다. 이 모델은 인쇄용 문서를 준비하는 시스템에 널리 사용됩니다.

HTML 언어를 사용하면 화면에 표시되는 전자 문서에 인쇄 수준의 디자인을 표시할 수 있습니다. 결과 문서에는 다양한 레이블, 일러스트레이션, 오디오 및 비디오 조각 등이 포함될 수 있습니다. 이 언어에는 다양한 수준의 제목, 글꼴 선택, 다양한 목록, 표 등을 생성하기 위한 개발된 도구가 포함되어 있습니다.

HTML의 운명에 영향을 미치는 두 번째 중요한 점은 일반 텍스트 파일이 기본으로 선택되었다는 것입니다.

따라서 WWW 개념의 하이퍼텍스트 데이터베이스는 정보 표현(마크업)의 형식과 이러한 파일과 다른 정보 리소스(하이퍼텍스트 링크) 간의 연결 구조를 결정하는 HTML로 마크업된 텍스트 파일 세트입니다. 텍스트 문서 간의 연결을 설정하는 하이퍼텍스트 링크는 점차적으로 사운드 및 비디오를 포함한 다양한 정보 리소스를 통합하기 시작했습니다. 그 결과 하이퍼미디어라는 새로운 개념이 등장했습니다.

이 접근 방식은 기술의 또 다른 구성 요소인 언어 통역사의 존재를 전제로 합니다. World Wide Web에서 인터프리터 기능은 하이퍼텍스트 데이터베이스 웹 서버와 사용자 인터페이스로 구분됩니다. 서버는 문서에 액세스하고 하이퍼텍스트 링크를 처리하는 것 외에도 문서의 사전 처리 기능을 제공하는 동시에 사용자 인터페이스는 정보 표시와 관련된 언어 구성을 해석합니다.

버전

HTML 4.01(변경 사항, 언뜻 보기보다 더 중요함) - 1999년 12월 24일;

ISO/IEC 15445:2000(소위 ISO HTML, HTML 4.01 Strict 기반) - 2000년 5월 15일.

HTML 5 - 개발 중입니다. 개발 종료는 2014년으로 예정되어 있다.

공식적인 HTML 1.0 사양은 없습니다. 1995년 이전에는 비공식 HTML 표준이 많이 있었습니다. 표준 버전을 다른 버전과 다르게 만들기 위해 즉시 두 번째 번호가 부여되었습니다.

버전 3은 1995년 3월 W3C(World Wide Web Consortium)에서 제안되었으며 표 만들기, 이미지 주위에 텍스트 배치, 복잡한 수학 공식 표시, gif 형식 지원과 같은 많은 새로운 기능을 제공했습니다. 이 표준은 두 번째 버전과 호환되기는 했지만 당시 브라우저에서는 구현하기가 어려웠습니다. 버전 3.1은 공식적으로 제안된 적이 없으며 HTML 표준의 다음 버전은 버전 3.0의 많은 혁신을 생략했지만 Netscape Navigator 및 모자이크 브라우저에서 지원하는 비표준 요소를 추가한 3.2였습니다.

HTML 4.0에서는 표준이 일부 정리되었습니다. 많은 항목이 더 이상 사용되지 않거나 더 이상 사용되지 않는 항목으로 표시되었습니다. 더 이상 사용되지 않음). 특히 글꼴 속성을 변경하는 데 사용되는 글꼴 요소는 더 이상 사용되지 않는 것으로 표시되었습니다(대신 CSS 스타일시트가 권장됨).

1998년에 World Wide Web 컨소시엄은 HTML 4를 기반으로 하지만 XML 구문과 일치하는 새로운 마크업 언어에 대한 작업을 시작했습니다. 그 후 새로운 언어는 XHTML로 명명되었습니다. XHTML 1.0의 첫 번째 버전은 2000년 1월 26일 World Wide Web 컨소시엄 권장 사항으로 승인되었습니다.

XHTML 2.0의 계획된 버전은 이전 버전의 HTML 및 XHTML과의 호환성을 깨기 위한 것이었지만 2009년 7월 2일 World Wide Web 컨소시엄은 XHTML2 작업 그룹이 2009년 말에 만료될 것이라고 발표했습니다. 따라서 XHTML 2.0 표준의 모든 추가 개발이 중단되었습니다.

World Wide Web 컨소시엄은 현재 HTML 버전 5를 개발 중입니다. 언어 사양 초안이 2007년 11월 20일 인터넷에 공개되었습니다.