How about leaving it up to the developer who uses the attribute?... we can warn them about it. But let's leave it to them.
Why should this group decide if a developer with different requirements / demands etc has the ability to add something to a tag? It's valuable to have it there simply for the anything unforeseen. Including allowing a developer to create a page for a specific browser, right down to a very specific one they hacked from an open source project for use in a custom data kiosk or something. Is there a plan to *enforce* Xhtml?... It's currently an "option", but why don't we just enforce it. It's a w3C spec. I get browser specific requests for things all the time, but can I ever turn back to my project manager and say that it can't be done because it's not in a W3C recommendation. I work for a large multinational, and have to support browsers 4+. Many large companies do, and there's no reason at all why it can't be done. Many of these older browsers have little properties that have to be used to get them to do what it is that you need them to do. eg. to get rid of the white space around your html layout for 4+ browsers... <body marginwidth="0" marginheight="0" leftmargin="0" topmargin="0" rightmargin="0"> Which ones are W3C?... But I have to do it because my business manager signed off on a document that was generated by a graphic designer in another department. Struts doesn't have a html:body tag... and just as well. Is struts meant to be an adaptable tool for reality?... Otherwise... I vote to have the project name changed to "Struts - a W3C explicit implementation". [+1] Almost being restrictive for the sake of it. There's no burden to bare, just a few lines of code that never have to be touched, just frisbee that little attribute... and just maybe it'll allow someone to do something they need to do. Arron. * (Something tells me I'm going to stay out of things like this in the future). Martin Cooper wrote: >-1 > >I guess I started this by marking the associated bug report invalid, and >adding the comments I received privately from the original reporter. > >The reasons I am -1 on this are: > >1) The attributes for which this has been suggested are not valid per the >W3C standards. I do not believe that Struts should be catering to >non-standard solutions. Yes, I realise that some browsers support >"extensions" to the standard. However, suppose that attribute 'foo', >currently supported by browser X, is eventually standardised such that the >standard values are not consistent with what browser X supported. What >should we do now? >2) name collisions >3) syntax validation >4) duplication >5) XHTML (need to ignore when value is set) > > >----- Original Message ----- >From: "Arron Bates" <[EMAIL PROTECTED]> >To: "Struts Developers List" <[EMAIL PROTECTED]> >Sent: Sunday, December 09, 2001 11:27 PM >Subject: Freetext attribute for all tags... > > >>Idea... >> >>There was just that too and fro in "additional properties needed on >>html:image..." bug in that there was the argument over what to support >>and what not to support... if there was a standard property (ie: >>"freetext", "freeform", "uglytext" or something) where developers could >>add a string to be included in the tag as they provide it (with an extra >>space at the front and back to avoid collisions). >> >>If a developer wants to include something to be rendered for one reason >>or another, Struts not supporting it or otherwise, they can without >>issue and code hacks that will have to be re-done the next version of >>the tag, tld etc... >> >>It means that the html:image and html:text can do whatever and the >>developer can still get the width, height and wrap stuff that he needs >>for nice formatting. >> >>Probably not *proper* for all the die -hards out there... but certainly >>useable, especially for html creatives that seek that extra level of >>control that Struts hasn't been around yet, doesn't want to or whatever. >> >>Just an idea. >> >> >>Arron. >> >> >> >>-- >>To unsubscribe, e-mail: >> ><mailto:[EMAIL PROTECTED]> > >>For additional commands, e-mail: >> ><mailto:[EMAIL PROTECTED]> > > > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
