왜 XHTML5가 아닌가?

53

HTML5가 큰 발전입니다. 내가 아는 마지막 단계는 XHTML의 도입이었습니다. 단순성, 엄격 성, 표준 XML 파서 및 생성기를 사용하여 웹 페이지 작업 등의 이점이 분명했습니다.

HTML5가이 모든 것을 되돌려 놓는 것이 얼마나 이상하고 실망 스러운가? 다시 한번 우리는 비표준 구문을 사용하고있다. 다시 한번, 우리는 역사적인 수하물과 파싱 복잡성을 처리해야합니다. 다시 한 번 표준 XML 라이브러리, 파서, 생성기 또는 변환기를 사용할 수 없습니다. W3C가 10 년 동안 좋은 이유 때문에 추진 한 XML (확장 성, 네임 스페이스, 표준화 등)에 의해 도입 된 모든 이점은 사라졌습니다.

우리는 XHTML5를 가지고 있지만 HTML5 인코딩처럼 인기를 얻지 못한 것 같습니다. 예를 들어이 SO question을 참조하십시오 . HTML5 사양 조차도 XHTML5가 아닌 HTML5는 "대부분의 저자에게 제안 된 형식"이라고 말합니다.

내 사실이 잘못 되었습니까? 그렇지 않으면 왜 내가 이런 식으로 느끼는 유일한 사람입니까? 사람들이 XHTML5 대신 HTML5를 선택하는 이유는 무엇입니까?

— jameshfisher
소스

6

+1 나는 HTML5의 모든 XML 이점을 잃어버린 것에 실망한 유일한 사람이 아니라는 것을 안다.

— Arseni Mourzenko 2016 년

좋은 질문을하는 것이 좋습니다.

— Konrad Rudolph

1

HTML5의 모든 XML 단점을 잃어버린 것에 만족하는 유일한 사람이 아니길 바랍니다. 예를 들어 유효한 HTML5와 유효한 XHTML을 비교해 봅시다. HTML5 : <!DOCTYPE html>Hello World, XHTML :

<?xml version="1.0" encoding="iso-8859-1"?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0  Transitional//EN" "DTD/xhtml1-transitional.dtd"><html xml:lang="en" lang="en" xmlns="http://www.w3.org/1999/xhtml"><head><title></title></head><body>Hello World</body></html>

— zzzzBov

@zzzzBov, 당신은 가장 기뻐하는 유일한 사람이 아니므로 처음 에이 질문을 한 이유입니다. 또한 : 당신은 진지하게 쓰지 <!DOCTYPE html>Hello World않을 것입니까? 이 유효성 검사기 에서 시도하십시오 .

— jameshfisher

1

@eegg, 선택적 시작 태그 에 대한 사양을 읽지 않은 것 같습니다. 왜냐하면 <!DOCTYPE html>Hello World!완벽하게 유효한 HTML5 이기 때문에 심각 하게 작성 하기 때문 입니다. 문서가 짧을수록 오버 헤드가 적으므로 대기업의 경우 상당한 비용을 절약 할 수 있습니다 (www.google.com에 Google이 보내는 내용을 보셨습니까?).

— zzzzBov 2016 년

25

우리는 어떻게 왔습니까?를 읽는 것이 좋습니다 . . Mark Pilgrim은 HTML5까지 HTML의 훌륭하고 짧은 역사를 제공합니다.

본질적으로, 내 이해는 많은 웹 페이지가 적절한 MIME 유형을 지정하지 않기 때문에 XHTML의 "X"를 이용하지 않는다는 것입니다.

— 가설
소스

18

네. 그 이야기에 대한 저의 요약은 "아무도 사양을 준수하는 사람이 없습니다. 사람들이 원하는 오류를 만들 수 있도록 지정하여 사양을 준수하도록 할 수있을 것입니다. 그러면 결국 모든 문서에 오류가 없습니다" 표준 준수. " 아무도 사양을 존중하지 않는다는 초기 가정으로 사양을 작성해도 좋은 결과를 얻을 수 없습니다.

— jameshfisher

1

@eegg, 마지막 줄은 현실에 대한 무지를 보여줍니다. 많은 사람들은 이미 아무도 완벽하지 않다고 가정하여 좋은 결과를 얻었습니다 . "당신이 실수를하면 모든 것이 망가진다"라는 말 대신에, "[이런 종류의 실수]를하면 [이 결과]는 어떻게됩니까?"라고 말합니다. 책을 출판하기 위해 100 % 정확한 철자법, 문장 부호 및 문법을 사용해야한다면 선반에 몇 권의 책이 있습니까?

