Re: Replacing div/ with div/div
On 11/5/07, Matej Knopp [EMAIL PROTECTED] wrote: Okay, I might have overlooked the *or* part with implicates that empty element shorthand should not be used for non-empty elements. Still this leaves us with 3 options. a) ignore things silently and then support lot of weird bugreport of user complaining that ajax is not working in firefox (because of the messed up DOM tree) b) fix the error for user (which is current behavior) c) throw an exception or warn user somehow If you will decide for option B, then please do it for all elements that are declared as non-EMPTY. tag/tag will be valid for all non-EMPTY elements in both HTML and XHTML. Now given that div/ might not actually be permitted in xhtml (though I'm still not 100% convinced) If you find any information that I might be wrong, then please tell me. Because it is not very logical to me too. I prefer to be wrong in this case. option c) could be better alternative to b), though I'd still insisted on doing it by default. However, we would need then some kind of mechanism that would allow us to suppress the behavior in case the document is actually an xml document and will be served as xml document. You might consider not supressing it since div/div is valid XML. Equal in XML yes. And yes, XHTML files are valid XML documents. However not all XML documents are valid XHTML files, even when using XHTML tag names. Which is kinda weird. Yes, it is weird. I was under impression that as long as you stick to the doctype (or xsd) all xml documents would be valid xhtml documents. No, not all rules can be fully expressed in DTD or even XML schema's. They only validate part of the rules. Yes, IE does not understand application/xml. And that is why I suspect that rule 4.3 exists. So that xhtml 1.0 could be server to IE, and the result would be equivalent as serving html 4.01. Ironically, IE doesn't have any problem with empty elements such as div/. That's because IE considers the DIV end tag optional, while in fact it is required.
Re: Replacing div/ with div/div
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 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
Re: Replacing div/ with div/div
Matej Knopp wrote: I haven't heard a single argument against replacing div/ with div/div except people being anxious of wicket touching the markup. The best real argument I know is that I want the HLTM to be viewable without Wicket. Of course it is fine to have Wicket provide optional behaviour to 'correct' html. Regards, Erik. -- Erik van Oosten http://2008.rubyenrails.nl/ http://day-to-day-stuff.blogspot.com/
Re: Replacing div/ with div/div
On 11/3/07, Erik van Oosten [EMAIL PROTECTED] wrote: Matej Knopp wrote: I haven't heard a single argument against replacing div/ with div/div except people being anxious of wicket touching the markup. The best real argument I know is that I want the HLTM to be viewable without Wicket. I don't understand how this change affects previewability. Of course it is fine to have Wicket provide optional behaviour to 'correct' html. It doesn't make sense to do this as optional unless it's on by default. -Matej Regards, Erik. -- Erik van Oosten http://2008.rubyenrails.nl/ http://day-to-day-stuff.blogspot.com/
Re: Replacing div/ with div/div
Matej Knopp wrote: Fixing this has practical benefits. And I haven't heard one argument against it except that wicket shouldn't do that because it's html. I have personally problems with such arguments. It just feels not pragmatic. We have three options here: 1. Fix the issue transparently for the user. 2. Tell the user they've made an error and how to fix it. 3. Not give you any help at all. I'd argue that if it's possible to make stuff just work (i.e. #1) then you should do. Computer/framework's job is to make things as easy as possible. If we can tell you how to fix an issue, then the only possible argument for not doing so automatically is if that's really hard, or if there's a performance penalty in doing that. Given this scan would only happen once per markup-file load, not on every page hit, it's probably fine performance-wise. So, uh, we should just fix it transparently. Regards, Al
Re: Replacing div/ with div/div
Though I'm not pro on this change, I suggest putting it in before rc1. Martijn On 11/3/07, Al Maw [EMAIL PROTECTED] wrote: Matej Knopp wrote: Fixing this has practical benefits. And I haven't heard one argument against it except that wicket shouldn't do that because it's html. I have personally problems with such arguments. It just feels not pragmatic. We have three options here: 1. Fix the issue transparently for the user. 2. Tell the user they've made an error and how to fix it. 3. Not give you any help at all. I'd argue that if it's possible to make stuff just work (i.e. #1) then you should do. Computer/framework's job is to make things as easy as possible. If we can tell you how to fix an issue, then the only possible argument for not doing so automatically is if that's really hard, or if there's a performance penalty in doing that. Given this scan would only happen once per markup-file load, not on every page hit, it's probably fine performance-wise. So, uh, we should just fix it transparently. Regards, Al -- 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/
Re: Replacing div/ with div/div
On 11/3/07, Eelco Hillenius [EMAIL PROTECTED] wrote: On 11/3/07, Martijn Dashorst [EMAIL PROTECTED] wrote: Though I'm not pro on this change, I suggest putting it in before rc1. Why aren't you pro? Because you don't agree with the idea, or because it is too late in the game? Ugh, nevermind. I thought this was another thread :-) I agree, we better decide on this before rc1. I'm +0. The fix looks fine, but it is yet another functional change. Eelco
Re: Replacing div/ with div/div
On 11/3/07, Martijn Dashorst [EMAIL PROTECTED] wrote: Though I'm not pro on this change, I suggest putting it in before rc1. Why aren't you pro? Because you don't agree with the idea, or because it is too late in the game? Eelco
Re: Replacing div/ with div/div
Done. -Matej On 11/3/07, Eelco Hillenius [EMAIL PROTECTED] wrote: On 11/3/07, Eelco Hillenius [EMAIL PROTECTED] wrote: On 11/3/07, Martijn Dashorst [EMAIL PROTECTED] wrote: Though I'm not pro on this change, I suggest putting it in before rc1. Why aren't you pro? Because you don't agree with the idea, or because it is too late in the game? Ugh, nevermind. I thought this was another thread :-) I agree, we better decide on this before rc1. I'm +0. The fix looks fine, but it is yet another functional change. Eelco
Re: Replacing div/ with div/div
I agree with this stance. On Fri, 2007-11-02 at 09:19 -0600, John Ray wrote: I got bit by this problem yesterday. Although I was just previewing the page in the browser by loading the HTML file directly. Since Wicket wasn't running it wouldn't have mattered if it fixed my div tag for me or not. I'd rather see Wicket not modify the HTML as it's then starting down the slippery slope of assuming the developer made an error and automatically correcting it. I think a better solution would be to have an option where Wicket looks for potential errors in your HTML and then outputs a warning to the console. John Gwyn Evans wrote: It seems to me that while it's something that Wicket /could/ do, I'm not sure if it's something that Wicket /should/ do... Having said that, I think I'd be less against it if we restricted it to only tags that had a wicket:id attribute? -- Philip A. Chapman Desktop and Web Application Development: Java, .NET, PostgreSQL, MySQL, MSSQL Linux, Windows 2000, Windows XP signature.asc Description: This is a digitally signed message part
Re: Replacing div/ with div/div
Okay. Again. This is not about developer making error! Code like this: div/ Something Is perfectly legal. However, firefox interprets it as div Something ... Which is completely wrong. This is not correcting developer error! This is correcting browser error. And such thing is very difficult to spot. -Matej On 11/2/07, Philip A. Chapman [EMAIL PROTECTED] wrote: I agree with this stance. On Fri, 2007-11-02 at 09:19 -0600, John Ray wrote: I got bit by this problem yesterday. Although I was just previewing the page in the browser by loading the HTML file directly. Since Wicket wasn't running it wouldn't have mattered if it fixed my div tag for me or not. I'd rather see Wicket not modify the HTML as it's then starting down the slippery slope of assuming the developer made an error and automatically correcting it. I think a better solution would be to have an option where Wicket looks for potential errors in your HTML and then outputs a warning to the console. John Gwyn Evans wrote: It seems to me that while it's something that Wicket /could/ do, I'm not sure if it's something that Wicket /should/ do... Having said that, I think I'd be less against it if we restricted it to only tags that had a wicket:id attribute? -- Philip A. Chapman Desktop and Web Application Development: Java, .NET, PostgreSQL, MySQL, MSSQL Linux, Windows 2000, Windows XP
Re: Replacing div/ with div/div
It does not matter who is making the error, John is still right imho. Regards, Erik. Matej Knopp wrote: Okay. Again. This is not about developer making error! Code like this: div/ Something Is perfectly legal. However, firefox interprets it as div Something ... Which is completely wrong. This is not correcting developer error! This is correcting browser error. And such thing is very difficult to spot. -Matej On 11/2/07, Philip A. Chapman [EMAIL PROTECTED] wrote: I agree with this stance. On Fri, 2007-11-02 at 09:19 -0600, John Ray wrote: I got bit by this problem yesterday. Although I was just previewing the page in the browser by loading the HTML file directly. Since Wicket wasn't running it wouldn't have mattered if it fixed my div tag for me or not. I'd rather see Wicket not modify the HTML as it's then starting down the slippery slope of assuming the developer made an error and automatically correcting it. I think a better solution would be to have an option where Wicket looks for potential errors in your HTML and then outputs a warning to the console. John -- Erik van Oosten http://2008.rubyenrails.nl/ http://day-to-day-stuff.blogspot.com/
Re: Replacing div/ with div/div
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
Re: Replacing div/ with div/div
Agreed. I understood from previous threads that it was not a developer error, but a firefox error. If we start going down this path, it is likely to get slippery indeed. I'd rather not see wicket modify markup any more than absolutely required. Are we going to fix code that breaks on all browsers? On Fri, 2007-11-02 at 20:14 +0100, Erik van Oosten wrote: It does not matter who is making the error, John is still right imho. Regards, Erik. Matej Knopp wrote: Okay. Again. This is not about developer making error! Code like this: div/ Something Is perfectly legal. However, firefox interprets it as div Something ... Which is completely wrong. This is not correcting developer error! This is correcting browser error. And such thing is very difficult to spot. -Matej On 11/2/07, Philip A. Chapman [EMAIL PROTECTED] wrote: I agree with this stance. On Fri, 2007-11-02 at 09:19 -0600, John Ray wrote: I got bit by this problem yesterday. Although I was just previewing the page in the browser by loading the HTML file directly. Since Wicket wasn't running it wouldn't have mattered if it fixed my div tag for me or not. I'd rather see Wicket not modify the HTML as it's then starting down the slippery slope of assuming the developer made an error and automatically correcting it. I think a better solution would be to have an option where Wicket looks for potential errors in your HTML and then outputs a warning to the console. John -- Philip A. Chapman Desktop and Web Application Development: Java, .NET, PostgreSQL, MySQL, MSSQL Linux, Windows 2000, Windows XP signature.asc Description: This is a digitally signed message part
Re: Replacing div/ with div/div
But we already do that. Part of Wicket as framework is to shield you from browser inconsistencies and this is one of them. -Matej On 11/2/07, Philip A. Chapman [EMAIL PROTECTED] wrote: Agreed. I understood from previous threads that it was not a developer error, but a firefox error. If we start going down this path, it is likely to get slippery indeed. I'd rather not see wicket modify markup any more than absolutely required. Are we going to fix code that breaks on all browsers? On Fri, 2007-11-02 at 20:14 +0100, Erik van Oosten wrote: It does not matter who is making the error, John is still right imho. Regards, Erik. Matej Knopp wrote: Okay. Again. This is not about developer making error! Code like this: div/ Something Is perfectly legal. However, firefox interprets it as div Something ... Which is completely wrong. This is not correcting developer error! This is correcting browser error. And such thing is very difficult to spot. -Matej On 11/2/07, Philip A. Chapman [EMAIL PROTECTED] wrote: I agree with this stance. On Fri, 2007-11-02 at 09:19 -0600, John Ray wrote: I got bit by this problem yesterday. Although I was just previewing the page in the browser by loading the HTML file directly. Since Wicket wasn't running it wouldn't have mattered if it fixed my div tag for me or not. I'd rather see Wicket not modify the HTML as it's then starting down the slippery slope of assuming the developer made an error and automatically correcting it. I think a better solution would be to have an option where Wicket looks for potential errors in your HTML and then outputs a warning to the console. John -- Philip A. Chapman Desktop and Web Application Development: Java, .NET, PostgreSQL, MySQL, MSSQL Linux, Windows 2000, Windows XP
Re: Replacing div/ with div/div
-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/
Re: Replacing div/ with div/div
See reply below 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? Yeah, because wicket's relation to java is same as it's relation to html it produces, right? This all reminds me when I introduced nested forms. People went crazy about how that's not valid and how HTML doesn't support nested forms so neither should Wicket. We are not talking about some hypothetical issue here. This behavior causes real issues and confuses people. It's causes problems that are hard to track down and that we must support because people think it's but in wicket ajax (guess to whom most of the ajax related bugs go). Fixing this has practical benefits. And I haven't heard one argument against it except that wicket shouldn't do that because it's html. I have personally problems with such arguments. It just feels not pragmatic. How far are we going to take this? Are we going to include spell checkers that automatically 'correct' misspelled words? This is a completely wrong analogy. Because misspelled words is something user is responsible for. But wrong interpretation of valid markup is not user's fault. -Matej 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/
Re: Replacing div/ with div/div
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/
Re: Replacing div/ with div/div
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/
Re: Replacing div/ with div/div
How is this relevant? You can't serve anything as text/xml or application/xml, unless you treat ie specially. I never said It's a bug in firefox, I now the behavior is intentional. But it doesn't matter for wicket, as we require that the markup is well formed (to a certain degree, e.g. not closed img tags.). So in wicket you can't leave a div opened, so there is no need for div/ to be treated as div. I wouldn't mind this behavior if it was omitted for documents with xhtml doctype, but it's not. As far as I know there is no way to serve xhtml documents with text/xml mime type that works cross browser. I kinda fail to see how this snippet from bugzilla concerns anything already said in this thread. -Matej On 11/3/07, Martijn Dashorst [EMAIL PROTECTED] wrote: 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/
Re: Replacing div/ with div/div
umm, so? that stuff is legal under xhtml which is what most apps are built with now, correct? -igor On 11/2/07, Martijn Dashorst [EMAIL PROTECTED] wrote: 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/
Re: Replacing div/ with div/div
See reply below: On 11/3/07, Martijn Dashorst [EMAIL PROTECTED] wrote: I think this change is controversial: several people have voiced their concerns regarding this change. It is something we have been opposed to until very recently (label with span/). You propose to change markup that is outside Wicket's control, I think that is a slippery slope and I advise against it, hence my -0.9. A div / does have a different meaning in XML versus HTML. We shouldn't just go about and muck things up. I've done some digging in firefox's bugzilla and found: - https://bugzilla.mozilla.org/show_bug.cgi?id=327637 - https://bugzilla.mozilla.org/show_bug.cgi?id=369609 - https://bugzilla.mozilla.org/show_bug.cgi?id=135425 where the first 2 are marked as dupes for the last one. After reading this and the firefox developers I think the div / element used in these cases is a user bug, and therefore my comparison to fixing spelling errors still holds. Does this buggy behavior still exist when you serve the page as XML? It exists when you serve it as xhtml document. However not with xml header, as I stated before, xml header is unusable. Unfortunately. So if you go ahead make sure it works for XML, XHTML and HTML documents. I don't see what possibly it could break. For xml and xhtml document, div / and div/div are semantically equivalent. For html documents div / is an error, however if we replace it with div/div the error is corrected. I think the practical approach is justified here. Most of people are using xhtml doctype. What good is xhtml doctype when you can't have valid xml tags in document? I wish we could just set the mime type to text/xml and the problem would be gone. But text/xml doesn't work in internet explorer and that is hardly a fact that you can ignore. So the only way of serving xhtml files is with html header. I know this is a browsers problem but if we used that as excuse every time we wouldn't get anywhere. Part of web framework responsibility is to shield user from inconsistencies like this. -Matej Martijn -- 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/
Re: Replacing div/ with div/div
until now we have the policy that we don't alter the markup. But we could expand all of them if needed. I don't mind to much On 11/1/07, Matej Knopp [EMAIL PROTECTED] wrote: Actually, I think that we might want to do this for all tags except for couple of selected ones, e.g. hr / This would also reduce confusion of new user when they do span wicket:id=label'/ -Matej On 11/1/07, Matej Knopp [EMAIL PROTECTED] wrote: Hi, I noticed that if you add empty div / tags to firefox, it treats it like if you forgot to close it. That can cause weird behavior on ajax replacements for example, as it treats the subsequent tags as children of the div / tag. I think we should have a MarkupFilter that replaces all div / tags with div/div. This semes to be also case for span, p, b, ... etc. -Matej
Re: Replacing div/ with div/div
That's not entirely true. E.g. we generate unique ids for script elements, that is altering markup (this is necessary for header contribution filtering). I don't think it would harm to expend those tags. -Matej On 11/1/07, Johan Compagner [EMAIL PROTECTED] wrote: until now we have the policy that we don't alter the markup. But we could expand all of them if needed. I don't mind to much On 11/1/07, Matej Knopp [EMAIL PROTECTED] wrote: Actually, I think that we might want to do this for all tags except for couple of selected ones, e.g. hr / This would also reduce confusion of new user when they do span wicket:id=label'/ -Matej On 11/1/07, Matej Knopp [EMAIL PROTECTED] wrote: Hi, I noticed that if you add empty div / tags to firefox, it treats it like if you forgot to close it. That can cause weird behavior on ajax replacements for example, as it treats the subsequent tags as children of the div / tag. I think we should have a MarkupFilter that replaces all div / tags with div/div. This semes to be also case for span, p, b, ... etc. -Matej
Re: Replacing div/ with div/div
It is semanticaly the same. And Firefox really treats div/ etc. wrong way. Should we have a vote on this? -Matej On 11/1/07, Johan Compagner [EMAIL PROTECTED] wrote: yeah we are generating extra attributes but do we introduce tags itself ? On 11/1/07, Matej Knopp [EMAIL PROTECTED] wrote: That's not entirely true. E.g. we generate unique ids for script elements, that is altering markup (this is necessary for header contribution filtering). I don't think it would harm to expend those tags. -Matej On 11/1/07, Johan Compagner [EMAIL PROTECTED] wrote: until now we have the policy that we don't alter the markup. But we could expand all of them if needed. I don't mind to much On 11/1/07, Matej Knopp [EMAIL PROTECTED] wrote: Actually, I think that we might want to do this for all tags except for couple of selected ones, e.g. hr / This would also reduce confusion of new user when they do span wicket:id=label'/ -Matej On 11/1/07, Matej Knopp [EMAIL PROTECTED] wrote: Hi, I noticed that if you add empty div / tags to firefox, it treats it like if you forgot to close it. That can cause weird behavior on ajax replacements for example, as it treats the subsequent tags as children of the div / tag. I think we should have a MarkupFilter that replaces all div / tags with div/div. This semes to be also case for span, p, b, ... etc. -Matej
Re: Replacing div/ with div/div
yeah we are generating extra attributes but do we introduce tags itself ? On 11/1/07, Matej Knopp [EMAIL PROTECTED] wrote: That's not entirely true. E.g. we generate unique ids for script elements, that is altering markup (this is necessary for header contribution filtering). I don't think it would harm to expend those tags. -Matej On 11/1/07, Johan Compagner [EMAIL PROTECTED] wrote: until now we have the policy that we don't alter the markup. But we could expand all of them if needed. I don't mind to much On 11/1/07, Matej Knopp [EMAIL PROTECTED] wrote: Actually, I think that we might want to do this for all tags except for couple of selected ones, e.g. hr / This would also reduce confusion of new user when they do span wicket:id=label'/ -Matej On 11/1/07, Matej Knopp [EMAIL PROTECTED] wrote: Hi, I noticed that if you add empty div / tags to firefox, it treats it like if you forgot to close it. That can cause weird behavior on ajax replacements for example, as it treats the subsequent tags as children of the div / tag. I think we should have a MarkupFilter that replaces all div / tags with div/div. This semes to be also case for span, p, b, ... etc. -Matej
Re: Replacing div/ with div/div
It seems to me that while it's something that Wicket /could/ do, I'm not sure if it's something that Wicket /should/ do... Having said that, I think I'd be less against it if we restricted it to only tags that had a wicket:id attribute? /Gwyn Thursday, November 1, 2007, 2:18:34 PM, you wrote: It is semanticaly the same. And Firefox really treats div/ etc. wrong way. Should we have a vote on this? -Matej On 11/1/07, Johan Compagner [EMAIL PROTECTED] wrote: yeah we are generating extra attributes but do we introduce tags itself ? On 11/1/07, Matej Knopp [EMAIL PROTECTED] wrote: That's not entirely true. E.g. we generate unique ids for script elements, that is altering markup (this is necessary for header contribution filtering). I don't think it would harm to expend those tags. -Matej On 11/1/07, Johan Compagner [EMAIL PROTECTED] wrote: until now we have the policy that we don't alter the markup. But we could expand all of them if needed. I don't mind to much On 11/1/07, Matej Knopp [EMAIL PROTECTED] wrote: Actually, I think that we might want to do this for all tags except for couple of selected ones, e.g. hr / This would also reduce confusion of new user when they do span wicket:id=label'/ -Matej On 11/1/07, Matej Knopp [EMAIL PROTECTED] wrote: Hi, I noticed that if you add empty div / tags to firefox, it treats it like if you forgot to close it. That can cause weird behavior on ajax replacements for example, as it treats the subsequent tags as children of the div / tag. I think we should have a MarkupFilter that replaces all div / tags with div/div. This semes to be also case for span, p, b, ... etc. -Matej -- Best regards, Gwynmailto:[EMAIL PROTECTED]
Re: Replacing div/ with div/div
On 11/1/07, Matej Knopp [EMAIL PROTECTED] wrote: This would also reduce confusion of new user when they do span wicket:id=label'/ have you tried that with the latest betas? :) -igor
