> 웹 프론트엔드 > H5 튜토리얼 > HTML5 디자인 원칙(권장 컬렉션)_html5 튜토리얼 기술

HTML5 디자인 원칙(권장 컬렉션)_html5 튜토리얼 기술

WBOY
풀어 주다: 2016-05-16 15:47:40
원래의
1437명이 탐색했습니다.

실제로 일부 사람들은 규범적인 콘텐츠에 대해 이야기합니다. 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 태그에서 메타 요소도 선언해야 하기 때문에 몇 가지 키 입력이 더 필요합니다.


코드 복사
코드는 다음과 같습니다.



HTML5에서 입력해야 하는 문자는 다음과 같습니다.


코드 복사코드는 다음과 같습니다.


짧고 기억하기 쉽습니다. 나는 그것을 기억할 수 있다.

마찬가지로 이렇게 쓰는 것도 유효합니다. 최신 버전의 브라우저뿐만 아니라 현재 누구나 사용하고 있는 모든 브라우저에서 작동합니다. 왜? 이러한 메타 요소를 브라우저에 입력하면 브라우저는 이를 "메타데이터(메타) 도트 도트 도트, 문자 세트(문자 세트) 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에서는 다음 구문 중 하나를 자유롭게 사용할 수 있습니다.


코드 복사코드는 다음과 같습니다.
bar

Hello world


bar

안녕하세요
bar

안녕하세요
< ;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"일 ​​수도 있습니다. 이것이 우리에게 익숙해진 것이 아닌가?
오늘 다음 문서를 작성했다고 가정해 보겠습니다.


코드 복사
코드는 다음과 같습니다.



...



코드 복사
코드는 다음과 같습니다.
> <헤더>...
...
🎜> < ;제외>...
<바닥글>...

물론 그렇게 할 수 있습니다. 문서 수준에서 이러한 요소를 사용하는 데 문제가 없습니다. 그러나 이러한 요소를 추가하는 목적이 원래 div를 교체하는 것이라면 실제로는 필요하지 않습니다.
이 문서에서는 ID를 이러한 새로운 요소로 대체하고 있지만, 제 개인적인 의견으로는 클래스를 대체하는 데 더 가치가 있다고 생각합니다. 왜 그런 말을 합니까? 왜냐하면 이러한 요소는 한 페이지에서 한 번만 사용될 수 있는 것이 아니라 여러 번 사용될 수 있기 때문입니다. 예, 문서에 머리글과 바닥글을 추가할 수 있지만 문서의 각 섹션에는 머리글과 바닥글도 있을 수 있습니다. 그리고 각 파티션은 다른 파티션 내에 중첩될 수 있습니다. 중첩된 파티션은 여전히 ​​자체 머리와 발을 가질 수 있습니다.
이 네 가지 새로운 요소인 섹션, 기사, 옆 및 탐색이 강력한 이유는 HTML에서 전례 없는 콘텐츠 모델인 새로운 콘텐츠 모델, 즉 콘텐츠 분할을 나타내기 때문입니다. 지금까지 우리는 페이지의 콘텐츠를 구성하기 위해 div를 사용해 왔지만 다른 유사한 요소와 마찬가지로 div 자체에는 의미가 없습니다. 하지만 섹션, 기사, 옆, 탐색은 실제로 이 섹션이 문서 내의 다른 문서와 같다는 것을 명확하게 알려줍니다. 이러한 요소 내에 있는 모든 콘텐츠에는 자체 요약, 제목, 바닥글이 있을 수 있습니다.
가장 일반적인 섹션은 콘텐츠와 가장 관련성이 높은 섹션이라고 할 수 있습니다. 그리고 기사는 특별한 종류의 섹션입니다. 옆에는 특별 섹션이 있습니다. 마지막으로 Nav도 특별한 섹션입니다.
글쎄, 지금도 다음과 같이 div와 클래스를 사용하여 페이지의 다양한 부분을 설명할 수 있습니다.


코드 복사
코드는 다음과 같습니다.

...


...


...



