>From the firefox bugzilla [1]: Resolving INVALID. To cut a long story short, remember that if you're serving this kind of markup as text/html, it will be accepted by older user-agents and probably throw a monkey wrench into their parsing. If you don't care about these user-agents, you should just switch to text/xml or application/xml to deliver your content :) We uphold this (and the W3C Markup Working Group agrees) so that people aren't tempted to try to throw XML constructs at these old user agents. (Incidentally, if you've been having problems with IE displaying "raw" XML when you give it XHTML with an XML content-type, I understand an "identity" XSLT stylesheet--that is, one that invokes XSLT processing but doesn't actually transform any of the document--applied to such documents will make IE work fine with them.)
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=135425#c5 On 11/2/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > i am +1 to fix this. > > a) we already support <span wicket:id="label"/> which expands to > <span></span> - give that is a wicket component, but still > b) <tag/> and <tag></tag> are semantically equivalent and thats how > browsers represent tags internally anyways > c) it solves a class of problems that is hard as hell to debug/find > d) it makes our ajax support more resilient > > can someone mention a few cons...? > > -igor > > > > On 11/2/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote: > > -0.9 on 'fixing' something that is b0rken in an external browser. I > > don't mind having fixes in javascript libraries to wrinkle out > > inconsistencies or work around bugs: these are local to the > > functionality in the js libraries. > > > > 'Fixing' HTML feels like fixing Java code for our users. If for some > > reason javax.util.Foo doesn't work on windows are we going to > > automatically replace the code with javax.tools.Bar? > > > > How far are we going to take this? Are we going to include spell > > checkers that automatically 'correct' misspelled words? > > > > Martijn > > > > On 11/2/07, Matej Knopp <[EMAIL PROTECTED]> wrote: > > > This doesn't really lead anywhere. > > > > > > I haven't heard a single argument against replacing <div/> with > > > <div></div> except people being anxious of wicket touching the markup. > > > > > > But you should realize that without this, you can't even put <div/> > > > inside markup because it breaks the DOM in firefox. So what's the > > > point? > > > > > > I really don't think that "I don't want wicket to touch my markup" is > > > a valid point. All Wicket does it touching the markup. So why this > > > particular case is wrong when it doesn't break anything (I know about > > > - If i'm wrong on this please anyone correct me), but, rather than > > > that it fixes real problems? > > > > > > -Matej > > > > > > On 11/2/07, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: > > > > A Html error finder (IMarkupFilter) already exists but is disabled by > > > > default. We could extend it or create a new one. Actually anybody can > > > > create it and provide it to us. > > > > > > > > Juergen > > > > > > > > > > > > > -- > > Buy Wicket in Action: http://manning.com/dashorst > > Apache Wicket 1.3.0-beta4 is released > > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta4/ > > > -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0-beta4 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta4/
