Re: Content-type for XHTML (was: XMLC, setEnable: msg#00025 java.enhydra.xmlc

On Wednesday 08 October 2003 02:15, Jacob Kjome wrote:
> Hi David,
>
> 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).

I'm more than willing to try it, but it's really a moot point unless we solve
the IE issue

>
> 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.

Should really need the Namespace declaration? Shouldn't the Content-type (not
to mention the document type) be adequate? (My question here is, "isnt this
a minor Mozilla bug? )

> 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!!!!

Is there perhaps some other Content-Type that would make IE understand it,
even if it's non-standard?

>
> Jake
>
>
> _______________________________________________
> XMLC mailing list
> XMLC@xxxxxxxxxxx
> http://www.enhydra.org/mailman/listinfo.cgi/xmlc

Previous by Date:	Re: Content-type for XHTML (was: XMLC, setEnableXTHMLCompatibilty), Jacob Kjome
Next by Date:	Re: Content-type for XHTML (was: XMLC, setEnableXTHMLCompatibilty), Jacob Kjome
Previous by Thread:	Re: Content-type for XHTML (was: XMLC, setEnableXTHMLCompatibilty), Jacob Kjome
Next by Thread:	Re: Content-type for XHTML (was: XMLC, setEnableXTHMLCompatibilty), Jacob Kjome
Indexes:	[Date] [Thread] [Top] [All Lists]

Re: Content-type for XHTML (was: XMLC, setEnableXTHMLCompatibilty): msg#00025

java.enhydra.xmlc