Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Minor
-
Resolution: Fixed
-
Affects Version/s: Release 1.5.1
-
Fix Version/s: Release 1.5.7, Release 1.6
-
Component/s: None
-
Labels:None
Description
Hello, If I use an input tag like this:
<stripes:text name="website.url" size="30"></stripes:text>
It'll generate some html like this:
<input name="website.url" type="text" size="30" />
But, if your html is using a doctype like this:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
That form is actually invalid. It should instead generate HTML like this:
<input name="website.url" type="text" size="30">
Or this:
<input name="website.url" type="text" size="30" ></input>
Here is a validator that you can test this with: http://validator.nu
Paste this html into it to see for yourself:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head><title>title</title></head>
<body>
<form action="na">
<div>
<input name="website.url" type="text" size="30"/>
</div>
</form>
</body>
</html>
This HTML will validate after you remove the trailing / on the input tag.
Activity
As I've been told on #css on freenode, http://validator.w3.org/ should not be used because it's validation rules are out of date.
Another thing I wanted to mention is that this form is actually invalid in HTML:
<input name="website.url" type="text" size="30" ></input>
It should not be considered as a way to solve this problem.
>As I've been told on #css on freenode, http://validator.w3.org/ should not be used because it's validation rules are out of date.
Perhaps if you're using one of the newer specs. But HTML 4.01 Strict is not new and the rules haven't changed. If you're declaring your page as HTML 4.01 Strict, the validator checks according to that spec and the Stripes tags pass that validation. As mentioned above, there are warnings for <FOO/> but do not cause problems in modern browsers.
I think this issue should be closed.
The Stripes input tags generate valid HTML. Using <input/> just gives you a warning for the HTML DOCTYPE mentioned, but <input> would break XML-based DOCTYPES.
I came to Stripes because it promised something that Struts and JSF did not... developers and engineers that understood that the View was as important as the Model and the Controller.
We should not be dismissing this as "not a bug," or "it's only a warning," or worse, "I heard on the internets." Let's get to the heart of the problem.
This is a configuration issue or enhancement to the tag library. On the gmane list, a great forum FAQ was cited, http://www.sitepoint.com/forums/showthread.php?t=393445, and I'll back that up with another great article on the argument of XHTML v. HTML from the engineers of WebKit, http://webkit.org/blog/68/understanding-html-xml-and-xhtml/
"...the vast majority of supposedly XHTML documents on the internet are served as text/html. Which means they are not XHTML at all, but actually invalid HTML that's getting by on the error handling of HTML parsers. All those 'Valid XHTML 1.0!' links on the web are really saying 'Invalid HTML 4.01!'."
I see this as a problem that the default response to tags is rendering source that follows the W3C recommendations for porting your HTML to XHTML. This default response should be HTML. And an XHTML response should be configurable by implementer of the library or the view developer.
Let's consider reopening this...
I'll address Frederic's Oct '08 comment in a moment.
First, XHTML is a dead spec. The W3C ended recommendation work in June 2009.
This move by the W3C validates the reporter, my comment and the work of WHATWG, WebKit, and many others. It's time for Stripes to drop the XHTML notation rendered by default in empty elements, e.g., input and img.
HTML 5 is the emerging standard. Molly Holzschlag, not just any "Molly," says it best, "implementation trumps recommendation." So, while HTML5 is not a recommended spec, it's clobbering XHTML and is in wide use and advocation. HTML5 is center stage in the Apple v. Adobe "debate" (with MSFT recently citing HTML5 as the basis for IE9, a subtle thumbs up for Apple without alienating Adobe, and more importantly IE9 bloggers are using HTML5 in active communication with developers).
I stand by my argument that "... the default response should be HTML [4.01 Strict]. And an XHTML response should be configurable by implementer of the library or the view developer."
Please fix the HtmlTagSupport method writeSingletonTag implementation. I've even provide a diff below.
Maybe you don't want break the current implementation? Then consider allowing a configuration in the DD for XHTML v. HTML 4/5, so that I, and others, can get on with the work of building modern web pages that are not shackled to a dead specification.
tstone@jagdtiger [~] % diff -u ~/Downloads/stripes-1.5.3/stripes/src/net/sourceforge/stripes/tag/HtmlTagSupport.java /tmp/HtmlTagSupport.java
— /Users/tstone/Downloads/stripes-1.5.3/stripes/src/net/sourceforge/stripes/tag/HtmlTagSupport.java 2009-12-16 08:46:54.000000000 -0500
+++ /tmp/HtmlTagSupport.java 2010-05-25 10:47:04.000000000 -0400
@@ -175,7 +175,7 @@
writer.print("<");
writer.print(tag);
writeAttributes(writer);
- writer.print(" />");
+ writer.print(">");
}
catch (IOException ioe) {
JspException jspe = new JspException("IOException encountered while writing singleton tag <" +
tstone@jagdtiger [~] %
Regarding the comment by Frederic, "Using <input/> just gives you a warning for the HTML DOCTYPE mentioned, but <input> would break XML-based DOCTYPES."
What XML-based DOCTYPES specifically? XHTML 1.0? XHTML 1.1? As noted, the W3C dropped them. And to make the case stronger for Stripes to fix this, or provide a configuration, as currently implemented by almost all XHTML advocates, XHTML is not correct. It is delivered the vast majority as "text/html" (which makes it just "invalid HTML 4.01") not the XHTML required "application/xhtml+xml". Serving XHTML correctly breaks web page in most widely distributed MSIE browsers, cause a download event, not a render event.
- writer.print(" />"); + writer.print(">"); } catch (IOException ioe) { JspException jspe = new JspException("IOException encountered while writing singleton tag <" + tstone@jagdtiger [~] %
Timothy,
Unless something has changed and HTML5 has gone "main stream" / beyond "expiremental" I think the HTML5 argument of this is the next upcoming thing and we should implement for it now is irrelevant. There are ample Developers using HTML 4.01 and your argument would best stick there IMHO....
Also as you speak to the W3C considering XHTML dropped / dead then it ONLY naturally makes sense to consider the W3C Validator (http://validator.w3.org/) in presenting your case and NOT the Validator at http://validator.nu ... which in the simple test cases you provided DOES NOT provide the same results.
With that said, I agree, it would be a good idea for Stripes to allow configurable support for HTML 4.01+ vs. XHTML doc type.
However what you have TODAY with your example and Stripes 1.5.X GENERATES:
<input name="website.url" type="text" size="30"/>
1) HTML 5: "This document was successfully checked as HTML5!"
2) XHTML 1.0 Strict: "This document was successfully checked as XHTML 1.0 Strict!"
3) HTML 4.01 Strict: "This document was successfully checked as HTML 4.01 Strict!" with 1 WARNING... YES... a WARNING not an ERROR it still successfully validates... and true a WARNING is annoying indeed... .
However the snippet of code you provide IS NOT configurable and instead GENERATES:
<input name="website.url" type="text" size="30">
1) HTML 5: "This document was successfully checked as HTML5!"
2) XHTML 1.0 Strict: "Errors found while checking this document as XHTML 1.0 Strict!" with 6 ERRORS!!!!!!!!!!!!!!!
3) HTML 4.01 Strict: "This document was successfully checked as HTML 4.01 Strict!"
So you propose incorporating a patch that results in an Unsuccessful validation and 6 Errors for Developers using XHTML VS. the status quo which is Successful validation in ALL cases save 1 warning for those strictly using HTML 4.01 AND... YES... NO ERRORS OR WARNINGS FOR THOSE USING HTML5 which is your main argument!!!
I too think Stripes should be smarter about this BUT not by using the code you propose BUT some other logic AND this is more of an annoyance for those using HTML 4.01 Strict which is a large group indeed BUT clearly not for anyone wanting to ride the edge with HTML5.
So I would like to see this solved too but not for the arguments / reasons or the manner you propose... .
--Nikolaos
Nikolaos,
Well argued! My "patch" was binary (turning off the current behavior altogether) and did not present an option for configuration by the web developer.
My foremost hope, and argument, is to get configuration in the Stripes tag library to choose the output style; It is the source of my, seemingly annual, re-visitation of this issue.
I surf a gray area in my position, but increasingly find myself in the waters of strict implementation of standards. While <input name="website.url" type="text" size="30"/> does indeed validate as XHTML 1.0 Strict, it is not. It is something in-between (much like the XHTML spec itself was a transitional notation toward XML). To be XHTML 1.0 Strict should also mean that the MIME type is correct, application/xhtml+xml. Most the validation in the wild ignore this point of the specification.
No question that WARNINGS annoy me. I suspect that `javac' warnings annoy engineers just the same... "Gotta get all those warnings out of my code.
There is no question that these warnings make me cringe. I have no choice in the matter and have to accept them, or custom spin my Stripes JAR to get rid of it.
HTML5 adoption is not a good position to take in arguing this issue, on that agree. However, I do believe that HTML5 is moving beyond early adoption, and at or past the "tipping point." Whether experimental or not, HTML5 IS being implemented. "Implementation trumps Recommendation." [Holzschlag, 2010, Philly ETE, speaking on HTML5].
HTML5 is in the wild and receiving A LOT of positive developer press (or depending on your business model, this could be a negative development).
"My foremost hope, and argument, is to get configuration in the Stripes tag library to choose the output style; It is the source of my, seemingly annual, re-visitation of this issue."
Allow me to also argue about the appeal of having the feature when looking to win the "hearts and minds" of developers. You don't want a web developer saying, "But Stripes doesn't provide a switch for HTML syntax. Look over here...Struts provides the choice of output style as far back as v1.1, e.g., <html:html xhtml="true">."
Timothy,
On your points:
1) "While <input name="website.url" type="text" size="30"/> does indeed validate as XHTML 1.0 Strict, it is not. It is something in-between (much like the XHTML spec itself was a transitional notation toward XML). To be XHTML 1.0 Strict should also mean that the MIME type is correct, application/xhtml+xml."
I have to disagree. Check this out:
http://www.greytower.net/archive/articles/xhtmlcontent.html
"Since the 1.0 version is designed to be compatible with HTML 4.01, a content type of text/html MAY 1 be used to identify the content - but only if the XHTML document is written according to the HTML Compatibility Guidelines.
For all other documents claiming to be XHTML 1.0, a content-type of application/xhtml+xml MUST be used."
2) "Whether experimental or not, HTML5 IS being implemented. "Implementation trumps Recommendation." [Holzschlag, 2010, Philly ETE, speaking on HTML5]."
Right... HTML5 implementation is not main stream nor is it accepted by all browsers... where as HTML 4.01 and XHTML are... so isn't this really a counter argument.
3) "HTML5 is in the wild and receiving A LOT of positive developer press (or depending on your business model, this could be a negative development)."
Right... but I don't think its fear that drives anyone from being an early adopter... its critical mass... once there is enough critical mass / adoption for ANY technology it makes sense to run with it but until then unless I want to build my home grown personal techie blog with it it doesn't make sense in the main stream "for me" but YMMV.
4) "My foremost hope, and argument, is to get configuration in the Stripes tag library to choose the output style; It is the source of my, seemingly annual, re-visitation of this issue. Allow me to also argue about the appeal of having the feature when looking to win the "hearts and minds" of developers. You don't want a web developer saying, "But Stripes doesn't provide a switch for HTML syntax. Look over here...Struts provides the choice of output style as far back as v1.1, e.g., <html:html xhtml="true">."
Once again on THIS Point I agree 100% and concur... it would be great if Stripes could support this somehow... perhaps similar to Struts.
Also I imagine once integrated with a Stripes tag as an option this would be EXTREMELY trivial to implement and can easily remain backwards compatible (i.e. if the tag option is not explicitly present default to doing things as they are done today).
What does everyone think?
I'll be honest. I really don't think this is a big deal. It seems rather nitpicky to me. But we discussed it on #stripes and we all agreed that it would not be a bad thing to have a tag, a la Struts, that turns on or off XHTML mode (and possibly other options in the future). If someone submits a patch that adds the tag to the tag library and alters the tags in question to honor the option then I'll apply the patch and release it with 1.5.4. I reserve the right to change the name of the tag or attribute or other aspects of the patch. I want to get 1.5.4 out in the next week or two so if you want it in there, you should act fast.
Ben, et. al, I have a patch bundle that I have been using for a week to great success. Where should I send for review? I can't seem to attach here.
After further discussion, I think for 1.6 we'll change Stripes so that it will output ">" instead of "/>" and add a global flag to revert to the old behavior if necessary. Apparently, XHTML is dead so I don't see why Stripes should step on the toes of the majority to support it.
Oops! It seems this was already fixed with the addition of the Stripes.HtmlMode option. Closing again.
W3C validator ( http://validator.w3.org/ ) says it's valid, with one warning:
This Page Is Valid HTML 4.01 Strict!
Result: Passed validation, 1 warning(s)
Line 15, Column 47: NET-enabling start-tag requires SHORTTAG YES.
<input name="website.url" type="text" size="30"/>
✉
The sequence <FOO /> can be interpreted in at least two different ways, depending on the DOCTYPE of the document. For HMTL 4.01 Strict, the '/' terminates the tag <FOO (with an implied '>'). However, since many browsers don't interpret it this way, even in the presence of an HMTL 4.01 Strict DOCTYPE, it is best to avoid it completely in pure HTML documents and reserve its use solely for those written in XHTML.