— zzzzBov 2016 년

6

@zzzzBov, 출판 된 책과의 비유는 이상합니다. HTML 구문 분석기가 구문 오류가 오류 메시지와 함께 나타나는 [여기의 다른 언어] 구문 분석기보다 더 관대해야하는 이유는 무엇입니까? C 컴파일러가 깨진 구문을 자동으로 재 해석하기 위해 최선을 다했을 때 혼란이 있다고 상상해보십시오.

— jameshfisher

@eegg, 다른 언어의 파서가 구문 오류에 더 용 서적으로 반응하면 어떻게 될지를 이미지화 할 수 있습니다 . 우리는 잘못 배치 된 대괄호를 찾는 데 더 적은 시간을 소비하고 세미 콜론을 누락하고 기능 코드를 입력하는 데 더 많은 시간을 할애합니다. 좋은 프로그래머가 여전히 프로그램을 제대로 구성하지는 않지만 평범한 프로그래머가 작업 코드를 작성하는 데 확실히 도움이 될 것이라고 말하지 는 않습니다 . C프로그램은 아마 훨씬 더 유사하게 보이는 끝낼 것 Python세미콜론 및 브라켓은 대부분 사라질 수 있다는 점에서 프로그램, 어떤 남아있을 것입니다 것은 중요한 코드입니다.

— zzzzBov 2016 년

"요청한 자원 /past.html을이 서버에서 더 이상 사용할 수 없으며 전달 주소가 없습니다."

— Marco

6

xml 호환 html5를 생성하고 xml을 mime 유형으로 보내면 xml 파서가 좋은 재즈가 돌아 오는 모든 것을 사용합니다.)

편집 : 자세한 내용은 다음을 참조 하십시오 : http://wiki.whatwg.org/wiki/HTML_vs._XHTML

— 치명적인
소스

"좋은 재즈"를 정의하십시오. AFAIK는 HTML을 XML로 구문 분석하는 이점이 없습니다. 생성 및 변환은 다른 문제이지만 편리 할 수 있지만 구문 분석 자체는 장점을 제공하지 않으며 단점 만 있습니다 (화장품 버그를 치명적으로 만듭니다).

— Joeri Sebrechts

3

@Joeri 파싱하기가 훨씬 쉽다는 사실은 여러 가지 이유로 내 책에서 장점입니다 (엄격한 구문 분석은 오류를 쉽게 찾고 도구를 쉽게 작성할 수 있기 때문에 도구를 더 잘 지원하므로 입력을 더 쉽게 위생 화하는 등).

— Konrad Rudolph

다른 XML 내용이 포함 된 micin xhtml과 같이 표준 HTML에서 사용할 수없는 일부 기능을 제공 할 수 있으며 일반적으로 모든 XML 기능, 예를 들어 네임 스페이스를 사용합니다. html 파서는 나쁜 소스 코드를 고칠 수 있습니다. 가격은 브라우저가 코드에서 무엇을 찾을 수 있는지 알아야하므로 사용 가능한 기능이 제한됩니다.

— deadalnix 2016 년

3

HTML5는 Postel의 법칙을 채택한 브라우저의 논리적이고 불가피한 결론입니다 ( "허용하는 것에 자유주의").

충분한 시장 점유율을 가진 브라우저가이 원칙을 채택하면, 다른 브라우저는 부적합한 컨텐츠를 수용함으로써 자유로울뿐만 아니라 경쟁 업체와 동일한 방식으로 렌더링해야합니다. HTML5는 이러한 상황의 논리적 결과입니다. 브라우저 공급 업체는 콘텐츠를 유효하지 않은 것으로 거부하지 않기 때문에 (최소한 HTML 수준이 아니라 Javascript가 또 다른 문제입니다!) 콘텐츠 작성자가 던질 수있는 모든 것에 대한 해석을 표하고 동의합니다. 이 환경에서 그들은 표준 괴짜들에게 친절하게 반응하지 않았으며, 잘못된 형식의 콘텐츠를 거부했을 때만이 혼란에 빠지지 않았을 것이라고 말합니다.

