Re: XMLC, setEnableXTHMLCompatibilty

On Monday 06 October 2003 19:14, Jacob Kjome wrote:
> Hi David,
>
> At 03:43 PM 10/6/2003 -0400, you wrote:
> >About a year ago, I submitted a patch which was "converted" to become the
> >enableXHTMLCompatibilty of OutputOptions.  Aside from the name change, the
> >functionality of the patch (always use "close tags" , rather than an
> > implied close) was limited to only the SCRIPT tag.
>
> Yes, since it is the only case that I know of where HTML allows for an
> empty or close tag *and* where IE has troubles dealing with the empty
> version.  Since either is valid XHTML, we choose the version that IE deals
> with when using enableXHTMLCompatibility(true).
>
> >Based on my recent experiences, this is wrong.  ALL tags need to be closed
> >with an explicit close tag to work in both Mozilla and IE.
>
> Hmm....  examples please?  I hope you don't mean <br></br> and the
> like.  That is just plain invalid.  And I'm guessing you mean it won't work
> with IE but Mozilla works just fine in almost every case.  Please provide
> markup (in an html document attached in a zip file so it isn't inlined in
> the email) which doesn't work for you and explain what exactly about it
> doesn't work.

No, not so much for br, though it seems that they handle closing tags for 
INPUT, IMG, etc just fine.  (Not that I want to force those, but all the 
things that CAN have close tags seem to need them)

But what I see happening, is that when I generate XHTML like this:

--snip--
<div>
        Title
        <div class="foo" />
        More content
</div>
Final Content
--end--

--snip--
I get very different results than when I generate

<div>
        Title
        <div class="foo" ></div>
        More content
</div>
--end--

Essentially, the browser is ignoring the implcit end of the second div.