결국 HTML보다 XHTML을 선택하는 이유는 무엇입니까?

결국 HTML보다 XHTML을 선택하는 이유는 무엇입니까?

---

HTML 대신 XHTML을 사용해야하는 이유가 궁금합니다.

XHTML은 "모듈화"되어야하지만, 서버 측 언어가이를 활용하는 것을 본 적이 없습니다.

XHTML도 더 엄격하며 이점이 보이지 않습니다. XHTML은 내가 필요로하는 무엇을 제공합니까? 내 코드를 "더 좋게"만드는 방법은 무엇입니까?

편집 : 주석에서 찾은 또 다른 질문 : XHTML은 HTML보다 빠르게 구문 분석합니까?

EDIT2 : 귀하의 모든 의견과 링크를 읽은 후 다른 게시물이 정답이 될 자격이 있다는 데 실제로 동의하므로 최고의 소스로 직접 연결되는 게시물을 선택했습니다.

또한 사람들이 읽지 않고 녹색 댓글에 찬성하는 것을 보여줍니다.

---

HTML에 대한 XHTML의 함정에 대해 경고하는 유익한 기사 인 Beware of XHTML을 읽어야 합니다.

나는 그것을 읽을 때까지 XHTML에 대해 꽤 총을 썼지 만 몇 가지 유효한 점을 만든다. 다음 비트 포함;

XHTML 1.x는 "향후 호환"되지 않습니다. 현재 초안 단계에있는 XHTML 2는 XHTML 1.x와 역 호환되지 않습니다. XHTML 2는 문서를 작성하고 구조화하는 방식에 많은 주요 변경 사항이있을 것이며, 이미 XHTML 1.1로 작성된 사이트가 있더라도 적절한 XHTML 2로 변환하려면 일반적으로 완전한 사이트 재 작성이 필요합니다. 일부 의미 체계가 제대로 번역되지 않기 때문에 대부분의 경우 XSL 변환으로는 충분하지 않습니다.

HTML 4.01은 실제로 미래와 더 잘 호환됩니다. 최신 지원 수준으로 작성된 유효한 HTML 4.01 문서는 유효한 HTML 5이며 HTML 5는 브라우저 개발자와 W3C에서 대부분의 관심을받는 곳입니다.

일부 프로젝트에서 작업 할 때 향후 호환성은 엄청날 수 있습니다. 이 기사는 다른 몇 가지 좋은 점을 계속해서 설명하지만, 그것이 저에게 가장 눈에 띄었을 것입니다.

이 기사를 XHTML에 대한 폭언으로 착각하지 마십시오. 저자는 XHTML의 장점에 대해 이야기하지만 시작하기 전에 단점을 인식하는 것이 좋습니다.

---

다른 게시물 중 하나에 댓글로 추가하려고했지만 너무 커졌습니다.

대부분의 사람들이 놓치고있는 근본적인 점은 XHTML의 목적입니다. XHTML 사양을 개발 한 주요 이유 중 하나는 마크 업에서 프리젠 테이션 관련 태그를 강조하지 않고 CSS로 프리젠 테이션을 연기하는 것입니다. 이 분리는 일반 HTML로 달성 할 수 있지만이 동작은 사양에 의해 촉진되지 않습니다.

메타 마크 업과 프리젠 테이션을 분리하는 것은 '프로그래밍 가능한 웹'개발의 중요한 부분이며 SEO 및 화면 판독기 / 텍스트 브라우저에 대한 액세스를 개선 할뿐만 아니라 원하는 사람들이 웹 사이트를 더 쉽게 분석 할 수 있도록 유도 할 것입니다. 프로그래밍 방식으로 액세스합니다 (많은 간단한 경우에 특정 API를 개발할 필요성을 없애거나 클라이언트 측 스크립트가 전화 번호를 쉽게 식별하는 것과 같은 작업을 수행하도록 허용 할 수 있습니다). 웹 페이지가 XHTML 사양을 준수하는 경우 XML 관련 도구 및 XPath와 같은 도구를 사용하여 쉽게 이동할 수 있습니다. 이는 웹 사이트에서 특정 정보를 추출하려는 사람들에게 환상적인 뉴스입니다.

