Re: ISSUE-4 - versioning/DOCTYPEs

Daniel Glazman, Sun, 16 May 2010 16:22:42 +0200:
> Le 14/05/10 03:46, Boris Zbarsky a écrit :
> 
>> Hold on. We were just talking about wysiwyg HTML/XHTML editors, no?
>> Those are very much NOT text editors.
> 
> Guys, since you mentioned BlueGriffon, Nvu and Kompozer and since I am
> the original guilty one for these three editors, let me say a word.

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?

> Leif, what precisely do you miss?

I miss an outlook for the future. Today, ability to produce XHTML is 
part of KompoZer/BlueGriffon. Will that remain? This doubt/question is 
more motivated by how HTML5 has been designed (leaving no way to to 
tell editors to produce XHTML in text/html mode), than by 
doubt/questions about how the KompoZer/BlueGriffon develops.

> A dialog for polyglot documents
> allowing to select the editing mode when a document is loaded? A
> way to save a document in a given mimetype?

Here is a list of questions/options/claims:

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

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.

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?

3) What about XHTML 1.0: Will these editors continue to produce XHTML 
1.0 at all? And will they do it in text/html mode - as they do now? Or 
in application/xhtml+xml mode, as some HTML5 ideologues think? What 
about compatibility with existing XHTML 1.0 documents, which for the 
most part are text/html documents?

4) Personally, if I were asked to pick just a single "mode" for 
KompoZer/BlueGriffon, then I would ask that it *always* produced 
polyglot syntax. That is: Just continue the XHTML 1.0 tradition that 
NVU/KompoZer has started. Such documents could be used in text/html and 
in application/xhtml+xml. And such a 'one mode' option seems to me as 
the simplest "for a mass market".

> The former might be a serious burden for an editor aimed at the masses.
> It could be an add-on though.

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. 
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. 
However, in order to work with existing XHTML 1.0 files, it would 
requires that you asked authors to change the file suffix of their 
files ...
 
> I need more input from you to understand more precisely the issue here.

I hope the above helps. But I also hope that you can offer me some 
insight into whether you see a need for, so to speak, a polyglot XHTML 
DOCTYPE. Would that be a simpler way to deal with this mode switch and 
mode preserving that I am looking for, given the "for the masses" 
constraint and all that? 

*I* think that if I had to take over the control of some HTML5 files - 
or had to hand them over to someone that were using KompoZer or 
BlueGriffon - *and* I wanted these documetns to use XHTML syntax no 
matter what was going on, then it would be very practical if I could 
simply insert a XHTML Polyglot DOCTYPE into all those pages, just to be 
certain that KompoZer/BlueGriffon would respect the syntax - the same 
way that it respects XHTML syntax today, if the file has a XHTML 1.0 
doctype.  (Note to "outsiders":if  KompoZer finds a <img> in an XHTML 
file, then it turns it into <img/>. And hence, by simply changing the 
DOCTYPE to XHTML5 polyglot, I would expect that KompoZer/BlueGriffon 
took care of correcting such errors.)
-- 
leif halvard silli

Received on Tuesday, 18 May 2010 00:03:13 UTC