HTML: 시맨틱 레이아웃. 의미론이란 무엇이며 HTML과 어떤 관련이 있습니까?
일러스트레이션: 케빈 코넬
번역: 블라드 메르제비치(Vlad Merzhevich)
나는 과감한 예측을 하고 싶다. 당신과 내가 사라진 후에도 HTML은 여전히 존재할 것입니다. 우리 시대의 수십억 개의 아카이브된 페이지뿐만 아니라 살아 숨쉬는 유기체로서. 인터넷 도구, 프로토콜 및 플랫폼을 개발하는 데 너무 많은 노력, 에너지 및 투자가 투입되어 쉽게 폐기될 수 있습니다.
우리의 책임에 집중합시다. 불행하게도, 역사상 우리는 앞으로 수십 년 동안 의사소통에 사용될 문명을 위한 중요한 도구의 개발과 연관되어 있습니다. 따라서 HTML 개선에 전념하거나 진지하게 정신을 바칠 때 오늘날 우리는 광범위한 결정의 결과를 이해해야 합니다.
최근 W3C가 차세대 HTML을 형성하기 위한 노력을 두 배로 늘린 HTML5는 상당한 추진력을 얻었습니다. 이는 HTML 구조뿐만 아니라 구문 분석 모델, 오류 처리, DOM, 리소스 추출 알고리즘, 미디어 콘텐츠, 2D 그래픽, 데이터 템플릿, 보안, 로딩 페이지, 클라이언트 측 데이터 저장 등을 다루는 거대한 프로젝트입니다. .
또한 기사에서 Lachlan Hunt가 부분적으로 다룬 HTML의 구조, 구문 및 의미 체계에 대한 변경 사항도 있습니다.
하지만 이 기사에서는 HTML 의미에만 초점을 맞추겠습니다. 그것은 수년 동안 나에게 관심을 가져왔고 의미론은 HTML의 미래에 근본적으로 중요하다고 믿습니다.
BBC는 최근 편리하고 접근 가능한 약어 템플릿을 위해 프로그램 목록에 사용되는 hCalendar 마이크로포맷을 포기한다고 발표했습니다. 이는 의심할 여지없이 해당 언어용으로 의도된 HTML의 의미론적 기능을 넘어섰다는 것을 나타냅니다. 문서의 의미적 마크업을 강화하는 HTML 요소와 속성이 부족해졌습니다. 기존 HTML 구성을 계속 속이는 경우 의미론적 마크업 언어로서의 HTML에는 근본적인 결함이 있기 때문에 많은 문제가 발생할 것입니다. 의미론은 고정되어 있고 확장할 수 없습니다.
이는 단지 이론적인 문제가 아닙니다. 수십만 명의 개발자가 class 및 id 속성을 사용하여 풍부한 의미 체계 마크업을 만듭니다. 동시에 개발자는 기존 스키마에서 가져온 값보다는 자신이 구성한 특수 사전을 거의 항상 사용합니다. 이것은 기껏해야 의사 의미론입니다.
인터넷의 많은 페이지에서는 마이크로포맷을 사용하여 사용 가능한 열악한 HTML 요소 및 속성 세트보다 더 구조화된 의미를 추가합니다. 이 경우 클래스 속성에 사용되는 값은 합의 어휘에서 설정되며 때로는 vCard와 같은 다른 표준에서 가져오고 때로는 고정된 표준이 없는(hReview에서와 같이) 새로 생성된 어휘에서 가져옵니다.
확장 가능한 의미론
해결해야 할 실제 문제가 있습니다. 개발자가 마크업에 의사 의미론보다 더 의미 있는 의미론을 추가할 수 있도록 명확하고 명확하게 허용하는 HTML 메커니즘이 필요합니다. 이것은 아마도 HTML5 프로젝트의 중요한 목표 중 하나일 것입니다.
그러나 어떤 솔루션이든 한계가 있기 때문에 그러한 메커니즘을 고안하는 것은 그리 쉽지 않습니다. 상당한 제한 사항이 있으며 그 중 가장 큰 것은 이전 버전과의 호환성일 것입니다. 이 솔루션은 현재 사용 중이며 앞으로도 수년 동안 사용될 수억 대의 장치를 중단해서는 안 됩니다. 이전 버전과의 호환성이 없는 솔루션은 독자를 잃을까 봐 개발자가 널리 수용하지 못할 것입니다. 그러한 결정은 금방 시들게 됩니다.
솔루션은 향후 버전과도 호환되어야 합니다. 미래의 브라우저에서 작동해야 한다는 의미는 아닙니다. 이는 브라우저 개발자의 책임이지만 확장 가능해야 합니다. 우리는 상상할 수 있거나 상상할 수 없는 미래의 의미론적 요구 사항을 모두 해결하기 위해 현재 개발되고 있는 단일 솔루션을 기대할 수 없습니다. 우리는 증가하는 요구 사항을 충족할 수 있는 솔루션을 설계할 수 있습니다.
두 가지 제한 사항이 함께 사용되는 것은 정말 큰 문제입니다. 그러나 수십 년 동안 주요 반복이 반복되고 커뮤니케이션을 위한 글로벌 플랫폼으로서의 중요성이 가장 중요한 언어의 맥락에서 이러한 과제는 충족되어야 합니다.
그렇다면 HTML5는 이 문제를 어떻게 해결합니까? HTML5에는 여러 가지 새로운 요소가 도입되었으며 그 중 일부는 "구조적" 요소입니다.
이러한 요소는 유용할 수 있고 관심을 불러일으킨 것처럼 보이지만 실제로 문제, 특히 이전 버전과 향후 호환성을 해결합니까?
각각의 제한사항을 살펴보겠습니다.
하위 호환성
최신 브라우저가 다음과 같은 새로운 요소를 처리하는 방법
최상위 헤더
두 번째 수준 제목
이것은 섹션 내부의 텍스트입니다.
세 번째 수준 제목
좋은 시작인 것 같습니다. 하지만 예를 들어 요소에 대해 이 스타일을 설정하려고 하면
섹션(색상: 빨간색)
언급된 대부분의 브라우저는 요소의 스타일을 변경했지만 IE8(및 IE6–7)은 변경하지 않았습니다.
따라서 우리는 현재 사용 중인 브라우저의 75%에서 심각한 하위 호환성 문제를 안고 있습니다. Internet Explorer의 반감기를 고려하면, 몇 년이 지난 후에도 대다수의 사용자가 여전히 IE6 및 IE7을 사용할 것이라고 예측할 수 있습니다.
HTML5에 새로운 요소가 도입된다면 해당 요소가 본질적으로 대부분의 브라우저와 호환되지 않는다는 점을 고려할 때 대부분의 개발자가 해당 요소를 채택할 가능성은 얼마나 됩니까? 불행하게도 CSS 문제에 대한 대안적인 해결책이 있다면 요소에 클래스 속성을 포함하는 것입니다.
두 번째 제한 사항인 향후 버전과의 호환성을 살펴보겠습니다.
미래 호환 가능
"왜 새로운 요소를 발명하는가?"라는 질문부터 시작해 보겠습니다. 이에 대한 합리적인 대답은 다음과 같습니다. "HTML에는 의미론적 풍부함이 부족하기 때문에 이러한 요소를 추가함으로써 HTML의 의미론적 풍부함이 증가합니다. 이는 나쁜 일이 아니죠, 그렇죠?"
이러한 요소를 추가함으로써 우리는 HTML에서 더 많은 의미론적 기능을 목표로 하고 있지만 이는 좁은 영역에서만 가능합니다. 얼마나 많은 요소가 도입되더라도 우리는 항상 HTML에 더 많은 의미를 추가하는 것에 대해 생각할 것입니다. 원하는 만큼 새로운 요소를 추가해도 문제가 해결되지 않습니다. 특정 항목을 추가할 필요는 없습니다. 자귀 HTML 사전에 필요에 따라 의미론을 사용하여 문서를 풍부하게 할 수 있는 메커니즘을 추가해야 합니다. 기술적인 관점에서 보면 HTML을 확장 가능하게 만들어야 합니다. HTML5에는 확장 메커니즘이 없습니다. 이것이 HTML5가 최신 브라우저의 상당 부분을 죽이고 실제로 의미를 전혀 추가하지 않는 이유입니다.
기존 사전, 동일한 Docbook을 받아들이는 것은 어떨까요? 문서 구조에 대한 어휘는 훨씬 더 풍부하며 수년에 걸쳐 수많은 전문가에 의해 개발되었습니다. 그러나 이것은 Docbook을 지지하는 주장이 아니며 HTML에서 의미론적 풍부함을 위한 메커니즘을 제공하는 작업이 30년 전 작업과 관련된 모범 사례에 거의 관심을 기울이지 않고 자체 방식으로 진행된다는 것이 요점입니다(원본 작업은 70년대 초반).
솔루션에 대한 몇 가지 생각
현재의 노력을 비판하면서 이 문제를 해결하는 방법에 대한 실용적인 조언이 있습니까? 음, 하나부터 시작하겠습니다.
HTML에 요소를 추가하는 것은 주제에서 벗어났지만, 적어도 이 논의에서는 속성이 우리가 집중할 HTML의 또 다른 논리적 영역입니다. 결국, 거의 10년 동안 우리는 HTML 의미를 확장하기 위한 메커니즘으로 class 및 id 속성을 사용해 왔습니다. 많은 개발자가 이 접근 방식에 익숙하고 편안합니다. microformats 프로젝트는 기존 HTML 속성이 HTML 의미 확장을 위한 보편적인 메커니즘을 제공하기에 충분하지 않다는 것을 보여주었습니다. 따라서 이 문제를 해결하기 위해 속성을 사용하려면 하나 이상의 새로운 속성을 포함해야 합니다. 이것이 어떻게 작동하는지에 대한 메커니즘을 알아보기 전에 새로운 HTML5 요소와 동일한 요구 사항에 대해 이 솔루션을 테스트해 보겠습니다. 가장 중요한 것은 새로운 HTML 속성이 이전 버전과 호환됩니까? 그렇다면 이것이 의미론적 HTML 확장을 위한 실제 메커니즘을 제공할 수 있을까요?
새로운 속성을 구현해 보겠습니다. 나는 그것을 "구조"라고 부르겠지만 구체적인 이름은 중요하지 않습니다. 우리는 이것을 다음과 같이 사용할 수 있습니다:
브라우저가 이를 어떻게 처리하는지 살펴보겠습니다. 물론 모든 브라우저는 CSS를 통해 스타일을 변경해야 합니다.
Div (색상: 빨간색)
하지만 어떻게 해야 할까요?
Div(글꼴 두께: 굵게)
실제로 IE7을 포함한 거의 모든 브라우저는 스타일을
속성을 통한 확장성
새로운 요소 대신 HTML5는 다양한 새로운 속성을 수용해야 합니다. 이러한 각 속성은 의미 체계의 범주 또는 유형에 포함됩니다. 예를 들어, 내가 하는 것처럼 HTML에는 구조적 의미론, 수사적 의미론, 역할 의미론(XHTML에서 가져온) 및 기타 의미론 클래스 또는 범주가 포함됩니다. 이러한 새로운 속성은 클래스 속성과 동일한 방식으로 사용될 수 있습니다. 요소에 대한 메타데이터를 추가할 뿐만 아니라 요소의 특성을 설명하는 요소에 의미를 추가하는 것입니다.
이는 XHTML의 역할 속성과 다르지 않지만 하나의 속성이 모든 의미 요소에 대한 공로를 인정하는 대신 다양한 유형의 요소 의미를 정의하고 이를 분리해야 합니다. 예를 들어 XHTML의 역할 속성은 다음과 같이 작동합니다.
역할 속성의 값은 기본 사전 또는 특정 사전의 공백으로 구분된 단어 목록입니다.
역할 속성을 그대로 사용하는 것은 어떨까요? 음, 역할 사전이 적용되지 않는 다른 종류의 의미론이 있습니다. 예를 들어:
그는 환상적인 사람입니다.
여기에는 이론적 유형의 의미론, 즉 문서의 수사적 특성을 표시하는 데 사용할 수 있는 "수사학"이 나와 있습니다. 이 요소는 분명히 문서에서 아이러니한 역할을 하지 않습니다. 오히려 아이러니한 요소를 담고 있다.
또 다른 예가 있습니다. 분명히 HTML에는 기계가 읽을 수 있는 버전을 사람이 읽을 수 있는 버전(예: 날짜)에 첨부하는 방법이 없습니다. 이것이 앞서 논의한 hCalendar 마이크로포맷과 관련된 BBC 문제의 핵심입니다. 하지만 내년 5월 1일정말 말도 안 돼요, 선 같은 것 내년 5월 1일나타날거야.
다시 말하지만, 이 의미론적 속성에 대해 "동등한"이라는 특정 용어를 사용하는지 아니면 다른 용어를 사용하는지 여부는 중요하지 않습니다. 주목해야 할 가장 중요한 점은 모든 경우에 하나의 클래스 또는 역할 속성을 사용하는 것만큼 간단하지 않다는 것입니다. 이전 버전과의 호환성과 충분한 유연성을 제공하는 적절한 확장 가능한 솔루션의 경우 이러한 라인에 따른 솔루션을 살펴볼 가치가 있습니다. 실제로 수용 가능한 솔루션을 달성하려면 수행해야 할 작업이 상당히 많기 때문에 이 섹션의 제목을 "솔루션에 대한 몇 가지 생각"으로 지정했습니다. 공개 질문에는 다음이 포함됩니다.
- 얼마나 많은 의미론적 속성이 있어야 합니까? 카테고리가 확장되었나요? 그렇다면 어떻게 확장되나요?
- 사전은 어떻게 정의되나요?
- 단순히 class 속성이 사용되는 방식과 비슷하게 우리가 원하는 용어를 만들어내는 걸까요, 아니면 표준 사양에 따라 가능한 값을 정의해야 하는 걸까요? 아니면 일종의 프로필을 사용하여 사전을 구현하고 공유할 수 있는 메커니즘이 있어야 합니까?
- 두 사전 사이에 충돌이 있는 경우(예: 서로 다른 사전에 두 개의 동일한 용어가 있는 경우) 이를 어떻게 해결합니까?
- 네임스페이스나 기타 유사한 메커니즘이 필요합니까?
이러한 질문에 성급하게 대답하기보다는 해결해야 할 문제를 강조하고 대화를 시작하겠습니다. HTML5에서 내린 결정의 결과와 영향은 언어학, 의미론, 기호학 및 관련 분야에 대한 충분한 이해 없이 내린 결정에 비해 너무 큽니다. 단순히 "새 요소를 만드는 것"이 HTML의 의미론적 힘을 높이는 해결책이 아니라는 것이 분명해졌으면 좋겠습니다. 결국 우리는 손자들에게 기후 변화에 대한 충분한 문제를 안겨주었습니다. 최소한 가능한 최고의 HTML을 남겨두도록 합시다.
그리고 댓글에 나온 추론으로 판단하여 HTML 언어와 그에 사용되는 태그에 대해 이야기하기 전에 이해해야 할 중요한 사항 하나를 명확히하고 싶습니다.
이 순간은 다음과 같은 중요한 개념을 이해하는 데 있습니다. 코드 의미론. 이 게시물에서 이 문제와 이 모든 것이 필요한 이유를 이해하려고 노력해 보겠습니다.
무슨 일이야? 코드 의미론?
의미론(언어학적 관점에서)은 언어 또는 개별 단위의 의미, 정보 내용입니다.
우리가 알고 있듯이 HTML 언어의 구조 단위는 의미와 정보 내용을 전달하는 개별 단위입니다.
인터넷 웹페이지에 표시해야 할 정보가 우리 앞에 있을 때, 우선 우리는 이 정보 중 어느 부분이 무엇인지 컴퓨터에 설명해야 합니다. 이를 모르면 모든 콘텐츠를 올바르게 표시할 수 없습니다.
따라서 HTML 언어를 사용하여 웹 페이지를 만들 때 우리는 페이지에서 어떤 요소가 어떤 역할을 해야 하는지 컴퓨터에 설명합니다.
우리는 웹페이지의 각 요소의 콘텐츠가 논리적, 의미론적 목적에 부합하는 태그로 둘러싸여 있어야 한다는 점을 이해해야 합니다.
저것들. 텍스트의 제목은 h 1-h 6 태그, p 태그의 단락, ul / ol (li) 태그의 목록 등에 포함됩니다.
이러한 조건을 충족하는 코드를 호출합니다. 의미론적저것들. 웹페이지의 각 요소는 옳은의미론적 의미.
이제 문제는 웹페이지의 제목을 단락 태그로 묶을 수 있느냐는 것입니다.
왜 안 돼? 물론 가능합니다. 많은 사람들이 말할 것이지만 이 경우 h 1-h 6이라는 제목의 디자인이 손실됩니다. 그러나 실제로 디자인은 여기서 어떤 역할도 하지 않습니다. CSS 스타일을 사용하면 h 1-h 6 요소와 정확히 동일한 디자인을 모든 단락에 할당할 수 있습니다.
여기서 우리가 이끌어내야 할 결론은 코드의 의미와 디자인이 서로 혼동되어서는 안되는 두 가지 다른 것이라는 것입니다. 태그마다 일정한 디자인이 부여되어 있어 쉽게 변경할 수 있지만, 이 태그가 갖는 의미적 의미는 변경할 수 없습니다.
제목을 단락으로 묶을 수 있지만 이 경우 코드의 의미가 손실되고 이 텍스트는 완전히 다른 의미를 전달하게 됩니다.
따라서 태그에 요소를 포함하기 전에 해당 요소가 페이지에서 어떤 기능과 의미를 전달하는지 생각해 보는 것이 좋습니다.
논리적인 질문이 생깁니다. 이 경우 코드 의미론이 왜 필요한가요?
제목은 제목으로, 단락은 단락으로, 약어는 약어로 만들어야 하는 이유는 무엇입니까?
제 생각에는 의미론적 코드에 의지하는 데 도움이 되는 몇 가지 이유가 있습니다. 의미론적 마크업은 우리에게 무엇을 제공합니까?
1) 기본 브라우저가 페이지에 이 요소 또는 해당 요소를 표시하는 방법에 대한 정보
예를 들어, 특별한 스타일이 지정되지 않은 경우 제목 h 1이 페이지에 2em 크기와 굵은 글꼴로 표시된다는 것을 알고 있습니다. 그러나 제 생각에는 이것이 가장 중요하지 않은 이유입니다.
2) 의미 체계 코드는 검색 엔진에서 더 잘 읽고 인식됩니다.
의미적 마크업이 있는 페이지(다른 조건이 동일함)가 비의미적 코드가 있는 페이지보다 검색 엔진 결과에서 더 높게 나타날 것으로 믿어집니다.
2) 코드는 인간이 더 이해하기 쉽습니다.
텍스트의 이 부분이 단락, 약어 등임을 모든 것이 명확하게 명시되어 있는 코드를 이해해야 한다는 데 동의합니다. 모든 정보가 하나의 연속적인 구조로 제공되고 작성자가 말하려는 내용이 명확하지 않은 코드보다 훨씬 쉽습니다.
3) 요소에 대한 액세스가 더 쉬워지고 결과적으로 유연성이 향상됩니다.
코드를 의미 있게 만들면 CSS, Javascript 등과 같은 웹 페이지의 요소와 작동하는 특수 도구를 사용하여 이러한 요소에 훨씬 더 쉽게 액세스할 수 있습니다.
페이지의 모든 약어를 abbr 태그로 묶은 다음 CSS에서 페이지의 모든 약어를 빨간색으로 바꾸려면 작성하기만 하면 됩니다.
약어 (색상 :빨간색 ;)
각 개별 약어에 대해 HTML에서 이 규칙을 강조하고 규정하는 대신.
이것은 단지 하나의 예일 뿐이며 그 중 많은 것들이 있습니다.
이러한 이유로 의미론적 코드는 단순히 문서에 더 많은 힘을 부여한다는 점을 이해해야 합니다. 일부 태그를 사용하여 사이트의 의미를 개선하고 더 큰 기능을 얻을 수도 있고, 태그를 사용할 수 없어 이러한 이점을 받지 못할 수도 있습니다.
그것은 당신의 사업입니다!
이 결정은 스스로 내려야 합니다.
이 글에서는 HTML5에서 의미론적 마크업을 사용하는 방법과 이를 올바르게 수행하는 방법을 배웁니다.
시맨틱 HTML5란 무엇입니까?
HTML에 어느 정도 익숙하다면 콘텐츠 형식을 지정하는 데 주로 사용되는 HTML 태그에 대해 알아야 합니다. HTML 태그는 페이지에 콘텐츠를 표시하는 방법을 브라우저에 알려줍니다. 포함된 콘텐츠 유형이나 콘텐츠가 페이지에서 수행하는 역할을 정의하지 않습니다.
시맨틱 HTML5는 페이지에서 콘텐츠의 명확한 역할을 설명하기 위해 정확한 태그를 정의하여 이러한 단점을 해결합니다. 이 추가 정보는 Google 및 Bing과 같은 크롤러/인덱서가 중요한 콘텐츠, 중요하지 않은 콘텐츠, 탐색에 사용되는 콘텐츠 등을 더 잘 이해하는 데 도움이 됩니다. 페이지에 의미론적 HTML 태그를 추가하면 검색 엔진이 페이지의 다양한 부분의 역할과 상대적 중요성을 이해하는 데 도움이 되는 추가 정보를 제공할 수 있습니다.
예
이는 의미가 없는 HTML 요소의 예입니다. 브라우저에 콘텐츠 표시 방법을 알려주는 관리인 역할을 합니다. 페이지에서 콘텐츠의 역할에 대한 정보는 제공하지 않습니다.
그리고 이것은 의미론적 요소입니다. 그들은 콘텐츠 콘텐츠의 역할을 명확하게 정의합니다.
왜 이것을 사용해야합니까?
주의 깊은 사용자라면 일반적으로 한 눈에 웹페이지의 여러 부분을 쉽게 식별할 수 있습니다. 제목, 메뉴 및 주요 콘텐츠는 모두 즉각적이고 시각적으로 명확합니다. 이제 당신이 장님이라고 상상해보십시오.
Google 및 Bing 봇은 시각 장애인이 아니라면 심각한 시각 장애를 가지고 있습니다. 그들에게는 시각적인 설명이 보고 이해하기가 엄청나게 어렵습니다.
그들은 당신의 도움이 필요합니다. 페이지의 어느 부분이 머리글, 바닥글, 탐색인지 성공적으로 검색 엔진에 전달할 수 있다면 감사할 것입니다. 가장 중요한 것은 어떤 콘텐츠가 가장 중요한지 알려주는 것입니다. 이를 통해 콘텐츠의 우선순위를 지정하는 방법에 대한 고급 지침을 제공할 수 있습니다.
가장 중요한 콘텐츠 — 가장 중요한 콘텐츠
HTML5를 사용하는 것만으로는 SEO 작동 방식에 혁명을 일으키지 않습니다. 아시다시피 성공적인 SEO는 수많은 작은 세부 사항의 조합입니다. 이는 모든 검색 엔진에서 사이트 콘텐츠에 대한 이해를 향상시켜 SEO 노력에 크게 기여할 작은 세부 정보 중 하나입니다.
향후 몇 년 동안 검색 엔진 최적화가 어떻게 발전할지 예측하면 이러한 시스템과의 향상되고 일관된 커뮤니케이션이 SEO/AEO 전략의 두 가지 초석 중 하나가 될 것입니다.
그것은 모두 어떻게 생겼습니까?
의미론적 HTML 태그의 예는 다음과 같습니다.
대신 다음 HTML5 태그를 사용할 수 있습니다.
각 콘텐츠에 대한 경계를 명확하게 설정하고 역할 속성을 자세히 설명하면 페이지가 훨씬 더 명확해지고 Google 및 Bing에 대한 올바른 색인 생성이 더 쉬워집니다.
이 태그는 다음과 같이 동작합니다.
의미론적 HTML5 예
매우 간단한 의미의 HTML5 예:
여기서는 페이지의 각 부분이 수행하는 역할을 매우 간단하게 정의합니다. HTML5 마크업을 시작할 때 가장 안전한 시작 방법은 머리글, 탐색, 기본, 바닥글입니다.
복잡하고 잘못된 실행보다는 100% 정확한 매우 간단한 실행이 더 좋습니다.
잘못 실행하면 상황을 개선하기는커녕 더욱 악화시키는 상충되고 혼란스러운 신호를 보내는 것입니다.
정확하고 간단한 구현은 이미 검색 엔진과의 커뮤니케이션에서 큰 진전입니다. 지나치게 야심적이지 마십시오. 잘못하면 해결하는 것보다 더 많은 문제가 발생할 수 있습니다.
더 복잡한 예
섹션 사용 및
여기서 우리는 주요 콘텐츠에 계층적 시스템을 만들었습니다. 모든 것을 포괄하는 것이 있다
디자인(주황색 블록)은 페이지의 의미 영역을 정의하는 데 사용되지 않습니다. 약간 혼란스러워 보이지만 템플릿 HTML과 의미론적 HTML이 서로 다른 역할을 갖고 있음을 아주 명확하게 보여줍니다.
실제 세계에서 의미론적 마크업은 이 예보다 더 명시적으로 기본 마크업을 따르는 경우가 많습니다. 주요 규칙을 기억하세요. 섹션은 다른 것의 일부를 구성합니다.
제쳐두고
여기서는 기본 콘텐츠에 관련 콘텐츠 두 개를 추가했습니다.
간접적인 관련은 제쳐두고
Aside는 메인 콘텐츠 옆에 사이드바가 될 필요는 없습니다. 제목, 텍스트, 다른 페이지에 대한 링크 등 주요 콘텐츠 아래의 블록에도 적용할 수 있습니다.
여기에서는 기본 페이지 외부의 페이지에 간접적으로 관련된 여러 콘텐츠를 정의했습니다.
우리의 최종 버전
이것은 매우 논쟁의 여지가 있는 주제입니다. 그리고 이에 대한 명확한 규칙은 없습니다.
개인적인 조언. 나는 그 안에 중첩된 섹션이 있다는 것을 알아차렸습니다.
중첩된 요소
요소는 다른 요소를 중첩할 수 있습니다. 예를 들어,
위에서 언급했듯이 SEO 목적을 위해서는 명확하고 단순한 구조를 만드는 데 집중해야 합니다.
하지 말아야 할 것
단지 경고일 뿐입니다. 나는 많은 사이트에서 HTML5에 대한 지침으로 시각적 디자인을 사용하는 것을 보았습니다. 아래에 표시된 것처럼 이는 의미론적 HTML5가 설계된 목적이 아닙니다.
이 믿을 수 없을 만큼 간단한 예는 단순히 템플릿 렌더링을 복제한 것입니다. 무의미한 것 이상으로 페이지가 하나의 기본 주제와 3개의 하위 주제가 아닌 4개의 서로 다른 주제로 구성되어 있다고 판단합니다. 이러한 체계는 검색 엔진에 오해의 소지가 있는 정보를 명확하게 제공함으로써 전반적인 이해에 부정적인 영향을 미칠 것입니다.
다음 단계?
페이지에 의미론적 HTML5를 사용하면 검색 엔진에 대한 정보 전달이 크게 향상됩니다. 그들은 귀하의 웹사이트가 무엇인지를 원하기 때문입니다. 그들은 당신이 그들이 이해하는 언어로 명확하게 말하기를 원하고 당신이 그들을 교육하기를 원합니다. 그렇기 때문에 그렇게하십시오.
의사소통
검색 엔진과의 커뮤니케이션(HTML5가 중요한 역할을 함)은 검색 엔진을 최적화해야 하는 세상에서 성공으로 이어질 장기적인 SEO 전략의 두 기둥 중 하나입니다. 이러한 유형의 의사소통을 개선하기 위해 할 수 있는 훌륭한 일이 많이 있습니다. 의미론적 HTML5가 이에 대한 예입니다. 스키마 마크업은 또 다른 예입니다.
신뢰할 수 있음
두 번째 열은 신뢰성입니다. 자신감을 높이기 위해 할 수 있는 멋진 일들도 있습니다. SEO와 AEO는 모두 커뮤니케이션과 신뢰성에 수렴됩니다.
결론: 좋은 HTML5 SEO 마크업에 대한 알림
구조, 중요성, 역할 및 계층 구조는 사람들이 패턴 디자인에서 본능적으로 이해하는 경우가 많습니다. 대신 의미론적 HTML5의 적절한 사용
사이트의 모든 항목에 div 태그를 사용하는 사람이라면 이 문서가 도움이 될 것입니다. 유효한 마크업을 사용하여 깔끔하고 의미 있는 HTML을 작성하는 방법에 중점을 둘 것입니다. 실제로 HTML 코드에서 div 태그 수를 최소화하는 방법을 살펴보겠습니다. 이론적인 내용뿐만 아니라 예제를 통해서도 의미론적 레이아웃을 학습하게 됩니다. 올바른 의미 템플릿을 작성하면 자신뿐만 아니라 팀 전체의 삶이 더 쉬워집니다. 음, 코드를 해석하는 브라우저가 더 쉽습니다. 코드가 적을수록 페이지 로드 속도가 빨라집니다. 또한 이를 통해 대규모 프로젝트를 만들 때 시간을 절약하고 코드를 쉽게 이해할 수 있습니다. 즉, 시맨틱한 레이아웃은 고품질의 웹사이트를 만들기 위한 필수 조건입니다.
시맨틱 레이아웃의 개념
의미론HTML 레이아웃- 태그 내부에 있는 정보에 대한 태그의 대응입니다. 코드 의미는 태그 수를 줄여도 달성됩니다. 따라서 우리는 깨끗하고 읽기 쉽고 유효한 HTML 코드를 만듭니다. 이러한 페이지는 더 빠르게 로드되고 검색 엔진에 의해 순위가 매겨집니다.
코드 의미론을 달성하는 방법은 무엇입니까?
간단합니다. 가장 중요한 것은 모든 것을 단순하게 유지하고 모든 것을 가능한 한 CSS 스타일에 넣고 JS 코드를 별도의 파일에 넣는 것입니다. 고전에 따르면 하나의 HTML 페이지에는 하나의 CSS 파일과 하나의 JS 파일만 포함되어야 합니다. HTML과 관련하여 각 사이트마다 고유한 상황이 있습니다. 결국, 그들 각각은 독특합니다. 이제 레이아웃 디자이너가 실수하는 주요 지점을 살펴보겠습니다.
- 제목은 H1, H2, H3, H4 태그로 강조 표시해야 하지만 B 및 STRONG 태그는 강조 표시할 수 없습니다.
- 메뉴를 생성할 때 LI 메뉴 요소를 포함하는 UL 목록을 사용하는 것이 가장 좋습니다. 이는 링크가 동일함을 나타냅니다. 두 번째 중첩 항목이 있는 경우 그에 따라 기본 LI 요소 내에 또 다른 UL 목록을 생성합니다.
- 모든 서비스 이미지(아이콘, 화살표, 글머리 기호...)는 CSS 코드로 작성되어야 합니다. HTML에서 IMG 태그는 큰 이미지에만 사용해야 합니다. 예를 들어 100 x 100 이상의 미리보기부터 시작하면 대형 개념이 유연해집니다.
- 텍스트의 단락 블록은 DIV가 아닌 P 태그를 사용하여 생성됩니다.
- HTML 태그 내에 STYLE 속성을 사용하지 마세요. 모든 스타일을 별도의 CSS 파일에 배치합니다.
- 자바스크립트도 마찬가지입니다.
- 문서 계층 구조와 논리를 유지합니다. 더 중요한 페이지 요소는 HTML 코드의 시작 부분에 있어야 하고 끝 부분에는 덜 있어야 합니다. CSS 스타일과 DIV 블록의 도움으로 어떤 템플릿 레이아웃에서도 이를 달성하는 것이 어렵지 않습니다.
- 어쩌면 제가 다른 것을 잊어버린 것일 수도 있습니다. 그렇다면 기사 댓글에서 제 내용을 정정해 주세요.
문제의 본질을 더 명확하게 알아보려면 의미론적 텍스트 마크업 다이어그램을 참조하세요.
실제로 시맨틱 레이아웃 - HTML + CSS 코드의 예
이제 실제로 의미론적 레이아웃의 모든 원칙을 통합해 보겠습니다. 구체적인 상황을 분석하겠습니다.
불필요한 div 태그 제거
나는 많은 사람들이 양식이나 ul 근처에 div 태그를 만드는 것을 보았습니다. 필요하지 않은 추가 div를 만드는 이유는 무엇입니까? CSS 파일에 몇 가지 지침을 추가하면 동일한 결과를 얻을 수 있습니다.
예시 1:
아래 예에서는 div 태그를 제거하고 양식 선택기에 동일한 스타일을 추가하는 방법을 보여줍니다.
예 2:
때로는 왼쪽 예제와 같이 패딩을 만들기 위해 div 블록에 콘텐츠를 래핑하는 경우도 있습니다. 그러나 각 블록에 h4 제목이 있는 경우 h4 선택기에 여백을 적용하고 추가 div 태그를 제거하면 됩니다.
의미론적 코드 마크업을 사용합니다.
앞서 언급했듯이 HTML 코드에는 항상 의미 체계 마크업을 사용해야 합니다. 그러나 이는 CSS 스타일시트 없이는 달성할 수 없습니다.
예:
아래 그림은 CSS 스타일이 없는 div 마크업과 시맨틱 마크업의 차이점을 보여줍니다.
div 태그 사용 최소화
아마도 div 태그가 어디에나 있는 템플릿을 본 적이 있을 것입니다... 그들은 나를 화나게 합니다. 추가 닫는 /div 태그나 닫히지 않은 div가 있었나요? 근처에 3~4개의 div 태그가 있을 때 모든 레이아웃 디자이너가 비슷한 문제에 직면했을 것이라고 확신합니다. 혼란을 피하려면 div 사용을 최소화해야 합니다. 이렇게 하면 오류를 더 쉽게 추적할 수 있습니다.
예시 1:
탐색 경로를 생성하기 위해 div를 사용하는 대신 p 태그를 사용할 수 있습니다.
HTML 코드의 의미는 항상 뜨거운 주제입니다. 일부 개발자는 항상 의미 체계 코드를 작성하려고 합니다. 다른 사람들은 독단적인 지지자들을 비판합니다. 그리고 일부는 그것이 무엇인지, 왜 필요한지 전혀 모릅니다. 의미 체계는 HTML에서 목적을 설명하지만 포함된 정확한 콘텐츠를 지정하지 않는 태그, 클래스, ID 및 속성으로 정의됩니다. 즉, 콘텐츠와 형식을 분리하는 것입니다.
분명한 예부터 시작해 보겠습니다.
잘못된 코드 의미
좋은 코드 의미론
누군가가 작성한 기사의 텍스트입니다. 인코 그니토- 저자.기사 제목
HTML5를 사용할 준비가 되었는지 여부에 관계없이 태그를 사용하여 그러나 모든 것이 HTML5 태그로 명확하게 표현되는 것은 아닙니다. 클래스 이름 집합을 살펴보고 의미론적 요구 사항을 충족하는지 살펴보겠습니다. 의미론적 코드가 아닙니다.이것은 전형적인 예입니다. 모든 CSS 그리드 워크벤치는 이러한 유형의 클래스 이름을 사용하여 그리드 요소를 정의합니다. "yui-b", "grid-4", "spanHalf" 등의 이름은 내용을 설명하는 것보다 마크업을 지정하는 데 더 가깝습니다. 그러나 모듈식 그리드 템플릿으로 작업할 때 대부분의 경우 이러한 사용은 불가피합니다. 의미론적 코드.바닥글은 웹 디자인에서 강한 의미를 얻었습니다. 반복 탐색, 사용 권한, 작성자 정보 등과 같은 요소가 포함된 페이지 하단 부분입니다. 이 클래스는 이러한 모든 요소를 설명하지 않고 그룹을 정의합니다. HTML5 사용으로 전환한 경우 요소를 사용하는 것이 좋습니다. 의미론적 코드가 아닙니다.내용을 정확하게 정의합니다. 그런데 왜 텍스트가 커야 합니까? 다른 작은 텍스트보다 눈에 띄도록 하시겠습니까? 이 경우에는 "standOut"(강조 표시)이 더 적합합니다. 강조 표시 텍스트의 스타일을 변경하기로 결정했지만 크기에 대해서는 아무 조치도 취하지 않을 수 있습니다. 이 경우 클래스 이름이 혼란스러울 수 있습니다. 의미론적 코드.이 경우 애플리케이션 인터페이스에서 요소(예: 단락 또는 버튼)의 중요도 수준을 결정하는 것에 대해 이야기하고 있습니다. 높은 수준의 요소는 더 밝은 색상과 더 큰 크기를 가질 수 있는 반면, 낮은 수준의 요소는 더 많은 콘텐츠를 포함할 수 있습니다. 하지만 이 경우 스타일에 대한 정확한 정의가 없으므로 코드는 의미론적입니다. 이 상황은 태그를 사용하는 것과 매우 유사합니다. 의미론적 코드.모든 클래스 이름이 이렇게 명확하게 정의될 수만 있다면! 이 경우에는 "트윗", "페이지 매김" 또는 "admin-nav"와 같이 목적을 쉽게 설명할 수 있는 콘텐츠가 있는 섹션에 대한 설명이 있습니다. 의미론적 코드가 아닙니다.이 경우 페이지 첫 번째 단락의 스타일 설정에 대해 이야기하고 있습니다. 이 기술은 독자의 관심을 자료에 끌어들이는 데 사용됩니다. 요소를 언급하지 않는 "intro"라는 이름을 사용하는 것이 더 좋습니다. 그러나 이러한 단락에는 기사 p:first-of-type 또는 h1 + p와 같은 선택기를 사용하는 것이 더 좋습니다. 의미론적 코드가 아닙니다.이는 요소의 형식을 구성하는 데 사용되는 매우 일반적인 클래스 이름입니다. 하지만 내용에 대한 설명과 관련된 내용은 전혀 없습니다. 다양한 의미 이론가들은 이러한 경우 "그룹"과 같은 클래스 이름을 사용할 것을 권장합니다. 그들이 옳을 가능성이 높습니다. 이 요소는 의심할 바 없이 다른 여러 요소를 그룹화하는 역할을 하기 때문에 권장되는 이름은 세부 사항을 자세히 설명하지 않고도 해당 목적을 더 잘 설명할 것입니다. 의미론적 코드가 아닙니다.콘텐츠 형식에 대한 설명이 너무 자세합니다. 형식보다는 내용을 설명하는 다른 이름을 선택하는 것이 좋습니다. 의미론적 코드.클래스는 콘텐츠의 상태를 매우 잘 설명합니다. 예를 들어, 성공 메시지는 오류 메시지와 완전히 다른 스타일을 가질 수 있습니다. 의미론적 코드가 아닙니다.이 예에서는 콘텐츠의 목적보다는 콘텐츠의 형식을 정의하려고 합니다. "plain-jane"은 "normal" 또는 "regular"와 매우 유사합니다. 이상적인 CSS 코드는 콘텐츠 형식을 설명하는 "regular"와 같은 클래스 이름이 필요하지 않은 방식으로 작성되어야 합니다. 의미론적 코드가 아닙니다.이러한 유형의 클래스는 일반적으로 링크 체인에 포함되어서는 안되는 사이트 요소를 정의하는 데 사용됩니다. 이 경우 링크에는 rel=nofollow와 같은 것을 사용하는 것이 좋지만 모든 콘텐츠에 대한 클래스는 사용하지 않는 것이 좋습니다. 의미론적 코드가 아닙니다.이는 내용의 목적이 아닌 내용의 형식을 설명하려는 시도입니다. 귀하의 웹사이트에 두 개의 기사가 있다고 가정해 보겠습니다. 그리고 당신은 그들에게 다양한 스타일을 주고 싶어합니다. '영화 리뷰'는 파란색 배경을 가지며 '속보'는 빨간색 배경과 더 큰 글꼴 크기를 갖습니다. 문제를 해결하는 한 가지 방법은 다음과 같습니다. 또 다른 방법은 다음과 같습니다. 확실히 어떤 코드가 의미론적 요구 사항에 더 일치하는지에 대해 여러 개발자를 인터뷰하면 대다수가 첫 번째 옵션을 가리킬 것입니다. 이는 이 강의의 내용과 완벽하게 일치합니다. 즉, 서식에 대한 링크 없이 목적에 대한 설명입니다. 두 번째 옵션은 형식을 나타냅니다("blueBg"는 "blue background"를 의미하는 두 개의 영어 단어로 구성된 클래스 이름입니다). 갑자기 영화 리뷰 디자인을 변경하기로 결정한 경우(예: 녹색 배경 만들기) 클래스 이름 "blueBg"는 개발자에게 악몽이 될 것입니다. 그리고 "영화 리뷰"라는 이름을 사용하면 탁월한 수준의 코드 지원을 유지하면서 디자인 스타일을 쉽게 변경할 수 있습니다. 그러나 어느 누구도 예외 없이 모든 경우에 첫 번째 예가 더 낫다고 주장하지 않습니다. 특정 파란색 음영이 사이트의 여러 위치에서 사용된다고 가정해 보겠습니다. 예를 들어 사이드바의 일부 바닥글과 영역에 대한 배경입니다. 다음 선택기를 사용할 수 있습니다. 영화 리뷰, 바닥글 > div:nth-of-type(2), side > div:nth-of-type(4) ( 배경: #c2fbff; ) 색상은 한 곳에서만 결정되므로 효과적인 솔루션입니다. 그러나 이러한 코드에는 시각적으로 이해하기 어려운 긴 선택기가 있기 때문에 유지 관리가 어려워집니다. 또한 고유한 스타일을 정의하려면 다른 선택기가 필요하므로 코드가 반복됩니다. 또는 다른 접근 방식을 취하고 분리된 상태로 유지할 수도 있습니다. 영화 리뷰( background: #c2fbff; /* 색상 정의 */ ) footer > div:nth-of-type(2) ( background: #c2fbff; /* 한 가지 더 */ ) Aside > div:nth-of - type(4) ( background: #c2fbff; /* 그리고 한 가지 더 */ ) 이 스타일은 CSS 파일을 보다 체계적으로 유지하는 데 도움이 됩니다(다른 영역은 다른 섹션에 정의되어 있음). 그러나 지불해야 할 대가는 정의의 반복입니다. 대규모 사이트의 경우 동일한 색상을 식별하는 것이 수천 번에 이를 수 있습니다. 끔찍한! 해결책은 "blueBg"와 같은 클래스를 사용하여 색상을 한 번 정의하고 해당 디자인을 사용하려는 경우 HTML 코드에 삽입하는 것입니다. 물론 서식 설명을 없애려면 "mainBrandColor" 또는 "secondaryFont"라고 부르는 것이 더 좋습니다. 리소스를 절약하기 위해 코드 의미를 희생할 수 있습니다. ,
,
, 등이 있지만 다른 인터페이스 요소에도 적용됩니다.
하지만...