Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #18391 > unrolled thread

Script in <a > tag in IE

Back to article view | Back to comp.lang.javascript

Contents

  Script in <a  > tag in IE Tim Slattery <Slattery_T@bls.gov> - 2013-02-07 14:32 -0500
    Re: Script in <a  > tag in IE "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2013-02-07 20:47 +0100
      Re: Script in <a  > tag in IE Tim Slattery <Slattery_T@bls.gov> - 2013-02-07 15:08 -0500
        Re: Script in <a  > tag in IE Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-02-07 21:20 +0100
        Re: Script in <a  > tag in IE SAM <stephanemoriaux.NoAdmin@wanadoo.fr.invalid> - 2013-02-09 16:42 +0100
      Re: Script in <a  > tag in IE Tim Streater <timstreater@greenbee.net> - 2013-02-07 21:30 +0000
        Re: Script in <a  > tag in IE Denis McMahon <denismfmcmahon@gmail.com> - 2013-02-08 07:08 +0000
          Re: Script in <a  > tag in IE Christoph Becker <cmbecker69@gmx.de> - 2013-02-08 16:30 +0100
            Re: Script in <a  > tag in IE Tim Streater <timstreater@greenbee.net> - 2013-02-08 15:41 +0000
    Re: Script in <a  > tag in IE Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-02-07 21:02 +0100
      Re: Script in <a  > tag in IE Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2013-02-09 00:19 +0100
        Re: Script in <a  > tag in IE Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2013-02-09 00:25 +0100
        Re: Script in <a  > tag in IE Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-02-09 14:35 +0100
          Re: Script in <a  > tag in IE Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2013-02-09 22:27 +0100
    Re: Script in <a  > tag in IE Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2013-02-09 20:33 +0100
      Re: Script in <a  > tag in IE Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-02-10 00:08 +0100
        Re: Script in <a  > tag in IE Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2013-02-10 00:52 +0100
          Re: Script in <a  > tag in IE Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-02-10 01:07 +0100
            Re: Script in <a  > tag in IE Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2013-02-10 01:20 +0100
              Re: Script in <a  > tag in IE Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-02-10 01:27 +0100
                Re: Script in <a  > tag in IE Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2013-02-10 01:43 +0100
                  Re: Script in <a  > tag in IE Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-02-10 13:55 +0100
                    Re: Script in <a  > tag in IE Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2013-02-10 20:38 +0100
                      Re: Script in <a  > tag in IE Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-02-10 21:28 +0100
                        Re: Script in <a  > tag in IE Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-02-10 21:37 +0100
                        Re: Script in <a  > tag in IE Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2013-02-10 22:56 +0100
                          Re: Script in <a  > tag in IE Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2013-02-11 00:09 +0100
                            Re: Script in <a  > tag in IE Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2013-02-11 00:30 +0100
                            Re: Script in <a  > tag in IE Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2013-02-11 00:43 +0100
                              Re: Script in <a  > tag in IE Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-02-11 01:02 +0100
                              Re: Script in <a  > tag in IE Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2013-02-11 01:16 +0100
                                Re: Script in <a  > tag in IE Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-02-11 01:49 +0100
                                  Re: Script in <a  > tag in IE Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2013-02-11 17:59 +0100
                                    Re: Script in <a  > tag in IE Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-02-11 18:19 +0100
                                      Re: Script in <a > tag in IE Scott Sauyet <scott.sauyet@gmail.com> - 2013-02-11 13:03 -0800
                                        Re: Script in <a > tag in IE Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-02-11 22:09 +0100
                                          Re: Script in <a > tag in IE Scott Sauyet <scott.sauyet@gmail.com> - 2013-02-11 13:59 -0800
                                            Re: Script in <a > tag in IE "Richard Cornford" <Richard@litotes.demon.co.uk> - 2013-02-18 00:15 +0000
                                              Re: Script in <a > tag in IE Scott Sauyet <scott.sauyet@gmail.com> - 2013-02-21 12:33 -0800
                                                Re: Script in <a > tag in IE "Richard Cornford" <Richard@litotes.demon.co.uk> - 2013-02-22 00:59 +0000
                                                  Re: Script in <a > tag in IE Scott Sauyet <scott.sauyet@gmail.com> - 2013-02-23 07:54 -0800
                                              Re: Script in <a > tag in IE Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-02-22 02:00 +0100
                                            Re: Script in <a > tag in IE Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-02-22 01:12 +0100
                            Re: Script in <a  > tag in IE Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-02-11 01:38 +0100
                          Re: Script in <a  > tag in IE Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-02-11 00:48 +0100
                            Re: Script in <a  > tag in IE Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-02-11 01:09 +0100
                            Re: Script in <a  > tag in IE Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2013-02-20 00:07 +0100
          Re: Script in <a > tag in IE dhtml <dhtmlkitchen@gmail.com> - 2013-02-11 07:30 -0800

