의미론적 마크업이 너무 개방적인가요?[닫은]

Question

나는 엿보고 있다 HTML5에 대해 자세히 알아보기.그것은 좋고 흥미로운 것 같지만 나는 의아해합니다.

1990년대, 넷스케이프가 브라우저이고 HTML이 HTML2나 HTML3이던 당시에는 태그가 많았습니다.주소, 인용, 코드...이들 중 대부분은 현재 사용되지 않으며 아마도 더 이상 사용되지 않을 수도 있습니다.

HTML5 태그 자체에 "의미론적 의미"를 표현하기 위해 태그를 도입합니다.이것은 모두 재미 있고 게임이지만 이 접근 방식에서 매우 이상한 점을 발견했습니다.기술적으로 의미론은 매우 개방적일 수 있습니다.HTML5에는 기사, 시간, 탐색 모음, 바닥글에 대한 태그가 있습니다.게시물 아이콘, 작성자의 장소, 이름과 성 또는 특정 의미를 할당하려는 기타 항목에 대한 태그를 포함하면 안 되는 이유는 무엇입니까(저는 확신합니다). <rant> 그리고 <nsfw> 매우 중요한 태그입니다):?나는 XML이 사물에 의미를 부여하는 전략이라고 생각했습니다.XML 청크를 아래에 두는 것을 금지하는 것은 없습니다. XHTML div 요소에 스타일시트를 할당하여 적절하게 스타일을 지정하거나 해당 네임스페이스 처리를 적절한 뷰어에 위임합니다(예: 처리할 때) RSS 또는 SVG).

결론적으로, 의미론이 잠재적으로 무한한 양의 의미론적 태그를 요구하는 매우 광범위한 주제라는 것이 분명할 때 의미론에 초점을 맞춘 이 확장의 이유를 이해하지 못합니다.똑똑한 사람들이 있다고 확신하기 때문에 W3C, 내 생각이 틀렸다고 생각하는데 그 이유를 알고 싶습니다.

Answer 1

기사, 시간, 내비게이션 바, 바닥 글이 유용한 이유는 무엇입니까?

Google과 같은 텍스트 처리 도구를위한 구문 분석을 용이하게하기 때문입니다.

그것은 의미론에 관한 것이 아닙니다 (적어도 '광범위한'의미에서). 대신 그들은 단지 말한다 : 여기에 페이지의 본문 (가장 중요한 텍스트 부분)이 있으며 링크로 가득 찬 탐색 막대가 있습니다. 이러한 접근 방식을 사용하면 필요한 것을 쉽게 추출 할 수 있습니다.

Answer 2

나도 W3C가 사양과 함께가는 방식을 싫어합니다. 내가 좋아하지 않는 많은 것들이 있으며,이 "의미론"유행은 그 중 하나입니다. (다른 사람들은 사양을 완성하기 위해 영원히 복용하고 브라우저가 선택한대로 구현하기에는 너무 많은 중요한 세부 사항을 남기는 것을 포함합니다).

무엇보다도 나는 웹 개발자로서의 작업을 더욱 어렵게 만들기 때문에 좋아하지 않습니다. 나는 종종 웹 페이지를 "의미 적으로 정확한"또는 "시각적/미적으로 즐겁게 만드는"여부를 선택해야합니다. 후자는 물론 사용자가 원하는 것이기 때문에 이기지 만 결과 검증이 실패하기 시작하고 모든 것이 상당히 의미가 없습니다 (레이아웃 및 기타 물건에 대한 테이블).

내가 눈살을 찌푸린 또 다른 문제는 그들이 "클래스"속성이 의미론이라고 선언했지만 CSS의 시각적 프레젠테이션 선택기에 사용했다는 것입니다.

결론 - 의미론과 시각적 표현을 혼합하지 마십시오. 시맨틱 (태그 이름, 속성 값 또는 다른 것이 아닌 것과 같은)을 설명하기 위해 일부 메커니즘을 사용하는 경우 Funcional/Visual 목적으로 사용하지 말고 그 반대도 마찬가지입니다.

