XHTML5는 어떻게 되었습니까?

http://www.w3.org/TR/html5/

이 페이지는 xhtml5와 html5 모두에 대한 초안입니까? 그래서이 doctype들 사이에 차이가 없습니까?

2012 년 에 W3C가 HTML 5를 위해 XHTML을 포기하기로 결정한 것이 분명했습니다.

• XHTML에 관심이있는 사람은 거의 없었습니다. 대부분의 웹 사이트는 일반 HTML로 작성되었습니다.

• XHTML이 무엇인지, 어떻게 사용하는지 이해하는 사람은 거의 없습니다. XHTML을 제공하는 것처럼 보이는 웹 사이트가 너무 많아 잘못된 헤더를 사용했습니다 Content-Type: application/xhtml+xml.

• XHTML이 무엇인지, 헤더가 무엇인지 완전히 이해하더라도 application/xhtml+xml콘텐츠 유형을 허용하거나 지원하지 않는 일부 엉터리 브라우저에서는 문제가 발생 합니다. 이것은 브라우저에 따라 헤더를 변경해야 함을 의미했습니다.

• XHTML의 XML 부분은 또한 개발자가 해결해야 할 이상한 상황을 야기했습니다. 하나는 INVALID_STATE_ERR: DOM Exception 11HTML 문자 (예 :)가 포함 된 텍스트를 éXHTML 페이지 내의 요소에 할당 할 때 나타나는 메시지 입니다. AJAX 요청을 한 후 대형 웹 응용 프로그램에서 매우 유용한 메시지와 함께이 오류가 발생하면 JQuery, AJAX 또는 기타의 결함인지 전혀 알 수 없습니다.

• HTML 5 코드를 작성한다고해서 모든 태그를 섞는 것은 아닙니다. XML과 XHTML에 대해 열정이 있다면 여전히 XML에 매우 가까운 HTML 5 코드를 작성할 수 있습니다.

• 휴대폰 초기에 XHTML은 그다지 강력하지 않은 모바일 장치에 흥미로 웠습니다. XML 구문 분석은 HTML보다 훨씬 쉽습니다. 이제 듀얼 코어 모바일 장치를 사용하면 깨끗하고 유효한 XML 또는 더러운 HTML로 가득 찬 해킹과 혼합 태그를 구문 분석해야하는지 여부는 중요하지 않습니다.

2014 년 10 월 사양 에는 XHTML 구문이 언급되어 있습니다 . 현재로서는 새로운 XHTML 언어 ( 구문 아님)와 같은 것이 있는지, 그리고 존재한다면, XHTML의 위치는 무엇이고, 주류 브라우저가 새로운 XHTML 표준을 채택 할 것인지는 확실하지 않습니다 .

XHTML5 는 "XML5 serialize as XML"의 동의어입니다.

이 추상 언어를 사용하는 리소스를 전송하는 데 사용할 수있는 구체적인 구문이 다양하며이 중 두 가지가이 사양에 정의되어 있습니다.

...

두 번째 구체적인 구문은 XML의 응용 프로그램 인 XHTML 구문입니다. application / xhtml + xml과 같은 XML MIME 유형으로 문서를 전송하면 웹 브라우저에서 XML 프로세서로 구문 분석하기 위해 XML 문서로 처리됩니다. 저자는 XML과 HTML의 처리가 다르다는 것을 상기시킨다. 특히, 사소한 구문 오류조차도 XML로 레이블이 지정된 문서가 완전히 렌더링되는 것을 방지하지만 HTML 구문에서는 무시됩니다. 이 사양은 "XHTML 5"로 알려진 XHTML 구문의 버전 5.0을 정의합니다.

• http://www.w3.org/TR/html5/introduction.html#html-vs-xhtml 에서 인용 ; "이 섹션은 비표준입니다."라고 표시되어 있습니다.

또한 HTML5 폴리 글 로트 (일반 HTML5 및 XML로 직렬화 할 수있는 페이지)를 작성하는 데 유용한 문서가 있습니다.

http://dev.w3.org/html5/html-polyglot/html-polyglot.html#bib-HTML5

그리고 유효성 검사기조차도!