Page 1 of 3  [1] 2 3  Next page →

#18391 — Script in <a > tag in IE

I have a tag that looks like this:

<a href="#" onclick="addAttachments();return false;">Add
Attachments</a>

The "addAttachments" function adds a row to a table and populates it.
It's supposed to do only that, and nothing else. That's why "return
false;" is there, to disable the normal click function for the tag

In Firefox and Chrome, this works just fine. Each time I click "Add
Attachments" another row is added to the table. But in IE, it
malfunctions.

On the first click in IE, it works fine. The second time, it acts like
Javascript has been disabled. No new row is added, and it jumps to the
top of the page (the "#" in the href, I presume). Also: there is a
button in the newly added row to delete it. If I click that and delete
the row, the next click on "Add Attachments" works fine. But anytime I
click it with a newly added row in the table, it jumps to the top of
the page.

Anybody have a clue?

-- 
Tim Slattery
Slattery_T@bls.gov

[toc] | [next] | [standalone]

#18392

Tim Slattery wrote on 07 feb 2013 in comp.lang.javascript:

> I have a tag that looks like this:
> 
> <a href="#" onclick="addAttachments();return false;">Add
> Attachments</a>
> 
> The "addAttachments" function adds a row to a table and populates it.
> It's supposed to do only that, and nothing else. That's why "return
> false;" is there, to disable the normal click function for the tag
> 
> In Firefox and Chrome, this works just fine. Each time I click "Add
> Attachments" another row is added to the table. But in IE, it
> malfunctions.
> 
> On the first click in IE, it works fine. The second time, it acts like
> Javascript has been disabled. No new row is added, and it jumps to the
> top of the page (the "#" in the href, I presume). Also: there is a
> button in the newly added row to delete it. If I click that and delete
> the row, the next click on "Add Attachments" works fine. But anytime I
> click it with a newly added row in the table, it jumps to the top of
> the page.
> 
> Anybody have a clue?

Yes, you have an js-error in addAttachments();,
so return false; is not reached. If only this occurs in IE, 
could be a DOM-method that fails, 
or a syntax difference you did not show.

Don't use <a> for executing javascript onclick,
us a properly css-ed <div>, <span> or <button>.

<button onclick="addAttachments();">Add Attachments</button>

<a> is for hyperlinks.



-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#18394

"Evertjan." <exxjxw.hannivoort@inter.nl.net> wrote:


>Yes, you have an js-error in addAttachments();,
>so return false; is not reached. If only this occurs in IE, 
>could be a DOM-method that fails, 
>or a syntax difference you did not show.

You got it. I'm using the firstElementChild property of a "td" object.
But I'm running IE8 and firstElementChild doesn't exist in IE until
version 9. I'm trying to get the <input   > element in that cell.

Ahh..looks like firstChild works just as well as firstElementChild in
this case.

-- 
Tim Slattery
Slattery_T@bls.gov

[toc] | [prev] | [next] | [standalone]

#18395

Tim Slattery wrote:

> "Evertjan." <exxjxw.hannivoort@inter.nl.net> wrote:
>> Yes, you have an js-error in addAttachments();,
>> so return false; is not reached. If only this occurs in IE,
>> could be a DOM-method that fails,
>> or a syntax difference you did not show.
> 
> You got it. I'm using the firstElementChild property of a "td" object.
> But I'm running IE8 and firstElementChild doesn't exist in IE until
> version 9.

To be precise, it is not supported by the MSHTML DOM until before version 9.

> I'm trying to get the <input   > element in that cell.

You should use names or IDs, the former being backwards-compatible, instead.

