At 08:58 AM 10/8/2003 -0400, you wrote:
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
IE is being buggy. Mozilla is doing the right thing. They way to solve
the issue is to return markup that an HTML parser can understand and return
a mime type that IE can understand.
>
> 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? )
XHTML is XML. If you don't provide a namespace, you have tag soup. Keep
in mind that XHTML allows for other types of XML being part of the document
(based on other dtd's). If it just assumed all tags were XHTML, then this
extensibility wouldn't be possible. Again, Mozilla is doing the right
thing and IE isn't even using an XML parser when evaluates XHTML. Even
when IE is given an XML document (with the mime type of text/xml) which
points to an XSLT file and is transformed, the result is rendered using the
HTML parser, not the XML parser. Don't let IE's sloppy behavior fool you
into thinking that Mozilla's strict behavior is incorrect.
> 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?
Well, if it is non-standard, then it wouldn't work with any browser other
than IE. That isn't a solution. IE is very wishy-washy with
mime-types. Sometimes it ignores them altogether causing many headaches
for developers. Pandering to IE's buggy behavior is not the right thing to
do. Your only option for cross browser compatibility is to use the
text/html mime type and the change I suggested above. I'll try to do this
today. I'd be willing to release an XMLC-2.2.3 for this issue alone,
although it would be nice if other issues were found to fix before that
happens.
Jake
| 