Re: Content-type for XHTML (was: XMLC, setEnableXTHMLCompatibilty)
Jacob Kjome <[email protected]> Wed, 08 Oct 2003 01:15:45 -0500
| Newsgroups | gmane.comp.java.enhydra.xmlc |
|---|---|
| Message-ID | <[email protected]> |
Hi David, I figured a few things out. Read below... At 04:07 PM 10/7/2003 -0400, you wrote: > A little research shows that If I'm sending it down as >"application/xhtml+xml", the SHOULD include the XML stylesheet processing >instruction (http://www.w3.org/TR/xhtml-media-types/). I don't have such in >mine, because I "want no XML styles applied". To me, it's just a "very well >formed" HTML document. Could this be the problem? No. I read that statement as (see my comments included in square brackets)... "When serving an XHTML document with this media type, authors SHOULD include the XML stylesheet processing instruction [<http://www.w3.org/TR/xhtml-media-types/#ref-xml-stylesheet>XMLstyle] to associate style sheets [instead of <style> or <link> elements]." To put it another way, *if* you want to include styles (and you don't *have* to), then you should use the XML stylesheet processing instruction rather than the HTML-centric <style> and <link> elements. Of course, the <link> will still work while <style> is probably to be very discouraged (since style information is XML CDATA). Either way, including style sheets is not a requirement of an XHTML document. >That having been said, I'm using Mozilla 1.3a. It has "Render Mode: >compliance mode, Type:application/xhtml+xml, and Endcoding:UTF-8". Yep, that's good. Do one more thing (which the w3c validator doesn't seem to properly check). Add the xhtml namespace to the <html> element like this... <html xmlns="http://www.w3.org/1999/xhtml"> That one little change will cause Mozilla to realize that the elements in the document are actually XHTML which allows it to render the document properly rather than seeing it as unrecognized XML. *All* of your XHTML documents should have this with no exceptions if you want to avoid future problems with XHTML (and XML in general). BTW, you might notice that the rendering is done as you'd expect this time. When documents are served up under text/html, Mozilla uses the HTML parser to parse the document. Since the HTML parser doesn't understand <div />, you get the faulty rendering you noticed. However, when the document is served as application/xhtml+xml (and you have included the xmlns declaration mentioned above), Mozilla uses the XML (XHTML) parser to parse the document. The XML parser, obviously, understands <div />, so it renders it just fine. Mozilla is doing the right thing here. We just need better tools to detect these things in editing. Mozilla is great at this, but doesn't provide us with information on why something isn't working. It just does the right thing and we are none-the-wiser until a bit of further thought. >When accessed on IE 6+, it warns the user about installing things, and then >asks "Open or Save". Of course, here's the big problem. IE absolutely does not support rendering documents served with application/xhtml+xml. What a lame POS it is!!! Well, anyway, that's reality and we have to deal with it. So, the solution is to serve things up with the text/html mime type ( use -domfactory org.enhydra.xml.xhtml.HTMLDomFactory or set it in the OutputOptions which, I think, can override the compiler-suggested mime-type??? ). But, again, the problem is that this will trigger Mozilla to use the HTML parser and render <div /> improperly. Of course IE will render <div /> like that anyway since it *always* uses the HTML parser for everything. So, the solution is what you suggested before: add all "element[s] whose content model is not EMPTY" as tags which are to have a forced </endtag> when using opts.setEnableXHTMLCompatibility(true). I will try to add this tomorrow to CVS. I hate IE so much!!!! Jake