See reply below.

On 11/4/07, Robert <[EMAIL PROTECTED]> wrote:
> Matej Knopp wrote:
> > Hi,
> >
> > I noticed that if you add empty <div /> tags to firefox, it treats it
> > like if you forgot to close it.
>
> There seem to be some misconceptions about what <div /> means in this
> thread.
> It is true that in XML <div></div and <div/> are equivalent. However
> XHTML (at least 1.0) has some additional rules you have to take into
> account.
> In this case the next rule applies:
> "For non-empty elements, end tags are required"

> http://www.w3.org/TR/xhtml1/#h-4.3
> Note that an element that is allowed to have a child node is always a
> non-empty element, even if this specific element instance has no content.
> Therefore <div/> is invalid XHTML

I don't believe that holds true. <div> (without closing tag) is
invalid XHTML. Because it's not well formed. There is certain
ambiguity in that section. I don't think <div> and <div/> are the same
thing. And I don't believe that if you use <div/> that means you've
ommited the end tag. Also all the examples in section show only open
tag, not open-close. This was probably meant to make sure that people
don't follow the html practice of using just open tags.

XHTML files are valid XML documents, and disallowing <div/> tags would
be against it, as <tag></tag> and <tag/> are as far as I know
considered equal in xml.

The reason why firefox does this is the mime type that we serve the
files with. If the files are serverd with application/xml, than the
xhtml file is properly parsed and the <div/> elements are treated
well.

However, Internet explorer doesn't understand the application/xml
header, which means that we have to serve xhtml files with text/html.
And that makes firefox use the html parser, which considers <div/> an
open tag, even though it's not true.

-Matej
>
> Of course this all has to do with backward compatibility for browsers,
> so that browsers don't have to care whether they are served XHTML 1.0 or
> HTML 4.01. They can still use the same parser and use their error
> recovery to create the same DOM.
>
> In my opinion Wicket does not need to correct any of these "user
> errors", including the invalid <span wicket:id="x"/>. It just creates
> more confusion than it fixes.
>
> However what would be nice is if you could choose to let Wicket use a
> XML parser for selected templates. This can give at least two
> advantages. Less chance of user errors when writing the templates, and
> you can choose the output mode independent of the input. So you can
> easily switch between HTML, XHTML and XML output. A few years ago I
> tried to do this with Xalan, however the XHTML output still created
> invalid XHTML. Since creating valid XHTML was not a requirement for a
> valid XSLT processor nobody was worried about this, and I never got
> around to fix it myself. But it cannot be hard to do.
>
> Robert
>
>

Reply via email to