html을 설계하려면 "클래스"속성과 같은 "Semantic"속성을 추가하여 모든 태그에 추가 할 수 있습니다. 그런 다음 모든 헤더/바닥 글/기사/따옴표 등과 같은 여러 가지 미리 정의 된 값이 있습니다.

태그는 기능을 정의합니다. 기본적으로 HTML 태그를 "div", "table/tr/td", "a", "img", "form", "input"및 "select"와 같은 소수로 줄일 수 있습니다. 나는 아마 몇 가지를 놓쳤을 것입니다. 그러나 이것은 벌크입니다. 시각적 스타일은 CSS를 통해 달성됩니다.

이런 식으로 의미, 시각적 표현 및 기능의 세 가지 영역은 완전히 독립적이며 실제 솔루션에서 충돌하지 않을 것입니다.

물론 W3C가 실용적인 솔루션에 관심이 없다고 생각합니다 ...

Answer 3

HTML 마크 업에는 클래스와 ID의 형태로 이미 많은 의미가 있으며, 그 중 (거의) 무한한 양의 가능성이 있으며, 모든 사람들은 이러한 의미론을 처리하는 자신만의 방법을 가지고 있습니다. HTML5의 목표 중 하나는 이것에 약간의 구조를 가져 오는 것입니다. 여전히 클래스 및 ID로 태그의 의미를 확장 할 수 있습니다. 또한 검색 엔진에서 더 쉽게 일할 수 있습니다.

Answer 4

페이지에 대해 또는 페이지에서 참조 된 객체에 대해 설명하는 각도에서보십시오. 당신이 보이면 au003Cfooter> 태그, 당신이 말할 수있는 것은 "여기에있는 것들이 바닥 글이있다"는 것입니다. 따라서 사용자 정의 태그를 추가하는 것은 속성을 추가하고 사람들이 자신의 URI를 선택하여 Predicates 및 선택적으로 값을 지정하기 위해 자신의 URI를 선택할 수있게하는 것만 큼 일반적인 솔루션이 아닙니다. 어느 RDF에서 좋아하는 트리플 진술은 한 페이지에서 어떤 방식 으로든 페이지에서 좋아합니다.

Answer 5

나는 단지 당신의 질문의 한 부분을 다루고 싶습니다. 당신은 말합니다 :

90 년대에는 Netscape가 브라우저이고 HTML이 HTML2 또는 HTML3이었을 때, 주소, 인용, 코드 등 많은 태그가있었습니다. 대부분의 사람들은 오늘날에도 사용되지 않았을 것입니다.

HTML에는 선택할 수있는 많은 태그가 있지만 사용이 부족하다고해서 쓸모 없다는 것을 의미하지는 않습니다. 특히 헤더 태그 <h1>, 등, 및 <ul>, <ol> Semantic을 고려하는 방식으로 항목을 목록에 연결하는 데 사용됩니다. 많은 사람들이 의미 적으로 태그를 사용하지 않을 수도 있지만 미세 기름 1990 년대의 유물을 고려하는 아이디어의 지속적인 연속입니다. 만들기위한 노력 시맨틱 웹 웹을 찾고 이해하는 방법에 따라 전체 텍스트 검색 및 링크 분석 (Google 형식)에도 불구하고 승자가 되십시오.

업데이트 된 버전을 보는 것이 좋을 것입니다. Google의 웹 통계 "그녀가 말하면서 HTML"을 보여줍니다. 그러나 당신은 많은 태그가 많이 사용된다는 것이 옳습니다.

html5가 성공할 것인지 여부는 개방적이고 흥미로운 질문이지만, 쓸모없는 것으로 묘사 한 태그는 아무데도 가지 않았고, 그들은 그곳에있었습니다. HTML 4.01 그리고 XHTML. html5 태그에 유용한 것을 강화하려는 노력 인 것 같습니다. 결국 HTML5가 브라우저에서 지원을 받고 웹 개발자의 작업을 더 쉽게 만들면 성공할 것입니다. xhtml2 브라우저에서 채택을 얻지 못했기 때문에 실패했으며 웹 페이지 제조업체의 작업을 더 쉽게 만들 수 없었습니다. HTML5에서 작업하는 힘은 XHTML2의 실패를 예리하게 알고있는 것으로 보이며, HTML5도 비슷한 운명을 겪는 것을 피하고 있다고 생각합니다.

