[jQuery] Re: Don't use onclick

2009-10-13 Thread RobG



On Oct 13, 1:34 pm, expresso dschin...@gmail.com wrote:
 I don't think it's too hyped.  Having calls to javascript in your
 elements defeats the purpose of unobtrusively maintaining and using
 libraries like jQuery.

The mechanism frequently used to attach such listeners is to add a
class, id, name or some other attribute value designed to make the
element identifiable specifically to add a listener. How is:

  div class=mySpecialClass ...

hugely different to:

  div onclick=mySpecialListener() ...

when both attributes can be added using exactly the same server logic,
static template or whatever? The only difference is that in the first
case, the client must do extra work to attach listeners that could
have been added on the server directly.

Consider also that in the second case, you don't care about a document
ready or load event, or whether the user must wait for elements to be
enlivened while other content loads. Not hip, not cool or funky, but
very robust and avoids a bunch of issues.

Adding listeners at the client simply because the chosen development
library supports it is not a particularly convincing argument.


--
Rob


[jQuery] Re: Don't use onclick

2009-10-13 Thread Jonathan Vanherpe (T T NV)


RobG wrote:


On Oct 13, 1:34 pm, expressodschin...@gmail.com  wrote:

I don't think it's too hyped.  Having calls to javascript in your
elements defeats the purpose of unobtrusively maintaining and using
libraries like jQuery.


The mechanism frequently used to attach such listeners is to add a
class, id, name or some other attribute value designed to make the
element identifiable specifically to add a listener. How is:

   div class=mySpecialClass ...

hugely different to:

   div onclick=mySpecialListener() ...

when both attributes can be added using exactly the same server logic,
static template or whatever? The only difference is that in the first
case, the client must do extra work to attach listeners that could
have been added on the server directly.

Consider also that in the second case, you don't care about a document
ready or load event, or whether the user must wait for elements to be
enlivened while other content loads. Not hip, not cool or funky, but
very robust and avoids a bunch of issues.

Adding listeners at the client simply because the chosen development
library supports it is not a particularly convincing argument.


--
Rob



For one, you're usually using that class to style something too (a 
class=required can be used for validation and for styling the input 
differently to show the user it's a required field), so you use 
essentially the same markup to hook in both your presentational layer 
and your behavioural layer.


I've rarely used onclick after discovering the unobtrusive way of doing 
js, it's easier to maintain and your code looks cleaner.


Jonathan
--
Jonathan Vanherpe - Tallieu  Tallieu NV - jonat...@tnt.be


[jQuery] Re: Don't use onclick

2009-10-13 Thread Liam Potter


Rob, keeping all JS outside of the HTML is a good practice, and keeps 
everything nice and easy to maintain.


Jonathan Vanherpe (T  T NV) wrote:


RobG wrote:


On Oct 13, 1:34 pm, expressodschin...@gmail.com  wrote:

I don't think it's too hyped.  Having calls to javascript in your
elements defeats the purpose of unobtrusively maintaining and using
libraries like jQuery.


The mechanism frequently used to attach such listeners is to add a
class, id, name or some other attribute value designed to make the
element identifiable specifically to add a listener. How is:

   div class=mySpecialClass ...

hugely different to:

   div onclick=mySpecialListener() ...

when both attributes can be added using exactly the same server logic,
static template or whatever? The only difference is that in the first
case, the client must do extra work to attach listeners that could
have been added on the server directly.

Consider also that in the second case, you don't care about a document
ready or load event, or whether the user must wait for elements to be
enlivened while other content loads. Not hip, not cool or funky, but
very robust and avoids a bunch of issues.

Adding listeners at the client simply because the chosen development
library supports it is not a particularly convincing argument.


--
Rob



For one, you're usually using that class to style something too (a 
class=required can be used for validation and for styling the input 
differently to show the user it's a required field), so you use 
essentially the same markup to hook in both your presentational layer 
and your behavioural layer.


I've rarely used onclick after discovering the unobtrusive way of 
doing js, it's easier to maintain and your code looks cleaner.


Jonathan




[jQuery] Re: Don't use onclick

2009-10-12 Thread RobG



On Oct 13, 10:49 am, CoffeeAddict dschin...@gmail.com wrote:
 Am I wrong to say you should never use onclick in an element as this would be
 contrary to the purpose of using jQuery

I think you have your design priorites backward. Firstly determine the
functionality required, then how to best implement it. If that means
using a library, then use it. If the library driving your design
decisions, you might need to rethink using the library.

 which means onclick would totally
 bind mark-up to javascript?

In a way that using a CSS selector to attach handlers doesn't?

  So it would not be unobtrusive in that case.

The concept of unobtrusive javascript (i.e. attaching listeners at
the client, rather than the server) is an implementation methodology
that has been much hyped but probaby creates as many issues as it
solves.


--
Rob


[jQuery] Re: Don't use onclick

2009-10-12 Thread expresso

I don't think it's too hyped.  Having calls to javascript in your
elements defeats the purpose of unobtrusively maintaining and using
libraries like jQuery.  How can you stay that Rob??

