HTML5 디자인 원칙(권장 컬렉션)_html5 튜토리얼 기술
- WBOY원래의
- 2016-05-16 15:47:401436검색
실제로 일부 사람들은 규범적인 콘텐츠에 대해 이야기합니다. Steve Faulkner가 HTML5와 접근성에 대해 이야기합니다. Paul Irish가 HTML5에서 제공하는 다양한 API에 대해 이야기합니다. 그러므로 오늘 제가 이 자리에 서면 HTML5에 대해서만 이야기하고 그것을 하루라고 부르지 않을 것입니다.
솔직히 정식으로 시작하기 전에 HTML5가 무엇을 의미하는지 명확하게 설명하고 싶습니다. 좀 웃기게 들리네요. 한동안 HTML5에 관해 이야기하셨는데, 우리는 아직 HTML5가 무엇인지 모르시나요? 다들 아시다시피 스펙이 있는데 그 이름이 HTML5 입니다. HTML5가 의미하는 것은 이 사양입니다. 그런데 문제는 어떤 사람들이 HTML5를 언급할 때 이 사양을 언급할 뿐만 아니라 다른 의미도 갖는다는 점입니다. 예를 들어 HTML5를 사용하여 CSS3을 참조하는 것은 일반적인 이름입니다. 그건 내가 아니야. 내가 HTML5라고 부르는 것은 CSS3를 포함하지 않고 HTML5입니다.
이전에 유사한 용어 문제가 발생했습니다. Ajax는 원래 명확한 의미를 지닌 기술이었지만, 시간이 지나면서 그 의미는 "JavaScript를 사용하여 모든 재미있는 일을 한다"가 되었습니다. 아약스 맞죠? 오늘날 HTML5도 같은 문제에 직면해 있습니다. 원래는 특정 사양을 지칭했지만 지금은 "웹에서 모든 재미있는 일을 한다"는 뜻이 아닙니다. HTML5에 등장했습니다. 나는 사양 자체인 HTML5에 대해서만 이야기하고 있습니다.
방금 말했듯이 오늘은 많은 이야기를 하고 싶지 않고 HTML5에 포함된 내용을 소개할 생각도 없습니다. 오늘 제가 이야기하고 싶은 것은 그것의 또 다른 측면인 HTML5의 디자인입니다. 즉, 제가 이야기하고 싶은 것은 스펙에 무엇이 포함되는지가 아니라 왜 스펙에 포함되는지, 디자이너들이 이 스펙을 설계할 때 이러한 것들을 어떻게 바라보았는가 하는 것입니다.
디자인 원칙
디자인 원칙은 본질적으로 행동의 근간이 되는 신념, 아이디어, 개념입니다. 사양을 개발하든, 실제 개체를 구축하든, 소프트웨어를 작성하든, 프로그래밍 언어를 발명하든 상관없습니다. 그 뒤에 있는 하나 이상의 디자인 원칙을 찾을 수 있으며, 여러 사람이 공동 작업한 결과가 그 예입니다. 이는 웹 개발에만 해당되는 것이 아닙니다. 인류 역사를 통틀어 국가와 사회 등 대규모 건설 활동에도 디자인 원칙이 있었습니다.
미국을 예로 들어보겠습니다. 미국의 디자인 원칙은 모두 독립선언서에 명시되어 있습니다.
우리는 모든 사람이 평등하게 창조되었으며 각 사람은 창조주로부터 생명, 자유, 행복 추구를 포함한 양도할 수 없는 권리를 부여받았다는 자명한 진리를 믿습니다.
여기 슬로건이 있습니다: 생존, 자유, 행복 추구. 이것이 우리 모두의 모든 것에 관한 헌법에 담긴 핵심 사상이자 우리 사회를 건설하는 원칙입니다.
또 다른 예는 20세기 사회주의 건설의 지침으로 평가받는 칼 마르크스이다. 기본 아이디어는 대략 다음과 같은 디자인 원칙으로 요약할 수 있습니다.
모든 사람은 자신이 할 수 있는 일을 하고, 필요한 것을 얻습니다.
이것이 실제로 경제 시스템의 설계 원리입니다.
이전 두 사례보다 역사가 길지만 유사한 또 다른 예가 있습니다.
모두가 하나를 위한, 하나가 모두를 위한 것입니다.
이 지극히 단순한 디자인 원리는 2천년 전 나사렛 출신의 유대인 예수 그리스도께서 제안하신 것입니다. 이 원리는 이후 많은 종교의 핵심 가르침이 되었습니다. 원칙과 실천이 때로는 일치하지 않을 수도 있습니다.
다음은 소설의 예입니다. 영국 소설가 조지 오웰이 쓴 『동물농장』은 디자인 원칙을 바탕으로 구축된 가상 사회이다. 이 디자인 원칙은 다음과 같습니다.
다리가 네 개 있는 사람은 좋은 사람이고, 다리가 두 개인 사람은 나쁜 사람입니다!
'동물농장'에서 흥미로운 점은 사회가 변하고 점점 더 나빠질수록 이 디자인 원칙도 '네 다리가 있는 사람은 좋은 사람이고, 두 다리가 있는 사람은 좋은 사람'으로 바뀌는 것입니다. 가장 중요한 것은 허구의 작품에도 디자인 원칙이 존재한다는 점이다.
미국 유명 소설가 아이작 아시모프의 로봇 클래식 시리즈인 세 가지 디자인 원칙을 바탕으로 한 허구 작품 세트도 있습니다. Asimov는 로봇공학이라는 용어를 창안하고 로봇공학의 3가지 법칙을 제안한 후 이 세 가지 간단한 디자인 원칙을 바탕으로 약 50권의 고전 작품 시리즈를 만들었습니다. 작품의 줄거리가 어떻게 바뀌더라도 실제로는 이 세 가지 디자인 원칙을 다른 각도에서 설명합니다. 여기 계신 모든 분들이 로봇의 3대 법칙을 잘 알고 계시리라 생각합니다.
로봇은 인간에게 해를 끼치거나 인간이 해를 입는 것을 지켜보아서는 안 됩니다.
로봇은 제1법칙을 위반하지 않는 한 인간의 명령에 복종해야 합니다.
로봇은 첫 번째와 두 번째 법칙을 위반하지 않는 한 스스로를 방어해야 합니다.
이것은 아마도 소설에 등장하는 최초의 소프트웨어 설계 원칙일 것입니다. 비록 이 세 가지 설계 원리에 기초한 소프트웨어가 가상의 로봇의 "양전자 두뇌"에서 실행되기는 하지만 이것이 사실상 소프트웨어 설계 원리의 시작이 되어야 한다고 생각합니다. 그 이후로 우리는 수많은 우수한 소프트웨어 뒤에 숨은 디자인 원칙을 살펴보았습니다.
웹의 발명가인 Tim Berners-Lee는 자신만의 디자인 원칙을 제공하는 URL을 포함하여 W3C 웹사이트에 문서를 게시했습니다. 이러한 디자인 원칙은 이해하기 쉽지 않을 뿐만 아니라 시간이 지나면서 계속 추가되고 수정되고 삭제될 것입니다. 하지만 그래도 자신이 동의하는 디자인 원칙을 적어서 어딘가에 두는 것이 좋다고 생각합니다.
실제로 CSS 창시자 중 한 명인 Bert Bos도 W3C 웹사이트에 문서를 게시했습니다. 이 문서는 CSS든 아니든 형식을 디자인하고 구축하는 방법과 같은 기본 디자인 원칙에 대해 설명합니다. 모두가 한 번 보시길 권합니다.
W3C 사이트에서 아무렇게나 검색해 보면 Tim Berners-Lee의 개인적인 원칙을 포함하여 이러한 디자인 원칙을 많이 찾을 수 있습니다. 물론 그가 소프트웨어 공학 학교에서 빌린 슬로건인 분산화, 관용, 단순성, 모듈성도 볼 수 있습니다. 그가 새로운 형식을 고안할 때 항상 염두에 두었던 키워드는 바로 이것이다.
여기 있는 모든 사람들은 Tim Berners-Lee의 기여를 매일 사용하기 때문에 매우 잘 알고 있습니다. 그는 웹을 발명했고 Robert Cailliau와 함께 웹을 공동 발명했으며 웹을 발명했을 때 우리가 웹에서 매일 사용하는 언어도 발명했습니다. 물론 그 언어는 HTML: Hypertext Markup Language입니다.
HTML
HTML은 버전 2.0부터 처음 시작되었습니다. 버전 1.0은 한번도 없었습니다. 누군가가 HTML 1.0부터 HTML을 처음 사용하기 시작했다고 말한다면 그는 분명히 거짓말을 하고 있는 것입니다. 실제로 HTML 태그라는 문서가 있었고, 그 안에 포함된 태그 중 일부는 오늘날에도 여전히 사용되지만 해당 문서는 공식 사양은 아닙니다.
태그, 꺾쇠괄호, p 또는 h1 등을 사용하는 것은 Tim Berners-Lee가 고안한 아이디어가 아닙니다. 이러한 개념은 당시 SGML에 존재했고, 당시 CERN(Conseil Europeen pour la Recherche Nucleaire)도 SGML의 특정 버전을 사용하고 있었습니다. 즉, 당시에도 그는 처음부터 시작하지 않았으며 이는 이후의 HTML 개발에도 반영되었습니다. 새로운 회사를 설립하고 처음부터 시작하는 것이 아니라 과거를 이어가고 미래를 여는 것입니다.
즉, HTML 태그라고 불리는 이 문서는 HTML의 첫 번째 버전이라고 볼 수 있지만 정식 버전은 아닙니다. 첫 번째 공식 버전인 HTML 2.0은 W3C에서 제작되지 않았습니다. HTML 2.0은 IETF(Internet Engineering Task Force)에서 개발되었습니다. W3C가 설립되기 전에 IETF는 많은 표준을 발표했습니다. 하지만 세 번째 버전부터 W3C와 월드와이드웹 컨소시엄(World Wide Web Consortium)이 이를 이어받아 후속 버전의 공식화를 담당하게 됐다.
HTML은 1990년대에 여러 가지 급속한 발전을 경험했습니다. 우리 모두 알고 있듯이 그 시대에 웹사이트를 구축하는 것은 매우 복잡한 프로젝트였습니다. 브라우저 전쟁은 골칫거리였습니다. 시장 경쟁의 결과로 각 브라우저는 다양한 독점 기능으로 가득 차 있으며, 모두 독점 기능 면에서 서로를 능가하려고 노력합니다. 당시의 혼란은 참을 수 없을 정도였으며 HTML이 여전히 중요한지, 웹 형식으로서 HTML의 미래가 어떻게 될지는 누구도 알 수 없었습니다.
1997년부터 1999년까지 HTML 버전은 3.2에서 4.0, 4.01로 매우 빠른 발전을 이루었습니다. 문제는 4.01이 나올 때 W3C의 이해가 거꾸로 갔다는 것입니다. 그들은 "좋아, 이건 이번 버전이고 HTML은 그게 다야. HTML 4.01은 HTML의 마지막 버전이고 우리는 필요하지 않아."라고 말했다. HTML 워킹 그룹은 더 이상 존재하지 않습니다." ”
W3C는 언어 개발을 중단한 것이 아니라 더 이상 HTML에 관심이 없다는 것입니다. HTML 4.01 이후에 그들은 XHTML 1.0을 내놓았습니다. 완전히 다르게 들리지만 XHTML 1.0과 HTML 4.01은 실제로 동일합니다. 내 말은, 문자 그대로 두 사양의 내용이 동일하고, 어휘도 동일하며, 모든 요소가 동일하고, 모든 속성이 동일하다는 뜻입니다. 유일한 차이점은 XHTML 1.0에서는 XML 구문을 사용해야 한다는 것입니다. 즉, 모든 속성은 소문자를 사용해야 하고, 모든 요소도 소문자를 사용해야 하며, 모든 속성 값은 따옴표로 묶어야 하며, img 및 br에는 자체 닫는 태그를 사용해야 한다는 점을 기억하세요.
사양 자체의 내용으로는 사실상 동일하며 차이는 없습니다. 차이점은 코딩 스타일입니다. 왜냐하면 브라우저의 경우 HTML 4.01, HTML 3.2 또는 XHTML 1.0 사양을 준수하는 웹 페이지를 읽는 데 문제가 없기 때문입니다. 브라우저의 경우 이러한 웹 페이지는 동일하며 동일한 DOM을 생성합니다. . 나무. 많은 사람들이 XHTML 1.0의 더 엄격한 코딩 스타일에 동의하기 때문에 사람들이 XHTML 1.0을 선호하는 것뿐입니다.
2000년이 되자 웹 표준 프로젝트(Web Standards Project) 활동이 본격화되었고, 개발자들은 브라우저에 포함된 난잡한 독점 기능에 싫증을 냈습니다. 모두가 매우 화가 나서 "사양을 준수하는 것이 씨발 그렇게 어려운가?"라고 질책했습니다. 당시 CSS는 엄청난 발전을 이루었고, CSS와 XHTML 1.0도 기본적으로 긴밀하게 통합되어 있었습니다. "모범 사례"로 간주될 수 있습니다. 제 생각에는 HTML 4.01이 XHTML 1.0과 근본적으로 다르지 않지만 모두가 이를 받아들입니다. 전문 개발자는 모든 요소를 소문자로, 속성을 모두 소문자로, 속성 값을 모두 따옴표로 묶을 수 있습니다. 전문가가 모범적인 역할을 하기 때문에 점점 더 많은 사람들이 이 구문을 지원하기 시작합니다.
내가 예시다! 나는 지난 10년 동안 XHTML 1.0 문서 유형을 사용해왔는데, 그 이유는 유효성 검사기가 나에게 많은 도움을 주기 때문이겠죠? XHTML 1.0을 작성하고 유효성 검사기로 테스트하는 한, 속성 값을 인용하는 것을 잊었는지, 태그를 닫지 않았는지 등을 알려줄 수 있습니다. 그리고 HTML 4.01을 작성하면 동일한 문제가 발생하고 유효성 검사기가 반드시 나에게 상기시켜 주지는 않습니다.
이것이 제가 XHTML 1.0을 사용하고 있는 이유입니다. 아마 많은 분들이... XHTML 1.0을 사용하는 친구들은 손을 들어주세요. 좋아요 HTML 4.01은 어떻습니까? 사람이 훨씬 적습니다. 아직 손 안들으신 분들은 좀 더 크게 말씀해주세요. 뭐 쓰시나요? HTML5도 좋습니다! 이전 문서는 어떻습니까? 아직도 이전 문서 유형을 사용하는 사람이 있나요? 하나도 남지 않았어?
나는 유효성 검사기가 나에게 정말 도움이 되기 때문에 10년 동안 XHTML 1.0을 사용해 왔습니다. XHTML 1.1을 사용하는 사람이 있나요? 그것을 사용하는 사람을 알고 있습니까? 손을 들고 내려놓지 마십시오. 웹페이지를 XML 문서로 표시한 사람이 있나요? 거기에 있나요? 그렇다면 XHTML 1.1을 사용하고 있지 않은 것입니다.
이것은 큰 문제입니다. XHTML 1.0에 이어 XHTML 1.1이 나왔지만 소수점 이하의 숫자에 1을 붙인 점만 제외하고, 어휘적인 관점에서 보면 사양 자체에 새로운 것이 없었고 요소도 동일했으며 속성도 동일했다. . 그러나 XHTML 1.1의 유일한 변경 사항은 문서를 XML 문서로 표시해야 한다는 것입니다. XHTML 1.0을 사용할 때 문서를 HTML로 표시할 수도 있으며 이것이 바로 우리가 한 일입니다. 그렇지 않으면 문서를 XML로 표시하면 사람들이 미치게 될 수 있습니다.
왜 그러세요? 첫째, 문서를 XML로 표시한 후에는 Internet Explorer에서 해당 문서를 처리할 수 없습니다. 물론 IE9에서는 이를 처리할 수 있습니다. "너무 귀엽다"라고 말씀하시는 분들도 계시겠지만, 아직도 잊지 않고 계십니다. 드디어 배가 정박했습니다! 하지만 당시 IE는 세계 최고의 브라우저로서 수신된 XML 문서 형식의 문서를 처리할 수 없었고, 문서를 XML 문서 형식으로 보내도록 요구하는 사양이 있었기 때문에 사람들을 미치게 만들었습니다.
따라서 XHTML 1.1은 현실과 다소 동떨어져 있으며 XML의 오류 처리 모델 때문에 XML을 이해할 수 있는 브라우저에 XML 형식의 문서를 보내고 싶지 않습니다. XML의 구문은 소문자 속성이든, 소문자 요소이든, 속성 값에 항상 따옴표를 추가하든 문제가 없습니다. 모두 좋습니다. 사실 저도 이 작업을 좋아하지만 XML의 오류 처리 모델은 다음과 같습니다. 이: 구문 분석 서버에 오류가 발생하면 구문 분석을 중지합니다. 사양에 그렇게 나와있습니다. Firefox에서 문서를 열었고 문서에 올바르게 인코딩되지 않은 앰퍼샌드(&)가 있다고 가정하고 XHTML 1.1을 XML 문서 유형으로 표시하면 이것이 전체 페이지의 유일한 오류라도 어떻게 될까요? 노란색 화면이 표시되고 브라우저가 종료되었습니다. Firefox는 "더 이상 불가능합니다. 페이지에 오류가 있습니다. 이 웹 페이지를 볼 수 없습니다."라고 말합니다. XML 사양에 따르면 이 처리는 Firefox의 경우 오류가 발생하면 구문 분석을 중지합니다. 내용은 XML 사양을 엄격히 준수합니다. HTML이 아니기 때문에 HTML에는 오류 처리 모델이 전혀 없지만 XML 사양에 따르면 그렇게 하는 것이 잘못된 것은 아닙니다.
이것이 문서를 XML로 표시하지 않는 또 다른 이유입니다. 다음으로 새 버전은 XHTML 2입니다. 본 사양이 완성되지 않아 마지막에 날짜가 없는 점 참고 바랍니다.
이제 XHTML 2에 대해 이야기해 보겠습니다. 문제를 명확하게 설명하고 싶습니다. XHTML 2는 실제로 이론적인 관점에서 매우 훌륭한 사양입니다. 내 말은, 이 표준을 만든 사람들은 매우 똑똑하다는 것입니다. 직설적으로 말하면, 이 코드의 개발을 주도한 사람은 Stephen Pemberton이었습니다. 그는 아마도 현지인이었고 매우 똑똑한 사람이었을 것입니다. 사양 자체도 훌륭하고 모두가 동의한다면 매우 좋은 형식이 될 것입니다. 그러나 그것은 충분히 실용적이지 않습니다.
우선, XHTML 2는 여전히 XML 오류 처리 모델을 사용하므로 문서가 XML 문서 유형으로 전송되는지 확인해야 합니다. 이는 설명이 필요하지 않습니다. 누구도 이를 원하지 않습니다. 둘째, XHTML 2는 의도적으로 더 이상 기존 HTML 버전과 역호환되지 않습니다. 심지어 img 요소를 없애는 것에 대해서도 이야기했는데, 이는 매일 웹 개발을 하는 사람들에게는 다소 이상하게 들릴 수 있습니다. 그러나 우리는 그들이 이렇게 한 데에는 이론적으로 타당한 이유가 있다는 것을 알고 있습니다. 객체 요소를 사용하는 것이 더 나을 수도 있습니다.
따라서 XHTML 2 형식이 이론적으로 아무리 완벽하더라도 실제로 적용할 기회는 없었습니다. 그리고 이것을 실행하기 어려운 이유는 여러분과 저 같은 개발자가 결코 이를 지원하지 않을 것이고 이전 버전과 호환되지 않기 때문입니다. 마찬가지로 브라우저 제조업체는 그렇지 않습니다. 브라우저 제조업체는 이전 버전과의 호환성을 보장해야 합니다.
XHTML 1.1이 XML만큼 널리 채택되지 않은 이유는 무엇이며 XHTML 2가 결코 빛을 보지 못한 이유는 무엇입니까? 디자인 원칙에 위배되기 때문에 이 디자인 원칙은 유명한 포스텔의 법칙입니다. 다들 아시죠:
보낼 때는 신중하고, 받을 때는 공개적으로 행동하세요.
네, 받을 때 개방적이어야 하며 이것이 웹이 구축되는 기반입니다. 브라우저를 개발하는 사람들은 과거에 표준 이하의 내용을 받았기 때문에 자신에게 전송된 모든 것을 받을 수 있는 열린 자세를 취해야 합니다. 그렇죠? 웹상의 많은 문서들은 표준화되어 있지 않지만, 그것이 바로 웹 발전의 원동력입니다. 어떤 관점에서 보면 웹은 혼란스러운 발전 경로를 따르고 있지만 매우 아름답고 매력적입니다. 웹에서는 불규칙한 형식의 문서를 어디에서나 볼 수 있지만, 그렇다면 어떨까요? 모든 사람이 정확한 XML을 작성할 수 있고 모든 문서의 형식이 완벽하다면 좋을 것입니다. 그러나 그것은 현실적이지 않습니다. 현실은 버스톨의 법칙이다.
전문가로서 우리는 문서를 보낼 때 보수적으로 노력하고 모범 사례를 사용하며 문서 형식이 올바른지 확인하려고 노력합니다. 그러나 브라우저의 관점에서 보면 모든 문서를 수신할 수 있도록 열려 있어야 합니다.
어떤 사람들은 XML에 XHTML 1.1과 XHTML 2 모두에서 사용되는 오류 처리 모델이 있다고 말할 수도 있지만 그 오류 처리 모델은 너무 가혹합니다. 수신 시 개방성 규칙을 확실히 준수하지 않습니다. 오류가 발생했을 때 구문 분석을 중지하면 어떻게 개방형이라고 할 수 있습니까? 우리는 이것이 견고성의 법칙(즉, 버스탈의 법칙)에 반대된다고 말할 수 있을 뿐입니다.
HTML5
이후에는 HTML5가 나오는데, HTML5는 W3C에서 직접 공식화한 것이 아닙니다. 이야기는 이렇습니다. 20세기 말에는 HTML 워킹 그룹이 없었고 W3C 내부에서는 "HTML을 조금만 확장하면 HTML의 수명이 더 길어질 수도 있습니다."라고 생각하기 시작했습니다. 우리가 XHTML에 쏟는 시간과 에너지를 투자함으로써 HTML의 형식을 개선하고 HTML을 프로그래밍 언어에 더 가깝게 만들고 다음 단계로 끌어올릴 수 있습니다.”
그래서 2004년. W3C 회원 내의 워크숍에서 당시 Opera 대표였던 Ian Hickson은 HTML을 확장하고 개선하기 위한 제안을 제시했습니다. 그는 새로운 태스크 포스가 XHTML 2와 병행하여 작업할 수 있지만 HTML 확장을 목표로 기존 HTML을 기반으로 작업할 수 있다고 제안했습니다. W3C 투표 결과는 "아니요"였습니다. 왜냐하면 HTML은 죽었고 XHTML 2가 앞으로 나아가는 길이기 때문입니다. 그러자 오페라, 애플 등 브라우저 제조업체와 일부 회원들은 "더 이상 그들에게 의존하지 마세요. 우리 스스로 할 수 있고 W3C에서 벗어나 웹 하이퍼텍스트 응용 기술을 구축했습니다"라고 말했습니다. 그룹( WHATWG(Web Hypertext Application Technology Working Group) - 공교롭게도 그들은 스스로를 태스크 포스라기보다는 워킹 그룹이라고 부르며 HTML5의 미래 운명을 예고합니다.
WHATWG는 W3C에서 완전히 분리되어 HTML 기반으로 작업하면서 몇 가지 새로운 기능을 추가하기로 결정했습니다. 이 워킹 그룹의 구성원으로는 브라우저 벤더들이 있기 때문에 원하는 것을 추가할 수 있을 뿐만 아니라 하나씩 구현할 수도 있습니다. 그 결과 다들 좋은 아이디어가 계속해서 떠오르고, 하나씩 브라우저에 구현해 나갔습니다.
WHATWG의 작업은 매우 효율적이며 곧 결실을 맺기 시작할 것입니다. 이 기간 동안 W3C의 XHTML 2에는 실질적인 진전이 거의 없었습니다. 특히 구현 측면에서는 가만히 있다고 해도 과언이 아닌 것 같다.
그 결과 흥미로운 일이 일어났습니다. 때는 2006년이었습니다. Tim Berners-Lee는 블로그에 다음과 같이 썼습니다. "그거 알아? 우리가 틀렸어. 웹을 하룻밤 사이에 XML 시대로 가져오려는 우리가 틀렸어. 그건 비현실적이야. 그래, 아마도 HTML 작업을 재구성해야 할 것 같아." 그룹." Shanzai가 말했고 이것이 후속 스토리라인이 전개된 방식입니다. W3C는 2007년에 HTML5 작업 그룹을 구성했습니다. 이 워킹 그룹이 직면한 첫 번째 질문은 의심할 바 없이 "처음부터 시작해야 하는가, 아니면 2004년에 설립된 WHATWG라는 워킹 그룹의 기존 결과를 기반으로 작업을 시작해야 하는가?"입니다. 물론 그들은 그렇게 하기를 희망합니다. 달성된 결과부터 시작하고 이를 기반으로 작업을 시작합니다. 그래서 그들은 다시 투표를 했고, "WHATWG 작업의 결과에 따라 작업을 계속한다"는 데 동의했습니다. 글쎄, 이제 그들은 WHATWG와 나란히 싸워야합니다.
두 번째 질문은 두 워킹그룹의 관계를 어떻게 정리할 것인가이다. 이 W3C 워킹 그룹의 편집자는 누구여야 합니까? 현재 Google의 Ian Hixon이 된 WHATWG의 편집자에게도 역할을 맡겨야 할까요? 그래서 그들은 "Ian Hickson을 W3C HTML5 사양의 편집자로 활동하는 동시에 WHATWG의 편집자로 두는 것이 새로운 작업 그룹의 작업에 더 도움이 될 것"이라는 의견에 다시 투표했습니다.
그들의 투표 결과는 오늘날 우리가 보는 것입니다: 하나의 형식, 두 가지 버전. 이 사양은 WHATWG 웹사이트에서 확인할 수 있으며, W3C 웹사이트에도 사본이 있습니다.
비밀번호를 모르시면 "실제 사양은 어느 버전인가요?" 물론 두 버전의 내용은 동일합니다....기본적으로 동일합니다. 실제로 두 버전은 앞으로 서로 다른 방식으로 진행될 예정입니다. 이제 이별의 조짐이 보입니다. 내 말은 W3C가 결국 특정 사양을 공식화하여 작업 초안이 되고 특정 역사적 순간에 수정될 것이라는 것입니다.
WHATWG는 아직 반복 중입니다. 현재 HTML5에 대해 이야기한다고 해도 WHATWG가 하고 있는 작업을 완전히 다룰 수는 없습니다. 가장 정확한 이해는 간단한 HTML이나 웹 기술을 개발하고 있다는 것입니다. 그것이 그들의 작업의 핵심 목표이기 때문입니다. 그러나 본질적으로 동일한 사양을 동시에 개발하는 두 개의 작업 그룹이 존재한다는 것은 어떤 경우에도 오해의 소지가 있습니다. 오해로 인해 문제가 발생할 수 있습니다.
사실 이 두 실무 그룹은 개념이 완전히 다르기 때문에 자체 프로세스를 갖고 있습니다. WHATWG에서는 권위주의적인 작업 메커니즘이라고 할 수 있습니다. 앞서 말했듯이 Ian Hixon이 편집자입니다. 그는 모든 당사자의 의견을 경청하고, 모든 구성원이 자신의 의견을 개진하고 완전히 진술한 후 자신이 옳다고 생각하는 의견을 승인합니다.
W3C는 정반대의 민주적인 작업 메커니즘이라고 할 수 있습니다. 모든 회원은 자신의 의견을 표현할 수 있으며, 누구나 투표권을 갖습니다. 이 과정의 핵심은 투표입니다. 표면적으로 WHATWG의 작동 메커니즘은 허용되지 않습니다. 받아들이기 어려울 뿐만 아니라, 단순히 역사의 퇴보일 뿐입니다. 다들 "이렇게 프로젝트를 진행하면 안 된다!"라고 생각하실 거라 믿습니다.
W3C의 작동 메커니즘은 매우 편안해 보입니다. 적어도 모든 사람이 평등하다는 것을 보여줍니다. 그러나 실제로 WHATWG의 작동 메커니즘은 매우 잘 작동합니다. 나는 그것이 주로 Ian Hickson 때문이라고 생각합니다. 그는 정말 유능한 편집자다. 그는 개인적인 감정 없이 항상 모든 측면의 의견을 들을 수 있었습니다.
원칙적으로 W3C의 작업 메커니즘은 공정하지만 실제로는 특정 프로세스나 링크에 얽매이기 쉽고 작업이 정체되는 경우가 많습니다. 그렇다면 어떤 작업 메커니즘이 가장 좋습니까? 내 생각에 가장 좋은 작업 메커니즘은 이 두 가지를 결합하는 것입니다. 사실 두 개의 규범 설정 주체가 동일한 규범을 공동으로 공식화하고 있다는 것은 이것이 서로의 강점과 약점을 통해 학습하는 두 가지 작업 메커니즘에 매우 도움이 된다고 생각합니다.
두 워킹그룹이 함께 일할 수 있었던 가장 큰 이유는 HTML5의 디자인 철학 때문입니다. HTML5를 디자인할 때 지켜야 할 원칙을 처음부터 정했기 때문이다. 그 결과 우리는 W3C 사이트에 게시된 문서인 HTML5 언어 사양이라는 하나의 사양을 보았을 뿐만 아니라 W3C 사이트에서 HTML 디자인 원칙이라는 또 다른 문서도 보았습니다. 이 문서의 편집자 역시 오늘 회의에 참석했습니다. 그녀는 Anne Van Kesteren입니다. 이 문서에 대해 궁금한 점이 있으면 Anne에게 문의하세요.
이 문서는 매우 훌륭하고 정말 뛰어납니다. 이 문서는 W3C와 WHATWG가 함께 협력하여 공동의 발전을 추구하는 과정을 목격했다고 할 수 있습니다. 당신은 그들이 한 쌍의 행복한 적과 같다고 생각하지 않습니까? 그렇다면 그들은 어떻게 여전히 같은 마음을 가질 수 있습니까? 이 문서에는 그들이 함께 한 일과 함께 무엇을 옹호했는지 충실하게 기록되어 있습니다.
다음으로 제가 이야기하고 싶은 것은 이 문서입니다. 왜냐하면 그들은 이 문서에 대한 합의에 도달할 수 있기 때문에 HTML5가 훌륭한 사양이 될 것이라고 믿고 있으며 이를 그들의 공통 실행 프로그램으로 인식했기 때문입니다. 이러한 이유로 호환성, 실용성, 상호 운용성 등의 개념을 보게 됩니다. W3C와 WHATWG 사이에 아무리 많은 불일치가 있더라도(실제로는 상당히 많습니다) 적어도 그들은 여전히 이 문서에 합의된 내용을 기록하고 있습니다. 이것은 매우 중요합니다. 그들이 합의를 바탕으로 설계 원칙을 설명하는 이 문서를 갖게 된 것은 바로 합의가 있었기 때문입니다.
불필요한 복잡성 방지
이제 이 문서에 기록된 몇 가지 디자인 원칙을 소개하겠습니다. 첫 번째는 매우 간단합니다. 불필요한 복잡성을 피하세요. 매우 간단한 것 같습니다. 예를 들어 설명하겠습니다.
HTML 4.01 사양을 사용한다고 가정하고 문서를 열고 doctype을 입력합니다. 여기 HTML 4.01 doctype을 기억하는 사람이 있나요? 음, 아니, 아닌 것 같아요. 그렇지 않으면... 내 말은, 당신은 바보입니다. 혹시 현장에서 누군가 외웠을까봐 걱정됩니다. HTML 4.01의 문서 유형은 다음과 같습니다.
"http://www.w3.org/TR/html4/strict.dtd">
이 두 줄의 코드가 기억나지 않습니다. 그렇지 않으면 메모장, Google 및 템플릿이 필요한 이유가 무엇입니까?
XHTML 1.0을 사용하면 어떻게 되나요? 이 사양을 10년 동안 사용해 왔습니다. 이 문서 유형을 기억하는 사람이 있나요? 예, 길이는 HTML 4.01과 크게 다르지 않습니다.
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
네, 기본적으로는 같습니다. 브라우저에 알리고 싶은 내용은 다음과 같습니다. 이 문서는 XHTML 1.0 문서입니다. 따라서 HTML 5에서는 불필요한 복잡성을 제거하여 doctype을 다음과 같이 단순화했습니다.
그게 다입니다. 글쎄요, 나에게도 사진 같은 기억력이 있어요. 이 문자를 메모장에 적을 필요는 없습니다. 처음 이 문서 유형을 봤을 때 - 물론 HTML 문서의 문서 유형인 줄 알았습니다. - 저는 충격을 받았습니다. "숫자 5가 빠졌나요?" 저는 스스로 생각했습니다. "이 문서 유형은 무엇인가요? 이 문서가 역사상 유일한 HTML 버전이라는 뜻인가요? 먼저 이를 파악해야 합니다. 앞으로는 새로운 버전이 나오지 않을까요? 횡포한 태도! 제가 틀렸습니다. 왜냐하면 이 문서 유형은 이것을 의미하지 않기 때문입니다. 그러기 위해서는 먼저 문서의 시작 부분에 doctype을 쓰는 이유를 이해해야 합니다. 브라우저가 읽을 수 있도록 작성되지 않았습니다. Doctype은 검증자가 볼 수 있도록 작성되었습니다. 즉, 문서 시작 부분에 해당 XHTML 1.0 doctype 줄을 쓰는 이유는 유효성 검사기에게 해당 doctype에 따라 내 문서를 검증하라고 지시하기 위한 것입니다.
브라우저는 더 이상 중요하지 않습니다. 내가 HTML 3.2 문서를 작성 중이고 HTML 3.2의 doctype이 문서 시작 부분에 기록되어 있다고 가정해 보겠습니다. 그리고 문서 어딘가에 HTML 4.01에서만 나타나는 요소를 사용했습니다. 브라우저는 이 상황을 어떻게 처리합니까? doctype에서 선언한 HTML 버전보다 최신 사양에 나타난다고 해서 요소를 해석하고 렌더링하지 않을까요? 아니, 물론 아니지! 여전히 요소를 해석하고 렌더링하며 Burstahl의 법칙과 견고성을 잊지 마십시오. 수신 시 브라우저가 열려 있어야 합니다. 따라서 유효성 검사기는 형식 유형을 확인하는 반면 유효성 검사기는 형식 유형에만 관심이 있습니다. 이것이 doctype이 존재하는 진짜 이유입니다.
HTML5의 또 다른 디자인 원칙에 따르면 상위 및 하위 호환이 가능해야 하며 향후 HTML 버전(HTML6, HTML7 등)은 현재 HTML 버전인 HTML5와 호환되어야 합니다. 따라서 doctype에 버전 번호를 넣는 것은 유효성 검사기의 경우에도 별 의미가 없습니다.
방금 doctype은 브라우저용으로 작성되지 않았기 때문에 대부분의 경우 문제가 없다고 말씀드렸습니다. 어떤 경우에는 여러분이 사용하는 문서 유형이 브라우저에 영향을 미칠 수 있으며, 여기 있는 모든 사람들이 그것을 알고 있다고 믿습니다. 하지만 이 경우 Doctype은 실제로는 그 목적으로 사용되지 않고 특별한 목적을 달성하기 위해서만 사용됩니다. Microsoft가 CSS를 도입했을 때 표준보다 먼저 브라우저에서 CSS를 지원했으며 나중에 표준이 출시되었지만 표준에는 다른 상자 모델이 사용되었습니다. 그들은 무엇을 해야 합니까? 그들은 표준을 지원하기를 원하지만 과거에 도입한 인코딩과의 역호환도 원합니다. 웹 페이지 작성자가 표준을 사용하기를 원하는지 또는 표준을 사용했던 방식을 어떻게 알 수 있습니까?
그래서 그들은 매우 기발한 아이디어를 생각해 냈습니다. 즉, doctype을 사용하고 유효한 doctype을 사용하여 quiks 모드 대신 표준 모드를 트리거하는 것입니다. 아이디어는 매우 영리합니다. 오늘날 우리 모두가 이것을 하고 있습니다. 문서에 doctype을 추가한다는 것은 "표준 모드를 사용하고 싶습니다"라고 말하는 것과 같지만, 이것이 doctype을 만들려는 원래 의도는 아닙니다. 이것은 단지 특별한 목적으로 doctype을 사용하는 것입니다.
아래에서 상을 받은 답변 질문을 드리겠습니다. 주의 깊게 들어보세요. "빠르면 1분 안에 먼저 문서 앞에 doctype html 작성을 완료하세요. 그런 다음 Internet Explorer를 사용하여 엽니다. 표준 모드를 트리거합니까, 아니면 호환 모드를 트리거합니까? "
답은 Internet Explorer에서 표준 모드를 트리거하는 최소 문자 수입니다. 나는 이것이 또한 HTML5 사양의 본질을 보여준다고 생각합니다: 그것은 이론적 완벽함을 추구하지 않습니다. HTML5가 구현하는 것은 "아, 작성자에게 짧고 기억하기 쉬운 doctype을 주는 것이 좋지 않을까?"가 아니라, 짧고 기억하기 쉬운 것이 좋다면 doctype은 기존 브라우저에 적응할 수 없으므로 작성자에게 짧고 기억하기 쉬운 doctype을 제공하는 것이 더 좋습니다. 따라서 이 균형은 매우 잘 이루어졌으며, 짧고 기억하기 쉬운 문서 유형인 이론적으로 좋은 아이디어일 뿐만 아니라 실제로도 좋은 아이디어입니다. 여전히 표준 모드를 트리거할 수 있습니다. Doctype은 매우 전형적인 예라고 할 수 있습니다.
사양이 어떻게 불필요한 복잡성을 생략하고 불필요한 복잡성을 피할 수 있는지 보여줄 수 있는 또 다른 예가 있습니다. 이전 문서가 HTML 4.01을 사용하고 있다면 문서의 문자 인코딩을 지정하고 싶다고 가정해 보겠습니다. 이상적으로 문자 인코딩은 서버에서 헤더로 전송되지만 문서 수준에서 지정할 수도 있습니다.
마찬가지로 저는 이 코드 줄을 외우지 않을 것입니다. 나는 또한 다른 더 가치 있는 것들을 기억하기 위해 내 뇌세포를 저장하고 싶습니다. 그러나 문서가 UTF-8로 인코딩되도록 지정하려면 이 코드 줄만 추가하면 됩니다. 이는 HTML 4.01에서 필요합니다. XHTML 1.0에서 동일한 인코딩을 지정하면 여는 XML 태그에서 메타 요소도 선언해야 하기 때문에 몇 가지 키 입력이 더 필요합니다.
마찬가지로 이렇게 쓰는 것도 유효합니다. 최신 버전의 브라우저뿐만 아니라 현재 누구나 사용하고 있는 모든 브라우저에서 작동합니다. 왜? 이러한 메타 요소를 브라우저에 입력하면 브라우저는 이를 "메타데이터(메타) 도트 도트 도트, 문자 세트(문자 세트) utf-8"과 같이 해석하기 때문입니다. 실제로 보시죠. 보스탈의 법칙에 따라 이러한 것들을 보아야 합니다. 그렇죠?
강건성의 원칙에 대해 여러 번 언급했지만 일부 사람들은 항상 이를 이해하지 못합니다. 다르게 말하면, 브라우저는 "글쎄, 작성자가 문자 집합을 지정하고 싶어하는 것 같은데... 보세요, 예, utf-8이 사양에 명확하게 명시되어 있습니다."라고 생각할 것입니다. 이제 슬래시를 생략할 수 있을 뿐만 아니라 메타 charset="utf-8"만 있으면 됩니다.불필요한 복잡성을 생략하거나 불필요한 복잡성을 피하는 예는 많습니다. 하지만 핵심은 기존 브라우저에서의 사용을 방해하지 않으면서 불필요한 복잡성을 피하는 것입니다. 예를 들어, HTML5에서 link 요소를 사용하여 스타일시트에 연결하고 rel="stylesheet"라고 말한 다음 type="text/css"라고 말하면 동일한 내용이 반복됩니다. 브라우저에 관한 한, 나는 반복하고 있습니다. 브라우저는 두 속성을 동시에 볼 필요가 없습니다. 브라우저는 연결하려는 항목이 CSS 스타일 시트라고 추측할 수 있기 때문에 rel="stylesheet"만 보는 것으로 충분합니다. 따라서 type 속성을 지정할 필요가 없습니다. 이미 이것이 스타일 시트라고 말했으므로 두 번 말할 필요가 없습니다. 물론 원하는 경우 더 많은 내용을 말할 수 있습니다. type 속성을 포함하려면 그렇게 하세요.
마찬가지로 스크립트 요소를 사용하고 type="text/javascript"라고 말하면 브라우저는 무슨 일이 일어나고 있는지 거의 알 수 있습니다. 웹 개발을 위해 다른 스크립트 언어를 사용하시나요? 정말로 다른 스크립팅 언어를 사용하고 싶다면 누구도 막을 수 없습니다. 하지만 어떤 브라우저도 당신을 지원하지 않을 것이라고 조언하고 싶습니다.
원하는 경우 유형 속성을 추가할 수 있습니다. 그러나 아무것도 쓰지 않을 수도 있으며 브라우저는 자연스럽게 JavaScript를 사용하고 있다고 가정합니다. 불필요한 복잡성을 피하십시오.
기존 콘텐츠를 지원합니다. 많은 사람들이 HTML5가 미래 개발 방향을 제시하고 웹을 새로운 개발 단계로 끌어올려야 한다고 생각하기 때문에 이는 매우 중요합니다. 이거 HTML5 맞죠? 분명히 우리 모두는 웹의 미래를 더 좋게 만드는 것에 대해 생각하지만 과거에 대해서도 생각해야 합니다. W3C 작업 그룹의 많은 사람들이 브라우저 제조업체를 대표하며 기존 콘텐츠 지원을 고려해야 한다는 점을 잊지 마십시오. 브라우저를 구축할 때마다 다음 원칙을 기억해야 합니다. 즉, 기존 콘텐츠를 지원해야 합니다.
기존 콘텐츠를 지원하는 HTML5의 예를 살펴보겠습니다.이 예는 동일한 콘텐츠를 작성하는 네 가지 방법을 보여줍니다. 상단은 img 요소이고 하단은 속성이 있는 단락 요소입니다. 네 가지 쓰기 방법의 유일한 차이점은 문법입니다. 브라우저에 코드를 제공하면 브라우저는 아무런 문제 없이 동일한 DOM 트리를 생성합니다. 브라우저의 관점에서 보면 이 네 가지 쓰기 방법에는 차이가 없습니다. 따라서 HTML5에서는 다음 구문 중 하나를 자유롭게 사용할 수 있습니다.
Hello world
안녕하세요
안녕하세요
< ;img src=foo alt=bar>
안녕하세요
이 코드를 본 후 "아니요, 아니요, 아니요. 그중 하나만 맞고 나머지 세 개는 "아니요"라고 말할 수 없습니다."라고 말할 수도 있습니다. 속성 값 주위에 따옴표를 붙입니다! 자, 우리는 항상 속성 값을 따옴표로 묶습니다! 요소 이름의 대문자가 올바르게 사용되었나요? 이 관행은 10년이 지나서 폐기된 것이 아닌가?
HTML5에서 이러한 작성 방법을 동시에 허용하는 것을 보니 마음이 아프지 않을 수 없었습니다. 나는 10년 동안 XHTML 1.0을 작성해 왔으며 엄격한 구문에 매우 익숙해졌습니다. 하지만 브라우저의 관점에서 볼 때 이러한 작성 방법은 실제로 동일하다는 점을 이해해야 합니다. 정말 문제 없습니다.
혹시 불편한 분 계시나요? 이것을 보고 "아, 이거 휘갈겨 쓴 거 아니야? 틀렸어"라고 생각한 사람이 있나요? 나만 이렇게 생각하는 걸까? 다른 사람이 있나요?
하지만 HTML5는 기존 콘텐츠를 지원해야 하며, 기존 콘텐츠는 이런 모습입니다. 그렇지 않나요? Burstahl의 법칙에 따르면 브라우저에는 선택의 여지가 없습니다.
어떤 사람들은 "이건 작동하지 않을 것 같아요. 작성자가 원하는 작업을 표시할 수 있는 스위치를 언어 자체에서 제공해야 한다고 생각합니다. 예를 들어 XHTML과 같은 특정 구문을 사용하려는 경우"라고 말할 수도 있습니다. , 다른 구문을 사용하는 대신. 나는이 사람들이 어디에서 왔는지 이해합니다. 그러나 나는 언어로 스위치를 설정하는 것에 동의하지 않습니다. 우리는 코딩 스타일이나 글쓰기 스타일만을 논의하고 있기 때문에 어떤 문법이 올바른지는 아무런 관련이 없습니다. 우리 같은 전문가들은 린트 도구(소프트웨어 품질 보증 도구 또는 좀 더 엄격한 컴파일러)를 사용할 수 있다고 생각합니다. 일반 컴파일러처럼 일반적인 구문 오류를 검사할 수 있을 뿐만 아니라, 비록 완전히 문법적이며 잠재적이고 찾기 어려운 오류가 있을 가능성이 높지만 다른 기술에도 Lint 도구를 사용하지 않습니까?
예를 들어 JavaScript용 Lint 도구를 사용하세요. JavaScript는 지저분하고 느슨한 예이기도 하지만, 지저분하고 느슨하며 다양한 코딩 방법이 있기 때문에 매우 강력합니다. 자바스크립트에서는 각 문장 끝에 세미콜론을 추가할 수 있지만, 자바스크립트는 자동으로 세미콜론을 삽입하기 때문에 꼭 그럴 필요는 없습니다... 좀 불쾌하지 않나요?
이 때문에 Douglas Crockford의 웹사이트 jslint.org에는 JSlint와 같은 도구가 있습니다. "JSlint는 기분을 상하게 할 수 있습니다."라는 페이지가 있습니다. 그러나 JSlint는 JavaScript 코드를 완벽하게 만들 수 있는 정말 훌륭한 도구입니다. JSlint를 통해 JavaScript를 실행하면 "알겠습니다. JavaScript 코드는 유효하지만 잘못 작성되었습니다. 코딩 스타일이 마음에 들지 않습니다. 승인하지 않습니다. 특히 좋지 않습니다."라고 말할 것입니다. JSlint는 통합 코딩 스타일을 사용하려는 팀에게 매우 편리한 도구입니다.
저는 개인적으로 팀을 위해서뿐만 아니라 여러분 스스로 코드를 작성하는 경우에도 문법 스타일을 준수해야 한다고 믿습니다. 브라우저 구문 분석 관점에서 어떤 구문이 다른 구문보다 나은지에 대해서는 의문의 여지가 없지만 전문가로서 "이것이 내 코딩 스타일입니다."라고 자신있게 말할 수 있어야 한다고 생각합니다. 그러나 이 스위치가 내장되어야 한다고는 생각하지 않습니다. 언어. 린트 도구를 사용하여 코딩 스타일을 통합할 수 있습니다. 이제 Lint 도구에 대해 이야기해 보겠습니다. htmllint.com에 로그인하여 HTML5 문서를 실행하면 속성 값이 따옴표로 묶여 있는지, 요소가 소문자인지 확인하는 데 도움이 됩니다. 또한 확인란을 선택하여 다른 확인 항목을 설정할 수도 있습니다.
그러나 이것이 부주의한 표시를 거부해야 한다는 의미는 아닙니다. 이를 정리할지 여부는 전적으로 귀하에게 달려 있습니다. 앞서 말했듯이 브라우저는 기존 콘텐츠를 지원해야 하기 때문에 HTML5도 예외는 아닙니다. 결국 보스탈의 법칙이 성립하게 됩니다. Burstahl의 법칙 없이는 결코 할 수 없습니다.
실생활 문제 해결
HTML5의 또 다른 디자인 원칙은 실생활의 문제를 해결하는 것입니다. 다양한 문제를 해결하기 위한 형식과 명세는 이미 어디에나 있는 것이 분명하기 때문에, 내 생각에는 이 원칙은 실제로는 실질적인 문제보다는 이론적인 문제를 해결하기 위한 것이라고 생각한다. 이 디자인 원칙은 사람들 사이의 공통적인 문제를 이론적으로 인정하고 민감한 문제를 제거하는 것입니다. 하지만 제 생각에는 그런 형식과 사양은 모두 이론적인 문제이지 실제적인 문제는 아닙니다. 이 디자인 원칙은 오늘날 사람들이 직면한 실제 문제와 골치 아픈 문제를 해결하고 싶은 것입니다.
예를 들어보겠습니다. 나는 많은 사람들이 이 예를 접했다고 믿는다. HTML 4 또는 XHTML 1을 사용하고 있고 페이지에 이미 콘텐츠가 있다고 가정해 보겠습니다. 전체 콘텐츠에 대한 링크를 추가하려면 어떻게 해야 합니까? 문제는 이 콘텐츠에 제목, 단락, 이미지가 포함되어 있다는 것입니다. 모두 클릭 가능하게 하려면 3개의 링크 요소를 사용해야 합니다. 그래서 먼저 제목(예: h2 요소)에 커서를 놓고 링크 태그를 작성한 다음 링크에 포함될 텍스트를 모두 선택해야 합니다. 그런 다음 문단에 커서를 놓고 링크 태그를 쓴 뒤 링크에 문단에 텍스트를 넣어주면 되는데...
HTML5에서는 모든 것을 링크 요소로 묶습니다.
예, 링크에는 블록 수준 요소가 포함되어 있지만 이제는 모든 요소를 하나의 요소에 포함할 수 있습니다. 이것은 훌륭합니다. 여러 블록 수준 요소에 동일한 링크를 추가해야 하는 비슷한 상황에 처해 있었기 때문에 이렇게 할 수 있으면 좋을 것 같습니다. 이러한 이유로 저는 새로운 표준 HTML5를 매우 환영합니다.
실제 문제를 해결합니다. 나는 이곳에 있는 많은 친구들이 이런 문제에 직면했다고 감히 말씀드립니다.
그렇다면 이것이 어떤 문제를 해결합니까? 브라우저는 이 접근 방식을 지원하기 위해 코드를 다시 작성할 필요가 없습니다. 이런 방식은 실제로 브라우저에 오랫동안 존재해왔습니다. 왜냐하면 누군가가 오랫동안 이런 식으로 작성해 왔기 때문입니다. 물론 이전에 이런 식으로 쓰는 것은 표준에 맞지 않았습니다. 그러므로 HTML5가 현실 문제를 해결한다고 말할 때 본질은 여전히 "수년 동안 이런 식으로 작성해 오셨죠? 이제 표준을 변경하여 이렇게 작성할 수 있게 되었습니다.
"입니다.
진리를 추구하고 실용주의
모든 디자인 원칙 중에서 진실을 추구하고 실용적이라는 것이 아마도 가장 큰 원칙일 것입니다. 회사에서 회의 중에 “선구적이고 진취적이며 진실을 추구하고 실용적이다”라는 슬로건을 들어본 적이 있는지 모르겠습니다. 사실 이는 기업 슬로건일 뿐만 아니라 매우 중요한 디자인 원칙이기도 합니다. , 진실 추구와 실용주의는 HTML에 매우 중요하기 때문입니다. 그 의미는 이러한 골치 아픈 문제를 해결하기 전에 먼저 사람들이 이러한 문제를 해결하기 위해 무엇을 생각해 냈는지 살펴보는 것입니다. 이러한 "민간" 솔루션을 이해하는 데 중점을 두는 것이 우선입니다.
HTML5의 새로운 의미 요소는 진리 추구와 실용주의 원칙을 반영합니다. 새로운 요소가 많지 않고, 무한한 확장성을 가지고 있다고는 할 수 없지만, 그래도 좋은 것 같습니다. 그 수는 적지만 그 의미는 매우 특별합니다. 이러한 새로운 요소에는 머리글, 바닥글, 섹션, 기사 등이 포함됩니다. 모든 사람이 낯설지 않을 것이라고 믿습니다. 즉, HTML5를 사용하지 않더라도 이러한 이름은 class="header"/"head"/"heading" 또는 class와 같이 이전에 사용했던 클래스 이름입니다. ="바닥글" /"발". 물론 ID, id="header", id="footer"일 수도 있습니다. 이것이 우리에게 익숙해진 것이 아닌가?
오늘 다음 문서를 작성했다고 가정해 보겠습니다.