I was surprised to come across four unexpected development problems in one week. If anyone can shed some light on what I have found below, please do.
Changing input types
For a form, you can have <input type="submit"> or <input type="image">, and both will successfully submit a form when clicked. Now, if you want to dynamically switch between these two, you can’t easily do so with JavaScript. Why? IE6. Element.type or Element.setAttribute() do not work with these two input types. So, the solution is to have the markup for both on the page, and to hide one with CSS when you don’t need it.
CSS background with a space
I didn’t have a chance to check this with all browsers, but in IE6 if you have a background image in your CSS with a space in the URL, it will prevent the rest of the CSS from showing. So, a URL like this, http://particletree.com/my back ground.jpg, will break the rest of the stylesheet. You can easily put a %20 in for the spaces, but I just found it interesting that the rest of the sheet doesn’t load.
Image inputs in a POST
When submitting a form with an <input type="image">, extra POST variables are sent. Two of them, in fact. The variable names are the name of the input with a _x and _y appended. So, if you’re expecting a fixed amount of variables in your POST, make sure you accommodate for this.
Ajax and subdomains
We know cross domain Ajax doesn’t work, but what about when a subdomain is required? Well, it turns out that even if a file is hosted on your server, it will only work if the path is relative, which means no subdomains in the Ajax call. This can be a pain for most modern services which create subdomains for every user. It means that with the Ajax call, a variable must be sent representing the subdomain.
I don’t know if this is true or not, but I thought for the spaces in background url’s you could just surround the URL in quotation marks and that will take care of the spaces. That might be easier than just using %20.
Re: Image inputs in a POST, they are the x and y coordinates of where you clicked on the image. I can envisage some places where you might want to use this, in particular in place of a basic image map. Never used it myself though.
For issue one, yeah, Internet Explorer sucks… I’ve been switching element types in Mozilla for years.
IE6 needs a hug.
Let’s face it: IE sucks!
Umm.. I think it would be better not to try change input type attribute, but remove it from DOM completely and create new input element with necessary attributes.
Any particular reason why it is better to remove and add it, other than it not working in IE? Code length would be the same because you have to change the src/value in both instances, and changing the type should execute faster.
No particular reason other than it is not working in IE. Only I think it is possible that just changing type will not be faster than replacing the element, because maybe when you do that (change type), browser anyway replaces that element. Anyway, i’m just guessing.
doesn’t document.domain work?
@Dave: server side image maps.
I’m not quite sure why you had a filename containing spaces to start with; you should know that is bad practice in the development world by now. ;)
document.domain will work. Alexander Kirk documented some of the potential pitfalls in his blog.
Thanks for pointing out document.domain. And Andy, it was user input for a custom CSS file, not something I created. Yes, I should have validated that user input before creating the file, but I didn’t. I’ve fixed it now though. I just found that bug to be unique enough to share. Haha, when you say “by now” — what portion of a web developers career would you be referencing? ;p
issue 1 (change input type) have the same issue (in ie) when changing from type text to password. (i like to do that for small forms when i hide labels. having a type text with the value “password” and change to type password as soon as there is focus/input on the field)
I may be stating the obvious, but the _x and _y post vars submitted when clicking an input type of ‘image’ represent the coordinates on the image where the click occurred. Possibly usable for server side image maps, but as far as i can think there are easier ways of doing pretty much anything you could use this for.
WRT “Image inputs in a POST”: One thing that I have done in the past with the X and Y coordinates was to compile all of the coordinates each day for a certain amount of time and determine where the “hotspots” of the image(s) were. That greatly helped me push my A/B (C/D, etc… hehe) testing of different graphics to increase performance (whatever that meant for a specific page) of the page. Eventually the test would finally reach an equilibrium in performance.
WRT “CSS background with a space”: IMHO, the use of spaces, and to an extent capitalization, in any file that is used/viewed online is flirting with disaster. The space(s) issue has been noted already, but with capitalization you run the risk of yourself or others misspelling the name and causing 404’s, missing images/*.js files, etc. In order to avoid this potential for error, I always try to stick with all lowercase letters and remove/replace spaces for filenames. It’s not always possible (due to pre-existing client code, etc.), but if/when possible I make it happen.
Heh…By “by now,” I just meant that you aren’t a beginner and that would have been a beginner mistake. :)
Regarding “Image inputs in a POST”:
These extra form variable are defined in the HTML standard. (See http://www.w3.org/TR/html4/interact/forms.html#h-17.4)
“When a pointing device is used to click on the image, the form is submitted and the click coordinates passed to the server. The x value is measured in pixels from the left of the image, and the y value in pixels from the top of the image. The submitted data includes name.x=x-value and name.y=y-value where “name” is the value of the name attribute, and x-value and y-value are the x and y coordinate values, respectively.”
In regards to the input type switching bug:
I usually just replace the element with a new input, created via the DOM. I know it’s inconvenient, but I still think it’s better than using the display rule.
You shouldn’t really be naming your files with spaces in them, everyone knows that’s bad practice… don’t they?
Everyone needs a hug.
if you’re already doing all sorts of trickery with javascript when submitting forms, why not just go with GO, GADGET GO! ???
It’ll hold both images and text and can be styled in whatever way you desire. It’s also easier to select with DOM methods, myForm.getElementsByTagName(“button”) … instead of trying to figure out which one is the button returned in myForm.getElementsByTagName(“input”).
What i meant to say was: <button type=”submit”>Button</button>
Regarding the AJAX comment… Yeah.. It doesn’t even work on a different port of the same domain. Big pain in my arse. What I’ve taken to doing is just pointing it at a script on my domain, which loads and returns the content of the page/resource on another domain.