HTML에 대해 엄격한 구문 분석이 선택되지 않은 이유는 무엇입니까?

HTML을 만들 때 왜 엄격한 구문 분석이 선택되지 않았는지 궁금합니다. 대부분의 인터넷 기록에서 브라우저는 모든 종류의 마크 업을 허용했으며이를 분석하기 위해 최선을 다했습니다. 이 프로세스는 성능을 저하시키고 사람들이 횡설수설을 할 수있게하며 쓸모없는 기능을 중단하는 것을 어렵게 만듭니다.

HTML이 엄격하게 구문 분석되지 않는 특별한 이유가 있습니까?

그 이유는 간단합니다. 첫 번째 그래픽 브라우저 인 NCSA Mosiac 및 이후 Netscape Navigator는 거의 모든 HTML을 직접 작성했습니다. 브라우저 제작자 (넷스케이프는 전직 모사 사람들에 의해 만들어졌다)는 잘못된 HTML 렌더링을 거부하면 사용자가 자신에 대해 반대한다는 점을 빨리 인식했습니다 !

브라우저 제작자의 관점에서 최상의 추측을하는 것이 옳은 일이기 때문입니다. 상황을 고려하십시오. 이상적으로는 수신하는 HTML이 완전히 정확하고 사양에 맞습니다. 훌륭합니다. 그러나 흥미로운 부분은 HTML이 올바르지 않을 때 발생하는 것입니다 . 우리가 아무런 영향을 미치지 않는 출처의 정보를 다루고 있기 때문에 실제로 준비해야합니다. 이제 그런 일이 생기면 어떻게해야합니까? a) 실패와 b) 오류를 복구하기 위해 최선의 노력을 다합니다. 우리가 실패하면, 사용자에게는 쓸모없는 오류 메시지 만있을뿐 서버를 제어하지 않기 때문에 할 수있는 일은 없습니다. 최선을 다한다면 사용자는 적어도 페이지에서 만들 수있는 것을 가지고 있으며 종종 추측이 맞습니다.

이 문제의 유일한 문제 는 일반적으로 개발 상황에있는 오류 메시지 가 필요할 때입니다. 생성하는 HTML이 올바른지 확인하고 "브라우저 X에서 작동"이 "올바른"과 같지 않기 때문에, 우리는 단순히 브라우저를 통해 실행할 수 없으며 작동하는지 확인할 수 없습니다. 브라우저에서 수정 한 올바른 HTML과 잘못된 HTML의 차이점을 알 수 없습니다. 이것은 해결할 수있는 문제입니다. 표준 위반을보고하는 브라우저 플러그인, W3C 유효성 검사기 및 기타 여러 유사한 도구가 있습니다.

HTML 작성자 및 제작 도구는 엉터리 마크 업을 생성합니다. 브라우저는 경쟁적인 이유로 최선을 다합니다. 대부분의 웹 페이지를 합리적인 방식으로 렌더링하지 못하는 브라우저는 사용자의 결함에 대해 신경 쓰지 않는 사용자가 거부합니다.

프로그래밍 언어 구현과는 다릅니다. 컴파일러와 통역사는 프로그래머가 작성할 수있는 코드로 작업하는 반면, 모든 사람과 그의 형제는 최소한의 교육만으로 또는 HTML없이 작성할 수 있습니다. HTML 마크 업은 어떤 의미에서 코드이지만 프로그래밍 언어 명령이 아닌 데이터이며 소프트웨어의 (전통적인) 전통은 데이터에 관대해야합니다.

XHTML은 원칙적으로 엄격한 (XML) 구문 분석 규칙을 적용하여 XML 컨텐츠 유형과 함께 제공되는 XHTML 문서가 XML 형식으로 잘 구성된 경우에만 표시됩니다. 그렇지 않으면 첫 번째 오류 만 사용자에게 전달됩니다. 이것은 웹 저작에서 인기를 얻지 못했습니다. 거의 모든“XHTML”은 텍스트 / html로 제공되며 새로운 편심으로 아주 자유로운 방식으로 전통적인 태그 수프로 처리됩니다.

HTML은 문서 및 매뉴얼 등에 자주 사용되는 SGML이라는 다른 하이퍼 링크되지 않은 마크 업 언어를 기반으로한다는 점이 부족합니다.

HTML의 역사에 관한 기사 에서 :

팀이 초기 HTML 문서의 일부는 CERN이 이미 사용되었다 오래된 SGML 언어를 기반으로하고 있음을 언급했다 : - 우리는 HTML에 포함 된 한 SGML 태그 세트에서 일부 태그에서 사용하면이 CERN에서 지원 [...] html로 파서 이해할 수없는 태그는 무시하고 CERN-SGML 태그에 대해 이해하지 못하는 속성은 무시합니다 .

