Amen Arron. It seems like the top priority of web development and this list in particular has become complying with standards. While I agree that is important and we've shot ourselves in the foot before, I think we're forgetting that the absolute number one priority in any UI development should be to make the user's life easier.
Arron makes a good point - not all apps are the same. If you're building a portal site, yes you absolutely need to comply with standards and support every browser possible. But increasingly that isn't the case. Currently I'm working on an intranet tool that is being used to administer a much broader application. So even though it is a fairly extensive web app, there are relatively few users. We have the luxury of making very strict requirements on the browsers that our customers use for several reasons: there are a finite number of users, we know what kind of PC's they are using, and we know what browsers they're using. So we require Windows, IE 5.5+ and JavaScript. So if I'm developing a page and there's an IE specific tag or attribute or DOM property or whatever that I can use which would greatly improve my user's experience (say what you will about the Evil Empire, but there are a LOT of these), can you tell me why I shouldn't deviate from compliancy?? > Otherwise... I vote to have the project name changed > to "Struts - a W3C > explicit implementation". [+1] Do you want Struts to be a framework for building just mass-market web sites (portals, ecommerce, etc)?? my $.02, -jon --- Arron Bates <[EMAIL PROTECTED]> wrote: > 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]> > __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