XHTML은 자체적으로 사용하기 위해 개발 된 것이 아니라 다양한 다른 기술과 함께 사용하여 개발되었습니다. 프레젠테이션을 위해 CSS 사용에 크게 의존하며 Microformats (당신이 좋아하든 싫어하든)와 같은 것들을위한 토대를 마련하여 일반적인 데이터 표현을위한 표준화 된 마크 업을 제공합니다.

XHTML이 무의미하고 지나치게 제한적이고 무의미하다고 생각하는 군중에 속지 마십시오. 전 세계 95 %가 무시하거나 모르는 것처럼 보이는 목적으로 만들어졌습니다.

반드시 HTML을 사용하되 그것이 좋은 것을 위해 사용하고 XHTML을 볼 때 동일한 접근 방식을 취하십시오.

---

파싱 ​​속도와 관련하여 XHTML과 HTML 사이의 실제 문서 파싱에는 거의 차이가 없을 것이라고 생각합니다. 절충점은 사용 가능한 마크 업을 사용하여 문서를 설명하는 방법에 있습니다. XHTML 태그는 필수 속성, 적절한 닫기 등으로 인해 더 길어지는 경향이 있지만 문서 자체에 표시 마크 업이 필요하지 않습니다. 이 경우에, 저는 여러분이 한 종류의 사과를 아주 약간 다른 종류의 사과와 비교하는 것에 대해 이야기하고 있다고 생각합니다 ... 그것들은 다르지만 (파싱 및 렌더링 측면에서 ) 건강하고 맛있는 사과 만 원할 때.

---

웹 사이트 방문자에게는 눈에 띄는 차이가 없을 것입니다. 또한 XHTML은 일반적으로 하나 이상의 널리 퍼져있는 브라우저가 여전히이를 처리하는 방법을 모르고이 경우 텍스트 / html로 제공해야하기 때문에 사용하기가 더 고통 스럽습니다 (잘못된 HTML을 생성 함).

HTML이 사람이 읽는 대신 자동화 된 도구에 의해 정기적으로 처리되는 경우 XHTML은 구조가 더 엄격하고 XML이기 때문에 구문 분석이 더 쉽습니다 (애플리케이션 관점에서 볼 때 XML은 그렇지 않습니다. 하지만 본질적으로 파싱하기 쉽습니다).

그 외에도 나는 그것을 사용하는 설득력있는 이유를 보지 못했습니다. XHTML은 HTML 용 XML 기능을 사용하는 접근 방식으로 만들어졌으며 기본적으로 "여러 가지 성가신 부작용이있는 HTML 4"(최소한 IMHO)로 요약됩니다.

---

사용 HTML (HTML4 엄격한 또는 HTML5).

• HTML은 CSS를 완전히 활용할 수 있으며, 명확하게 검증 및 구문 분석 할 수 있습니다. 구조와 표현의 분리는 HTML4에서 이루어졌고 XHTML은 단지 그것을 계속했습니다.

• 모든 브라우저는 HTML을 지원합니다. 일부 브라우저 만 XHTML을 지원하고 지원하는 브라우저는 종종 더 성숙하고 더 잘 테스트되고 최적화 된 HTML 지원을 제공합니다 ( 페이지의 극히 일부 가 XML 모드를 사용하기 때문입니다).

• IE와 Google에 관심이 있다면 HTML 또는 XHTML 사양의 부록 C에 정의 된 XHTML 및 HTML의 하위 집합을 사용해야합니다. 이러한 XHTML은 표준 XML 도구로 생성 할 수없고 XHTML에 새로운 확장 메커니즘을 사용할 수 없으며 HTML만으로는 추가 제한 사항이 있기 때문에 후자는 두 세계 모두에서 거의 최악입니다.

• XHTML1.0은 이제 10 년이 넘었고 "Web1.0"시대로 설계되었으며 W3C의 책임자가 말했듯 이 돌이켜 보면 제대로 작동하지 않았고 더 나은 접근 방식이 필요합니다 . W3C HTML5는 우리가 말한대로 작성되었으며 오늘날 사용되는 웹 애플리케이션의 요구 사항을 해결하며 이전 버전과의 호환성이 매우 뛰어납니다.