[...] 대부분의 초기 HTML 태그는 실제로 CERN SGMLGuid 언어에서 가져 왔습니다.이 언어 자체는 AAP (초기 SGML 언어)의 변형이었습니다. 예를 들어 title, hn, p, ol 등은 모두이 언어에서 가져온 것입니다. 유일한 근본적인 변화는 모든 중요한 앵커 () 링크를 추가하는 것이었고, WWW는 이륙하지 않았습니다.

내가 굵게 표시된 부분을 주목하면서, 기본적으로 그들은 익숙한 SGML 시스템에서 사용할 수있는 태그 의 하위 세트 를 구현 하고 새로운 앵커 <a> 태그를 추가하고 그들이 가지고 있던 많은 태그를 무시하도록 선택했습니다. 참고 문헌 목록의 태그, "예"의 경우 xmp, 텍스트 블록 주위에 상자를 그리는 "상자"태그 등의 이유로 이유를 신경 쓰거나 지원하지 않습니다. 따라서 가장 간단한 방법은 파서에서 알려지지 않은 마크 업을 용서하고 원인이 사용자 유형이 나쁜 마크 업인지 또는 기존 문서를 이 새로운 HTML 형식은 기존 SGML 문서에 일부 하이퍼 링크를 추가하고 지원되지 않거나 구현되지 않은 태그를 무시하는 것입니다.

이것은 부분적으로 브라우저 전쟁의 역사적인 잔재입니다.

IE와 넷스케이프는 시장을 점령하기 위해 경쟁하고 점점 더 "굉장한"상태를 유지하고 다른 브라우저 용으로 설계된 페이지를 수용해야하는 새로운 기능을 계속 출시했습니다.

위원회가 관여 시작 후 브라우저를 받아 자동으로 알 수없는 태그를 무시한다는이 수단은 ... 잘 당신은이 위원회 설계 물건을 그 결과로 브라우저의 대부분을 지원하고자 (일부 모호하게 표현 된 사양과) 다른 버전의 많은 각 버전마다 별도의 파서를 작성하면 막대한 팽창이 발생합니다. 따라서 다른 모드에서 단일 파서를 사용하는 것이 상대적으로 쉽습니다.

또 다른 부분으로 netscape와 IE는 일반적인 사람이 HTML에 액세스 할 수 있기를 원했습니다 (그 당시 유행과 마찬가지로).

문제를 더 악화시키는 것은 잘못된 것을 가르치고 그들이 가르치는 것이 일을한다고해서 그들이 옳다고 생각하는 몇몇 "자습서"사이트가 있다는 것입니다.

궁극적으로 이는 이제 사이트의 99 %를 구문 분석하는 엄격한 html만으로 브라우저를 만들면 작동하지 않습니다.

우리는 000에서 좋은 엄격한 옵션을 설정하려고 시도했지만 "모범 사례"를 맹목적으로 따르는 사람들이 맹목적으로 잘못된 마크 업이 엄격한 모드에서 조각으로 이동했을 때 브라우저를 비난했기 때문에 팬 아웃되지 않았습니다. 브라우저 공급 업체는 비난을 좋아하지 않았습니다.

그들은 전문가가 아닌 사람들이 웹에보다 쉽게 ​​액세스 할 수 있기를 원했지만 HTML 4를 가장 관대 한 형태로 사용하는 것을 중단 한 사람은 아무도 없었습니다.

즉, 엄격한 스타일 레이아웃을 원한다면 여전히 HTML5를 XML로 제공 할 수 있습니다. IMO 그것은 실제 위험없이 엄격하거나 원하지 않는 다른 사람들에게 넘겨주기 전에 엄격한 모드에서 레이아웃이나 UI 작업을 수행하는 것의 이점을 얻는 좋은 방법이 될 수 있습니다 (doctype을 제거하는 것을 금지합니다) 그들은 실제로 쿼크 모드를 선호합니다-2017 년 (이 편집 시간) 촬영해야합니다. 그래서 기본적으로 여전히 있지만 약간의 연구를하십시오 .XHTML에는 없었던 몇 가지주의 사항이 있다는 것을 기억합니다. 레이아웃 작업에 실제로 영향을 미칩니다. "올바르게 할 수있는 유일한 방법"이라는 말을 퍼뜨 리거나 그러한 종류의 대화에 참여하는 사람들이 아이디어를 약화시키고 브라우저를 다시 비난 할 수 있습니다. 우리가 남긴 유일한 엄격한 대안 중 (2017 편집 :

http://mathiasbynens.be/notes/xhtml5