Doctype

by **JAB Creations** » Thu Oct 04, 2007 7:33 pm

I'm going to start by asking a question: what is with the negative and anti-doctype disposition?

by **zcorpan** » Fri Oct 05, 2007 1:16 pm

I don't understand the question.

by **JAB Creations** » Fri Oct 05, 2007 6:03 pm

Well for starters...
http://www.whatwg.org/specs/web-apps/cu ... he-doctype

I've also read a lot of posts on here where people either didn't want to use the doctype or thought a reduced doctype was the preferred way to go.

by **zcorpan** » Sat Oct 06, 2007 1:52 pm

JAB Creations wrote:Well for starters...
http://www.whatwg.org/specs/web-apps/cu ... he-doctype

I've also read a lot of posts on here where people either didn't want to use the doctype or thought a reduced doctype was the preferred way to go.

Right. Do you disagree? If so, why?

by **JAB Creations** » Sat Oct 06, 2007 11:36 pm

My question hasn't been answered, see my original post please.

by **zcorpan** » Sat Oct 06, 2007 11:58 pm

In text/html, the doctype's only purpose is to trigger a rendering mode in browsers. It doesn't do anything else. The shortest non-ugly doctype that triggers full standards mode in relevant browsers is "<!doctype html>".

In XML, doctypes are actively harmful because either communication will fail for clients with non-validating XML processors (if you use external entities), or you are wasting bandwith and time for for clients with validating XML processors (if you don't use external entities).

Does that answer the question?

by **bmcelwee** » Thu Dec 06, 2007 10:27 pm

"<!doctype html>" should not be part of HTML 5. The WD explains the spurious rationale; I have added clarifications in [brackets]:

DOCTYPEs are required for legacy reasons. When omitted, [legacy] browsers tend to use a different rendering mode that is incompatible with some specifications [HTML 4?]. Including the DOCTYPE in a document ensures that the [legacy] browser makes a best-effort attempt at following the relevant specifications [HTML 4].

So the doctype is only there to trigger standards mode in legacy browsers (e.g. IE7). But what's the point in doing that? Such browsers won't display HTML 5 correctly anyway because of all the new elements (section, nav, etc.).

If we really must have a doctype, why not make it do something useful? "<!doctype html 5>" at least lets us see that the document claims to conform to the HTML 5 spec. Otherwise, there is no way of knowing what browser should be used to view any given HTML file.

by **anne** » Sat Dec 08, 2007 9:54 pm

Triggering standards mode in HTML is done by a DOCTYPE. Changing the way to trigger standards mode is not considered to be worth it. Given that making the DOCTYPE as short as possible make sense.

Given that browsers treat all versions of HTML the same putting a version number in there doesn't make much sense.

by **bmcelwee** » Sun Dec 09, 2007 1:22 am

anne said:

Triggering standards mode in HTML is done by a DOCTYPE

Yes, that's why I had said earlier:

So the doctype is only there to trigger standards mode in legacy browsers (e.g. IE7). But what's the point in doing that? Such browsers won't display HTML 5 correctly anyway because of all the new elements (section, nav, etc.).

anne said:

putting a version number in there doesn't make much sense.

When you are writing an HTML document, you know which version of HTML you are targeting. So why not put the version number in? It doesn't hurt, and it gives useful information (for validation, etc.). It makes sense.

by **haka** » Mon Dec 10, 2007 3:47 am

A doctype with a version is important for HTML validators, HTML importers or other HTML parsers to detect the elements fit with the version. I agree that the doctype should be simple as possible, but if HTML 5 is a success (what I realy believe) there may be some more versions like HTML5tiny, HTML5print, HTML6. And to say the parser that the document is XHTML would be nice to. I know there are a lot of mixed SGML/XML documents online.

In the browser, the version definition wont make sense, but not only browsers works with HTML. There is a wide range of applications wich parses, checks or imports HTML.

So when I use an application that is HTML 5 compatible, but not HTML 6, it would be a hard work to find the unsupported elements. With a validation that detects the version by a document information its simple to find the unsupported elements.

by **zcorpan** » Mon Dec 10, 2007 7:10 pm

bmcelwee wrote:"<!doctype html>" should not be part of HTML 5. The WD explains the spurious rationale; I have added clarifications in [brackets]:

DOCTYPEs are required for legacy reasons. When omitted, [legacy]

Not only legacy, but also future. Browsers simply cannot remove quirks mode; the majority of the Web depends on it.

bmcelwee wrote:
browsers tend to use a different rendering mode that is incompatible with some specifications [HTML 4?].

More notably CSS.

bmcelwee wrote:
Including the DOCTYPE in a document ensures that the [legacy] browser makes a best-effort attempt at following the relevant specifications [HTML 4].

So the doctype is only there to trigger standards mode in legacy browsers (e.g. IE7). But what's the point in doing that? Such browsers won't display HTML 5 correctly anyway because of all the new elements (section, nav, etc.).

HTML5 browsers will have quirks mode as well.

bmcelwee wrote:If we really must have a doctype, why not make it do something useful?

It does what it's supposed to do: trigger standards mode.

bmcelwee wrote:"<!doctype html 5>" at least lets us see that the document claims to conform to the HTML 5 spec.

Why is that useful information? How would you express this information in XHTML5? What about when you only have a fragment, e.g. in an Atom feed?

[edit] Oh, and as it happens, "<!doctype html 5>" actually triggers quirks mode in Firefox and Safari. [/edit]

bmcelwee wrote:Otherwise, there is no way of knowing what browser should be used to view any given HTML file.

The latest version of a browser should be able to view all "versions" of HTML. Moreover, all "versions" of HTML should be viewable to some extent in all browsers.

This is how HTML has always worked. This is not something that is new with HTML5.

Try this: create an HTML 2.0 document and load it in the latest version of your favorite browser. Then create an HTML 4.01 document and load it in Netscape 2 or some other old browser.

by **zcorpan** » Mon Dec 10, 2007 7:27 pm

haka wrote:A doctype with a version is important for HTML validators,

Unless I'm mistaken, Henri Sivonen (who develops Validator.nu) would disagree.

haka wrote:HTML importers

Could you elaborate on how they would benefit?

haka wrote: or other HTML parsers

Do you mean "HTML parsers" as in "build a tree from this byte stream" or general UAs? If the former, I don't think they would benefit; a HTML parser would simply just use the parsing rules defined in the latest HTML spec. If the latter, could you elaborate on which UAs those would be, and how they would benefit?

haka wrote: to detect the elements fit with the version. I agree that the doctype should be simple as possible, but if HTML 5 is a success (what I realy believe) there may be some more versions like HTML5tiny, HTML5print, HTML6.

Not sure I follow here.

haka wrote:And to say the parser that the document is XHTML would be nice to. I know there are a lot of mixed SGML/XML documents online.

Surely, the MIME type says that the document is XML, not the contents of the file. No?

haka wrote:In the browser, the version definition wont make sense, but not only browsers works with HTML. There is a wide range of applications wich parses, checks or imports HTML.

Indeed, but can't they just assume the last version of HTML that they support?

haka wrote:So when I use an application that is HTML 5 compatible, but not HTML 6, it would be a hard work to find the unsupported elements. With a validation that detects the version by a document information its simple to find the unsupported elements.

I'm not sure I follow.

So your app supports HTML5. It can validate a document according to HTML5. If you feed it an HTML document with new elements that were not in HTML5, it will point out the new elements as errors. No? What makes it hard to find the unsupported elements, exactly?

Now, if this HTML document with new elements claimed to be "HTML6", what would your app do differently? Validate it as HTML5 (in which case, what is the difference?)? Refuse to validate the document (in which case, how do you find the unsupported elements?)?

by **bmcelwee** » Tue Dec 11, 2007 8:55 am

zcorpan wrote:The latest version of a browser should be able to view all "versions" of HTML. Moreover, all "versions" of HTML should be viewable to some extent in all browsers.

Actually, I can see why this is a good thing, and I see why this makes the version number in the doctype unnecessary.

I think I also see something I have been missing: I thought that there was a new language called "HTML 5" that was being specified. I didn't understand why the draft spec talked about legacy stuff: that's all dealt with in the earlier spec.

But I see now that version 5 of the spec actually subsumes and replaces all previous versions. So as well as specifying what a valid HMTL file is, it also needs to allow old HTML files to continue to be renderable as far as is reasonably possible.

Maybe the spec didn't make the separation clear enough for me. I was blinded by my dismay at the hilarious suggestion of retaining the font tag...

by **zcorpan** » Thu Dec 13, 2007 9:59 am

bmcelwee wrote:But I see now that version 5 of the spec actually subsumes and replaces all previous versions. So as well as specifying what a valid HMTL file is, it also needs to allow old HTML files to continue to be renderable as far as is reasonably possible.

Correct.

by **jkilgrow** » Fri Oct 29, 2010 8:24 pm

zcorpan wrote:So your app supports HTML5. It can validate a document according to HTML5.

How? If there is no DTD, how can validation on a document be accomplished? If there is a DTD, where is it? Do I have to build it myself based off of the spec? Is it just not published yet? What?

zcorpan wrote:What makes it hard to find the unsupported elements, exactly?

Well....the lack of a published DTD for starters.

I'm not saying there "isn't" a published DTD. I'm sure there is otherwise there would not be a W3C validation tool online. I'm just asking "where can I get my hands on a copy of that DTD?"

The online validation tool is fine if you are manually validating a few pages but if I have to/want to validate hundreds of pages each day, I'm not going to use the online validator unless there is some webservice API that I can code to. And if that is the case, where is the documentation for that? I have found the XML documentation for the messages going "into" the W3C validator but I have no idea what they look like coming "out".

Sorry...very frustrated. Any help/advice is appreciated.

Thanks

Doctype

Doctype

doctype for document validation

Who is online

Who is online