A dirty way to run js script inline and bring focus to an element:
<html>
<body>
<form method="post" action="index.php" id="myForm">
<p> Login: <input type="text" name="pwd" id="pwd" /> </p>
</form>
<script type="text/javascript">document.myForm.pwd.focus();</script>
</body>
</html>
Notice that both the form and form element have an ID
I ran across an interesting situation where some users of mine were complaining that a form I created “didn’t work”. Kind of strange to get this complaint after almost a full year of operation. I remember testing the xhtml and css design in both firefox and IE browsers and it all checked out. What I didn’t think of checking was the behavior of browsers when one presses the return key. With the help of Fiddler (thanks to Casey Williams for the Fiddler suggestion) this is what I discovered:
| IE | Firefox | |
|---|---|---|
| Submit Button Clicked | All inputs $_POSTed | All inputs $_POSTed |
| Return Key Pressed | All inputs $_POSTed except form buttons |
All inputs $_POSTed |
(For a larger, more detailed image click here)
As you can see, when my IE users were pressing the return key, the button itself was not being $_POSTed. So what right? Well what if you were checking if the submit button was pressed before doing any processing? Like so…
< ?php
if(isset($_POST['button_name'])){
// validate the user entries...
}
?>
This would fail if the user hit the return key in IE7. I haven’t tested earlier versions.
View the example. Test it in both browsers.
Right now the only thing that was suggested to me was to add a hidden field to mimic the submit button in your form like so:
<form ...>
<input type="hidden" name="button_name" value="whatever"... />
</form>
That works just fine.
From perusing irc and several forums, the only response as to WHY this happens are comments like “It’s IE, what do you expect?”. I’m already annoyed that IE doesn’t think it has to adapt to web standards, but this ont really caught me off guard.
I’m wondering if any readers might have some input on my inputs ;P
Ahoy there!
Just a reminder that today is talk like a pirate day! Arggghhh!
All posts and comments for today will be translated in to pirate speak by using the nifty text plugin from Dougal Campbell. It looks like it hasn’t been updated in a while, but it still works. At least in version 2.1.3.
So what are you waiting for people!? Let’s have some fun in the comments!
I was searching my Vista accessories for hyperteminal and stumbled upon a built in screen shot tool in Vista called Snipping Tool. I’m sure to most it’s nothing new, but coming late in the game leaves for more surprises!
You can find it in the start menu -> all programs -> accessories.
By default there is an outline around any window space that you choose to grab. This can be turned off by clearing the check box in the options ->“Show selection ink after snips are captured“.
You can take snips of menus and the like this:
Of course to take screen shots of the snipping tool, I needed to use the old stand by Screen Grab Pro. Otherwise it took a selection of the desktop behind the app.
I haven’t posted much (No, this isn’t a blogpology) lately. Mainly because I haven’t had the passion to write about anything. Secondly because I just don’t want to do the work of messing with the UI and entering one.
Thanks for the tip from my buddy TDavid who pointed me toward Windows Live Writer.
The setup was simple for this machine (Vista Business edition sp1). It’s got some really neat features. First off inserting hyperlinks is a snap. So is adding pictures. Also drag and drop tables, and image resizing.
It also includes preview views, and category selecting, tagging, and you can post date posts.
You can post drafts, post live, and even save drafts locally. I find it much easier to use than the WP UI.
