W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2004

[whatwg] Re: DOCTYPE shouldn't be optional

From: Ian Hickson <ian@hixie.ch>
Date: Wed, 7 Jul 2004 16:14:51 +0000 (UTC)
Message-ID: <Pine.LNX.4.58.0407071551350.24332@dhalsim.dreamhost.com>
On Wed, 7 Jul 2004, Malcolm Rowe wrote:
>
> [I would note that, in general, there is no way to determine what the
> meaning of a document composed from multiple namespaces is. That very
> issue is actually the topic of the W3C TAG's issue
> mixedNamespaceMeaning-13, now subsumed by mixedUIXMLNamespace-33 [2],
> focussing on XHTML, MathML, SVG, etc.]

I don't really buy that it isn't defined. A lot of people seem to think
that compound documents are An Area That Needs Work, but I don't really
see it. Specs by and large define how they work and what they mean. Things
that aren't defined anywhere are meaningless.

For example,

   <html xmlns="http://www.w3.org/1999/xhtml">

    <title>
     This is a title, even though it's not in a HEAD element.
     It's not valid XHTML, but it is still defined.
    </title>

    <foo:bar xmlns:foo="http://example.org/">
     This element is semantic-free and meaningless.
     It is bad to send content that is semantic-free over
     the wire, but it can be useful if the semantic isn't
     necessary for understanding the document, for example
     if you just need a hook to attach style to.
    </foo:bar>

    <div>
     This element is semantic-free as well.
     You can use this in HTML when HTML lacks the necessary
     elements to express your meaning, and when none of the
     other elements are a better approximation.
     (If you need this element, tell WHATWG what tag they
     should add to Web Apps 1.0 so that you no longer need it.)
    </div>

    <svg:rect xmlns="http://www.w3.org/2000/svg">
     This element is semantic-free and meaningless as well,
     because SVG is only defined when there is a parent
     SVG element.
    </svg:rect>

    <svg:svg xmlns="http://www.w3.org/2000/svg"
             width="10" height="10">
     <svg:rect x="0" y="0" width="10" height="10"
               fill="blue">
      <!-- This is a blue square. That's all that
           this element means. -->
     </svg:rect>

     <p> This is an HTML paragraph. It won't be displayed, because SVG
     defines its rendering model such that foreign elements are
     ignored when rendering. But it still has the semantic of being a
     paragraph of text. </p>

    </svg:svg>

   </html>

I'm not claiming everything is well-defined. There are plenty of edge
cases that aren't. But that's not a problem inherent to Compound
Documents, it's a problem of the specs being too vague.


> It *is* true to say, contrary to what I said before, that you don't need
> to have a DOCTYPE to be 'an XHTML document' (which isn't a well-defined
> term, I agree). However, it's also true to say that you do need a
> DOCTYPE to be a 'strictly conforming XHTML document'.

Yes.


> Perhaps you could add a note in the prose about 'strictly conforming
> XHTML documents'?

I could, but the note would be:

   Note: Documents that use the new features described in this
   specification cannot be strictly conforming XHTML or HTML4 documents.

...and I'm not sure how that would help anything.


>> The only difference between a document that complies to XHTML 1.0, and
>> the document you create by using XML, "Namespaces in XML", and the
>> XHTML namespace, is the presence or absence of the DOCTYPE.
>
> Not strictly true, actually - there are also some restrictions on DTD
> subsets, for example.

Sure. What I meant was that if you created a document using the starting
point of the XHTML spec, then created the same document using the starting
point of the XML and Namespaces specs, you would end up with two identical
documents except that one lacked a DOCTYPE.

It is true that there are other restrictions on what makes a strictly
conformant XHTML document. For example, you can't use namespace prefixes.


> Perhaps you could change the prose to read something like the following:
>
> HTML documents that use the new features described in this specification and
> that are served over HTTP must be sent as text/html and must use the
> following DOCTYPE: <!DOCTYPE html PUBLIC "-//WHATWG//NONSGML HTML5//EN">.
>
> XML documents using elements from the XHTML namespace that use the new
> features described in this specification and that are served over HTTP must
> be sent using an XML MIME type such as application/xml or
> application/xhtml+xml and must not be served as text/html. [RFC3023]
>
> These XML documents may contain a DOCTYPE if desired, but this is not
> required unless the document is intended to be a 'strictly conforming XHTML
> document' as defined by the XHTML specification [XHTML1].
>
> Thoughts?

What's an "HTML document"?

But yeah, that text is better than what we have now. Changed.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 7 July 2004 09:14:51 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:35 UTC