콘텐츠 작성자에 관한 메타데이터가 포함되어 있으며 아래에 몇 가지 링크가 있지만 그게 전부입니다. HTML5에서는 이 컨텐츠가 문서라고 완전하게 말할 수 있고, 섹션, 기사, 옆을 사용하여 "이 컨텐츠는 독립적으로 존재할 수 있다"고 말할 수 있습니다. 머리글과 바닥글.


코드 복사
코드는 다음과 같습니다.

...


...

< ;div class="content">
...



아래에는 바닥글도 꼭 나오지 않아도 되니 주의해주세요. 머리글, 바닥글, 옆 및 탐색 요소에서 가장 중요한 점은 위치와 관련이 없다는 것입니다. 우리는 바닥글이라는 단어를 생각할 때 항상 '아, 아래에 배치해야지'라는 생각을 하게 됩니다. 하지만 사양을 살펴보면 이러한 요소는 콘텐츠에만 관련되어 있음을 알 수 있습니다. 따라서 바닥글에 배치된 내용은 서명, 기사 작성자 등이 될 수도 있습니다. 단지 사용하는 요소일 뿐입니다. 이 요소는 "문서나 섹션 아래에 배치해야 합니다."라고 말하지 않습니다.
여기서 가장 중요한 것은 원래 div 클래스를 여러 가지 새로운 요소로 교체한 것이 아니라 원래 div를 교체했다는 것입니다. 몇 가지 새로운 요소가 포함된 클래스입니다. H2가 H1으로 대체되었습니다. 충격적이어서 일부 사람들이 떨고 있는 것을 보았습니다. 나는 사양에 따르면 문서에 H1이 하나만 있을 수 있다고 수년간 믿었던 많은 전문 웹 개발자를 만났습니다. 또한 이렇게 말하는 자칭 전능한 SEO 팁도 있습니다. 많은 SEO 기술은 실제로 매우 독단적입니다. 교리란 데이터를 신뢰하지 않는다는 뜻입니다. 과거에는 이 도그마가 "아니요, 페이지에 H1이 2개 이상 포함되면 죽습니다."라고 표현되었습니다. HTML5에서는 섹션, 기사, 옆, nav, 또는 다른 요소에서는 이 블록의 제목이 전체 페이지에서 어떤 수준으로 순위가 지정되어야 하는지 걱정하지 않고 H1을 사용할 수 있습니다. 문제가 없습니다.
이런 변화는 정말 놀랍습니다. 생각해 보십시오. 이러한 변화는 콘텐츠 관리에 있어서 혁명적입니다. 이제 각 콘텐츠 섹션을 페이지에서 꺼낼 수 있는 별도의 섹션으로 생각할 수 있기 때문입니다. 이 시점에서 문맥에 따라 이 독립 섹션의 H1은 문서 내 어디에 나타나는지에 따라 전체 페이지에서 H2 또는 H3의 역할을 할 수 있습니다. 이러한 갑작스러운 변화에 직면하여 일부 사람들은 일시적으로 혼란을 겪을 수 있습니다. 그것은 중요하지 않습니다. 그러나 저는 이것이 HTML5의 새로운 의미론적 마크업의 진정한 가치가 있는 곳이라고 생각한다고 말씀드릴 수 있습니다. 즉, 이제 제목 수준을 재정의할 수 있는 독립적인 요소가 있습니다.
내 문서에는 다른 파티션이나 기사에 중첩될 수 있는 파티션이 포함될 수 있으며 기사는 파티션에 중첩되고 파티션은 기사에 중첩되고 파티션에 중첩된 다음 다음 항목에 중첩됩니다. 기사 기사. 그리고 각 섹션과 기사에는 자체 H1~H6이 있을 수 있습니다. 이런 의미에서 H 요소는 실제로 "우리 후손의 후손은 한없이 가난하다"고 말할 수 있습니다. 그러나 콘텐츠나 콘텐츠 관리 시스템을 작성하면 모두 독립적이고 완전히 독립적인 콘텐츠 블록입니다. 진정한 가치는 바로 여기에 있습니다.
사실 이 아이디어는 HTML5 워킹 그룹에서 생각해낸 것도 아니고 최근 W3C에서 제안한 것도 아닙니다. 다음 문장은 Tim Berners-Lee가 Dan Connolly에게 보낸 1991년 이메일에서 발췌한 것입니다. 그는 이메일에서 HTML에 대한 자신의 이해를 설명했다. 또는 일반 H 요소를 포함할 수 있으며 그 안에 다른 레벨을 중첩할 수 있습니다. "하지만 일반 H 요소를 보는 대신 H1 및 H2를 계속 사용했습니다. 이는 기존 요소를 계속 지원했기 때문입니다. 20년이 지난 오늘, 마침내 이 이상이 실현되었습니다.

