- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Mon, 26 Jan 2009 09:36:58 +0200
- To: Sam Ruby <rubys@intertwingly.net>
- Cc: HTML WG <public-html@w3.org>
On Jan 25, 2009, at 19:31, Sam Ruby wrote: > Henri Sivonen wrote: >> On Jan 25, 2009, at 16:00, Sam Ruby wrote: >>> Henri Sivonen wrote: >>>> On Jan 25, 2009, at 12:48, Sam Ruby wrote: >>>>> Julian Reschke wrote: >>>>>> Henri Sivonen wrote: >>>>>>> ... >>>>>>> Thus, "about:sgml-compat" is *not* interpreted as a URI by any >>>>>>> conforming HTML5 consumer. In my opinion, it is therefore >>>>>>> unnecessary for it to be of the form of a URI in a registered >>>>>>> scheme. >>>>> >>>>> What about XHTML5? >>>> XHTML5 doesn't need a doctype and the best practice is not to use >>>> one. >>> Can you site *any* issues with placing a DOCTYPE in XHTML5 that >>> backs up your claim that not placing an DOCTYPE in such documents >>> is a best practice? >> <!DOCTYPE html> doesn't have any useful effect in XML, so it is >> completely pointless for *XML* purposes. It would be weird to >> characterize something pointless as "best practice". (It does have >> a point for non-XML purposes in the Venus case, though.) > > Again, it is worth repeating that Venus produces a file. Whether > that file is later served as text/html or as application/xhtml+xml > is something the person who uses Venus decides. As such, <!DOCTYPE > html> serves a very valid purpose for this application. > > It would be weird to characterize <!DOCTYPE html> as anything other > than best practice merely because the output *might* be served as > application/xhtml+xml. Serving an XHTML5 file as text/html in itself (which is the reason to have a doctype in XHTML5) shouldn't be labeled "best practice". Instead, it should be labeled "Do not attempt; professional driver on closed road." As Hixie pointed out, there are many more things that one needs to be very careful about when producing a byte stream that is suited for serving as both text/html and application/xhtml+xml. We shouldn't suggest to authors in general that this stunt is something they should do aka. "best practice". >> With any doctype that points to an external subset, there are the >> following problems, the creation of which would be weird to >> characterize as "best practice": >> 1) If a URI scheme that involves network traffic to derefernce is >> used, there exists an XML parser that generates wasteful network >> traffic. (These requests have a dramatic performance impact on XML >> parsing. They are wasteful, because XHTML5 doesn't need a DTD.) >> 2) If a non-deferencable URI scheme is used, there can be assumed >> to exist a parser that fails when it is tries to dereference the >> URI and fails. >> 3) If a locally-dereferencable URI scheme (data:) is used, there >> can be assumed to exist a parser that doesn't support the scheme >> and fails. >> 4) If there is a public id, there exists a parser that doesn't >> recognize it and falls back onto the system id reducing the problem >> to points 1-3 above. >> (These problems aren't specific to XHTML5--they are general XML >> problems.) >> A doctype with an internal subset would not address you dual media >> type concern, since cruft would be rendered in existing text/html >> agents. > > I am not suggesting any of the above. I was talking about either of > the two DOCTYPEs that are defined for HTML5. I would agree that > using anything other than those two may happen to work as XHTML5, > but would not be best practice. It seems to me that one of the two doctypes is going to run into these issues. > I did not comment on this previously, but as you have persisted, I > object to you continuing to refer to XSLT as "legacy". Not to XSLT. To the serializers--in the sense that they have shipped before taking HTML5 into account. If the HTML5 spec needs to adapt to them instead of they adapting to the spec, they are legacy from the spec writing point of view. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Monday, 26 January 2009 07:37:41 UTC