이 문서에 포함된 모드 전환은 Firefox 및 기타 Gecko 기반 브라우저, Safari, Chrome 및 기타 Webkit 기반 브라우저, Opera, Konqueror, Mac용 Internet Explorer, Windows용 Internet Explorer 및 임베디드 IE 브라우저에 적용됩니다. 브라우저 엔진의 이름을 언급하는 것을 피하고 대신 해당 엔진을 사용하는 가장 잘 알려진 브라우저의 이름을 언급하세요.
이 문서에서는 각 모드의 정확한 동작을 문서화하기보다는 모드 선택 메커니즘에 중점을 둡니다.
다양한 모드는 다음과 같습니다.
text/html 콘텐츠에 대한 모드 선택은 문서 유형 스니핑에 따라 다릅니다(이 문서 뒷부분에서 설명). IE8에서는 모드가 다른 요인에 따라 달라집니다. 그러나 IE8에서는 기본적으로 Microsoft 블랙리스트에 없는 비인트라넷 사이트의 모드가 문서 유형에 따라 다릅니다.
이 글에서 동일하게 다루더라도 모드의 정확한 동작은 브라우저마다 다르다는 점은 아무리 강조해도 지나치지 않습니다.
Firefox, Safari, Chrome 및 Opera에서 application/xhtml xml HTTP 콘텐츠 유형(메타 요소나 doctype이 아님!)은 XML 모드를 트리거합니다. XML 모드에서 브라우저는 브라우저에 지정된 범위까지 XML 문서 사양에 맞는 올바른 처리를 제공하려고 시도합니다.
IE6, 7, 8은 application/xhtml xml을 지원하지 않으며 Mac IE5도 지원하지 않습니다.
WebKit 기반 Nokia S60 브라우저에서는 application/xhtml xml HTTP 콘텐츠 유형이 XML 모드를 트리거할 수 없습니다. 모바일 월드 가든의 초점은 비표준 콘텐츠와의 호환성이기 때문입니다. (이전 '모바일 브라우저'는 비정규 콘텐츠가 XML로 태그되어 있기 때문에 실제 XML 파서를 사용할 수 없습니다.)
Konqueror를 충분히 테스트하지 않았기 때문에 이 브라우저에서 어떤 일이 일어날지 정확히 말할 수 없습니다.
일부 엔진에는 웹 콘텐츠와 관련이 없는 모드가 있습니다. 완전성을 위해 여기서만 언급됩니다. Opera에는 WML2.0 모드가 있습니다. Leopard의 WebKit에는 레거시 대시보드 위젯을 위한 특정 모드가 있습니다.
이러한 패턴의 주요 영향은 다음과 같습니다.
text/html 모드는 주로 CSS 레이아웃에 영향을 미칩니다. 예를 들어, 테이블이 스타일을 상속하지 않는다는 것은 특이한 일입니다. 일부 브라우저 특수 모드에서는 상자 모델이 IE5.5 상자 모델이 됩니다. 이 문서에는 모든 레이아웃 문제가 나열되어 있지 않습니다.
준표준 모드(이 모드를 지원하는 브라우저)에서는 이미지가 포함된 테이블 셀의 높이만 표준 모드와 다릅니다.
XML 모드에서 선택기는 대소문자를 구분하는 동작이 다릅니다. 또한 HTML 본문 요소에 대한 특정 규칙은 최신 CSS 2.1 변경 사항을 구현하지 않는 이전 브라우저에는 적용되지 않습니다.
HTML 및 CSS 구문 분석에 영향을 주어 표준을 준수하는 웹페이지가 잘못 구문 분석될 수 있는 문제도 있습니다. Quirk 레이아웃은 이러한 Quirk의 활성화 여부를 결정합니다. 그럼에도 불구하고 CSS 레이아웃 및 구문 분석(HTML 구문 분석 아님)에서 Quirks 모드와 표준 모드 간의 주요 유사점과 차이점을 이해하는 것이 중요합니다.
일부 사람들은 표준 모드를 "엄격한 구문 분석 모드"로 잘못 언급합니다. 이는 HTML 구문 규칙을 적용하는 브라우저의 기능과 마크업의 정확성을 평가하는 브라우저의 기능을 오해하는 것입니다. 이것은 사실이 아닙니다. 표준 모드 레이아웃이 적용되는 경우에도 브라우저는 여전히 태그 수프(http://en.wikipedia.org/wiki/Tag_soup) 수정 작업을 수행합니다. (2000년 Netscape 6이 출시되기 전에 Mozilla에는 HTML 구문 규칙을 적용하기 위한 구문 분석 모드가 있었습니다. 이러한 모드는 기존 웹 콘텐츠와 호환되지 않아 폐기되었습니다.)
또 다른 일반적인 오해는 XHTML 구문 분석에 관한 것입니다. 일반적으로 XHTML 문서 유형을 사용하면 다른 구문 분석이 발생한다고 믿어집니다. 실제로는 그렇지 않습니다. 콘텐츠 유형이 text/html인 XHTML 문서는 HTML 문서와 동일한 파서를 사용합니다. 현재 모든 브라우저는 문서 유형이 text/html인 XHTML이 단지 "크루톤이 포함된 태그 수프"(어디에나 추가 슬래시가 있음)라는 점에 관심을 갖고 있습니다.
XML 문서 유형(예: application/xhtml xml 또는 xmapplication/)을 사용하는 문서가 구문 분석을 위해 XML 모드를 트리거하는 경우에만 이 시점의 구문 분석기는 HTML 구문 분석기와 완전히 다릅니다.
Quirks Mode는 주로 CSS에 관한 것이지만 스크립팅에 관한 것도 약간 있습니다. 예를 들어 Firefox의 특수 모드에서 HTML id 속성은 IE에서와 마찬가지로 전역 스크립트 범위 개체 참조를 설정합니다. IE8의 스크립팅이 미치는 영향은 다른 브라우저보다 더 많은 관심을 받을 가치가 있습니다.
XML 모드에서 일부 DOM API의 동작은 완전히 다릅니다. 왜냐하면 XML DOM API의 동작은 정의된 HTML의 동작과 호환되지 않기 때문입니다.
최신 브라우저는 문서 유형 스니핑을 사용하여 text/html 문서의 엔진 모드를 결정합니다. 이는 모드 선택이 HTML 문서 시작 부분의 문서 유형 선언(또는 선언 부족)을 기반으로 함을 의미합니다. (XML 문서 유형을 사용하는 문서에는 적용되지 않습니다.)
문서 유형 선언(doctype)은 SGML의 문법적 위조입니다. SGML은 구식 마크업 프레임워크이며 HTML5 이전의 HTML은 이를 기반으로 정의되었습니다. HTML4.01 사양에서 문서 유형 선언은 HTML의 버전 정보를 기술합니다. "문서 유형 선언"이라는 이름과 "버전 정보"를 설명하는 HTML 4.01 사양에도 불구하고 문서 유형 선언은 (이름 때문에) SGML 또는 XML 문서를 특정 유형의 문서로 분류하지 않습니다. . (자세한 내용은 부록에서)
HTML4.01 사양이나 ISO 8879(SGML) 모두 문서 유형 선언을 엔진 모드 변환으로 사용하는 것에 대해 언급하지 않습니다. Doctype 스니핑은 Doctype 스니핑이 설계되었을 당시 대부분의 기발한 문서에는 문서 유형 선언도 없고 이전 DTD에 대한 참조도 없다는 관찰을 기반으로 합니다. HTML5는 이 사실을 받아들이고 text/html의 doctype을 유일한 모드 변환으로 정의합니다.
일반적인 HTML5 이전 문서 유형 선언에는 "". 문서 유형 선언은 문서 루트 요소의 여는 태그 앞에 배치됩니다.
다음은 새 텍스트/html 문서를 만들 때 문서 유형을 선택하는 방법에 대한 간단한 가이드입니다.
text/html로 사용되는 XHTML은 유해한 것으로 간주되기 때문에 어떤 XHTML 문서 유형도 권장하지 않습니다. 그럼에도 불구하고 XHTML doctype을 사용하기로 선택한 경우 XML 선언이 IE6(IE7은 아님)에서 쿼크 모드를 트리거한다는 점에 유의하세요.
application/xhtml xml에 대한 간단한 지침은 doctype을 절대 사용하지 않는 것입니다. 이런 방식의 웹 페이지는 XHMTL 1.0과 "완전히 일관성"이 없지만 이는 중요하지 않습니다. (뒷면 부록을 참고하세요)
A List Apart는 doctype 외에도 IE8이 모드 선택 요소 중 하나로 메타 요소 기반의 모드 변환을 사용할 것이라고 소개한 적이 있습니다. (Ian Hickson, David Baron, David Baron again, Robert O'Callahan 및 Maciej Stachowiak 댓글 참조 .)
IE8에는 IE5.5 쿼크 모드, IE7 표준 모드, IE8 준표준 모드, IE8 표준 모드의 4가지 모드가 있습니다. 모드 선택은 문서 유형, 메타 요소, HTTP 헤더, Microsoft의 정기적인 다운로드 데이터, LAN 도메인, 사용자 설정, LAN 관리자가 설정한 설정, 상위 프레임 모드(해당하는 경우) 등 여러 소스의 데이터에 따라 달라집니다. 모두) 사용자가 트리거하는 주소 표시줄 보기 버튼과 호환됩니다. (엔진에 내장된 다른 앱의 경우 내장된 앱에 따라 모드도 달라집니다.)
다행히 IE8은 일반적으로 다음과 같은 경우 다른 브라우저처럼 문서 유형 스니핑을 사용합니다.
위의 X-UA-Compatible과 관련된 두 가지 경우를 제외하면 IE8은 IE7과 마찬가지로 문서 유형 스니핑을 수행합니다. IE7 에뮬레이션을 호환성 보기라고 합니다.
X-UA-Compatible의 경우 IE8은 다른 브라우저와 완전히 다르게 동작합니다. 이 페이지에서 부록이나 PDF, PNG 형식의 흐름도를 보고 싶습니다.
안타깝게도 X-UA 호환 HTTP 헤더나 메타 태그가 없으면 적절한 doctype이 있어도 IE8에서는 사용자가 실수로 IE8의 표준 모드에서 에뮬레이션 IE7 표준 모드인 IE7 모드로 페이지를 다운그레이드할 수 있습니다. 더 나쁜 것은 LAN 관리자도 이 작업을 수행할 수 있다는 것입니다. Microsoft는 귀하가 사용하는 모든 도메인 이름을 블랙리스트에 추가할 수도 있습니다.
이러한 효과를 처리하려면 doctype만으로는 충분하지 않으며 X-UA 호환 HTTP 헤더와 메타 태그가 필요합니다.
다음은 다른 브라우저에서 표준 모드 또는 준표준 모드를 트리거하는 문서 유형이 이미 있는 새 text/html 문서에 대해 X-UA 호환 HTTP 헤더 또는 메타 태그를 선택하는 방법에 대한 간단한 가이드입니다.
Doctype 스니핑은 태그 차우더 문제를 해결하기 위한 태그 차우더와 유사한 접근 방식입니다. Doctype 스니핑은 작성자가 예상한 동작을 준수하는 문서와 오래된 문서를 구별하는 HTML4 및 CSS2 사양 출시 이후에 설계된 경험적 방법입니다.
가끔 XML에서 문서 유형 스니핑을 사용하여 다양한 처리 일정을 예약하고 사용 중인 어휘를 식별하거나 기능을 활성화하는 것이 좋습니다. 이것은 나쁜 생각입니다. 예약 및 어휘 식별은 네임스페이스를 기반으로 해야 하며 기능 활성화는 명시적인 처리 지침이나 요소를 기반으로 해야 합니다.
잘 구성된 형식의 전체 아이디어는 DTD 없는 XML 구문 분석을 도입하고 문서 유형 없는 문서를 장려하는 것입니다. 두 개의 XML 문서가 동일한 표준 형식을 갖고 애플리케이션이 이를 다르게 처리하는 공식적인 경우(차이는 외부 엔터티를 처리할 선택의 부족으로 인한 것이 아님) 애플리케이션이 손상될 수 있습니다. 실제로 두 개의 XML 문서로 인해 동일한 콘텐츠가 SAX2
콘텐츠 핸들러에 보고되고(qnames 무시) 애플리케이션이 문서를 다르게 처리하는 경우 애플리케이션이 손상될 수 있습니다. 웹 작성자로서 모든 사람이 자신의 페이지를 구문 분석하기 위해 추가 엔터티를 확인하는 XML 프로세서를 사용할 것이라는 점을 신뢰할 수 없다는 점을 고려하면(일부 브라우저는 특정 공개 식별자를 잘린 엔터티 정의 DTD에 매핑하기 때문에 그렇게 하는 것처럼 보이지만), 삽입 웹용 XML에 대한 문서 유형은 무의미하며 종종 화물 문화 습관으로 이어집니다. (W3C 유효성 검사기에서는 결과가 일시적으로만 유효하다고 말하지만 여전히 W3C 유효성 검사기의 DTD 재정의 기능을 사용하여 DTD를 유효성 검사합니다. 또는 더 나은 방법은 유효성 검사 를 사용하여 NG를 완화할 수 있다는 것입니다. 이는 스키마에서 참조하는 문서를 오염시키지 않습니다. ) 스니핑을 위해 문서 유형을 요구하는 것은 HTML 실행의 해결 방법이라 할지라도 매우 어리석은 일입니다. 또한 하위 사양이 두 가지를 동일하게 정의하는 경우 상위 사양에서는 서로 다른 의미를 부여하려고 해서는 안 됩니다. . 공개 식별자를 제거해도 동일한 DTD가 계속 지정되므로 doctype 은 이전 doctype과 같은 의미입니다. 냄새를 다르게 맡아야 할까요? 더 이론화할 수 있습니다. foobar.dtd라는 DTD가 example.com에 복사되었다고 가정합니다: . 이것을 냄새 맡는 방법? 같은 의미여야 합니다. 전체 DTD도 문서에 첨부할 수 있습니다. 즉, #include "foo.h"가 있는 경우 foo.h라는 이름에 어떤 흑마술도 묶어서는 안 됩니다. foo.h의 내용을 문서에 복사하거나 foo를 복사할 수 있어야 하기 때문입니다. h를 bar.h에 넣고 #include "bar.h"를 의미합니다. HTML과 SGML이 동일한 매개변수를 구성하는 것에 대해 걱정하지 않는 이유는 웹 브라우저가 HTML을 구문 분석하는 데 실제 SGML 파서를 사용하지 않기 때문입니다. 따라서 SGML인 척하는 것은 유용하지 않다고 생각합니다. 어쨌든, 아직 확신하지 못하신다면 여기 W. Eliot Kimber의 comp.text.sgml 아래 표에서 쿼크 모드, 표준 모드, 준표준은 각각 Q, S, A로 표시됩니다. 브라우저에 두 가지 모드만 있는 경우, 테이블 셀의 행 높이가 Mozilla의 표준 모드와 일치하면 표준 모드는 "S"로 표시됩니다. 테이블 셀의 행 높이가 Mozilla의 준표준 모드와 일치하면, 그런 다음 "A"로 표시됩니다. XML 콘텐츠 모델을 사용하여 제공되는 XHTML은 XML 모드로 렌더링됩니다. 이 표의 목적은 표의 모든 문서 유형이 새 페이지에 대한 합리적인 선택이라고 말하는 것이 아닙니다. 이 표의 목적은 내 권장 사항이 어떤 데이터를 기반으로 하는지 표시하는 것입니다. 열 헤더에는 다음 약어 기호가 사용됩니다. 부록: text/html에서 일부 문서 유형을 처리하는 방법
Moziila의 문서 유형 스니핑 코드는 2000년 10월, 2001년 9월, 2002년 6월에 크게 수정되었습니다. 이 문서에 설명된 Mozilla(및 Netscape 6.x) 빌드의 상태는 2000년 10월 19일 현재 ftp.mozilla.org에서 볼 수 있습니다. 이 문서에서는 Mozilla M18(및 Netscape 6.0 PR3)에서 문서 유형 스니핑이 작동하는 방식을 다루지 않습니다. Safari의 문서 유형 스니핑 코드도 첫 번째 공개 베타 버전 이후 크게 수정되었습니다. 이 문서에서는 0.9라고도 불리는 V73 이전 버전의 동작을 다루지 않습니다.
Konqueror 3.5 이전의 doctype 스니핑 코드는 Safari 초기 버전에서 나온 것 같습니다. Konqueror는 이제 Safari와 일치하며 문서 유형 스니핑 코드는 Mozilla에서 제공됩니다.
표에서 볼 수 있듯이 Opera의 문서 유형 스니핑은 IE와 유사한 것에서 Mozilla와 유사한 것으로 정기적으로 바뀌고 있지만 Opera 9.5와 9.6은 다시 돌아오는 중입니다. 동시에 Opera의 쿼크 모드 레이아웃 동작은 IE6의 쿼크 모드 에뮬레이션에서 Mozilla의 쿼크 모드로 전환되었습니다.
형식의 순서도로 볼 수 있습니다. 감사합니다 다양한 오페라 버전의 패턴 시트를 수정하는 데 도움을 주고 의견을 주신 Simon Pieters, Simon Pieters 및 Anne van Kesteren에게 감사드립니다. 또 다른 IE8 순서도를 만들어 주신 Simon Pieters에게 감사드립니다.
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