원활한 저하

다음 원칙은 누구에게나 친숙해야 한다는 것, 바로 원활한 저하입니다. 결국 우리는 수년간 이 규칙을 따라왔습니다. 점진적 향상의 반대 측면은 원활한 저하입니다.
이 원칙을 따르는 HTML5의 예는 유형 속성을 사용하여 양식을 향상시키는 것입니다. 숫자, 검색, 범위 등을 포함하여 유형 속성에 지정할 수 있는 새로운 값은 다음과 같습니다.

코드 복사
코드는 다음과 같습니다.

input type="number"
입력 유형="검색"
입력 유형="범위"
입력 유형="이메일"
입력 유형="날짜"
입력 유형="url"

가장 중요한 질문은 브라우저가 이러한 새로운 유형 값을 볼 때 무엇을 할 것인지입니다. 미래의 브라우저가 아닌 기존 브라우저는 이러한 새로운 유형 값을 이해할 수 없습니다. 그러나 이해하지 못하는 유형 값을 보면 유형 값을 텍스트로 해석합니다.
input type="foo" 또는 input type="bar"를 쓰든 기존 브라우저는 "글쎄, 작성자가 텍스트를 의미했을 수도 있습니다."라고 말할 것입니다. 따라서 이제부터 이 새로운 값을 사용할 수 있습니다. 이를 이해하지 못하는 브라우저는 새로운 값을 type="text"로 취급할 것이므로 안심하세요. 이는 브라우저가 우아한 성능 저하 원칙을 실천하는 좋은 예입니다.
예를 들어 이제 type="number"를 입력합니다. 숫자 값을 입력하기 위한 텍스트 상자가 필요하다고 가정해 보겠습니다. 그런 다음 이 입력의 유형 속성을 숫자로 설정할 수 있으며, 이를 이해하는 브라우저는 작은 화살표 아이콘이 있는 스피너 컨트롤과 같은 귀엽고 작은 컨트롤을 표시합니다. 오른쪽? 그리고 그것을 이해하지 못하는 브라우저에서는 여러분 모두에게 너무 익숙한 텍스트 상자인 텍스트 상자를 보게 될 것입니다. 이 경우 type="number"를 입력하면 작은 화살표 아이콘이 있는 스피너가 표시된다고 말할 수 없는 이유는 무엇입니까?
물론 최소 및 최대 속성을 설정할 수도 있으며 원활하게 저하됩니다. 이것이 문제의 핵심입니다.
입력 유형="검색"을 다시 살펴보세요. 이러한 종류의 입력 상자는 Safari에서 시스템 수준 검색 컨트롤로 표시되고 오른쪽에 클릭하여 검색 키워드를 지울 수 있는 X가 있기 때문에 이러한 종류의 입력 상자를 고려할 수도 있습니다. 다른 브라우저에서는 input type="text"라고 쓴 것처럼 텍스트 상자만 표시됩니다. 이는 이미 매우 친숙한 텍스트 상자입니다. 그렇다면 입력 유형="검색"을 사용하지 않는 이유는 무엇입니까? 부작용은 전혀 없을 거에요, 그렇죠?
HTML5는 자리 표시자와 같은 입력 요소에 새로운 속성도 추가합니다. 이 속성의 용도를 모르는 사람이 있나요? 맞습니다. 텍스트 상자에 일부 텍스트를 미리 배치하는 데 사용됩니다. 아니요, 라벨이 아닙니다. 자리표시자와 라벨은 전혀 같은 것이 아닙니다. 자리 표시자는 텍스트 상자에 허용되는 샘플 콘텐츠이며 일반적으로 회색입니다. 텍스트 상자를 클릭하면 즉시 사라집니다. 입력한 내용을 모두 삭제한 후 텍스트 상자 밖을 클릭하면 다시 나타납니다.
물론 JavaScript로 일부 코드를 작성하여 이 기능을 구현할 수도 있지만 HTML5는 하나의 자리 표시자 속성만으로 문제를 해결하는 데 도움이 됩니다.
물론 이 속성을 지원하지 않는 브라우저의 경우에도 JavaScript를 사용하여 자리표시자 기능을 구현할 수 있습니다. 브라우저가 JavaScript를 통해 이 속성을 지원하는지 테스트하는 것도 매우 간단합니다. 지지한다면 한발 물러서서 비켜서 성공을 즐기세요. 지원되지 않는 경우 JavaScript에서 이 기능을 시뮬레이션하도록 할 수 있습니다.
이제 또 다른 주제인 HTML5와 Flash를 언급해야 합니다. 아마도 당신은 그것에 대해 들어본 적이 있거나, 어딘가에서 그것에 대한 논의를 본 적이 있을 것입니다. 솔직히 말해서 전혀 이해가 되지 않습니다. 나는 사람들이 어떻게 자신의 추측만으로 논쟁을 시작할 수 있는지 이해하지 못합니다.
우선, HTML5와 Flash를 비교한다는 것은 HTML5나 Flash를 의미하는 것이 아닙니다. 오히려 이는 HTML5의 하위 집합과 Flash의 하위 집합을 나타냅니다. 특히 그들은 비디오를 언급하고 있습니다. 따라서 누군가 "HTML5 vs. Flash"라는 말을 들을 때마다 이는 아마도 단지 HTML5 비디오와 Flash 비디오일 뿐일 것입니다.
둘째, HTML5와 Flash의 경우 선택을 해야 하는 것과 같습니다. 당신은 어느 편에 속합니까? 실제로는 그렇지 않습니다. HTML5 표준의 디자인을 통해 두 가지 장점을 모두 누릴 수 있습니다.
자, 이 새로운 비디오 요소를 살펴보겠습니다. 매우 사려 깊은 요소이며 디자인이 간단하고 실용적입니다. 시작 비디오 요소와 엔딩 비디오 요소, 백업 콘텐츠를 중간에 배치할 수 있습니다. 이는 접근성을 보장하는 콘텐츠가 아니라 대체 콘텐츠라는 점에 유의하세요. 다음은 video 요소를 지원하지 않는 브라우저용으로 작성된 코드입니다.