그래서 당신과 나는 부수적으로 소리 쳐서 브라우저 공급 업체와 사용자에게 John Postel을 믿지 않았다면 세상이 더 좋은 곳이었을 것이라고 말할 수 있지만, 피해는 이루어졌으며 실행을 취소하기가 매우 어렵습니다.

— 마이클 케이
소스

3

브라우저의 경쟁 우연에 대한 이야기는 충분합니다. 그러나 여기에 문제가 있습니다. 그것이 표준 괴짜들이 존재하는 이유입니다. 모든 브라우저가 처음부터 똑 바르고 좁아 졌다면, W3C와 같은 조직은 상황을 통제하기 위해 여기에있을 필요가 없습니다. 표준의 요점 은 피해 통제입니다. 표준기구가 허풍을 포기하고 받아들이는 것은 그 목적을 무너 뜨린다.

— jameshfisher

1

@eegg : HTML5는 파싱 규칙을 재정 의하여 모든 입력이 유효하고 예측 가능한 결과를 얻습니다. 구문 오류가 불가능하면 처음부터 모든 종류의 버그가 배제됩니다. 구문 분석 오류가있는 XML의 기능은 디자인 결함이므로 인식해야합니다.

— Joeri Sebrechts

1

@Joeri, 귀하의 입장은 HTML5 사양의 입장 인 것 같습니다. "HTML5는 구문 분석 규칙을 재정 의하여 모든 입력을 유효하게합니다"-그렇지 않습니다. 구문 분석 오류의 개념은 여전히 존재합니다. "구문 오류가 불가능하다면, 모든 종류의 버그가 처음부터 배제된다"-아마도 패러디일까요? 이 논리는 @pthesis의 답변에 대한 주석에서 비꼬는 말로 표현됩니다. 예 . 더 큰 클래스의 브라우저 구문 정정 오류 로 대체되도록 구문 오류 클래스 가 제거됩니다 .

— jameshfisher

2

HTML5 사양은 실제로 HTML4 사양에 비해 크게 향상되었습니다. 특히, 오류 조건 및 유효하지 않은 마크 업 처리는 실제로 표준화되어 있으므로 표준을 올바르게 구현하는 모든 브라우저가 유효하지 않은 마크 업을 동일한 방식으로 처리합니다.

HTML은 (보통 일종의 템플릿 언어와 관련하여) 인간이 자주 작성하지 않으며 인간은 실수를 저지 릅니다. 모든 브라우저가 동일한 방식으로 구문 오류를 처리하는 한 "허용되는 것에서 자유 롭다"규칙은 완벽하게 수용 가능합니다.

HTML을 처리하는 도구와 라이브러리는 거의 쉽게 사용할 수 있으며 HTML보다 사람이 XML을 작성하기가 더 쉽기 때문에 유효한 XML을 생성 할 때 실제로 이점이 거의 없습니다.

— 딘 하딩
소스

오버 HTML4의 사양, 예. 그러나 내 요점은 XHTML1.1이 이미 개선되었다는 것입니다. HTML을 처리하는 도구 / 라이브러리는 BeautifulSoup 과 같은 경향이 있습니다. 훌륭한 도구이지만 구문 분석 할 페이지와 함께 죽어야합니다.

— jameshfisher 2016 년

1

어쨌든 클라이언트 측에서 더 간단한 파서 또는 표준 XML 도구의 이점을 얻지 못할 것입니다.

웹에는 HTML에 수십억 개의 페이지가 있으며 그중 일부는 오랫동안 죽은 사람들이 작성했기 때문에 결코 XML로 업데이트되지 않습니다. 당신은 일반적으로 도움이되는 사용자 에이전트를 만들려면 그래서 당신 이 어쨌든 구식 HTML을 구문 분석 할 수 있도록. 아마도 XHTML은 이미 지원해야하는 HTML 구문 분석 외에 새로운 구문 분석 모드가 필요하기 때문에 추가적인 복잡성을 야기 할뿐입니다.

서버 측에서는 여전히 다음과 같은 방법으로 XML 도구를 활용할 수 있습니다. XSLT를 사용하여 XHTML 생성 그러나 XML 툴체인을 사용하지 않는 경우 HTML이 아닌 XML 구문을 사용하면 이점이 없습니다.

(HTML이 "비표준"구문인지는 정확하지 않습니다. HTML 구문은 HTML5 사양에서 어려운 세부 사항으로 지정되므로 XML 구문만큼이나 표준입니다.)

— 자크 B
소스