• HTML5는 HTML4와 XHTML1 (예 : 인라인 SVG 추가, MathML i RDF 추가) 사이에 있었던 많은 차이를 없애고 XHTML1.0 및 XHTML1.1에서 수행 된 것 이상의 언어를 정리합니다.

• XHTML2는 당분간 웹 브라우저에서 지원되지 않을 것입니다. 지원 되지 않을 가능성이 높습니다 (모든 브라우저 공급 업체는 [X] HTML5를 강력하게 지원하고 일부는 이미 XHTML2를 구현하지 않을 것이라고 선언했습니다).

---

XHTML1.0은 HTML4.01과 정확히 동일한 의미와 구조에서 표현을 분리합니다. 달리 말하는 사람 은 사양을 읽지 않았습니다 . 나는 모두가 스펙을 읽어 보길 권한다 – 그것은 놀랍도록 짧고 흥미롭지 않다.

• 스타일 시트는 HTML4.01에서 도입 되었으며 XHTML1.0 에서는 변경 되지 않았습니다 .
• 프리젠 테이션 요소는 HTML4.01에서 더 이상 사용되지 않으며 XHTML1.0에서 제거 되지 않았습니다 .

XHTML 신화 .

---

하나의 구문 분석을 다른 것보다 훨씬 느리게 만드는 HTML과 XHTML에는 다루기 힘든 차이가 없습니다. 파서가 구현되는 방법에 따라 다릅니다.

• SGML과 XML 파서 모두 엔티티를 이해하기 위해 전체 DTD를로드하고 파싱해야합니다. 이것만으로도 일반적으로 문서 자체를 구문 분석하는 것보다 더 많은 작업이 수행됩니다. HTML 파서는 거의 항상 "속임수"를 쓰며 하드 코딩 된 엔티티와 요소 정보를 사용합니다. 브라우저의 XHTML 파서도 속입니다.
• HTML을 구문 분석하려면 암시 ​​된 시작 및 끝 태그를 처리해야하며 실제 HTML에서는 잘못 배치 된 태그를 처리하기위한 추가 작업이 필요합니다.
• XHTML을 올바르게 구문 분석하려면 XML 네임 스페이스를 추적해야합니다.
• Draconian XML 규칙은 모든 문자가 올바르게 인코딩되었는지 확인해야합니다. HTML 파서는 이것으로 벗어날 수 있지만 OTOH는 <meta>.

문서를 다운로드하고, DOM을 빌드하고, 스크립트를 실행하고, CSS를 적용하고, 브라우저가해야하는 다른 모든 작업에 걸리는 시간에 비해 구문 분석 비용의 전반적인 차이는 작습니다.

---

여기의 모든 답변이 HTML보다 XHTML을 권장한다는 사실에 놀랐습니다. 나는 단호하게 반대 의견을 가지고 있습니다. 가까운 미래에 XHTML을 사용해서는 안됩니다. 그 이유는 다음과 같습니다.

• mimetype으로 제공하지 않는 한 브라우저는 XHTML을 XHTML 로 해석 하지 않습니다 application/xhtml+xml. 기본 MIME 유형으로 제공하는 경우 모든 브라우저는이를 HTML로 해석합니다. 예를 들어 닫히지 않거나 부적절하게 중첩 된 요소를 허용합니다.

• 그러나 Internet Explorer가을 인식하지 못하고 페이지를 완전히 렌더링 하지 못하므로 실제로이 작업을 수행 해서는 안됩니다 application/xhtml+xml.

• XHTML과 HTML 간의 DOM에는 상당한 차이가 있습니다. 현재 소위 XHTML 페이지는 모두 HTML로 제공되므로 모든 자바 스크립트 코드는 HTML DOM을 사용하여 작성됩니다. XHTML mimetype에 대한 지원이 사람들이이를 사용하도록 설득 할만큼 중요 해지면 페이지가 XHTML로 유효성이 확인된다고 생각하더라도 대부분의 자바 스크립트 코드가 손상됩니다.

---