코드 복사
코드는 다음과 같습니다.


그럼 백업 콘텐츠에는 무엇을 넣나요? 좋습니다. Flash 비디오를 재생할 수 있습니다. 이러한 방식으로 HTML5 비디오와 Flash 비디오가 함께 작동할 수 있습니다. 선택을 할 필요가 없습니다.


코드 복사
코드는 다음과 같습니다.

물론 코드가 실제로 그렇게 간단하지는 않습니다. 여기서는 H264를 사용했기 때문에 일부 브라우저에서는 이 비디오 형식을 지원합니다. 하지만 일부 브라우저에서는 이를 지원하지 않습니다.
죄송합니다. 영상 형식에 대해 얘기하지 마세요. 들으면 속상해요. 기술 때문이 아닙니다. 기술은 중요하지 않습니다. 핵심은 많은 특허, 변호사, 지적 재산권 등이 관련되어 있다는 것입니다. 이것들은 웹의 천적이며 웹 사이트를 구축하는 데 나에게 아무런 도움이 되지 않습니다.
하지만 실제로 해야 할 일은 백업 콘텐츠를 거기에 넣는 것뿐입니다. 백업 콘텐츠에는 다양한 비디오 형식이 포함될 수 있습니다. 원하는 경우 src 속성 대신 source 요소를 사용하여 다른 비디오 형식을 지정할 수 있습니다.


