-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I apologize for the "rethreading" of this argument. I couldn't get the
raw email from the list or archives to import it into my home client.
Hopefully the subject will help.
John W. Newman wrote:
> Can you please clarify to me why invalid html is such a big deal?
> (validator tool results aside)
The same reason you would not want to have invalid XML. I know that
there is at least some appreciation for valid and well-form XML in the
Java community. :) HTML 4.01 has a DTD. It deserves to be well-formed.
Validation is the next step. Respect the validation step.
> I'm not arguing the premise of your post, you're right, the tag
> rendering should be able to adapt itself
> based on a supplied doctype and always do the right thing.
I don't think rendering should be based on a reading a "streamed
DOCTYPE". It would be very "ugly" too rely on that. Instead, Stripes
would want base output on the response MIME type. But XHTML is *not*
"text/html". XHTML is properly typed "application/xhtml+xml" or "text/
xml". If the mime type is correct for XHTML, then process the XHTML
response. More in a moment.
> I'm just
> not sure how much it really matters in the
> real world.
I don't think you, I or others could get away with dimissing valid and
well-formed XML as "it doesn't really matter." Validated and well-
formed *HTML* does matter. Whether it's just an "HTML view" or service
integration with Ajax. Respect the DTD.
> I mean, IE will take a page that is initially considered
> a masterpiece by the designer and turn
> it into crap with all its quirks, but leave some tags open or put them
> out of order or something and it's
> happy. (I'm exaggerating a lot there but you get it, the range of
> browsers rarely always do exactly what
> you'd expect). But 2 wrongs do not make a right...
Understanding that you are exaggerating, this is at least also little
incorrect. IE has a much more forgiving HTML parser: closing unclosed
elements or forgiving poorly formed elements, e.g, <p><i>...</p></i>.
However, beginning with IE 6, IE has a specific understanding of
"Standards Mode" and "Quirks Mode". The mode is determined by the
DOCTYPE, *not* the mime/type. Any advanced use of DHTML and Ajax will
behave differently based on whether the DOCTYPE is present and
properly written
>
> In other words, if I do <doctype strict what effect does
>
> <input name="x"></input>
> vs
> <input name="x" />
This is a classic XML-developer misunderstanding. An empty INPUT tag
is *never* written in the form:
<input name="x"></input>
it is written
<input name="x"> <!-- no "space+solidus" -->
And the HTML 4.01 DTD is specific about this.
The format, which Stripes produces by default, is the XHTML form:
<input name="x" />
This form has a very specific legacy tied to the XHTML 1.0
Transitional DTD. It was intended to allow web page developers a way
to update existing HTML in preparation for a more complete XHTML
conversion to the Strict and XHTML 1.1 DTDs.
However, it is this developer's opinion that XHTML has failed, for
many reasons, not forgetting that Microsoft's browser prevented the
proper mime typing of XHTML.
All of this returns to my original argument why STS-556 was
prematurely closed.
I think that Stripes is producing a response that makes a terrible
assumption: the Web Tier/View developer is writing to the XHTML 1.0
Transistional DTD.
And while I think that there are many that are, including leaders of
Stripes, I might suggest that they are doing it wrong. Especially if
they are not mime typing the response correctly. And if they are not
using the correct mime type, then they are not writing XHTML, but
invalid HTML.
I also think they would be especially surprised by the experience that
their IE6/7 audience get if they were to correctly type the response.
Regards,
Tim
>> First, a brief introduction. I'm a long time follower of the Stripes
>> project, coming to Stripes after *significant* disenchantment with
>> JSF
>> and Struts. I've been an advocate for Stripes in my organization for
>> some time and have "won." We are moving to Stripes in our next
>> generation of applications.
>>
... snip ...
>> Without reciting the history of XHTML, its Transitional and Strict
>> DTDs,
>> and why HTML 4.01 is just the better choice, I think Stripes has made
>> terribly bad assumption. And even though this is not explicitly
>> documented, it is assumed anywhere that Stripes closes an "empty
>> element" with " />". Stripes should not be making assumptions about
>> the
>> DOCTYPE. Let's understand why this assumption is bad.
>>
>> There are ten (10) empty elements defined by HTML 4.01:
>>
>> BASE, META, BR, AREA, LINK, IMG, PARAM, HR, INPUT, COL
>>
>> Stripes defines a tag for INPUT (and its various types). Some code
>> diving in v1.5.1 shows that input tags are terminated in the XHTML
>> fashion through the writeSingletonTag method of HtmlTagSupport.
>>
>> With nine (9) other elements wholly in the domain of the Web/HTML
>> developer using, hopefully, best practices to create validating
>> code to
>> the HTML DTD, particularly HTML 4.01, Stripes throws a curve ball.
>> The
>> "Am I XHTML or HTML?" schizophenic response is full of warnings and
>> errors for elements provided by Stripes.
>>
... snip ...
>> I look forward to the debate and resolution of this topic, both as a
>> Stripes user and HTML/JavaScript/CSS guru.
>>
>> Regards,
>> Tim
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Ask me how you can start digitally signing your email!
iEYEARECAAYFAkngtqYACgkQNsfkZJstizpHKQCeLYSaPUXZ5+1T4xKwCdOa2v5g
HnEAoM3jl5I0u75HwSAwUp3Qtklyh3yE
=MDk0
-----END PGP SIGNATURE-----
------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Stripes-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-development