HTML 4.01 Strict 대 XHTML Strict에 대해 계속 토론하는 대신 오늘 HTML 5를 사용하기 시작하는 것이 좋습니다. jquery의 저자 인 John Resig는 작년 에 그의 블로그에서 비슷한 제안 을했습니다.

HTML 5 doctype은 아름답 기 때문에 모든 브라우저 (IE6 포함)에서 표준 모드를 ​​트리거합니다.

<!DOCTYPE html>

그게 다야.

HTML 5는 <canvas>잠재적으로 자바 스크립트 애플리케이션 개발을 다음 단계로 끌어 올릴 수 있는 태그 와 같은 흥미로운 새로운 기능을 제공 합니다. HTML 5는 미디어에 대한 적절한 지원을하고있다 (미디어 웹의 매우 중요한 측면 요즘!이다)의 형태 <video>와 <audio>태그.

XHTML 구문이 마음에 들면 <br />HTML 5에서 완전히 지원되는와 같은 닫는 "빈"태그 가 마음에 들면 HTML 5를 작성하는 방법 알아보기 W3C 게시물의 Karl Dubost에서 다음과 같이 말합니다 .

자동 닫기 태그가 허용되며 HTML 5를 준수합니다.

XHTML2 has received relatively little attention compared to HTML 5. It's becoming increasingly clear that HTML 5 is the future of markup on the web. Microsoft's latest browser, IE8 still renders XHTML served as text/xml as text/html.

Microsoft have a co-chair on the W3C HTML working group and there's an implied support from them for HTML 5. All of the browser vendors have publicly announced their support for HTML 5.

At the end of the day, even if XHTML2 regains support from the industry, it won't be a significant issue having two competing standards as it has been in the past. Both languages support XML namespaces (in the case of HTML 5, serialization of HTML i.e. DOCTYPE switching).

---

Take a look at http://www.w3.org/MarkUp/2004/xhtml-faq#need. There are some good reasons apart from modularisation.

I favor XHTML because it's stricter and more clearly laid out. HTML is quirky and browsers have to accept things like <b><i>sadasd</b></i>. While this is a really simple example, it could also get more confusing and different browsers could lay out things differently.

Also I think that XHTML has to be "faster" since the browser doesn't have to do that kind of "reparations".

---

Some differences are:

• XHTML tags must be properly nested
• The documents must have one root element
• XHTML tags are always in lowercase
• Tags must always be closed (e.g. using the <br> tag in XHTML must have closing tag <br /> or <br></br> in XHTML)

Here are some links on it

wiki XHTML

wiki HTML vs XHTML

---

As a programmer, you should be VERY concerned about your code. HTML is ugly and follows few rules.

XHTML on the other hand, turns HTML into a proper language, following strict structural and syntactic rules.

XHTML is better for everyone, as it will help move the web to a point where everyone (all browsers) can agree on how to display a web page.

XHTML is an XML descendent, and us such is much easier on parsers built for the job of analysing syntactically sound XML documents.

If you can't see the benefit of XHTML, you might as well be using MS Word to create your HTML documents.

---

XHTML allows to use all those tools designed for XML. Among then, there is XSLT, embedding SVG, etc...

---

Interesting development: XHTML 2 Working Group Expected to Stop Work End of 2009, W3C to Increase Resources on HTML 5

2009-07-02: Today the Director announces that when the XHTML 2 Working Group charter expires as scheduled at the end of 2009, the charter will not be renewed. By doing so, and by increasing resources in the Working Group, W3C hopes to accelerate the progress of HTML 5 and clarify W3C's position regarding the future of HTML. A FAQ answers questions about the future of deliverables of the XHTML 2 Working Group, and the status of various discussions related to HTML. Learn more about the HTML Activity.

Well, I guess that makes the future of HTML pretty clear.

---

XHTML forces you to be neat.

For example, in HTML, you can write:

<img src="image.jpg">

This isn't very logical, because the img tag never gets closed. In XHTML, however, you're forced to close the tag neatly, like this:

<img src="image.jpg" />

I like using something that forces me to be neat.

Steve

---

The subtitle to the XHTML 1.0 recommendation:

A Reformulation of HTML 4 in XML 1.0

