"modern" javascript...

[maya]

hi,

so what is "modern" javascript?? the same as "DOM-scripting"? i.e.,
editing content (or changing appearance of content) dynamically by
massaging javascript objects, html elements, etc? (in conjunction with
css, you know, the usual...;) this is what is meant by "modern"
javascript?? so how do folks feel about this who think javascript is so
evil they disable it from their browsers?? do sites designed with
"modern" javascript (like what's talked about here,
http://www.sitepoint.com/books/dhtml1/) work in browsers that have
javascript disabled????

just curious.. thank you...

[Joost Diepenmaat]

Re: "modern&qu ot; javascript...

maya <maya778899@yah oo.comwrites:

hi,
>
so what is "modern" javascript??

Who knows. I should hope that some day, relatively decent code will be
considered "modern". Today is not that day.

the same as "DOM-scripting"? i.e.,
editing content (or changing appearance of content) dynamically by
massaging javascript objects, html elements, etc? (in conjunction
with css, you know, the usual...;) this is what is meant by "modern"
javascript??

Is there a question in there somewhere?

so how do folks feel about this who think javascript is
so evil they disable it from their browsers??

They're right. It's much better to have scripting disabled by
default. Of course, it's also handy to have a quick way to turn it on
for trusted sites, which is why things like the firefox noscript
extension exist.

do sites designed with
"modern" javascript (like what's talked about here,
http://www.sitepoint.com/books/dhtml1/) work in browsers that have
javascript disabled????

Unobtrusive javascript is only interesting in that it promotes the
idea that sites in general should work even without javascript. All
the rest is bullshit - especially the bits about not mixing scripts
with HTML.

just curious.. thank you...

Well, there you go.

--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/

[maya]

Re: &quot;modern&qu ot; javascript...

Joost Diepenmaat wrote:

maya <maya778899@yah oo.comwrites:
>

>hi,
>>
>so what is "modern" javascript??

>
Who knows. I should hope that some day, relatively decent code will be
considered "modern". Today is not that day.
>

>the same as "DOM-scripting"? i.e.,
>editing content (or changing appearance of content) dynamically by
>massaging javascript objects, html elements, etc? (in conjunction
>with css, you know, the usual...;) this is what is meant by "modern"
>javascript??

yes there is, I meant: is "modern" javascript the same as what is usu.
meant by "DOM-scripting", i.e., editing content (or changing appearance
of content) dynamically by massaging javascript objects or html
elements? (in response to user input or other events?)

>
Is there a question in there somewhere?
>

> so how do folks feel about this who think javascript is
>so evil they disable it from their browsers??

>
They're right. It's much better to have scripting disabled by
default.

Of course, it's also handy to have a quick way to turn it on

for trusted sites, which is why things like the firefox noscript
extension exist.
>

>do sites designed with
>"modern" javascript (like what's talked about here,
>http://www.sitepoint.com/books/dhtml1/) work in browsers that have
>javascript disabled????

>
Unobtrusive javascript is only interesting in that it promotes the
idea that sites in general should work even without javascript.

not sure if this answers question about whether or not sites built with
"modern" javascript work in browsers that have javascript disabled...
(papa don't preach -- just the facts, ma'm....;)

(not sure what is meant by "unobtrusiv e" javascript -- javascript you
don't like??....;)

thank you...

[Joost Diepenmaat]

Re: &quot;modern&qu ot; javascript...

maya <maya778899@yah oo.comwrites:

(not sure what is meant by "unobtrusiv e" javascript -- javascript you
don't like??....;)

Please trim your quotes down to some reasonable amount so that it's
clear what you're replying to, without overwhelming the readers.

Anyway, what I don't like is the idea that separating javascript from
HTML (by *only* including javascript via <script src=...tags) is a
worthwhile goal. It may be useful if you're writing all your HTML by
hand, instead of using some kind of logical system to generate HTML
for you (and I'm not talking about WYSIWYG editors here - I prefer
light-weight off-line templating systems for simple sites), but most
any site that makes heavy use of javascript already generates bunches
of code anyway, and the goal is not to produce "clean" HTML, it's to
create accessible sites, using maintainable code.

--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/

[Joost Diepenmaat]

Re: &quot;modern&qu ot; javascript...

Joost Diepenmaat <joost@zeekat.n lwrites:

maya <maya778899@yah oo.comwrites:
>

>(not sure what is meant by "unobtrusiv e" javascript -- javascript you
>don't like??....;)

>
Anyway, what I don't like is the idea that separating javascript from
HTML (by *only* including javascript via <script src=...tags) is a
worthwhile goal.

And just to be clear: the term "unobtrusiv e javascript" was not
brought up by me: read the link you posted, here:

http://www.sitepoint.com/books/dhtml1/

--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/

[Thomas 'PointedEars' Lahn]

Re: &quot;modern&qu ot; javascript...

Joost Diepenmaat wrote:

maya <maya778899@yah oo.comwrites:

>so how do folks feel about this who think javascript is so evil they
>disable it from their browsers??

>
They're right. It's much better to have scripting disabled by default. Of
course, it's also handy to have a quick way to turn it on for trusted
sites, which is why things like the firefox noscript extension exist.

That depends on which sites you visit, and your favorite UA. I prefer
Firefox and I have never found it necessary to disable scripting anywhere.

>do sites designed with "modern" javascript (like what's talked about
>here, http://www.sitepoint.com/books/dhtml1/) work in browsers that
>have javascript disabled????

>
Unobtrusive javascript is only interesting in that it promotes the idea
that sites in general should work even without javascript.

Does it?

All the rest is bullshit - especially the bits about not mixing scripts
with HTML.

No argument there :)


PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>

[Peter Michaux]

Re: &quot;modern&qu ot; javascript...

On Jul 16, 9:59 am, Thomas 'PointedEars' Lahn <PointedE...@we b.de>
wrote:

Joost Diepenmaat wrote:

[snip]

Unobtrusive javascript is only interesting in that it promotes the idea
that sites in general should work even without javascript.

>
Does it?

Apparently it might

http://en.wikipedia.org/wiki/Unobtrusive_JavaScript

All the rest is bullshit - especially the bits about not mixing scripts
with HTML.

>
No argument there :)

When the browser makers give us an API where separating script and API
works and connecting them by something like CSS selectors (probably
CSS selectors as they already work and are part of the browser world)
then I think the separation is a good idea. Until then, the only
alternatives to mixing script and HTML are far too complex for their
apparent value of "maintainabilit y" etc.

Peter

[Joost Diepenmaat]

Re: &quot;modern&qu ot; javascript...

Thomas 'PointedEars' Lahn <PointedEars@we b.dewrites:

Joost Diepenmaat wrote:

>maya <maya778899@yah oo.comwrites:

>>so how do folks feel about this who think javascript is so evil they
>>disable it from their browsers??

>>
>They're right. It's much better to have scripting disabled by default. Of
>course, it's also handy to have a quick way to turn it on for trusted
>sites, which is why things like the firefox noscript extension exist.

>
That depends on which sites you visit, and your favorite UA. I prefer
Firefox and I have never found it necessary to disable scripting anywhere.

The sites I visit are none of your business :-) but it's better to be
safe than sorry and also, noscript & friends seem to reduce the number
of ads, flash etc quite a bit, which is a good thing in my opinion.

But I do turn scripting on whenever a site seems to need it and it
looks like it's serious. Detecting serious sites isn't that hard, by
the way: it seems to work the same way that detecting spam vs serious
email works.

>Unobtrusive javascript is only interesting in that it promotes the idea
>that sites in general should work even without javascript.

>
Does it?

It should. Maybe I'm just projecting :-)

>All the rest is bullshit - especially the bits about not mixing scripts
>with HTML.

>
No argument there :)

Cheers.

J.

--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/

[RobG]

Re: &quot;modern&qu ot; javascript...

On Jul 17, 8:34 am, Peter Michaux <petermich...@g mail.comwrote:

On Jul 16, 9:59 am, Thomas 'PointedEars' Lahn <PointedE...@we b.de>
wrote:
>

Joost Diepenmaat wrote:

>
[snip]
>

Unobtrusive javascript is only interesting in that it promotes the idea
that sites in general should work even without javascript.

>

Does it?

>
Apparently it might
>
http://en.wikipedia.org/wiki/Unobtrusive_JavaScript

That article is pretty ordinary, it's more like a marketing spiel.
The statement that it represents "[b]est practices to avoid the
problems of traditional JavaScript programming (such as browser
inconsistencies and lack of scalability)" is laughable.

At best it's a technique to completely separate script code from the
document code, at worst meaningless buzz words.

All the rest is bullshit - especially the bits about not mixing scripts
with HTML.

>

No argument there :)

None at all.

When the browser makers give us an API where separating script and API
works and connecting them by something like CSS selectors (probably
CSS selectors as they already work and are part of the browser world)
then I think the separation is a good idea. Until then, the only
alternatives to mixing script and HTML are far too complex for their
apparent value of "maintainabilit y" etc.

If that connection does away with waiting for events like
documentReady and load, I'm all for it. How about a new element called
'event' that uses CSS rules to assign listeners? The properties would
be events, values would be whatever you would have put in the
attribute value.

<script ... >
function sortMe(){ ... };
function showTooltip(){ ... };
function useAjax(){ ... };
</script>

<event ... >
table.sortable {
click: sortMe(parm1, parm2);
}
table.sortable th {
hover: showTooltip();
}
form {
submit: useAjax();
}
</event>

Then leave the progressive attaching of events to elements up to the
browser - hasta la vista onload!


--
Rob

[dhtml]

Re: &quot;modern&qu ot; javascript...

On Jul 16, 10:00 pm, RobG <rg...@iinet.ne t.auwrote:

On Jul 17, 8:34 am, Peter Michaux <petermich...@g mail.comwrote:
>

On Jul 16, 9:59 am, Thomas 'PointedEars' Lahn <PointedE...@we b.de>
wrote:

>

Joost Diepenmaat wrote:

>

http://en.wikipedia.org/wiki/Unobtrusive_JavaScript

>

<quote>
"However, the purpose of markup is to describe a document's structure,
not its programmatic behavior. Combining the two negatively impacts a
site's maintainability for the same reason that combining content and
presentation does: if a site contains hundreds of such date fields,
adding the appropriate onchange attribute for each one (and modifying
them later, if necessary) can be a labor-intensive process.
Furthermore, inline syntax prevents the registration of more than one
event handler for the element's onchange event, which can be a problem
as the application grows."
</quote>

I've seen messes like this this firsthand and dealt with HTML
generated from javascript. HTML was built from JavaScript, the data
came in the form of JSON. delivered over XHR. Event handlers attached
to the elements as attributes in the HTML. In one case, I was told
that this was done "for performance reasons" (JSON downloads faster).
THis was the TV Listings that was written by a couple of guys at
Yahoo, one an intern, another a F/T employee. What a mess! I
distinctly remember Mike L. attempting to justify their decision as he
was simultaneously trying to understand it. Performance was, of
course, negatively impacted by the design decision to build the page
from javascript object literals. The "performanc e of the development"
was stalled, too and the proposed changes were abandoned, as was the
project abandoned, by Mike L. What a waste.

HTML in scripts is usually a lot harder to maintain than just plain
HTML.

The same can be true for scripts in HTML. When event handlers are in
the HTML, not in the js file, the script is more scattered. Look in
the JS file for that page, not some html/tag file. Doesn't that seem
easier?

It is also useful to have a common methodology that is accepted by the
team. Having a restraint like "no event handlers in the HTML" can
make debugging easier.

>

When the browser makers give us an API where separating script and API
works and connecting them by something like CSS selectors (probably
CSS selectors as they already work and are part of the browser world)
then I think the separation is a good idea. Until then, the only
alternatives to mixing script and HTML are far too complex for their
apparent value of "maintainabilit y" etc.

>

A simple alternative is to use a bottom script. Slightly more complex:
an onload event handler. Another approach is to capture events on
bubble.

Then leave the progressive attaching of events to elements up to the
browser - hasta la vista onload!
>

Microsoft already did that.

http://msdn.microsoft.com/en-us/library/ms535892(VS.85).aspx

http://msdn.microsoft.com/en-us/library/ms533746(VS.85).aspx

Garrett

--
Rob

[Thomas 'PointedEars' Lahn]

Re: &quot;modern&qu ot; javascript...

dhtml wrote:

On Jul 16, 10:00 pm, RobG <rg...@iinet.ne t.auwrote:

>On Jul 17, 8:34 am, Peter Michaux <petermich...@g mail.comwrote:

>>On Jul 16, 9:59 am, Thomas 'PointedEars' Lahn <PointedE...@we b.de>
>>wrote:
>>>Joost Diepenmaat wrote:

[...] HTML in scripts is usually a lot harder to maintain than just plain
HTML.
>
The same can be true for scripts in HTML.

But it is not. That's a straw man argument.

When event handlers are in the HTML, not in the js file, the script is
more scattered. Look in the JS file for that page, not some html/tag
file. Doesn't that seem easier?

It may seem easier at first, but on a closer look one observes how easy
debugging and maintenance is instead hindered by it. In addition to that,
one important drawback of Unobtrusive JavaScript that is frequently
overlooked is that it requires enhanced DOM support, and it may need to
resort to the use of proprietary APIs, and maybe even host object
augmentation (which is pretty bad as support for this is specified as being
optional). Standards-compliant intrinsic event handler attributes seldom
impose such restrictions.

It is also useful to have a common methodology that is accepted by the
team. Having a restraint like "no event handlers in the HTML" can make
debugging easier.

Having had to debug several such scripts in my job, I seriously doubt that.
To begin with, name a DOM inspector application which shows all the
dynamically added event listeners attached for a target object without
triggering the event, to begin with. Then name one DOM inspector
application that does not show the value of intrinsic event handler
attribute values.

>>When the browser makers give us an API where separating script and
>>API works and connecting them by something like CSS selectors
>>(probably CSS selectors as they already work and are part of the
>>browser world) then I think the separation is a good idea. Until
>>then, the only alternatives to mixing script and HTML are far too
>>complex for their apparent value of "maintainabilit y" etc.

>
A simple alternative is to use a bottom script.

A "bottom script" (I suppose you mean a `script' element at the end of the
`body' element as anything below that would be invalid) is not supposed to
work as the document is not fully loaded.

Slightly more complex: an onload event handler.

Hence this event handler, which should be used through the
standards-compliant attribute of the `body' element (and *not* through the
proprietary property of the Global/window object). What makes it slightly
more complex also has a strong tendency to ease maintenance, because you
will be forced to design the used algorithms top-down (or bottom-up) unless
you want to make a complete illegible mess of the attribute value.

Another approach is to capture events on bubble.

Yes, that would be a so far viable and better alternative to Unobtrusive
JavaScript, except when you need to handle proprietary events or events that
do not bubble.

>Then leave the progressive attaching of events to elements up to the
>browser - hasta la vista onload!

>
Microsoft already did that.

http://msdn.microsoft.com/en-us/library/ms535892(VS.85).aspx

http://msdn.microsoft.com/en-us/libr...46(VS.85).aspx

But, unsurprisingly, they did it wrong again, i.e. contrary to the markup
standards that they signed up to as a W3C member.


PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann

[Thomas 'PointedEars' Lahn]

Re: &quot;modern&qu ot; javascript...

dhtml wrote:

[about Unobtrusive JavaScript:] [...] HTML in scripts is usually a lot
harder to maintain than just plain HTML.
>
The same can be true for scripts in HTML.

But it is not. That is a straw man argument.

When event handlers are in the HTML, not in the js file, the script is
more scattered. Look in the JS file for that page, not some html/tag
file. Doesn't that seem easier?

It may seem easier at first, but on a closer look one observes how easy
debugging and maintenance is instead hindered by it. In addition to that,
one important, frequently overlooked drawback of Unobtrusive JavaScript is
that it requires enhanced DOM support. One may need to resort to the use
of proprietary APIs with it, and maybe even host object augmentation (which
is pretty bad as support for this is specified as being optional).
Standards-compliant intrinsic event handler attributes seldom impose such
restrictions.

It is also useful to have a common methodology that is accepted by the
team. Having a restraint like "no event handlers in the HTML" can make
debugging easier.

Having had to debug several such scripts in my job, I seriously doubt that.
To begin with, name a DOM inspector application which shows all the
dynamically added event listeners attached for a target object without
triggering the event. Then name one DOM inspector application that does not
show the value of intrinsic event handler attributes.

>>When the browser makers give us an API where separating script and
>>API works and connecting them by something like CSS selectors
>>(probably CSS selectors as they already work and are part of the
>>browser world) then I think the separation is a good idea. Until
>>then, the only alternatives to mixing script and HTML are far too
>>complex for their apparent value of "maintainabilit y" etc.

>
A simple alternative is to use a bottom script.

A "bottom script" (I suppose you mean a `script' element at the end of the
`body' element as anything below that would be invalid) is not supposed to
work for adding event listeners in all cases as the document is not fully
loaded.

Slightly more complex: an onload event handler.

Hence the existence of this event handler, which should be used through the
standards-compliant attribute of the `body' element (and *not* through the
proprietary property of the Global/window object). That which makes it
"slightly more complex" also provides a good chance for easing maintenance,
because you will be forced to design the used algorithms top-down (or
bottom-up) unless you want to make a complete illegible mess of the
attribute value.

Another approach is to capture events on bubble.

Yes, that would be a so far viable and better alternative to Unobtrusive
JavaScript, except when you need to handle proprietary events or events that
do not bubble.

>Then leave the progressive attaching of events to elements up to the
>browser - hasta la vista onload!

>
Microsoft already did that.

http://msdn.microsoft.com/en-us/library/ms535892(VS.85).aspx

http://msdn.microsoft.com/en-us/libr...46(VS.85).aspx

But, unsurprisingly, they did it wrong again, i.e. contrary to the markup
standards that they signed up to as a W3C member.


PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann

[RobG]

Re: &quot;modern&qu ot; javascript...

On Jul 17, 5:20 pm, dhtml <dhtmlkitc...@g mail.comwrote:

On Jul 16, 10:00 pm, RobG <rg...@iinet.ne t.auwrote:
>

On Jul 17, 8:34 am, Peter Michaux <petermich...@g mail.comwrote:

>

On Jul 16, 9:59 am, Thomas 'PointedEars' Lahn <PointedE...@we b.de>
wrote:

>

Joost Diepenmaat wrote:

>

>http://en.wikipedia.org/wiki/Unobtrusive_JavaScript

>
<quote>
"However, the purpose of markup is to describe a document's structure,
not its programmatic behavior. Combining the two negatively impacts a
site's maintainability for the same reason that combining content and
presentation does:

If that really were true, HTML would only have one element (say div)
and the entire layout would be in CSS. The real point is that CSS
provides a more maintainable and efficient method of modifying the
*default* presentation of HTML elements.

if a site contains hundreds of such date fields,
adding the appropriate onchange attribute for each one (and modifying
them later, if necessary) can be a labor-intensive process.

That is an issue only if the source is manually created. In that
case, the issue can often be overcome by event delegation (i.e.
responding to bubbling events on a common parent element). If the
source is generated by a server framework, it is no more difficult
that modifying a script that attaches them at the client.

Furthermore, inline syntax prevents the registration of more than one
event handler for the element's onchange event,

That's just not true:

<input onchange="func1 (); func2();" ... >

which can be a problem
as the application grows."
</quote>

[...]

HTML in scripts is usually a lot harder to maintain than just plain
HTML.
>
The same can be true for scripts in HTML. When event handlers are in
the HTML, not in the js file, the script is more scattered. Look in
the JS file for that page, not some html/tag file. Doesn't that seem
easier?

In a non-trivial page, it is likely that the work will be done using
search and replace in an editor. i don't think it is any harder to
search an HTML file than a script file if they are both formatted to
some reasonable standard.

It is also useful to have a common methodology that is accepted by the
team. Having a restraint like "no event handlers in the HTML" can
make debugging easier.

Usually the bug is in the code, not the call, so it *might* make
debugging easier. But easier maintenance isn't an inherrant trait of
attaching handlers at the client using script - you may have to debug
the code that attaches them, which makes debugging harder, especially
given the issues many programmers have with scope and the value of the
this keyword for listeners added that way.

When the browser makers give us an API where separating script and API
works and connecting them by something like CSS selectors (probably
CSS selectors as they already work and are part of the browser world)
then I think the separation is a good idea. Until then, the only
alternatives to mixing script and HTML are far too complex for their
apparent value of "maintainabilit y" etc.

>
A simple alternative is to use a bottom script. Slightly more complex:
an onload event handler.

I think Peter was referring to the whole strategy of adding listeners
at the client using script, the actual method used isn't the issue.

Another approach is to capture events on
bubble.

Different issue.

Then leave the progressive attaching of events to elements up to the
browser - hasta la vista onload!

>
Microsoft already did that.http://msdn.microsoft.com/en-us/libr...46(VS.85).aspx

Ugghh - that is just bastardisation of the script element, what I was
suggesting was a CSS-like system (say Event Definition Sheet) for
associating listeners with elements. In the case of say multiple date
inputs, something like:

<head>
...
<script type="text/javascript">
function validate(e, el) { ... }
</script>

<event type="text/EDS">
.xx_validateDat eField {
change: validate(event, this);
}
</event>
</head>
<body>
...
<input class="xx_valid ateDateField" id="date01" ... >
<input class="xx_valid ateDateField" id="date02" ... >
<input class="xx_valid ateDateField" id="date03" ... >
...
</body>


--
Rob

[Peter Michaux]

Re: &quot;modern&qu ot; javascript...

On Jul 17, 7:38 pm, RobG <rg...@iinet.ne t.auwrote:

On Jul 17, 5:20 pm, dhtml <dhtmlkitc...@g mail.comwrote:

On Jul 16, 10:00 pm, RobG <rg...@iinet.ne t.auwrote:

On Jul 17, 8:34 am, Peter Michaux <petermich...@g mail.comwrote:

[snip]

<quote>
"However, the purpose of markup is to describe a document's structure,
not its programmatic behavior. Combining the two negatively impacts a
site's maintainability for the same reason that combining content and
presentation does:

>
If that really were true, HTML would only have one element (say div)
and the entire layout would be in CSS. The real point is that CSS
provides a more maintainable and efficient method of modifying the
*default* presentation of HTML elements.

I don't think that is true. If HTML only had div elements then there
would be no way to describe the document's structure: what's a
heading, what's a paragraph, what's a list, etc. That is exactly the
purpose of HTML: denoting what is what in the text.

HTML itself doesn't have a default presentation. A user agent supplies
a default styling (e.g. font style or voice inflection) and different
user agents do this differently.

[snip]

Furthermore, inline syntax prevents the registration of more than one
event handler for the element's onchange event,

>
That's just not true:
>
<input onchange="func1 (); func2();" ... >

I agree with dhtml, that is only one handler; however, Rob's sentiment
that these are two handlers can easily been understood. If func1
errors then func2 won't run in the code above. The code can be
modified with try-catch to make it so func2 would still run. With two
genuinely separate handlers this sort of business wouldn't be
necessary.

[snip]

When the browser makers give us an API where separating script and API
works and connecting them by something like CSS selectors (probably
CSS selectors as they already work and are part of the browser world)
then I think the separation is a good idea. Until then, the only
alternatives to mixing script and HTML are far too complex for their
apparent value of "maintainabilit y" etc.

>

A simple alternative is to use a bottom script. Slightly more complex:
an onload event handler.

>
I think Peter was referring to the whole strategy of adding listeners
at the client using script, the actual method used isn't the issue.

All the current options for adding unobtrusive listeners to elements
in the page provide a poorer user experience than just using inline
handlers. That includes the Dean Edwards hack, DOM polling and adding
the listener as soon as the element appears, and the bottom script
technique. They all can leave elements visible to the user but un-
enlived while the page continues loading. Inline handlers don't do
that and so are better.

The only real alternative is using global event delegation but that
doesn't work with non-bubbling events. In the W3C DOM all events do go
through the capture phase. If all events in all browsers had event
capture then event capture delegation would be a viable technique and
a developer could build a complete roll-your-own event system. That
would likely be less efficient than using the built in system.

I explored this problem in way too much detail but I'm glad I did.

http://peter.michaux.ca/article/553

http://peter.michaux.ca/article/3752

Those investigations really turned me off the mainstream libraries and
their acceptance of hack solutions because they "drank the Kool-Aid"
and think unobtrusive is a necessity.

When it really matters, I use inline handlers because they *work*
exactly how the unobtrusive people want their techniques to work.

After some experiments with a roll-my-own event system, I also
discovered that the style of programming where you would add listeners
through a css selector leads to code I don't like. It involves The
Flyweight Pattern and elements have to have special ids that match
them up. For example, a tabbed pane might have tabs with ids tab123,
tab124, tab125 and they toggle pane123, pane124, pane125 respectively.
When a tab is clicked, the id is parsed, the current pane is found and
turned off and the new pane to show is found and turned on. The
JavaScript never retains the associated elements. They have to be
found all the time. (OK you could do some weird tricks but they aren't
the natural way to program such system.) This flyweight pattern does
require less memory which is the whole point of the flyweight pattern
but the response time is slower. I would only use such a system in a
situation where the efficiency was necessary.

Another approach is to capture events on
bubble.

>
Different issue.
>

Then leave the progressive attaching of events to elements up to the
browser - hasta la vista onload!

>

Microsoft already did that.http://msdn.microsoft.com/en-us/libr....aspxhttp://ms...

That link doesn't work for me. So I'm not sure what ot ma

Ugghh - that is just bastardisation of the script element, what I was
suggesting was a CSS-like system (say Event Definition Sheet) for
associating listeners with elements. In the case of say multiple date
inputs, something like:
>
<head>
...
<script type="text/javascript">
function validate(e, el) { ... }
</script>
>
<event type="text/EDS">
.xx_validateDat eField {
change: validate(event, this);
}
</event>
</head>
<body>
...
<input class="xx_valid ateDateField" id="date01" ... >
<input class="xx_valid ateDateField" id="date02" ... >
<input class="xx_valid ateDateField" id="date03" ... >
...
</body>

I think I would rather just see the addEventListene r or something take
a string argument that is the CSS selector rather than farming the
connection between script and html to a separate sheet. Something like

<script type="text/javascript">
function validate(e, el) { ... }
window.addCssLi stener('.xx_val idateDateField' , validate);
</script>

This is how my roll-your-own experiment worked and that part of it I
thought was fine. I just didn't like the code that went into the
handler function.

Peter

[dhtml]

Re: &quot;modern&qu ot; javascript...

On Jul 17, 10:01 pm, Peter Michaux <petermich...@g mail.comwrote:

On Jul 17, 7:38 pm, RobG <rg...@iinet.ne t.auwrote:
>

On Jul 17, 5:20 pm, dhtml <dhtmlkitc...@g mail.comwrote:

On Jul 16, 10:00 pm, RobG <rg...@iinet.ne t.auwrote:
On Jul 17, 8:34 am, Peter Michaux <petermich...@g mail.comwrote:

>

Furthermore, inline syntax prevents the registration of more than one
event handler for the element's onchange event,

>

That's just not true:

>

<input onchange="func1 (); func2();" ... >

>
I agree with dhtml, that is only one handler; however, Rob's sentiment
that these are two handlers can easily been understood. If func1
errors then func2 won't run in the code above. The code can be
modified with try-catch to make it so func2 would still run. With two
genuinely separate handlers this sort of business wouldn't be
necessary.

Event handler attributes are fine for small sites, but don't scale
well.

Often handlers need to be attached dynamically and this is where
multiple handlers becomes a concern.
Other times, handlers need to be removed.

In these cases, it is absolutely necessary to access and modify the
event handler in the javascript. Now there are two places where event
handlers are modified. It seems best to have just one.

It's possible to wrap the existing callback. That's kind of a pain.

Using a registry is another approach:

addCallback(but ton, "onmousedow n", cb);

The Registry can provide other benefits as well. The Registry can also
work with event handler attributs, but the result will be HTML that
looks like: <button onclick="f()" where the button's REAL onclick is
something like wrappedFn.

All the current options for adding unobtrusive listeners to elements
in the page provide a poorer user experience than just using inline
handlers.

That would be true if the user didn't have to wait for all of the top
scripts to load. Having an attribute event with a top script results
in a slower UX. The user has to wait for the scripts to d/l and be
evaluated.

That includes the Dean Edwards hack, DOM polling and adding
the listener as soon as the element appears, and the bottom script
technique. They all can leave elements visible to the user but un-
enlived while the page continues loading. Inline handlers don't do
that and so are better.

Event handler attributes work unless a bottom script is used. In that
case, there will be errors when attempting to call an undefined
function in the element's event handler attribute.

Using bottom scripts has been shown to significantly decrease page
load time.

If "unresponsi ve widgets during page load" is a problem, it might be
an option to hide those widgets by using CSS and unhide them with
javascript.

If javascript is not enabled, then the user would not be able to use
those widgets anyway.

>
The only real alternative is using global event delegation but that
doesn't work with non-bubbling events. In the W3C DOM all events do go
through the capture phase. If all events in all browsers had event
capture then event capture delegation would be a viable technique and
a developer could build a complete roll-your-own event system. That
would likely be less efficient than using the built in system.
>

These things would be easier if IE were to support DOM events.

>

Microsoft already did that.http://msdn.microsoft.com/en-us/libr...92(VS.85).aspx

http://ms...

>
That link doesn't work for me. So I'm not sure what ot ma
>

?

Peter: Are you using google groups? I've had stuff chopped off like
that using groups in Webkit.

The MSDN links work for me if I click them twice. I don't know why,
but they usually only work the second time. I'm not sure how they got
concatenated together like that.

>
I think I would rather just see the addEventListene r or something take
a string argument that is the CSS selector rather than farming the
connection between script and html to a separate sheet. Something like
>
<script type="text/javascript">
  function validate(e, el) { ... }
        window.addCssLi stener('.xx_val idateDateField' , validate);
</script>
>
This is how my roll-your-own experiment worked and that part of it I
thought was fine. I just didn't like the code that went into the
handler function.
>

Having the actual object before attaching any callback handler is
useful because you actually have it. Otherwise, if the string value is
not resolved to an element ID (or selector), then there is silent
failure.

Garrett

Peter