> Ahh..looks like firstChild works just as well as firstElementChild in
> this case.

Add whitespace before the input element or change its position and it will 
not work anymore.  Can you afford such glitches in your software?  Think 
again.

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#18413

Le 07/02/13 21:08, Tim Slattery a écrit :
>
> You got it. I'm using the firstElementChild property of a "td" object.
> But I'm running IE8 and firstElementChild doesn't exist in IE until
> version 9. I'm trying to get the <input   > element in that cell.

theInput = thatTD.getElementsByTagName('INPUT')[0];



-- 
Stéphane Moriaux avec/with iMac-intel

[toc] | [prev] | [next] | [standalone]

#18401

In article <XnsA160D37EFE0D0eejj99@194.109.133.133>,
 "Evertjan." <exxjxw.hannivoort@inter.nl.net> wrote:

> Tim Slattery wrote on 07 feb 2013 in comp.lang.javascript:
> 
> > I have a tag that looks like this:
> > 
> > <a href="#" onclick="addAttachments();return false;">Add
> > Attachments</a>
> > 
> > The "addAttachments" function adds a row to a table and populates it.
> > It's supposed to do only that, and nothing else. That's why "return
> > false;" is there, to disable the normal click function for the tag
> > 
> > In Firefox and Chrome, this works just fine. Each time I click "Add
> > Attachments" another row is added to the table. But in IE, it
> > malfunctions.
> > 
> > On the first click in IE, it works fine. The second time, it acts like
> > Javascript has been disabled. No new row is added, and it jumps to the
> > top of the page (the "#" in the href, I presume). Also: there is a
> > button in the newly added row to delete it. If I click that and delete
> > the row, the next click on "Add Attachments" works fine. But anytime I
> > click it with a newly added row in the table, it jumps to the top of
> > the page.
> > 
> > Anybody have a clue?
> 
> Yes, you have an js-error in addAttachments();,
> so return false; is not reached. If only this occurs in IE, 
> could be a DOM-method that fails, 
> or a syntax difference you did not show.
> 
> Don't use <a> for executing javascript onclick,
> us a properly css-ed <div>, <span> or <button>.
> 
> <button onclick="addAttachments();">Add Attachments</button>

Does this need to be:

<button type='button' onclick=...

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [prev] | [next] | [standalone]

#18403

On Thu, 07 Feb 2013 21:30:51 +0000, Tim Streater wrote:

> In article <XnsA160D37EFE0D0eejj99@194.109.133.133>,
>  "Evertjan." <exxjxw.hannivoort@inter.nl.net> wrote:
> 
>> Tim Slattery wrote on 07 feb 2013 in comp.lang.javascript:
>> 
>> > I have a tag that looks like this:
>> > 
>> > <a href="#" onclick="addAttachments();return false;">Add
>> > Attachments</a>
>> > 
>> > The "addAttachments" function adds a row to a table and populates it.
>> > It's supposed to do only that, and nothing else. That's why "return
>> > false;" is there, to disable the normal click function for the tag
>> > 
>> > In Firefox and Chrome, this works just fine. Each time I click "Add
>> > Attachments" another row is added to the table. But in IE, it
>> > malfunctions.
>> > 
>> > On the first click in IE, it works fine. The second time, it acts
>> > like Javascript has been disabled. No new row is added, and it jumps
>> > to the top of the page (the "#" in the href, I presume). Also: there
>> > is a button in the newly added row to delete it. If I click that and
>> > delete the row, the next click on "Add Attachments" works fine. But
>> > anytime I click it with a newly added row in the table, it jumps to
>> > the top of the page.
>> > 
>> > Anybody have a clue?
>> 
>> Yes, you have an js-error in addAttachments();,
>> so return false; is not reached. If only this occurs in IE, could be a
>> DOM-method that fails,
>> or a syntax difference you did not show.
>> 
>> Don't use <a> for executing javascript onclick,
>> us a properly css-ed <div>, <span> or <button>.
>> 
>> <button onclick="addAttachments();">Add Attachments</button>
> 
> Does this need to be:
> 
> <button type='button' onclick=...

It depends .... If the button is inside a form element and Tim doesn't 
want the button to also submit the form, he may need stop it doing so - 
but his onclick returns false already.