Answer 6

"왜 포스트 아이콘, 저자의 장소, 이름 및 성을위한 태그를 포함해서는 안된다.

너는 사용한다u003Cdialog> 대화 나 의견을 설명합니다. Rant와 NSFW는 주관적인 용어이므로 사용하지 않는 것이 합리적입니다.

내가 이해 한 것에서 많은 경험이 풍부한 웹 개발자들이 HTML에서 대부분의 웹 사이트가 공통적으로 가지고있는 것을 연구하고 찾았습니다. 그들은 대부분의 웹 사이트에 ID = "헤더", id = "바닥기", id = "섹션"및 id = "nav"태그가 있음을 알았으므로 해당 ID를 대체하기 위해 HTML 태그가 필요하다고 결정했습니다. 다시 말해, 그들이 당신에게 엄청난 양의 HTML 어휘를 줄 것을 기대하지 마십시오. 가장 일반적인 필요한 HTML 태그를 해결하면서 가능한 한 단순하게 유지하십시오.

NAV 태그는 접근성을 제공하는 데 매우 중요합니다. 링크가 탐색 할 것인지 여부를 찾도록 강요하기보다는 내비게이션이 어디에 있는지 알기를 원합니다.

Answer 7

추가 태그를 추가하는 데 동의하지 않습니다. 상세한 어휘가 실제로 가져 오면 사전의 모든 단어마다 다른 태그 이름이있을 수 있습니다. 추가 태그 이름은 인간에게 추가 의미를 전달할 수 있지만 언어의 기계 구문 분석을 용이하게하기 위해 아무것도하지 않기 때문에 도움이되지 않습니다. 그렇기 때문에 HTML5의 "의미 론적"태그가 마음에 들지 않는 이유는 어휘를 너무 복잡하게 제공하는 동시에 완전히 해결되지 않은 문제에 대한 약한 솔루션을 제공하는 데 미끄러운 경사라고 생각하기 때문입니다.

내 의견으로는 마크 업 언어 구조 데이터를 트리 다이어그램 형식으로 설명하는만큼 설명합니다. 구조를 구문 분석하고 RDFA와 같은 시맨틱 컨벤션의 적절한 사용을 통해 컨텍스트를 활용하여 일반적인 태그 이름에 특정한 의미를 제공 할 수 있습니다. 예를 들어, 과도한 어휘는 존재할 필요가 없으며 바닥 글 및 따로 구조적으로 중복되는 태그 이름을 제거 할 수 있습니다. 최종 목표는 인간과 기계 모두가 동시에 해석하는 동안 콘텐츠를 더 빠르고 정확하게 해석하는 동안 가능한 한 적은 코드를 사용하여 해당 결과를 달성하는 것입니다. HTML5를 제외하고 해당 솔루션이 덜 중요합니다.

Answer 8

나는 XML이 의미론에 시맨틱을 할당하는 전략이라고 생각했다.

내가 아는 한, 그렇지 않았습니다. XML을 사용하면 XML 구문을 모두 사용하기 때문에 모두 같은 방식으로 구문 분석되는 새로운 언어를 정의 할 수 있습니다.

그 자체로는 그 언어에 의미를 추가 할 수있는 방법 ( "의미 적"을 의미 함)을 제공하는 것은 아닙니다. 그리고 컴퓨터가 인공 지능을 얻을 때까지 실제로 의미를 이해하지 못하기 때문에 의미는 인간 사이에 합의 된 것입니다. HTML은 태그의 의미가 합의 된 가장 일반적으로 사용되는 언어입니다.

HTML이 매우 일반적이므로 응용 프로그램에서 일반적으로 의미있는 몇 가지 의미있는 태그를 추가하는 것이 도움이됩니다. 새로운 HTML5 태그가 목표입니다. HTML5 사양의 저자는 실제로이 경로를 수행하여 가능한 모든 의미에 대한 태그를 만들 수 있지만 로봇이 아니기 때문에 아마 그렇지 않을 것입니다.

