"The buttons aren't styling" I remarked as I stared at the page in Camino and Safari. Testing on the Mac platform has been the absolute bane of my existence as of late, mostly because for some reason, these browsers in particular are very protective of their form widgets. Coming back to Cameron Adams' Entry on Styling Form Widgets, I found that none of the Macromedia examples were actually working for Camino/Safari, although they looked beautiful in Firefox. The submit button simply would not take the background settings. Interesting enough though, something of input type="button" styled perfectly.
However, the value attribute of the button wasn't getting passed in. For the legacy code around Gaia, we have forms with more than one possible "submit" for an action. The most common case of this is preview and submit buttons we traditionally use in the forums. This left us with two scenarios:
Submit Buttons that couldn't be styled in Camino / Safari
or Button tags that wouldn't pass in their value to the PHP script (and shouldn't technically perform a submit either)
The final solution ended up being something right down the middle and using JavaScript to make up for Safari / Camino's shortcomings. Starting with a default submit button, we can replace it with a input type="button" node, and add a bit of JavaScript to the onclick to make up for the stylized button's shortcomings. The first block of JavaScript goes into the HEAD, and the second block can either go into an onLoad handler or at the end of the form tag, depending on how soon you need the replacement.
Replace FORMID and SUBMITBUTTONID with the relevant values. If you want to see it in action, check out a working example. The example will also echo out the form contents on submit. You'll have to forgive the poor PNG buttons.
Drawbacks
The largest drawback hands down is the addition of JavaScript. It's not something to depend on, and many steps were taken to ensure that the enhancement is progressive in nature.
Styled images will have to be styled to reflect the change from an input to a button node, and can be referenced via button#idNameofElement to apply all the necessary stylization.
In response to "Stylizing the Form Submit Button":
What’s wrong with just doing the ‘paypal method’?
<input type="image" src="src.png" border="0" name="submit" alt="Submit Me!” value="something" />
It’s neither a button nor a ‘submit’ input, but it does the same thing, doesn’t it? I’m almost 100% sure it works in any modern browser and doesn’t require javascript.
Jason: Using an ‘image’ button type usually has even more draw backs, or has the same.
Image buttons are something to use for single form elements (such as how paypal does, a single valid click with all hidden data being submitted), else you would end up implementing some type of onclick Javascript control in the end anyways.
I don’t think Gaia wants to place an entire dedicated form object around a single image button to handle something that can be handled in the Javascript a bit simpler.
Jakobo: I think in Gaia’s case, the worry about ‘Not being dependant on Javascript’ shouldn’t be a case at all, considering if someone is trying to use Gaia with no Javascript, its gonna be hard for them to get up to the point of even posting to the forums properly.
Think the Javascript could prob be a bit more simplified too, seems you could do the same, just as cross-browser friendly at a more simply built code.
The biggest drawback with using the “IMG” attribute is that it cannot convey any value associated with it. Additionally, it likes to transmit the X,Y coordinates of the click, clogging up the request a bit more. In cases like the friendlist, there are 3-4 different actions you can take for a selected set of options. Typically, from a UI perspective, this is solved by a dropdown selector for actions to take, followed by a single submit button. However, this didn’t match the requested specification from the art team.
The nice thing about this replacement is that if you don’t have javascript, you just get normal form submit buttons and life goes on. Give it a try yourself by going to the example page with JS disabled, and you should get your normal form controls.
Nate: Right you are about the Paypal example. However, the Javascript is actually that complex for a reason. It’s construction isolates it to a single namespace. Additionally, if you use something like Nyman’s Encapsulated Load Objects, you can run all of the JavaScript from the head of the document without introducing additional script tags or onclick="” items.
And yeah, right now lots of things on Gaia are hard to do without JS. There’s a small group of us actively teaching everyone about the ideals of progressive enhancement and how to layer JS on top of something without hindering functionality or creating a dependency on the JavaScript.
*laughs* Spam bot, Viagra likes your site, thats amusing : P
Back onto subject though, yeah I’ve noticed the whole x/y coords appending on Javascript clicks like that.
The ELO script could come in useful for my site as well, I’ll have to check that out, on my one system I’m working on now I could use something like that possibly for pre-scripted functions to load first up.
I usually try and avoid in-line scripts and keep everything to included script source where its absolutely possible to do so, else if its some type of HTML print, I’ll usually just make a span or div element layer and have a global onLoad script that will (element)[removed] the feed into it to help also avoid use of an inline script to print something from like a function or something.
onClick I find useful though, especially with my site and how the majority of it is powered with with Javascript and AJAX handling.
I think in the long run in this day and age, everyone should really have Javascript, so coming across those without it is rare, unless its someone with a noscript extension in their browser (which I’ve come across a few of).
With me I’ve been working on trying to structure an alternative backend for my site though for those not capable of the AJAX, where if it works where I think it will, I can at least handle an iframe process of the data while still staying as dynamic as possible without needing to refresh the page fully, though thats a bit more troublesome with my code.
I’ve updated the script to include preservation of the onclick for any submit buttons that get replaced. I’m also hoping someone might have some ideas for how to place the new button element where the old input type="submit" used to be. Currently, I’m looking into adding a DOM node as a placeholder, but I’m certain there’s something more elegant.