Re: ISSUE-4 - versioning/DOCTYPEs

Boris Zbarsky, Fri, 14 May 2010 12:47:40 -0400:
> 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).

Cool. If my text editor behaved like that, I then I bet I would use it 
whenever I needed XHTML syntax, regardless of how I would serve it. 
Does it also provide HTML5 syntax error coloring in HTML mode?
 
>>> 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.

I had in mind WYSIWYG XML editors - with built in image display.
 
>>>> 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.

The text/html editor advantage is that it knows which elements are 
void. Syntax coloring goes a long way in getting  authors to do it 
right. 
-- 
leif halvard silli

Received on Friday, 14 May 2010 21:19:16 UTC