W3C home > Mailing lists > Public > public-html@w3.org > May 2010

Re: ISSUE-4 - versioning/DOCTYPEs

From: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
Date: Tue, 18 May 2010 13:43:53 +0200
Message-ID: <4BF27D79.2060701@disruptive-innovations.com>
To: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Cc: Boris Zbarsky <bzbarsky@MIT.EDU>, public-html@w3.org
Le 18/05/10 02:02, Leif Halvard Silli a écrit :

> Firstly, it would be very interesting to hear your view on the issue. I
> am trying to find out whether or not current editors look at the
> DOCTYPE when deciding what syntax to produce, to decide whether there
> is a need for more than the naked HTML5 doctype - in the future. That
> is my motivation for discussing NVU&  its continuation, KompoZer and
> BlueGriffon.
>
> Fact is that at least KompoZer and NVU produce Appendix C compatible
> XHTML for documents in text/html mode if the document has an XHTML
> DOCTYPE. Thus, KompoZer and NVU are dependent on the doctype in order
> to produce XHTML. (Though it is probably more correct to say that they
> produce HTML4 with XHTML syntax.) Thus I wonder what
> KompoZer/BlueGriffon would do if in HTML5 (as it stands) there is no
> way to tell (in text/html mode) whether the editor should produce XHTML
> style or HTML4 style syntax?

Wait. "no way to tell" has strictly no meaning from a DOM point of view.
In a HTML5 or XHTML5 document <img> is <img/> is <img></img>. Your
"way to tell" is based on the source, not on the DOM, AFAIC.

An editor like BlueGriffon (or the two other usual suspects) does not
care about the source. In short, serialization is only the process
needed by the user and happening just before he/she closes the
application. The app only works on the DOM. So BlueGriffon has only two
pieces of information in hand:

1. the mimetype associated with the current editor
2. the document tree with its doctype

Very naive question here: if the "Save" menu item saves the document
according to the mimetype of the editor, will a "Save as" allowing to
set that mimetype and a similar "Load as" be enough to solve your
problem?

> 0) The problem: Some HTML5 ideologues think that XHTML should only be
> produced in documents with the .xhtml file suffix.

It's a question of having a clue about the document without opening
and parsing the document. There are cases (local storage for instance)
where the file extension is really the only available information.

> 1) Currently KompoZer (and I think BlueGriffon) have  a problem with
> 'application/xhtml+xml': xml:lang="*" then becomes just lang="*". I
> have filed bug(s) against KompoZer for that. I hope it gets fixed,
> regardless of whether it will remain possible to create XHTML documents
> in text/html mode, or not.

Hmmmm....

> 2) Today one *can* chose polyglot syntax in KompoZer and NVU. And it
> doesn't require any dialog or anything. Just open an existing document
> with an XHTML DOCTYPE - and - voila. (New XHTML documents requires a
> little bit more: an active choice in the preferences and/or in the new
> document dialog.) So I wonder if the following is what I want: An
> XHTML5 polyglot doctype which is possible to use in text/html mode.
> Thus I wonder I want something *not* from BlueGriffon/KompoZer, but
> from HTML5/XHTML5/polyglot HTML5 ... What would be the best option  to
> you  - given the mass market considerations etc?

Yeah, the more I read about this issue, the more I think it's a question
of UI and app preferences and not a question of adding something to the
language.

> In KompoZer, there is a preference option: One can select to create new
> documents as XHTML 1.0 files ore as HTML 4 files. I guess a similar
> choice between XHTML5 (polyglot) and HTML5 could also be acceptable.

Sure thing.

> However, there is a problem with this: this would only work for new
> documents that I create myself. Whereas for HTML5 documents that I
> receive, there is no way to for KompoZer to know what kind of syntax I
> want. Unless, of course, it starts to depend on the file suffix.

Or unless you have a "Load as..." feature.

</Daniel>
Received on Tuesday, 18 May 2010 11:44:50 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:02 UTC