코드 복사
코드는 다음과 같습니다.

위 코드에는 4가지 레벨이 포함되어 있습니다.
1. 브라우저가 비디오 요소와 H264를 지원한다면 말할 것도 없고 그냥 첫 번째 비디오를 사용하세요.
2. 브라우저가 비디오 요소와 Ogg를 지원하는 경우 두 번째 비디오를 사용하십시오.
3. 브라우저가 비디오 요소를 지원하지 않으면 Flash 비디오를 사용해 보세요.
4. 브라우저가 동영상 요소나 플래시를 지원하지 않는 경우 다운로드 링크도 제공합니다.

네, 처음부터 이렇게 배려하는 경우는 거의 없습니다. 이 수준이면 충분히 완성됩니다.

요컨대 HTML5든 플래시든 다양한 기술을 고려하는 것이 빼놓을 수 없는 부분이 아닐까 싶습니다. 영상 요소만을 사용하여 영상을 제공한다면 필연적으로 발에 총을 쏘게 될 것이라고 개인적으로 생각합니다. 그리고 플래시 영상만 제공한다면 상황은 별로 나아지지 않고 성격은 똑같습니다. 따라서 여전히 두 가지를 모두 고려해야 합니다.

왜 두 기술을 모두 고려해야 합니까? Flash를 지원하지 않는 일부 휴대용 장치에 비디오를 제공해야 한다고 가정해 보겠습니다. 예를 들어, 휴대용 장치의 사용자가 비디오를 볼 수 있기를 원할 것입니다.

다른 형식이 사용되는 이유와 Flash 비디오 및 오디오가 왜 그렇게 성공적인지에 대해서는 또 다른 디자인 원칙인 Metcalfe의 법칙에 기인한다고 생각합니다.

네트워크의 가치는 네트워크 사용자 수의 제곱에 비례합니다.

Metcalfe의 법칙은 전화망에 대해 제안되었지만 여러 분야에도 적용 가능합니다. 네트워크를 사용하는 사용자가 많을수록 네트워크의 가치는 더욱 커집니다. 모두가 Facebook을 사용하는 것은 아닙니다. 모두가 Facebook을 사용하기 때문이 아닙니다. Facebook의 진정한 가치는 여기에 없지만 모든 사람이 Facebook에 있어야만 가치가 높아질 것입니다.
Metcalfe의 법칙은 팩스에도 적용됩니다. 물론 한 사람만 팩스기를 구입한다면 아무 소용이 없습니다. 그러나 다른 사람들이 차례로 팩스기를 구입한다면 그의 투자는 보상을 받을 것입니다.
물론 경쟁하는 비디오 형식과 다른 인코딩 방법으로 인해 Metcalfe의 법칙의 효과를 느낄 수 없습니다. 나 또한 비디오를 다른 방식으로 인코딩하는 것을 싫어하지만 이렇게 인코딩된 비디오는 브라우저에 하나만 전송됩니다. 작동하지 않습니다. 이것이 바로 Flash가 비디오/오디오 분야에서 성공을 거둔 이유입니다. Flash 비디오를 브라우저로 보내면 플러그인이 설치된 브라우저에서 정상적으로 재생됩니다. 기본적으로 Flash는 Metcalfe의 법칙을 활용합니다.

최종 사용자 우선순위

오늘 이야기하고 싶은 마지막 디자인 원칙은 제가 개인적으로 가장 존경하는 원칙이기도 하지만, 보여드릴 코드 예제가 없습니다. 이 원칙은 보다 철학적인 특징을 갖고 있습니다. 즉, 최종 사용자가 먼저입니다.
이 디자인 원칙은 본질적으로 충돌 해결 메커니즘입니다. 즉, 해결해야 할 문제에 직면했을 때, W3C가 하나의 해결책을 제시하고 WHATWG가 또 다른 해결책을 제시한다면, 한 사람은 이렇게 생각하고, 다른 사람은 이렇게 생각하는데... 이때 누군가 일어나서 이렇게 말했습니다. "이 문제를 해결하는 방법은 다음과 같습니다.