As Evertjan said, a css styled div or span is also a possibility, as it 
provides an onclick action without needing to worry about other related 
functions (like form submitting, or jumping to bookmarks etc). It's not 
difficult with CSS to style spans to appear to be buttons or links.

-- 
Denis McMahon, denismfmcmahon@gmail.com

[toc] | [prev] | [next] | [standalone]

#18404

Denis McMahon wrote:

> It depends .... If the button is inside a form element and Tim doesn't 
> want the button to also submit the form, he may need stop it doing so - 
> but his onclick returns false already.

In this case one can set the `type' attribute of the `button' element to
`button':

<button type="button" ...>...</button>

See <http://www.w3.org/TR/REC-html40/interact/forms.html#adef-type-BUTTON>

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#18405

In article <kf35kr$pu5$1@speranza.aioe.org>,
 Christoph Becker <cmbecker69@gmx.de> wrote:

> Denis McMahon wrote:
> 
> > It depends .... If the button is inside a form element and Tim doesn't 
> > want the button to also submit the form, he may need stop it doing so - 
> > but his onclick returns false already.
> 
> In this case one can set the `type' attribute of the `button' element to
> `button':
> 
> <button type="button" ...>...</button>
> 
> See <http://www.w3.org/TR/REC-html40/interact/forms.html#adef-type-BUTTON>

That's what I said :-)

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [prev] | [next] | [standalone]

#18393

Tim Slattery wrote:

> I have a tag that looks like this:
> 
> <a href="#" onclick="addAttachments();return false;">Add
> Attachments</a>

That is an _element_, not a tag.  This “a” element (because “a” is the name 
of its type) consists of tags,

  <a href="#" onclick="addAttachments();return false;">

(start-tag, with attribute specifications), and

  </a>

(end-tag), and (text) content:

  Add Attachments

See also: <http://www.w3.org/TR/REC-html40/intro/sgmltut.html#h-3.2.1>
 
> The "addAttachments" function adds a row to a table and populates it.
> It's supposed to do only that, and nothing else. That's why "return
> false;" is there, to disable the normal click function for the tag
> 
> In Firefox and Chrome, this works just fine. Each time I click "Add
> Attachments" another row is added to the table. But in IE, it
> malfunctions.
> 
> On the first click in IE, it works fine. The second time, it acts like
> Javascript has been disabled. No new row is added, and it jumps to the
> top of the page (the "#" in the href, I presume). Also: there is a
> button in the newly added row to delete it. If I click that and delete
> the row, the next click on "Add Attachments" works fine. But anytime I
> click it with a newly added row in the table, it jumps to the top of
> the page.
> 
> Anybody have a clue?

The addAttachments() function has caused a runtime error in IE/MSHTML, 
therefore afterwards no further script code in that document is being 
executed.  There should be a yellow icon on the left-hand side of the status 
bar which you can double-click and see (to some extent) what the problem is 
and where it is located (while the line number is close to the erroneous 
one, the filename may be wrong).

If you have IE 7 or IE ≥ 8, you can use the IE Developer Tools to find out 
more; for IE 7 there is an add-on, for IE ≥ 8 you can press F12.  There is 
also Firebug Lite which, after loaded (e.g. via bookmarklet), responds to 
the same keyboard shortcut.

However, you should not be using that approach because it does not work 
without client-side script support; use a script-augmented HTML form 
instead.

If at all necessary, at least generate the “a” element dynamically so that 
users where it cannot work do not have to bother with the non-working 
element in the first place.
 
-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#18409

Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:

> Tim Slattery wrote:

>   <a href="#" onclick="addAttachments();return false;">

> If at all necessary, at least generate the “a” element dynamically so that 
> users where it cannot work do not have to bother with the non-working 
> element in the first place.

But that would rather reliably enable user interaction without a
pointing device, and without jumping through hoops in terms of
implementation. How would that be better than just plonking some SPAN or
DIV element in the HTML source and unconditionally style it as an
interactive element, just in case, as has been suggested earlier in
this threat?

(In military markup, we call that strategy 'the element of suprise'.)

[toc] | [prev] | [next] | [standalone]

#18410

Eric Bednarz <bednarz@fahr-zur-hoelle.org> writes:

> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>
>> Tim Slattery wrote:
>
>>   <a href="#" onclick="addAttachments();return false;">

As the attribution and content flow still suggest, Tim wrote that, not
Thomas. I must have messed up the quotation level manually, and feel
rather inconsolable about it.

[toc] | [prev] | [next] | [standalone]

#18412

Eric Bednarz wrote:

[Quotation fixed]

> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>> Tim Slattery wrote: 
>>>   <a href="#" onclick="addAttachments();return false;">
>> 
>> If at all necessary, at least generate the “a” element dynamically so
>> that users where it cannot work do not have to bother with the
>> non-working element in the first place.
> 
> But that would rather reliably enable user interaction without a
> pointing device,

What good is a clickable element if nothing happens – or worse, something 
unexpected and unwanted happens, like scrolling to the top of the document – 
when it is clicked?

> and without jumping through hoops in terms of implementation.

IBTD.

  <script type="text/javascript">
    document.write(
      '<a href="#" onclick="addAttachments();return false;">…<\/a>');
  </script>

or 

  <script type="text/javascript">
    (function () {
      var a = document.createElement("a");
      a.href = "#";
      a.onclick = function () {
        addAttachments();
        return false;
      };

      var scripts = document.getElementsByTagName("script");
      var lastScript = scripts[scripts.length - 1];
      lastScript.parentNode.insertBefore(a, lastScript.nextSibling);
    }());
  </script>

or something along those lines (the simplest way without document.write() 
would be to use an element node with an ID as reference node; implementation 
of that is left as an exercise to the reader).

> How would that be better than just plonking some SPAN or
> DIV element in the HTML source and unconditionally style it as an
> interactive element, just in case, as has been suggested earlier in
> this threat?

An element that is not there in the first place when it could not do 
anything useful cannot be activated in order to do nothing useful.  An 
element that is merely styled can still be activated even when it cannot
do anything useful; the implementation of CSS is optional on top of that.

Good user interface design aims to reduce the probability of user errors.

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#18415

Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:

> Eric Bednarz wrote:
>
> [Quotation fixed]
>
>> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>>> Tim Slattery wrote: 
>>>>   <a href="#" onclick="addAttachments();return false;">
>>> 
>>> If at all necessary, at least generate the “a” element dynamically so
>>> that users where it cannot work do not have to bother with the
>>> non-working element in the first place.
>> 
>> But that would rather reliably enable user interaction without a
>> pointing device,
>
> What good is a clickable element if nothing happens – or worse, something 
> unexpected and unwanted happens, like scrolling to the top of the document – 
> when it is clicked?

What good is my sarcasm? No good at all, apparently. Sorry about
that. Constructive answer, though.

[toc] | [prev] | [next] | [standalone]

#18414

W dniu 2013-02-07 20:32, Tim Slattery pisze:
> I have a tag that looks like this:
>
> <a href="#" onclick="addAttachments();return false;">Add
> Attachments</a>
[...]

My "5 cents":

1. Don't mix behaviours with logic. Move "onclick" outside of element 
<a>. A good example was provided by Thomas Lahn (he's second example).

2. Do not use href="#" which means that users without JavaScript (there 
are several situations where JavaScript is not available) can not get 
into data which are behind "#". Rather use normal URL that provide a 
simple form where user can send file. This is fall-back.

-- 
Cezary Tomczyk
http://www.ctomczyk.pl/

[toc] | [prev] | [next] | [standalone]

#18416

Cezary Tomczyk wrote:

> W dniu 2013-02-07 20:32, Tim Slattery pisze:
>> I have a tag that looks like this:
>>
>> <a href="#" onclick="addAttachments();return false;">Add
>> Attachments</a>
> [...]
> 
> My "5 cents":
> 
> 1. Don't mix behaviours with logic. Move "onclick" outside of element
> <a>.

You have not said why.  I think there is no good reason why.  That script 
code here is short enough so that it is maintainable when in an event 
handler attribute value, and it is only needed when that particular “a” 
element is needed.  Loading it always would be a waste of resources.

> A good example was provided by Thomas Lahn (he's second example).

Which “second example” are you referring to?
 
> 2. Do not use href="#" which means that users without JavaScript (there
> are several situations where JavaScript is not available) can not get
> into data which are behind "#". Rather use normal URL that provide a
> simple form where user can send file. This is fall-back.

Usually good advice (probably in the FAQ).  In this case, however, it might 
be better to use form controls instead.  One cannot be certain as not all 
the code was posted.

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#18417

W dniu 2013-02-10 00:08, Thomas 'PointedEars' Lahn pisze:
> Cezary Tomczyk wrote:
>
>> W dniu 2013-02-07 20:32, Tim Slattery pisze:
>>> I have a tag that looks like this:
>>>
>>> <a href="#" onclick="addAttachments();return false;">Add
>>> Attachments</a>
>> [...]
>>
>> My "5 cents":
>>
>> 1. Don't mix behaviours with logic. Move "onclick" outside of element
>> <a>.
>
> You have not said why.  I think there is no good reason why.  That script
> code here is short enough so that it is maintainable when in an event
> handler attribute value, and it is only needed when that particular “a”
> element is needed.  Loading it always would be a waste of resources.

I am referring to:

* 
http://en.wikipedia.org/wiki/Unobtrusive_JavaScript#Separation_of_behavior_from_markup
* 
http://www.w3.org/wiki/The_principles_of_unobtrusive_JavaScript#Separation_of_structure_and_behaviour

There is a lot of materials in internet about (let's use some keywords) 
"separate behavior content javascript".

Plus ( from my memory :-) ):

* HTML files are bigger by using inline events and are not cached, while 
JavaScript files can be cached by browsers

>> A good example was provided by Thomas Lahn (he's second example).
>
> Which “second example” are you referring to?

[...]
       a.onclick = function () {
         addAttachments();
         return false;
       };
[...]

which means that attaching method to event could be done, for example, 
in that way. Not by using inline events.

>> 2. Do not use href="#" which means that users without JavaScript (there
>> are several situations where JavaScript is not available) can not get
>> into data which are behind "#". Rather use normal URL that provide a
>> simple form where user can send file. This is fall-back.
>
> Usually good advice (probably in the FAQ).  In this case, however, it might
> be better to use form controls instead.  One cannot be certain as not all
> the code was posted.

Yes. Small form could be very usefully and if HTML5 features are 
available (like multiple upload) then developer can even add progress 
bar, show file size, etc.

-- 
Cezary Tomczyk
http://www.ctomczyk.pl/

[toc] | [prev] | [next] | [standalone]

#18419

Cezary Tomczyk wrote:

> W dniu 2013-02-10 00:08, Thomas 'PointedEars' Lahn pisze:
>> Cezary Tomczyk wrote:
>>> W dniu 2013-02-07 20:32, Tim Slattery pisze:
>>>> I have a tag that looks like this:
>>>>
>>>> <a href="#" onclick="addAttachments();return false;">Add
>>>> Attachments</a>
>>> [...]
>>>
>>> My "5 cents":
>>>
>>> 1. Don't mix behaviours with logic. Move "onclick" outside of element
>>> <a>.
>>
>> You have not said why.  I think there is no good reason why.  That script
>> code here is short enough so that it is maintainable when in an event
>> handler attribute value, and it is only needed when that particular “a”
>> element is needed.  Loading it always would be a waste of resources.
> 
> I am referring to:
> 
> *
> 
http://en.wikipedia.org/wiki/Unobtrusive_JavaScript#Separation_of_behavior_from_markup
> *
> 
http://www.w3.org/wiki/The_principles_of_unobtrusive_JavaScript#Separation_of_structure_and_behaviour
> 
> There is a lot of materials in internet about (let's use some keywords)
> "separate behavior content javascript".
> 
> Plus ( from my memory :-) ):
> 
> * HTML files are bigger by using inline events and are not cached, while
> JavaScript files can be cached by browsers

Utter nonsense, all of the above.
 
>>> A good example was provided by Thomas Lahn (he's second example).
>> Which “second example” are you referring to?
> 
> [...]
>        a.onclick = function () {
>          addAttachments();
>          return false;
>        };
> [...]
> 
> which means that attaching method to event could be done, for example,
> in that way. Not by using inline events.

This code is part of an example in which the “a” element is created 
dynamically.  It has nothing to do with some misguided idea of “Unobtrusive 
JavaScript”.

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#18420

W dniu 2013-02-10 01:07, Thomas 'PointedEars' Lahn pisze:
> Cezary Tomczyk wrote:
[...]
>>>> 1. Don't mix behaviours with logic. Move "onclick" outside of element
>>>> <a>.
>>>
>>> You have not said why.  I think there is no good reason why.  That script
>>> code here is short enough so that it is maintainable when in an event
>>> handler attribute value, and it is only needed when that particular “a”
>>> element is needed.  Loading it always would be a waste of resources.
>>
>> I am referring to:
>>
>> *
>>
> http://en.wikipedia.org/wiki/Unobtrusive_JavaScript#Separation_of_behavior_from_markup
>> *
>>
> http://www.w3.org/wiki/The_principles_of_unobtrusive_JavaScript#Separation_of_structure_and_behaviour
>>
>> There is a lot of materials in internet about (let's use some keywords)
>> "separate behavior content javascript".
>>
>> Plus ( from my memory :-) ):
>>
>> * HTML files are bigger by using inline events and are not cached, while
>> JavaScript files can be cached by browsers
>
> Utter nonsense, all of the above.

You have not said why.

>>>> A good example was provided by Thomas Lahn (he's second example).
>>> Which “second example” are you referring to?
>>
>> [...]
>>         a.onclick = function () {
>>           addAttachments();
>>           return false;
>>         };
>> [...]
>>
>> which means that attaching method to event could be done, for example,
>> in that way. Not by using inline events.
>
> This code is part of an example in which the “a” element is created
> dynamically.  It has nothing to do with some misguided idea of “Unobtrusive
> JavaScript”.

The code contains an fragment of adding event and method. That part I 
wanted to cite as an example of way how to add events and methods in a 
proper way. Not by inline events. Also, I provided links that contains 
explanations "why not inline events". You do not have to agree with them.

-- 
Cezary Tomczyk
http://www.ctomczyk.pl/

[toc] | [prev] | [next] | [standalone]

#18421

Cezary Tomczyk wrote:

> W dniu 2013-02-10 01:07, Thomas 'PointedEars' Lahn pisze:
>> Cezary Tomczyk wrote:
> [...]
>>>>> 1. Don't mix behaviours with logic. Move "onclick" outside of element
>>>>> <a>.
>>>>
>>>> You have not said why.  I think there is no good reason why.  That
>>>> script code here is short enough so that it is maintainable when in an
>>>> event handler attribute value, and it is only needed when that
>>>> particular “a”
>>>> element is needed.  Loading it always would be a waste of resources.
>>>
>>> I am referring to:
>>>
>>> * 
http://en.wikipedia.org/wiki/Unobtrusive_JavaScript#Separation_of_behavior_from_markup
>>> * 
http://www.w3.org/wiki/The_principles_of_unobtrusive_JavaScript#Separation_of_structure_and_behaviour
>>>
>>> There is a lot of materials in internet about (let's use some keywords)
>>> "separate behavior content javascript".
>>>
>>> Plus ( from my memory :-) ):
>>>
>>> * HTML files are bigger by using inline events and are not cached, while
>>> JavaScript files can be cached by browsers
>>
>> Utter nonsense, all of the above.
> 
> You have not said why.

True, because we have been over this ad nauseam here already.
 
>>>>> A good example was provided by Thomas Lahn (he's second example).
>>>> Which “second example” are you referring to?
>>>
>>> [...]
>>>         a.onclick = function () {
>>>           addAttachments();
>>>           return false;
>>>         };
>>> [...]
>>>
>>> which means that attaching method to event could be done, for example,
>>> in that way. Not by using inline events.
>> This code is part of an example in which the “a” element is created
>> dynamically.  It has nothing to do with some misguided idea of
>> “Unobtrusive JavaScript”.
> 
> The code contains an fragment of adding event and method. That part I
> wanted to cite as an example of way how to add events and methods in a
> proper way. Not by inline events.

My example has nothing to do with that mindbogglingly stupid approach.
Do not cite it as an example of that.

> Also, I provided links that contains explanations "why not inline events".
> You do not have to agree with them.

I do not, because they are utter nonsense.

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.javascript

csiph-web