PDA

View Full Version : Gmail feature



pstar
08-06-2006, 12:24 AM
On gmail if you click the 'attach file' link a text box and browse button appears. How can this be replicated?

Twey
08-06-2006, 12:57 AM
<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>

zeropsi
08-06-2006, 12:59 AM
JavaScript


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";
}
}


HTML


<a href="#" onClick="javascript:toggle('attach');">Attach another file</a>
<div id="attach" style="display:none;"><input type="file" name="file_name"></div>


Hopefully that can help you.

Twey
08-06-2006, 01:15 AM
This one has more support for obsolete browsers. However, it can be condensed:
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";
}


<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.

zeropsi
08-06-2006, 05:52 AM
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.

Twey
08-06-2006, 01:01 PM
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).

shachi
08-06-2006, 02:01 PM
I think the best way would be appending nodes with javascript(dynamically).

Twey
08-06-2006, 02:07 PM
Not really, since the OP only specified one box, so we can avoid using the slow DOM methods.

shachi
08-06-2006, 02:14 PM
Twey, What is OP?? Option Provider or something??

Twey
08-06-2006, 02:25 PM
Original Poster -- the one who started the thread (and usually the one who asked the question).

zeropsi
08-06-2006, 03:55 PM
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).

So should all inline event handlers always be followed by a return false?

Twey
08-06-2006, 04:15 PM
No, only if you want to cancel the default action (in this case, flicking to the top of the page).

zeropsi
08-06-2006, 05:01 PM
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?

Also, can you intiate more than one request from an inline event handler? Like this: onclick="sendRequest('a',00); sendRequest('b', 2000);"

Twey
08-06-2006, 05:08 PM
Are their better alternatives to inline event handlers?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.
Also, can you intiate more than one request from an inline event handler? Like this: onclick="sendRequest('a',00); sendRequest('b', 2000);"Yes.

mwinter
08-06-2006, 05:44 PM
This one has more support for obsolete browsers.

To a degree, but that support may as well be provided by the server-side that should be afforded to unscriptable browsers.



However, it can be condensed:

Indeed. There's no need to call the method (or access a collection) twice. Feature detection should also be added for the style object.



that # will wreak havoc if you don't return false
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.



... or, even better, use javascript:void(0)

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.



<input> elements must be in a form.

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.



javascript: really shouldn't be parsed in event handlers (although it is error-corrected and ignored).

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.

Mike

Twey
08-06-2006, 06:31 PM
Not only may it [javascript:void(0);] have negative effects in IEWould you expand on that?
but it would be considered an error (an unrecognised URI scheme) in unscriptable browsers.I was under the impression that ignoring it was something of a convention.

mwinter
08-06-2006, 07:39 PM
Not only may it [javascript:void(0);] have negative effects in IE

Would you expand on that?

First of all, it's the javascript pseudo-scheme itself that's at issue, not just the void(0) 'path'.

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).



I was under the impression that ignoring it was something of a convention.

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.

Mike

Twey
08-06-2006, 08:06 PM
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?