struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <>
Subject Re: Form autocomplete property
Date Fri, 31 Dec 2004 17:37:53 GMT
On Sat, 01 Jan 2005 00:49:04 +0800, Andrew Hill
<> wrote:
> <snip>
> a rather puritanical approach
> </snip>
> Yes, that about sums it up.

Except that it was really a *deliberate* puritannical approach :-).

Part of the thing about "doing open source" is the opportunity to make
political statements -- in this case, "just say no" to supporting what
was originally solely an IE capability (and this is one of several
popular nonstandard attributes we don't support).  Historically, I and
the other Struts committers have maintained that attitude, even though
some other browsers have supported some of the nonstandard attributes
on some of the elements, with some level of fidelity to the way that
IE does it.  (As you can see from that sentence, supporting this kind
of thing would be a testing nightmare, especially for those of us who
don't run Windows at all.)

I see no reason to change that attitude -- instead, I see an
opportunity for people who really want that capability to create their
own extended versions of the tags, that do whatever you want.  It
certainly makes sense for the base tag classes themselves to be
internally organized to make such specializatied subclasses relatively
painless (and there's been quite a bit of progress in that direction
over the years), but fundamentally the development and testing burden
should be on yourselves.

Or, band together at someplace like and create
a "value add" tag library that adds all the attributes you want.

> Im rather of the opinion that all the struts html tags should have some
> kind of generic mechanism to allow you to specify any non-standard
> attributes you want. Perhaps something like:
> <html:text property="blah">
>    <html:customAttr name="autocomplete" value="off"/>
> </html:text>
> Though that would have problems with those that have body content.
> hmm... :-(

Besides being technically problematic, that would also violate the
"just say no" spirit :-).


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message