Re: One page, multiple submit buttons

The Natural Philosopher wrote:
Scott Johnson wrote:
Even worse. No one with a clear mind would do that on a public website.
JS is always optional, you can never(!) rely on it.

I just want to chime in on this thought. I agree 100%. I think it is very wise to embed in new designers to not even think about JS until an after thought as an enhanced version.

If you can get the site up and running with great error and validation routines you are building a solid site that will less likely break.

Some will argue I am sure that the visitors you lose due to requiring JS is acceptable, but i think just one person lost when it is not necessary is not acceptable.


What visitors?

That code was from a site that has no visitors. Just users on predictable platforms.


Why do you dorks always think that HTML and javascript is about attracting Joe Public to a crappy public web site?

And that 100% market penetration will be received by only coding to HTML standard 0.0?



And as far as absolute positioning. It has its place, but if you take the time to create a fluid layout with DIV and SPAN (which take time and attention), you will do yourself great rewards. Leave the static layout sites to those who are lazy or are condemned to using a WYSIWYG IDE because they have not learned the trade.


The thought of a carefully constructed form layout having randomly varying elements is a total nightmare, when writing a web app.

How many other desktop applications have fluid varying screens that arrange their buttons and form inputs according to the window size?

even my web browser doesn't do that to its frame..and suddenly reposition control elements in different locations.

99% of all the comments I see/hear about web sites have nothing to do with lack of fluid formatting, and everything to do with poor structure and inadequate content. Thats nothing to do with screen appearance per se: its to do with what's ON the screen, and how you get to it. Its not a coding issue: its a DESIGN issue.

I suppose you drive a car whose gear stick and pedals rearrange themselves according to where you position the wing mirrors...

Ive tried using fluid formatting on forms: Its ghastly. At some level you end up with fields tht are simply to small to see what's typed in them. Its FAR better to make your form elements of fixed size, and use scroll bars or pop up sub forms (more javascript) to bring extra detail into play when needed.

Remember HTML is only another language, and so is javascript. When designing applications that just happen to us a browser as an interface, there is no more point in trying to ensure compatibility with earlier standards than there is trying to make a CAD program run on an 80x25 vt100 with no graphic input device.

At some level you have to say 'if this is what you want, you need this browser to run it'

Fluid formatting with no javascript is fine and dandy, but its no more a mark of 'good' design than suddenly having the size of your plate and cutlery shrink when someone sits down next to you at a table.

What's vital in industrial forms, that people have to use to get where they want to to do their work, is not fluidity. Its absolutely repeatability, so that things are always exactly where they were yesterday, and that everything you (may) need to do the data entry job you have to do, is there to hand. That means pop up and drop down overlays to present user information FAST, - faster than you can reload a page - and that absolutely necessitates javascript.

Neither do those people care whether you used one or another construct..they don't see the difference between if..the,..else if..then versus say a 'case' statement (which is virtually the same thing anyway: just more readable at source level).

I can only conclude that you are a coder, not a designer, and lacking any idea about what constitutes design, you have only the limited view of a construction worker who looks at the Eiffel tower and mutters 'I still think that they should have used 9mm bolts in that with hex heads'.


There is simply no other way but javascript to put input to a browser that changes its context without a call to the server.

And as far as custom buttons go, its NOT just artistic pretension to want a uniform look and feel to an app..color and text style are important for ergonomics and clarity, and if the browsers typically clunky form elements don't cut it, you have to design your own.

Oh and there is nothing resizable about the average browser's button or input control set either.

If you want a custom clickable area that does something instantly, you are stuck with javascript event handling. Get used to it. The Ark sailed out a long time ago.

Wake up and smell the coffee. Writing code that appeals to other coders is mutual masturbation. The name of the game is writing applications that appeal to the end users.

They don't give a toss whether its elegant, or clunky, whether it uses php, javascript, CSS or whatever. They don't care whether the code uses classes or not. They care that it does what they they want, fast, consistently and to their minds 'intuitively'. Believe it or not, its not other coders who are the target market. Its end users.



IMHO


yeah, right ;-)
Scotty
Well I did not even bother to read the rest since you jumped on the flame wagon right away. I was (an I suppose I was not clear) meaning web pages, not so much web apps.

Scotty
.