http://html5.validator.nu/

요즘 XHTML5라고 불리는 경우는 드물다. 기본적으로 여전히 HTML5이기 때문에 여전히 거의 사용되지 않는다.

간단히 말해 : HTML5 사양에 대한 모든 변경 사항은 XHTML5에 대한 암시 적 변경 사항이기도합니다.

HTML5는이다 사실상 및 법률 상의 표준! XHTML도 표준으로 존재합니다.

HTML5-HTML 및 XHTML 용 어휘 및 관련 API

W3C 권장 사항 2014 년 10 월 28 일

표준의 제목에는 "and XHTML" 이라는 문자열이 포함되어 있으므로 HTML과 XHTML을 하나의 단일 표준으로 병합 하기 위한 W3C의 최종 결정에 대해 이야기하고 있습니다 . 이 표준은 HTML 파일을 XHTML 파일로 직렬화하는 방법을 보여줍니다.

XHTML 부품 및 중요 사항 :

• MIME 유형은 application/xhtml+xml
• 2.2.4. XPath 및 XSLT와의 상호 작용
• 9. XHTML 구문

이해하고 사용하기

LF 시코 스에 의해 요약 된 대로

XHTML5는 HTML5의 XML 직렬화입니다. 구문은 HTML5 사양에 설명되어 있습니다. 그러나 XHTML5는 XML의 응용 프로그램이므로 혼동해서는 안됩니다. 다시 말해, HTML5와 XHTML5는 어휘는 동일하지만 구문 분석 규칙이 다릅니다.

HTML5 문서는 유효한 XML 문서 일 수도 있습니다. 이 마크 업은 종종 "폴리 글 로트"언어라고합니다. HTML5 및 XML 문서 인 문서의 겹치는 언어입니다. HTML5 및 XHTML5 직렬화는 상호 호환됩니다. 그러나 XHTML5는보다 엄격한 구문을 가지고 있습니다. 또한 XHTML5의 일부 부분 (예 : 처리 명령)은 HTML5에서 유효하지 않습니다.

그래서, 엄밀히 말하면 (그리고 @vaxquis 강조) "XHTML은 XML 직렬화 단지 구문입니다", 없다 어떤 DTD 또는 XML 스키마의 다른 종류 .

어떤 사람들은 "XHTML5는 XHTML"이라고 말하고 싶지 않습니다. 질문은 "XHTML로 사용할 수있는 경우"에 대한 미니 FAQ로 나누어 져야합니다. 이것은 위키입니다. "오해"가 있으면 수정하십시오 ...

자주하는 질문

XHTML5를 "2014 버전의 XHTML 표준"으로 사용할 수 있습니까?

"완벽하고 일반적인 HTML5-XHTML5 / XHTML5-to-HTML5 변환"에는 몇 가지 문제가 있으므로 "개인 선택"을 수행하고 정보를 잃어야합니다. 상황에 따라 다른 답변이 될 것입니다.

• 느슨한 말하기 : 예. 매핑이 완벽하고 가역적 인 많은 (간단한) 예가 있습니다.

• 엄밀히 말하면 : NO. 아래 @vaxquis 의견 과이 페이지의 이전 답변을 참조하십시오. 몇 가지 일반적인 문제 :

  • https://stackoverflow.com/a/16591582/287948
  • ... 더 많은 예제로 강화하십시오 ...

XSLT, XPath 등으로 XHTML5 직렬화를 사용할 수 있습니까?

그래 넌 할수있어. 조각을 직렬화하는 것조차도.

XHTML5의 유효성을 검사 할 수 있습니까?

네,하지만 너무 빨리하고 이전 DTD의보다 쉬운 일이 아닙니다 ... 같은 복잡한 유효성 검사기를 참조 validator.nu

XSLT 체인에서 XHTML5를 터미널이 아닌 출력으로 사용할 수 있습니까?

그래 넌 할수있어. 무엇을 할 수 있는지 설명해 봅시다.