충돌이 발생하는 경우 최종 사용자가 우선 순위를 차지하고 그 다음 작성자, 구현자, 표준 설정자, 마지막으로 이론적 완성도가 높습니다.
이론적 완벽함은 일반적으로 가능한 가장 완벽한 형식을 만드는 것을 의미합니다. 표준 설정자(작업 그룹, W3C 등) 구현자는 브라우저 제조업체를 참조합니다. 작성자는 우리 개발자죠? 이 사슬에서 우리가 얼마나 높은지 보세요! 우리는 최종 사용자 다음으로 중요한 위치에 있습니다. 그래야 합니다. 사용자가 먼저입니다. 그리고 우리의 목소리는 표준 설정 과정에서도 매우 중요합니다.
Hixie(즉, Acid2, Acid3의 작성자이자 유지관리자이자 HTML5 및 CSS 2.1 사양의 공식화자인 Ian Hickson)는 누군가가 특정 기능을 제안하고 HTML5 작업 그룹이 이에 대해 토론할 수 없다고 자주 말합니다. 브라우저 제조업체가 "우리는 이 기능을 지원하지 않을 것이며 우리 브라우저에서 이 기능을 구현하지 않을 것입니다"라고 말하면 이 기능은 사양에 기록되지 않습니다. 사양에 기능을 기재하더라도 이를 구현하는 제조사가 없다면 사양은 종이 한 장에 불과하기 때문이죠. 구현자는 사양 구현을 거부할 수 있습니다.
최종 사용자 우선 원칙에 따라 체인 내에서 우리의 위치는 구현자보다 높습니다. 사양의 일부 부분에서 문제가 발견되면 '우리는 그러한 조항에 동의할 수 없으며 우리는'이라고 생각합니다. 이 기능의 구현을 지원하지 않습니다." ", 그러면 해당 특성을 부정하는 것과 동일하며, 우리 목소리의 가중치가 더 높기 때문에 사양에서 삭제해야 합니다. 내 생각엔 이게 좋은 것 같아! 본질적으로 우리는 더 큰 발언권을 가지고 있습니다. 그렇죠? 저는 개발자들이 더 많은 발언권을 가져야 한다고 생각합니다.
이 원칙은 귀하의 권리를 인정하기 때문에 가장 중요한 디자인 원칙이 되어야 한다고 생각합니다. 형식을 디자인하든 소프트웨어를 디자인하든 이 원칙은 귀하의 발언권을 보장합니다. 그리고 이 원리는 사물이 작동하는 방식의 본질도 표현합니다. 충분히 명백하지 않습니까? 사용자는 작성자보다 더 큰 권한을 갖고, 작성자는 구현자보다 더 큰 권한을 가지며, 구현자는 표준 설정자보다 더 큰 권한을 갖습니다. 그러나 XHTML2와 같은 다른 사양을 살펴보면 정반대의 접근 방식을 찾을 수 있습니다. 이론적인 완벽함을 최우선으로 생각하고, 엄격한 오류 처리로 인해 발생하는 온갖 문제를 감내해야 하는 사용자를 최하위로 두십시오. 이것이 틀렸다는 것은 아니지만, 완전히 다른 사고방식이라고 생각합니다.
따라서 HTML5와 같은 형식을 구축하든, 웹사이트를 구축하든, 콘텐츠 관리 시스템을 구축하든, 무엇을 하든 디자인 근거를 명확히 하는 것이 중요하다고 생각합니다.

모든 기술과 마찬가지로 소프트웨어도 본질적으로 정치적입니다. 코드는 반드시 작성자의 선택, 편견 및 기대를 반영합니다.

아래 예를 들어보겠습니다. Drupal 커뮤니티는 Drupal의 인터페이스를 디자인하기 위해 Mark Boulton과 Leisa Reichilt에게 연락했습니다. 그들은 몇 가지 디자인 원칙을 따를 계획입니다. 이를 위해 그들은 단지 종이로만 이야기하는 것이 아니라, 오랜 시간 고민하고 고민한 끝에 향후 작업의 지침이 될 4가지 디자인 원칙을 제안했습니다.

