Fred Drake schrieb:

> On 10/14/05, Tonico Strasser <[EMAIL PROTECTED]> wrote:
>> HTML mode is still useful for user agents that use a SGML parser instead
>> of a XML parser and would break if they had to deal with real XML code.
>> I know, such user agents are very rare, Netscape 4 comes into my mind.
>> (If you want to make Netscape 4 burn just put a <br/> somewhere in the
>> source).
>> Why does HTML mode help? It converts <foo/> to <foo />.
> We can make the XML mode do this as well, though, and would need to in
> order to have modeless output.

So if the goal is to make PTs modeless and to dismiss HTML support (not XHTML support) and preserve some backwards compatibility this is OK for me. Because I don't deal with classic HTML.

A valid HTML but invalid XHTML snippet:

    <UL id=snippet>

> Where you want a "real" SGML parser to handle the document, the slash
> isn't acceptable.  <foo/> isn't accepted for empty elements by most
> SGML parsers, that's new syntax for XML.  The W3C HTML validator, for
> example, won't accept it.
> Using the XHTML backward-compatibility guidelines does not provide for
> valid HTML; those are designed for happy browsers, not valid HTML.

Yes. (However, most HTML browsers are happy and tolerate backward compatible XHTML code, the spec is telling us.)

>> MSIE is known to handle XHTML pretty well althought it doesn't use a XML
>> parser. IE can deal with <br/> but it can't deal with <script/>. You
>> have to write <script></script> for IE.
> Yes, which seems like it is a case that might need special handling,
> since we want that to be automatic.  Since for XML <script/>, <script
> />, and <script></script> are semantically identical, I don't see a
> problem with that.

Technically speaking there is no problem in supporting IE. As you noted on the wiki, that means that we *must* send a 'text/html' mime type, and that means that the mime type must be independent of the ZPT XML mode.

There are lots of XML mime types anyway. I think one question is wheter a Page Templates should know the mime type of the rendered document. If the answer is no, we could use the generic 'application/xml' (or 'application/zpt+xml') media type internally.

>> From this information I come to the conclusion that it would be best to
>> simply follow the compatibility guidlines in appendix C. HTML mode helps
>> me to do this by inserting a space before the closing slash.
> I suspect the right thing is to make sure XML mode supports the XHTML
> recommendations, since those are designed to be entirely
> XML-acceptable.

The conclusion was for me as HTML author not for the ZPT implementation :)

FWIW, besides appendix C, I don't belive there are any special things in the XHTML recommendation that makes XHTML different from regular XML for a XML parser.


Zope3-dev mailing list

Reply via email to