Cocoon 과 같은 일부 프레임 워크 는 " XSLT 체인 "을 사용합니다. HTML5 및 XHTML5 출력은 "체인의 마지막 출력"으로 사용할 수 있습니다 ... 물론 중간 단계에서는 HTML이 아니기 때문에 HTML5를 사용할 수 없지만 XHTML5를 사용할 수 있습니다.

위의 유효성 검사 문제가 여기에 다시 나타납니다. 강력한 규칙이 없으므로 때때로 "XHTML 표준 구조"의 명확성 이 떨어 집니다. 그러한 상황에서는 "자체 협약"에주의를 기울이고 일관성을 유지해야합니다.

HTML5 페이지의 DOMDocument를 사용할 때 saveXML()메소드를 사용할 수 있습니까?

예. 직렬화 권장 사항이 사용되는 일반적인 상황입니다. XML은 유효하며 XHTML5 코드는 원래 HTML5 및 DOM 상태에서 매핑됩니다. 그러나 일부 구조에서는 위에서 언급 한대로 일부 정보가 손실 될 수 있습니다.

네 불행히도 XHTML은 사라졌습니다.

MainMa의 훌륭한 답변에 1 가지 이유 추가 :

XHTML은 웹 브라우저에서 비 브라우저 소프트웨어에서 이해할 수 있고 태그 수프 HTML 파서가없는 구조화 된 컨텐츠를 제공하는 데 사용되었습니다. ScreenReaders의 경우 XHTML은 여전히 ​​훌륭하지만 다른 종류의 소프트웨어의 경우 WebServices가 그 요구에 적합하며 주로 XML 또는 JSON을 사용합니다. SOAP 자체에는 XHTML보다 간단하고 작업 지향적 인 자체 XML 스키마가 있습니다.

내가 아는 한, 세계에는 브라우저와 다른 클라이언트 모두에게 동일한 HTTP 메시지를 제공하는 WebApp이 하나도 없습니다. 클라이언트의 선호도에 따라 여러 컨텐츠 유형에서 컨텐츠 의 동일한 표시 를 제공하기위한 REST 아키텍처도 XHTML / 피드 브라우저를 제공하는 데 사용되지 않습니다.

예를 들어 Java EE에서 Eclipse를 사용하여 Servlets + JSP를 보유한 고유 한 war 파일을 배치하여 HTML을 제공하고 Axis2와 함께 웹 서비스를 제공 할 수 있습니다. 브라우저와 웹 서비스를 대상으로하는 소프트웨어를 모두 제공하는 독특하고 복잡한 소프트웨어를 개발하는 것보다 브라우저와 웹 서비스를위한 별도의 소프트웨어를 개발하는 것이 더 쉽습니다.

REST가 거부되는 주된 이유는 모든 유형의 클라이언트에 대해 동일한 정보를 제공하는 서버를 전혀 모르는 서버를 개발하는 것이 복잡하고 간단하다는 것입니다. 또한 XHTML이 변경 될 때마다 브라우저 이외의 클라이언트가 업데이트되지 않도록하는 안정적인 정의를 유지하면서 웹의 빠른 진화에 대한 요구를 처리하기가 어렵습니다.

같은 방식으로, 브라우저 렌더링 된 레이아웃을 구성하고 컨텐츠를 보유하기위한 것이 아닌 모든 XML 요소로 인해 XHTML 문서를 구문 분석하는 브라우저가 아닌 클라이언트를 개발하는 것은 매우 어렵습니다.

REST 채택자가 브라우저의 XHTML보다 훨씬 간단한 SOAP의 XML 복잡성에 대해 이미 불만을 제기하는 경우 여러 클라이언트 유형, 서버 및 클라이언트 측에서 XHTML을 처리하는 것이 얼마나 어려운지 상상해보십시오.

실제로 : 원하는 경우 HTML과 같은 HTML을 사용하여 브라우저 용 WebSites를 작성하고 비 브라우저 클라이언트 용 WebService 솔루션을 작성하십시오.

그러나 XHTML5를 만들어야한다고 생각합니다. XHTML 1.1 (ok, 1.0, 1.1은 사용할 수 없음)은 HTML5에서 구식이되고 HTML5의 요소를 받아들이고 XML 형식을 검증하는 유효성 검사기가 여전히 필요합니다.