가장 일반적인 작업을 단순화하고 덜 일반적인 작업은 덜 번거롭게 만듭니다.
80%만을 위해 설계되었습니다.
콘텐츠 제작자에게 최대한의 권리를 부여하세요.
기본 설정은 스마트입니다.

사실 제가 Mark와 이 문제에 대해 이야기했을 때 Mark는 주로 이 두 가지에 관한 것이라고 말했습니다. 즉, "오직 디자인은 80%에게만 주어집니다. 콘텐츠 제작자에게 가장 큰 권리를 부여합니다." “우리는 이 프로젝트에서 콘텐츠 제작자가 그 누구보다 중요하다고 믿습니다.” 디자인의 근거를 세울 때 많은 사람들이 모든 사람을 기쁘게 하기 위해 요점을 놓치는 데 많은 시간을 소비합니다. 핵심은 모든 사람을 기쁘게 하는 것이 아니라 누가 가장 중요한지 파악하는 것입니다. 그들은 콘텐츠 제작자가 가장 중요하다고 믿습니다.
또 다른 디자인 원칙인 Only Design for 80%는 사실 공통적인 디자인 원칙이자 보편적인 패턴, 즉 파레토 원칙입니다.
이탈리아 경제학자 파레토는 80/20이라는 비율을 제안했는데, 이는 세계 인구의 20%가 부의 80%를 소유하고 있다는 의미입니다. 이 비율은 자연의 다양한 분야에서 거듭제곱 법칙 분포 현상과 일치합니다. 간단히 말해서, 소프트웨어를 작성하든 무언가를 제조하든 그것은 동일합니다. 즉, 20%의 노력이 사용 사례의 80%에 도달할 수 있다는 것입니다. 마지막 20%의 사용 사례에는 80% 이상의 노력이 필요합니다. 따라서 때로는 20%의 노력만 필요하다는 것을 알기 때문에 80%를 위해 디자인하는 것이 합리적입니다.
또 다른 예로 마이크로포맷은 파레토 원칙을 활용하고 몇 가지 상황을 고려하지 않고 일반적인 사용 사례만 처리합니다. 그들은 모든 사람을 기쁘게 할 수는 없으며 그들의 목표도 모든 사람을 기쁘게 하는 것이 아니라는 것을 알고 있습니다. 그들이 따르는 디자인 원칙은 다양하고 모두 매우 가치가 높지만 가장 매력적인 것은 다음과 같습니다.

인간을 위한 디자인이 먼저이고, 기계는 그 다음입니다.

마찬가지로 여러분과 저는 이것이 당연한 사실이라고 생각하겠지만 실제로는 이 원칙을 위반하는 사례가 여전히 많습니다. 사용자가 이해하는 것보다 기계가 이해(파싱)하는 것이 더 중요합니다.
그래서 다른 사람들이 추천하는 디자인 원칙을 자세히 살펴보는 것이 당면한 작업을 수행하는 데 도움이 될 것이라고 생각합니다. 당신이 이해한다고 생각하는 디자인 원칙을 벽에 게시할 수 있습니다. 물론, Mozilla 재단처럼 URL을 유지하고 가치 있다고 생각하는 디자인 원칙을 공유할 수 있습니다. 다음은 Mozilla의 디자인 원칙입니다.

공공 자원으로서 인터넷의 운영 효율성은 상호 운용성(프로토콜, 데이터 형식, 콘텐츠), 변화 및 글로벌 협업에 달려 있습니다.
투명한 커뮤니티 기반 프로세스는 협업, 책임감, 신뢰를 높이는 데 도움이 됩니다.

관련 라벨:
원천:php.cn
본 웹사이트의 성명
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.
인기 튜토리얼
더>
최신 다운로드
더>
웹 효과
웹사이트 소스 코드
웹사이트 자료
프론트엔드 템플릿