On Oct 12, 9:39 pm, RobG robg...@gmail.com wrote:
 On Oct 13, 10:49 am, CoffeeAddict dschin...@gmail.com wrote:

  Am I wrong to say you should never use onclick in an element as this would 
  be
  contrary to the purpose of using jQuery

 I think you have your design priorites backward. Firstly determine the
 functionality required, then how to best implement it. If that means
 using a library, then use it. If the library driving your design
 decisions, you might need to rethink using the library.

  which means onclick would totally
  bind mark-up to javascript?

 In a way that using a CSS selector to attach handlers doesn't?

   So it would not be unobtrusive in that case.

 The concept of unobtrusive javascript (i.e. attaching listeners at
 the client, rather than the server) is an implementation methodology
 that has been much hyped but probaby creates as many issues as it
 solves.

 --
 Rob


[jQuery] Re: Don't use onclick

2009-10-12 Thread expresso

unobtrusive in this case is keeping javascript out of elements.
onclick= binds them together.

On Oct 12, 9:39 pm, RobG robg...@gmail.com wrote:
 On Oct 13, 10:49 am, CoffeeAddict dschin...@gmail.com wrote:

  Am I wrong to say you should never use onclick in an element as this would 
  be
  contrary to the purpose of using jQuery

 I think you have your design priorites backward. Firstly determine the
 functionality required, then how to best implement it. If that means
 using a library, then use it. If the library driving your design
 decisions, you might need to rethink using the library.

  which means onclick would totally
  bind mark-up to javascript?

 In a way that using a CSS selector to attach handlers doesn't?

   So it would not be unobtrusive in that case.

 The concept of unobtrusive javascript (i.e. attaching listeners at
 the client, rather than the server) is an implementation methodology
 that has been much hyped but probaby creates as many issues as it
 solves.

 --
 Rob


[jQuery] Re: Don't use onclick

2009-10-12 Thread expresso

I think you have your design priorites backward. Firstly determine the
functionality required, then how to best implement it. If that means
using a library

obviously we're past that point.  We've decided this was a good use
for jQuery.  So how can you say priorities are tangled here when you
assume we're overthinking this because we're using a library.  It
sounds as though you're a bit anti-new, stay hard core javascript type
of dude.  If you're using javascript to make an entire application
fine, but I'm in with the new and new to me makes sense.  Unobtrusive
is not overrated, it's good practice and it's a pattern as far as I'm
concerned.

On Oct 12, 10:35 pm, expresso dschin...@gmail.com wrote:
 unobtrusive in this case is keeping javascript out of elements.
 onclick= binds them together.

 On Oct 12, 9:39 pm, RobG robg...@gmail.com wrote:

  On Oct 13, 10:49 am, CoffeeAddict dschin...@gmail.com wrote:

   Am I wrong to say you should never use onclick in an element as this 
   would be
   contrary to the purpose of using jQuery

  I think you have your design priorites backward. Firstly determine the
  functionality required, then how to best implement it. If that means
  using a library, then use it. If the library driving your design
  decisions, you might need to rethink using the library.

   which means onclick would totally
   bind mark-up to javascript?

  In a way that using a CSS selector to attach handlers doesn't?

    So it would not be unobtrusive in that case.

  The concept of unobtrusive javascript (i.e. attaching listeners at
  the client, rather than the server) is an implementation methodology
  that has been much hyped but probaby creates as many issues as it
  solves.

  --
  Rob


[jQuery] Re: Don't use onclick

2009-10-12 Thread expresso

The simple fact that you don't have javascript floating all over your
doc inside elements is alone a reason that unobtrusive rocks.  Let
alone many other reasons.

On Oct 12, 10:44 pm, expresso dschin...@gmail.com wrote:
 I think you have your design priorites backward. Firstly determine the

 functionality required, then how to best implement it. If that means
 using a library

 obviously we're past that point.  We've decided this was a good use
 for jQuery.  So how can you say priorities are tangled here when you
 assume we're overthinking this because we're using a library.  It
 sounds as though you're a bit anti-new, stay hard core javascript type
 of dude.  If you're using javascript to make an entire application
 fine, but I'm in with the new and new to me makes sense.  Unobtrusive
 is not overrated, it's good practice and it's a pattern as far as I'm
 concerned.

 On Oct 12, 10:35 pm, expresso dschin...@gmail.com wrote:

  unobtrusive in this case is keeping javascript out of elements.
  onclick= binds them together.

  On Oct 12, 9:39 pm, RobG robg...@gmail.com wrote:

   On Oct 13, 10:49 am, CoffeeAddict dschin...@gmail.com wrote:

Am I wrong to say you should never use onclick in an element as this 
would be
contrary to the purpose of using jQuery

   I think you have your design priorites backward. Firstly determine the
   functionality required, then how to best implement it. If that means
   using a library, then use it. If the library driving your design
   decisions, you might need to rethink using the library.

which means onclick would totally
bind mark-up to javascript?

   In a way that using a CSS selector to attach handlers doesn't?

 So it would not be unobtrusive in that case.

   The concept of unobtrusive javascript (i.e. attaching listeners at
   the client, rather than the server) is an implementation methodology
   that has been much hyped but probaby creates as many issues as it
   solves.

   --
   Rob