<section> 유용하며 많은 문서에 의미있게 적용 할 수있을만큼 일반적입니다. <author-last-name> 그렇지 않습니다. 이 둘을 구별하는 것은 판단 부름입니다. 그래서 컴퓨터가 아닌 인간은 사양을 작성합니다.

태그로 html에 추가하기에는 너무 구체적인 맞춤형 의미론의 경우 HTML5는 정의합니다. 마이크로 데이터.

Answer 9

나는 앤디 클락의 책을 읽고 있어요 CSS를 초월하다 (33페이지).

...,이제 다음과 같은 표시 이름이 널리 받아들여지고 있습니다. 머리글, 왼쪽, 또는 빨간색 요소의 모양이나 위치를 설명하는 것은 잘못된 선택입니다.

이 줄을 읽은 후 나는 스스로에게 이렇게 물었습니다.안녕하세요, HTML5 사양에 머리글, 바닥글 같은 요소가 없나요??왜 바닥글이 더 의미가 있나요?앤디는 자신의 책에서 다음과 같이 주장합니다. 사이트 정보 바닥글 div의 ID에 대한 것이며 IMHO가 더 의미가 있습니다.바닥글은 표시 이름입니다(요소의 위치를 ​​설명함).

Answer 10

한마디로, Ajax. 새로운 태그는 실제 개발자가 교체함으로써 수행하는 일을 지원하기위한 것입니다. 일부 그만큼 <div class="sidebar-wrap"><div class="styling-hook"><div><ul class="nav"> 많은 웹 사이트가 겪고있는 divitis의 유형. 유일한 <div> HTML5에 왼쪽에는 스타일링 후크가 있습니다.

클래스의 태그로 홍보되는 의미는 XHTML/CSS 채택 기간이 연장 된 경우 개발자가 모범 사례로 자유롭게 채택한 의미입니다. Spec 's Sections 페이지의 Whatwg Developer's Edition을 확인하십시오.여기. 문서 자체는 즐거움이지만 아직 보지 못했다면 망치지 않을 것입니다.

W3C가 내린 일부 결정에 대한 명백한 이유 중 하나는 WebKit의 중요성입니다. 당신이 보면, 당신은 그들이 HTML5 실무 그룹의 현재 작업을 수행하고 아이디어를 구현하는 것보다 더 낫다는 것을 알 수 있습니다. 그들은 역사적으로 규정 준수에 앞서 나갔다 (여기를 봐). W3C는 (예 : Android, iPhone, Googlebot, Chrome, Safari, Dreamweaver 등)에서 우선 순위가 높았습니다. Google, 프레임 워크 사용자, WordPress/이동식 유형/Joomla! 유형의 사용자와 다른 사람들은 자체 포함 된 빌딩 블록을 원했기 때문에 이것이 우리가 얻는 스타일입니다.

Facebook은 모듈 식입니다. 반응 형 디자인의 그리드는 모듈 식입니다. WordPress는 모듈 식입니다. Ajax는 모듈 식 페이지 구조에서 가장 잘 작동합니다. 위젯은 모듈입니다. 플러그인은 모듈입니다. 적절한 요소를 더 쉽게 연결하고 문서/응용 프로그램/정보 네트워크 하이브리드 웹 2.0에서 활성화 할 수 있도록 이러한 태그를 적용하는 방법과 같은 것들을 알아 내려고 노력해야 할 것 같습니다.

마감시, HTML5는 문서의 일부에 대한 AJAX 요청을하는 도구와 기계가 잘 형성된 유용한 응답을 얻을 수 있도록 XML (사양을 참조)으로 작성해야합니다. 피드 리더, 점자 프린터, 주석기 등과 같은 장치의 미디어 쿼리와 같은 것들과 함께 얼마나 멋진 지. 나는 좋은 의미 론적 콘텐츠가있는 것이 자신의 뉴스 피드 인 것이 자동으로 (가까운) 미래를 본다! 개발자가 준수 문서를 채택하고 작성하는 경우에만 발생합니다.