• 0

HTML 4.01 -> XHTML 1.0 -> XHTML 1.1 -> HTML 5 -> ?


Question

It seems a bit confusing as to which web standard we should be using for an average website these days.

Back in the days of HTML 4 and HTML 4.01 it was a simple decision between Frameset, Transitional or Strict. Choosing between these simply depended on what sort of site you were building but we were encouraged to try to build a Strict site so that we would have the best browser cross-compatibility (with sensible browsers anyway... IE6 I'm looking at you...).

When XHTML 1.0 came along it was basically the same thing as HTML but implemented using XML. The decision was much the same: Frameset, Transitional or Strict, and once again, we were encouraged to use Strict where possible. It seemed like XHTML was the way forwards and I, along with many other web developers, began coding all my sites using XHTML instead of HTML.

XHTML 1.1 took this one step further by eliminating support for the Frameset and Transitional DTDs. This seemed like a logical progression because ever since HTML 4.0 we had been encouraged to create more strictly formatted web pages.

However, now with the introduction of HTML 5 we seem to be going backwards... Sure, HTML 5 introduces loads of application oriented structures which is great, but why couldn't they just do it in XHTML? Why not create XHTML 2.0 with all the new things they've introduced in HTML 5 rather than confusing us by going back to the old way of doing things in HTML.

Am I supposed to change all my sites from XHTML 1.1 to HTML 5 now in the interests of progress? And will XHTML 2.0 basically be to HTML 5 what XHTML 1.0 was to HTML 4?

What is the reasoning behind continuing to develop HTML when XHTML is still clearly the future?

/rant :laugh:

Link to comment
https://www.neowin.net/forum/topic/875818-html-401-xhtml-10-xhtml-11-html-5/
Share on other sites

16 answers to this question

Recommended Posts

  • 0

It seems a bit confusing as to which web standard we should be using for an average website these days.

Back in the days of HTML 4 and HTML 4.01 it was a simple decision between Frameset, Transitional or Strict. Choosing between these simply depended on what sort of site you were building but we were encouraged to try to build a Strict site so that we would have the best browser cross-compatibility (with sensible browsers anyway... IE6 I'm looking at you...).

When XHTML 1.0 came along it was basically the same thing as HTML but implemented using XML. The decision was much the same: Frameset, Transitional or Strict, and once again, we were encouraged to use Strict where possible. It seemed like XHTML was the way forwards and I, along with many other web developers, began coding all my sites using XHTML instead of HTML.

XHTML 1.1 took this one step further by eliminating support for the Frameset and Transitional DTDs. This seemed like a logical progression because ever since HTML 4.0 we had been encouraged to create more strictly formatted web pages.

However, now with the introduction of HTML 5 we seem to be going backwards... Sure, HTML 5 introduces loads of application oriented structures which is great, but why couldn't they just do it in XHTML? Why not create XHTML 2.0 with all the new things they've introduced in HTML 5 rather than confusing us by going back to the old way of doing things in HTML.

Am I supposed to change all my sites from XHTML 1.1 to HTML 5 now in the interests of progress? And will XHTML 2.0 basically be to HTML 5 what XHTML 1.0 was to HTML 4?

What is the reasoning behind continuing to develop HTML when XHTML is still clearly the future?

/rant :laugh:

XHTML was a failure for web and layout (there's little you need that for compared to HTML 4, and IE still doesn't support the standard properly due to not supporting application/xml+html). I think W3C may not be that open about it, but I think the inofficial stance is now at least that the forthcoming XHTML 2.0 is for document structure (as in not the web, but generic documents), while HTML 5 for the web and presentation. When W3C made this distinction, that let them do a lot more for the web than they would have been able to with XHTML 2. CANVAS, VIDEO, AUDIO as major examples, but there is more than this too. Much more.

Think of HTML 5 as a standard with a purpose: layouting websites and providing user interaction for the modern web. While XHTML 2 is for more abstract stuff.

  • 0

I don't like how the comic said that XHTML will live on through HTML5. Yea, it allows for strict syntax, but so did HTML4. It's still pointless if sloppy coding is allowed, you're still going to have a plethora of different ways the same document could be syntactically "styled", making it just as difficult to read/parse and by extension to learn. I just hope that by the time everyone starts using HTML5 the competent early adopting developers would already have set an industry standard to use strict syntax.

  • 0

I've found, rendering wise, IE (read: IE7, IE8 is a step up) plays better with XHTML 1.1 over the others, that being said I've meet others who say the opposite, so i donno. Changing from XHTML1.0 Transition/Strict has sometimes pulled IE out of quirks mode ( why? WHY? o_0 ) As it stands now I build all sites to XHTML1.1, ( I also do HTML4 if the page might be sent as an email/newsletter ).

I used to revert back to XHTML1.0 Transitional for sites that need the Document.Write() function in JS, but I found a js to get around that a while ago, so that killed that issue right there..

In the end as the comic says, it's all personal preference. HTML4 irks me, I can't stand it. If I am working on a site that was done it in I will go out of my way to make it XHTML1.1. ( OC much ? Yes, I am, thanks for noticing :) )

  • 0

It's a bit confusing, but the answer is HTML5 is the future of HTML and XHTML.

Most XHTML sites aren't actually XHTML, they're HTML with self closed tags (view the source for this page, even though the doctype says it's XHTML 1.0, the page is treated as HTML). The actual important bit is the mime type, which tells the browser to use an XML parser or a HTML parser. The doctype means nothing, it's solely there to actually trigger standards mode (vs. quirks mode or almost standards mode)

HTML5 unifies it a bit, under HTML5 all elements are in the XHTML namespace (so namespace aware functions work fine), and the parsing is the same between XML and HTML. A valid HTML5 document will parse properly with a HTML mime type or a XML mime type.

Edit: As for XHTML2? It's dead, you won't be seeing it used on the internet, or probably even offline.

  • 0

it's still stupid, typical w3c bureaucracy. I don't care about the name, xhtml of html, but at least make sure it's mandatory to serve and parse it as xml. That would result in faster browsers and less confusion

It would result in a standard that everybody ignores. I'm also willing to be that an unencoded ampersand 'blowing up' a web page with a yellow screen of death will result in a lot more confused users than the possibility of a missing word or space in a paragraph.

  • 0

I tend to use XHMTL 1.0 Strict with Text/HTML content type (since IE doesn't support true XHTML with the Application/XML+HTML content type) simply for the fact that I find that I prefer self-closing tags and the rules that the standard dictates (i.e. XML rules such as lower case attributes, quoted attr. values, etc). I used to use the XHTML 1.1 doctype tag, but abandoned it due to the fact that its impossible to comply with the standard (cannot use the XML+HTML content type because of IE).

I want to, but haven't adopted HTML 5 yet simply for the fact that you can't use the semantic tags yet due to browser issues. (FF2 doesn't cooperate with them properly, IE needs JS hacks to use them), and thats too many hacks for me simply to make a browser render a page. IE also doesn't support most (all?) of the new content tags like <video></video>, so you'd still need to serve up flash for IE, somewhat defeating the point.

In the end its your choice, a lot of people still opt for HTML 4.01, but equally as many opt for XHTML, its just whatever syntax you prefer. Some people like to self-close their tags (XHTML), and others like to capitalize their tags (HTML 4.01).

  • 0

Self closed tags in HTML is technically a syntax error.

So it might be "cleaner", but it's actually messier to the browser and invalid.

Its definitely valid XHTML though. Short of older browsers' issues with self-closing tags, how is it any harder for a browser to parse? Technically it should be easier since XHTML requires that all tags be explicitely be closed, whereas HTML allows things like paragraphs, table rows and table cells to be "auto-closed" by the browser.

  • 0

It may be XHTML, but since you're sending it as HTML it's being parsed as such.

Edit: In XML mode <p /> is a self closed paragraph tag, in HTML mode <p /> is an unmatched opening paragraph tag, with a forward slash in it.

Edit 2: And according to HTML5, <p /> is a self closed, empty paragraph in HTML and XML mode, mainly for people who do "XHTML sent as HTML".

  • 0

It may be XHTML, but since you're sending it as HTML it's being parsed as such.

Edit: In XML mode <p /> is a self closed paragraph tag, in HTML mode <p /> is an unmatched opening paragraph tag, with a forward slash in it.

Edit 2: And according to HTML5, <p /> is a self closed, empty paragraph in HTML and XML mode, mainly for people who do "XHTML sent as HTML".

The first edit is actually invalid XHTML syntax, since the XHTML rec states that:

"Given an empty instance of an element whose content model is not EMPTY (for example, an empty title or paragraph) do not use the minimized form (e.g. use <p> </p> and not <p />)."

Given that, if you use a self-closing paragraph, you're breaking both HTML and XHTML rules (excl. HTML5, which I haven't looked at properly yet). The recommendation also states that valid XHTML can be sent as either text/html or application/XML+HTML. At the end of the day though, the variation between strict HTML and strict XHTML is almost nil. The recommendation only states 12 variations between XHTML 1.0 and HTML 4.01, and that is simply things like lower-case tags, stricter whitespace definitions, self-closing tags, and other small rules, all things that don't break compliance with HTML 4.01 (aside from the self-closing slash, and the extra attributes, but any half-decent browser would ignore unknown attributes anyway), but enable it to be almost compliant XML (except for the DOCTYPE tag, which has been all but nuked in (X)HTML5).

  • 0

The first edit is actually invalid XHTML syntax, since the XHTML rec states that:

"Given an empty instance of an element whose content model is not EMPTY (for example, an empty title or paragraph) do not use the minimized form (e.g. use <p> </p> and not <p />)."

Given that, if you use a self-closing paragraph, you're breaking both HTML and XHTML rules (excl. HTML5, which I haven't looked at properly yet). The recommendation also states that valid XHTML can be sent as either text/html or application/XML+HTML. At the end of the day though, the variation between strict HTML and strict XHTML is almost nil. The recommendation only states 12 variations between XHTML 1.0 and HTML 4.01, and that is simply things like lower-case tags, stricter whitespace definitions, self-closing tags, and other small rules, all things that don't break compliance with HTML 4.01 (aside from the self-closing slash, and the extra attributes, but any half-decent browser would ignore unknown attributes anyway), but enable it to be almost compliant XML (except for the DOCTYPE tag, which has been all but nuked in (X)HTML5).

Not quite true. Section C is informative, which means that it "is not required for conformance but contributes to the correct use and implementation of the specification."

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Posts

    • Because Chrome is doing it. And no one said anyone had to update immediately. That's silly. They could update every day for all I care as long as it's fast, and the next time the browser restarts, you're good. And the basic point is not to tee it up for bigger updates. As it is right now, all the windows I had open reopen anyway except inprivate.
    • Why? Does anybody actually want this? The constant need to close all browser sessions and wait for a new version to install, just so that there’s a integrated coupon manager feels like a waste of everyone’s time
    • I remember when Louis used to just do interesting Mac/iPhone repairs, now he's boring and just launches "crusades" every week
    • A shame it don't allow people to bypass the MS account, I will stick to using Rufus.
    • Microsoft about to radically change how often your Edge browser updates by Paul Hill Microsoft has just announced that starting with Edge 152, it will be moving to a two-week release cycle for faster, smaller updates. This faster release cadence will begin on August 27. This change comes just several months after Microsoft switched Visual Studio Code to weekly updates. The company said that the Extended Stable releases will remain on an eight-week cycle and that no admin changes are needed to experience the faster release cycle on the Stable channel. The new two-week release cycle will enable the faster delivery of security updates and platform improvements, all while reducing the size and complexity of individual updates. Microsoft claims that organizations will benefit from this change as it offers predictable validation cycles. For organizations that prefer a “more deliberate pace”, the Extended Stable channel remains an option. This change will affect Edge Stable releases on Windows, macOS, Linux, and mobile. The Extended Stable channel will continue to be updated every eight weeks, or every fourth Stable release, for example: versions 152, 156, 160, and 164. The Extended Stable could be a good option for organizations that don’t want the latest updates twice a month and don’t want as much hassle constantly updating browsers. In the case of Visual Studio Code, many of the updates being pushed by Microsoft are AI-related. As we all know, Microsoft Edge has a lot of AI features, so we could see Microsoft pushing more AI, thanks to the faster cycles. On the flip side, quicker releases could mean faster security updates, which is beneficial in a world where AI systems are hunting for software exploits. What do you think? Let us know in the comments. For more updates on Edge, be sure to follow Neowin's coverage. In May alone, we reported on Edge offering in-browser pop-ups to assist users with website compatibility issues, that Edge was losing Copilot Mode, and that Microsoft had fixed a plain-text password bug in Edge. Source: Microsoft 365 Admin Center
  • Recent Achievements

    • Week One Done
      davidbazooked earned a badge
      Week One Done
    • One Month Later
      Jamswaz earned a badge
      One Month Later
    • Week One Done
      Jamswaz earned a badge
      Week One Done
    • Rookie
      Marzoid went up a rank
      Rookie
    • Community Regular
      coch went up a rank
      Community Regular
  • Popular Contributors

    1. 1
      +primortal
      514
    2. 2
      PsYcHoKiLLa
      185
    3. 3
      +Edouard
      159
    4. 4
      Steven P.
      83
    5. 5
      ATLien_0
      75
  • Tell a friend

    Love Neowin? Tell a friend!