Re: ISSUE-4 - versioning/DOCTYPEs

On 5/14/10 12:01 PM, Leif Halvard Silli wrote:
>>> But, based on the file suffix *only*?
>>
>> That's the simplest thing, yes, and the one set up by default, though
>> of course you can set up your own conditions for picking the mode
>> using a turing-complete programming language that has full access to
>> the file data.
>
> But "out of the box", doesn't an XHTML1 doctype cause XHTML syntax if
> the suffix is .html?

In Emacs?  Not at all.  It completely ignores the doctype out of the box 
in its HTML mode (which is what .html loads).

>> And again, unless the editor _parses_ your polyglot .html file as XML
>> it will almost certainly fail to create a useful polyglot document
>> when it saves. I have a hard time believing that most editors parse
>> .html files as XML even if they sniff the XHTML doctype (again,
>> because most such files are not well-formed XML).
>
> KompoZer don't. But I think some pure XML editors might do.

Sure; they parse everything as XML no matter what it actually is. 
They'd parse your JPEG as XML too, if you told them to edit it.

>>> Yes. But I think that, to a degree, some DOCTYPEs already causes
>>> polyglot mode. E.g. KompoZer turns<img></img>   into<img />.
>>
>> That's just a matter of the fact that Gecko's editor (and presumably
>> KompoZer too, if in a different form) has a hardcodedlist of empty
>> HTML tags and tries to make use of it.  This doesn't even have to be
>> a mode switch.  It could just be done all the time.
>
> So, what you say here means that there are some *advantages* to
> creating polyglot syntax in text/html mode, because the limitations are
> defined by text/html parsers more than by XHTML parsers. ;-)

No, the limitations are very much defined by both.  The limitations on 
what you do with <img> are defined by both, for sure.

-Boris

Received on Friday, 14 May 2010 17:24:47 UTC