Many tools exist today to process XML. By using XHTML, you are allowing a huge set of tools to operate on your pages and to extract information programmatically.

If you were to use HTML, this would be possible too. There are tools in existence to parse HTML DOM trees. However, these tools can often be more specialized than those for XML. You may not find your favorite XML data processing tools compatible with HTML. Furthermore, there are so many uses for XML nowadays that you may be using XML for some other part of an application; why not also use that same XML parser to parse your web pages? This is the motivation behind XHTML.

If you're already comfortable and familiar with HTML 4.01, you have an established project using HTML 4, and you don't have tons of spare time, just go with HTML 4.01. If you have spare time, learn XHTML 1.1 anyway, and start your new projects in XHTML 1.1 – there's no harm in doing so. If you're using something other than HTML 4.01 or are pretty unfamiliar with HTML 4 anyway, just learn XHTML 1.1.

---

Using XHTML with the correct DocType will force the browser to render the content in a more standards compliant (strict) mode. This makes the different browsers behave better and, most importantly, more like each other. This makes your job as a webdeveloper a lot easier since it reduces the amount of browser specific tweaks needed to make the content look the same in all browsers.

Quirksmode.org has a lot of good info on this subject.

---

In my opinion, the strictness is, at least in theory, a good thing, because in HTML, you don't need to be strict, and because of that and the HTML5 junk, Browsers have advanced error correction algorithms that will make the best out of broken HTML. The problem is, the algorithms are not exactly the same and will lead to really strange behaviour you can't predict. With XHTML, on the other hand, you typically have fine, valid XHTML and so the error correction algorithms are not needed, i.e. the entire Browser behaviour is predictable. In addition, strict code makes it easier for your tools to work with the code. So you have actually nothing to lose by using XHTML, but there is some potential to gain. Things will get worse with plain HTML when HTML5 is finally out and the "be open in what you accept" will lead to the described strange behaviour. But at least then it's a standardized strange behaviour. Sigh.

On the other hand, if you use a good IDE like Visual Studio, it's almost impossible to produce broken HTML code anyway, so the result is the same.

---

Use XHTML

• Fails fast. If there are any inconsistencies they will be found during validation.
• It encourages better design by separating semantic markup from presentation etc.
• It's structured which means that you can treat it as a data object and run all sorts of queries against it. For example you could find all addresses or citations within your website.
• You can do build-time optimizations. Since it's well-formed XML you can easily do find/replace operations during build time. Or any document management and manipulation.
• You can write XSLT or other transformation scripts to programatically transform your XHTML for other platforms. For example you could have an XSLT for the iPhone that would transform all XHTML to make it compatible or more user-friendly for the iPhone
• You are future proofing yourself. Transforming XHTML to newer semantics is again, very easy using transformation.
• Search engines will continue to evolve to gather more semantic information as part of the programmable web.
• DOM operations are more reliable since it's structured.
• From an algorithmic perspective, it yields easier and faster parsing.

---

XHTMl is a good standing point to use because if you want valid code you would need to provide some aspect of help to the disabled community due to the fact screen readers need the alt and title parts of the image and link tags. It must be faster to parse to an extent because unlike HTML the parser wouldn't need to check to see if the tag wasn't closed properly, if it was nested correctly etc. Also it is better to use it because yes it is strict but it helps you to think more logically (in my opinion) when it comes to learning programming languages.

---

I believe XHTML is (or should be) faster to parse. A valid XHTML document must be written to a stricter spec in that errors are fatal when parsing, whereas HTML is more lenient and allows for oddities mentioned before my comment like out of order closing tags and such. I found this helpful in uncovering the differences between HTML and XHTML parsing:

http://wiki.whatwg.org/wiki/HTML_vs._XHTML#Parsing

A reason you might use XHTML over HTML might be if you intend to have mobile users as part of your audience. If I recall, many phones use something more of an XML parser, rather than an HTML one to display the web. If you are writing for desktop browsers, HTML would probably be acceptable.

That said, if you are going to serve the data as text/html anyway, you should use HTML:

http://www.hixie.ch/advocacy/xhtml

참고URL : https://stackoverflow.com/questions/867498/at-the-end-of-the-day-why-choose-xhtml-over-html