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