On gmail if you click the 'attach file' link a text box and browse button appears. How can this be replicated?
Printable View
On gmail if you click the 'attach file' link a text box and browse button appears. How can this be replicated?
Code:<script type="text/javascript">
function toggleVisibility(el) {
if(el.style.display === "none")
el.style.display = "";
else el.style.display = "none";
}
</script>
<p><button onclick="toggleVisibility(document.getElementById('attachDiv'));">Attach File</button></p>
<p id="attachDiv">
<form action="">
<input type="file" name="userfile">
<input type="submit" value="Go">
</form>
</p>
JavaScript
HTMLCode:function toggle(id) {
var obj = "";
// Check browser compatibility
if(document.getElementById)
obj = document.getElementById(id);
else if(document.all)
obj = document.all[id];
else if(document.layers)
obj = document.layers[id];
else
return 1;
if (!obj) {
return 1;
}
else if (obj.style)
{
obj.style.display = ( obj.style.display != "none" ) ? "none" : "";
}
else
{
obj.visibility = "show";
}
}
Hopefully that can help you.Code:<a href="#" onClick="javascript:toggle('attach');">Attach another file</a>
<div id="attach" style="display:none;"><input type="file" name="file_name"></div>
This one has more support for obsolete browsers. However, it can be condensed:Code:function toggle(el) {
var obj = document.getElementById && document.getElementById(el) ? document.getElementById(el) :
document.all && document.all[el] ? document.all[el] :
document.layers && document.layers[el] ? document.layers[el] :
el;
// if obj.style isn't defined, it hasn't been hidden
// in the first place, since we've used CSS to do so.
obj.style.display = obj.style.display === "none" ? "" : "none";
}
Quote:
Code:<a href="#" onClick="javascript:toggle('attach');">Attach another file</a>
<div id="attach" style="display:none;"><input type="file" name="file_name"></div>
- The OP asked for a button;
- that # will wreak havoc if you don't return false; from the event handler or, even better, use javascript:void(0); instead;
- the javascript: pseudo-URL schema has no place in an event handler: javascript: is for URLs;
- <input> elements must be in a form.
I am sure there is a 1 million ways to do it, I just posted up one that could be used.Quote:
Originally Posted by Twey
It can't, really. That # will irritate users no end; it's still not what the OP actually asked for; and javascript: really shouldn't be parsed in event handlers (although it is error-corrected and ignored).
I think the best way would be appending nodes with javascript(dynamically).
Not really, since the OP only specified one box, so we can avoid using the slow DOM methods.
Twey, What is OP?? Option Provider or something??
Original Poster -- the one who started the thread (and usually the one who asked the question).
So should all inline event handlers always be followed by a return false?Quote:
Originally Posted by Twey
No, only if you want to cancel the default action (in this case, flicking to the top of the page).
Are their better alternatives to inline event handlers?Quote:
Originally Posted by Twey
Also, can you intiate more than one request from an inline event handler? Like this: onclick="sendRequest('a',00); sendRequest('b', 2000);"
That's a matter of what you're doing and your personal taste. It is generally considered neater to assign the event handlers in the onload event if possible (thus separating the script from the markup as much as possible), but this isn't always a plausible option.Quote:
Are their better alternatives to inline event handlers?
Yes.Quote:
Also, can you intiate more than one request from an inline event handler? Like this: onclick="sendRequest('a',00); sendRequest('b', 2000);"
To a degree, but that support may as well be provided by the server-side that should be afforded to unscriptable browsers.Quote:
Originally Posted by Twey
Indeed. There's no need to call the method (or access a collection) twice. Feature detection should also be added for the style object.Quote:
However, it can be condensed:
If an empty fragment is used as the value of a href attribute, then it is doubtful that the element is really an anchor, and, in that case, a button should be considered instead. This is one of those cases.Quote:
that # will wreak havoc if you don't return false
That is hardly better. Not only may it have negative effects in IE, but it would be considered an error (an unrecognised URI scheme) in unscriptable browsers.Quote:
... or, even better, use javascript:void(0)
An input element that is to be submitted needs to be a descendant of a form element, but I'm sure the OP knows that already.Quote:
<input> elements must be in a form.
No, it isn't. There's nothing invalid about it: it should be parsed as a label. However, it is almost always pointless. The exception is in IE where using VBScript can change the assumed scripting language, but using VBScript is rarely, if ever, necessary.Quote:
javascript: really shouldn't be parsed in event handlers (although it is error-corrected and ignored).
Mike
Would you expand on that?Quote:
Originally Posted by mwinter
I was under the impression that ignoring it was something of a convention.Quote:
but it would be considered an error (an unrecognised URI scheme) in unscriptable browsers.
First of all, it's the javascript pseudo-scheme itself that's at issue, not just the void(0) 'path'.Quote:
Originally Posted by Twey
IE - quite reasonably, in my opinion - expects that when the user activates a source anchor, a navigation operation will result. As such, it stops performing certain actions in preparation for replacing the document. Examples can include a pending "meta refresh", animating GIF images, and the downloading of external resources (images, etc.). They may include other effects, such as informing plugins like Flash or Java applets that they may stop running (that's from a third-party source), and making the swapping of images (in rollovers, for example) unreliable.
The full extent of the issues may not be possible to ascertain, but it's irrelevant really: there are problems, but they are easily avoided by using the javascript pseudo-scheme for only it's original intention. That is, replacing a document with the result of evaluating an expression (and that in itself is a very rare usage).
Some browsers with scripting disabled might, but there's no reason why an unscriptable browser should; it's a (pseudo-)scheme that the user agent doesn't know how to handle, so the user should be informed.Quote:
I was under the impression that ignoring it was something of a convention.
Mike
Interesting. Thank you.
Not that it's particularly relevant to the thread, but wouldn't showing the user an error message saying "You cannot do this because you do not have Javascript" or similar a better idea than letting the increasingly frustrated user continue clicking on a button and wondering why it isn't doing anything?