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

Re: ISSUE-4 - versioning/DOCTYPEs

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Wed, 19 May 2010 02:59:59 +0200
To: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
Cc: Boris Zbarsky <bzbarsky@MIT.EDU>, public-html@w3.org
Message-ID: <20100519025959482590.e62a9e3c@xn--mlform-iua.no>
Daniel Glazman, Tue, 18 May 2010 13:43:53 +0200:
> 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.

It is based on the source, yes, to the extent that the DOCTYPE is 
considered "source". That is why I said that KompoZer creates XHTML as 
if it were HTML4 - with the difference that it adds some XHTMl specific 
features ("/>" and xmlns and so on): KompoZer operates with a text/html 
DOM, but makes sure that it creates XHTML compatible output. 

> 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.

So I guess that "sniffing" the DOCTYPE is no problem in KompoZer, 
because it doesn't need to actually create the XHTML syntax until the 
author *saves* the document. So the "sniffing" takes place long before 
the file is edited and save again.

> 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?

Do you by "Load as" refer to a preference? Certainly, this would also 
help. Saving it according to the MIME type will of course also help - 
if switching the mime type has a wished for effect, then it will be 
used. 

But with regard to "Save as": Let's say that I was creating a 
file.xhtml document. What will then happen if I save it as .html? Will 
<img/> become <img>? In general, one can always open and save as - to 
convert the syntax. But it is irritating to not know - to not be in 
control.

>> 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.

But HTML5 has two syntaxes - at least if we judge things according to 
tradition: in HTML5, then <img/> is permitted inside text/html.
 
>> 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.

Currently, in KompoZer, we have both: We have two different doctypes 
(XHTML1 vs HTMl4) and we have preferences.
 
>> 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.

Load as what? And should it be "with" instead of "as"? Load *with* 
XHTML syntax? Once the page has been loaded, how does KompoZer know how 
to save the page?  How do I as author know how this page will be saved? 
Will you show a tag so that I remember that I chose to use XHTML 
syntax?  ... In my view it is much simpler if there is a DOCTYPE to 
respect. Then the author can look into the code to find the 
explanation, if need be.
-- 
leif halvard silli
Received on Wednesday, 19 May 2010 01:01:14 UTC

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