Re: <!DOCTYPE html> vs (polyglot) spec

Henri Sivonen, Tue, 27 Apr 2010 06:13:09 -0700 (PDT):
> In my opinion, tools like KompoZer should use the XML serialization 
> if the file name ends in .xhtml and the HTML serialization if the 
> file name ends in .html.

It would be great if they did! But ... 

1) How does the HTML serialization look like? <link /> or <link>?

2) Do you have behavior data? Some mixed Mac & Windows data:
2A) Preselected suffix when creating a new XHTML 1.0 file:
    .xhtml: Oxygen [for Strict doctype only].
     .html: (texteditors:)  Seedit, TextMate, Notepad++
            (WYSIWYG-ish:) Amaya, KompoZer, NVU,
            XMLmind XML Editor, Oxygen [for Transitional doctype],
            [ and many many more ]
      .xml: Serna
     The above means that tools in the wild do not ignore whether
     the DOCTYPE says XHTML or HTML4.
     Ignoring DOCYPE could destroy the XHTML documents with .html
     suffix, when they were reinterpreted as HTML4-ish documents.
     Curiosa: OpenOffice's XHTML export defaults to .html, even
              when using the XHTML 1.1 plus MathML doctype.

2B) Preselected suffix when saving one of Sam's pages,
    (application/xhtml+xml & <!DOCTYPE html>):
    .xhtml: Safari, Firefox, 
     .html: NVU, KompoZer, BlueGriffonALPHA, IE7-8, 
            SeaMonkey Composer, iCab (iCab being corrected)
      .xml: Opera

2C) Browser/browser editors maintaining XHTML syntax of
    (application/xhtml+xml & <!DOCTYPE html>)
    when saving to disk:
       Yes: Firefox, Opera, Webkit, IE
        No: NVU, SeaMonkey Composer, BlueGriffonALPHA, KompoZer

2D) Repeating 3C) for the No-tools, with an XHTML doctype added:
      Yes, now it is preserved: NVU, KompoZer 
      Doesn't matter: SeaMonkeyCompozer, BlueGriffonALPHA

3) Editors (humans and apps) want to know, when they create new 
documents, and before they save the document (thus: before they add any 
suffix), whether they deal with a HTML4-ish or XHTML-ish syntax.

Btw, what are 'tools like KompoZer'?
> Polyglot documents provide enough rope for authors to shoot 
> themselves in the foot with, so I think tools like KompoZer shouldn't 
> attempt to generate polyglot documents.

It's more or less norm, for editors (humans + apps) to, when they 
create non-compound XHTML documents, use polyglot syntax. 

And many Web apps that are based on XHTML stretch the interpretation of 
what polyglot syntax is far beyond Appendix C. E.g. check the 
<meta></meta>, the <link></link> and the <img></img> elements of the 
web site of the popular (in Scandinavia) platform Idium, It creates fully valid XHTML pages, served as 

> Not attempting the [to] generate polyglot documents removes the need
> to address problems related to polyglot documents.

The KompoZer devs could indeed say "sorry, no more <img /> with our 
tool". But, they could just as well say "Always <img /> with our tool". 
The latter option would be much more universally useful.

Following your logic to the end, one shouldn't even need to use 
<!DOCTYPE html> in XHTML documents. In practice, this would lead to 
Quirks Mode galore.
leif halvard silli

Received on Tuesday, 27 April 2010 19:10:04 UTC