Bram,
>> "Luckily" all variants break Netscape 4.7x. (No input tag at all :)
> dunno what ns browser you used, but it works fine here, (maybe forgot the
> "form" tags?)
Yes, you're right. I was in a hurry and just ommitted the form. (I also
used NS 4.76, btw.)
So, at first, it doesn't look as if adding (this specific kind of) invalid
html to the output any problems. I still have some objections against doing
so, that I tried to explain below.
a) It's invalid (HTML)
I've nether found it worth in-the-long-term to implement something against
a clearly written spec just as workaround for other problems. It doesn't pay.
Of course, this is not a real argument but just my personal opinion.
b) struts-form is not for XHTML
The tags are used to (and intended to) generate HTML, not XHTML or XML.
The reason to add the forbidden closing tag was - if I remember correctly -
to be able to use the generated document as input for XSLT. While I would
too like the ability to use Struts to generate output in different markup
languages (like XHTML1.0, WML or ....), it seems obvious, that each
markup language has it's own feature set and the approach to use a single
tag library for each and any markup language is doomed to fail.
A better approach IMHO would be to have different (form-)taglibs (one for
each markup language) and to switch between them with the taglib-directive.
c) (just) changing input would be "patchwork"
This is not the only occurrence where HTML differs from XHTML in a way that
prevents XSLT. What's about minimized boolean attributes (like selected,
checked, disabled and so on...). Struts generates them in their minimized
form, also being invalid XHTML. So, if it has to be done and I'm the only
one seeing problems with this kind of changes, it should be done _right_,
i.e. all occurrence should be properly changed and it should be documented,
that the form taglib is intended to generated XHTML (or HTML _and_ XHTML).
Comments ?
--
Matthias (mailto:[EMAIL PROTECTED])
