"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]

maya <ma********@yahoo.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]

Joost Diepenmaat wrote:

maya <ma********@yahoo.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 "unobtrusive" javascript -- javascript you
don't like??....;)

thank you...

[Joost Diepenmaat]

maya <ma********@yahoo.comwrites:

(not sure what is meant by "unobtrusive" 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]

Joost Diepenmaat <jo***@zeekat.nlwrites:

maya <ma********@yahoo.comwrites:

>(not sure what is meant by "unobtrusive" 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 "unobtrusive 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]

Joost Diepenmaat wrote:

maya <ma********@yahoo.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]

On Jul 16, 9:59 am, Thomas 'PointedEars' Lahn <[e-mail]>
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 "maintainability" etc.

Peter

[Joost Diepenmaat]

Thomas 'PointedEars' Lahn <Po*********@web.dewrites:

Joost Diepenmaat wrote:

>maya <ma********@yahoo.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]

On Jul 17, 8:34*am, Peter Michaux <[e-mail]:

On Jul 16, 9:59 am, Thomas 'PointedEars' Lahn <[e-mail]>
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 "maintainability" 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]

On Jul 16, 10:00*pm, RobG <[e-mail]:

On Jul 17, 8:34*am, Peter Michaux <[e-mail]:

On Jul 16, 9:59 am, Thomas 'PointedEars' Lahn <[e-mail]>
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 "performance 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 "maintainability" 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/libr...92(VS.85).aspx
http://msdn.microsoft.com/en-us/libr...46(VS.85).aspx

Garrett

--
Rob

[Thomas 'PointedEars' Lahn]

dhtml wrote:

On Jul 16, 10:00 pm, RobG <[e-mail]:

>On Jul 17, 8:34 am, Peter Michaux <[e-mail]:

>>On Jul 16, 9:59 am, Thomas 'PointedEars' Lahn <[e-mail]>
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 "maintainability" 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/libr...92(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]

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 "maintainability" 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/libr...92(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]

On Jul 17, 5:20 pm, dhtml <[e-mail]:

On Jul 16, 10:00 pm, RobG <[e-mail]:

On Jul 17, 8:34 am, Peter Michaux <[e-mail]:

On Jul 16, 9:59 am, Thomas 'PointedEars' Lahn <[e-mail]>
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 "maintainability" 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_validateDateField {
change: validate(event, this);
}
</event>
</head>
<body>
...
<input class="xx_validateDateField" id="date01" ... >
<input class="xx_validateDateField" id="date02" ... >
<input class="xx_validateDateField" id="date03" ... >
...
</body>
--
Rob

[Peter Michaux]

On Jul 17, 7:38 pm, RobG <[e-mail]:

On Jul 17, 5:20 pm, dhtml <[e-mail]:

On Jul 16, 10:00 pm, RobG <[e-mail]:

On Jul 17, 8:34 am, Peter Michaux <[e-mail]:

[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 "maintainability" 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_validateDateField {
change: validate(event, this);
}
</event>
</head>
<body>
...
<input class="xx_validateDateField" id="date01" ... >
<input class="xx_validateDateField" id="date02" ... >
<input class="xx_validateDateField" id="date03" ... >
...
</body>

I think I would rather just see the addEventListener 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.addCssListener('.xx_validateDateField', 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]

On Jul 17, 10:01*pm, Peter Michaux <[e-mail]:

On Jul 17, 7:38 pm, RobG <[e-mail]:

On Jul 17, 5:20 pm, dhtml <[e-mail]:

On Jul 16, 10:00 pm, RobG <[e-mail]:
On Jul 17, 8:34 am, Peter Michaux <[e-mail]:

>

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(button, "onmousedown", 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 "unresponsive 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 addEventListener 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.addCssListener('.xx_validateDateField', 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

[Thomas 'PointedEars' Lahn]

dhtml wrote:

On Jul 17, 10:01 pm, Peter Michaux <[e-mail]:

>On Jul 17, 7:38 pm, RobG <[e-mail]:

>>On Jul 17, 5:20 pm, dhtml <[e-mail]:
On Jul 16, 10:00 pm, RobG <[e-mail]:
On Jul 17, 8:34 am, Peter Michaux <[e-mail]:
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.

Nonsense. Downloading a script that has to retrieve the reference for every
object in question, do the feature test, and use the detected method of
adding an event listener is certainly less efficient than just parsing the
markup and have the script engine act only when required.

And you are persistently ignoring the fact that you can only cope with a
handful of known DOMs this way.

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

Often? When?

Other times, handlers need to be removed.

Again, when?

In these cases, it is absolutely necessary to access and modify the
event handler in the javascript.

No, it is not.

Now there are two places where event handlers are modified.

There are no places where event handlers are modified except when compiling
the UA-native DOM Event API. There are places where event *listeners* are
added or removed for an event for an object, which causes them to be called
or not called by the event handler on event.

It seems best to have just one.

It seems best to get yourself informed before you attempt parroting nonsense
at other people who might know better than you and the people you have
learned this nonsense from.

[...]
Using a registry is another approach:

addCallback(button, "onmousedown", 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.

Nothing you said is exactly new here, but most of what you said is simply wrong.

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

But adding all/most event listeners on load the document results in *no*
user experience at all (aside from the HTML default) if the user causes an
event before the script has added the listener to the target element.

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

There will only be errors if the corresponding event is triggered before the
function to be called and the functions it is calling were instantiated.

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

Using "bottom scripts" is unreliable at best.

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

So that nothing works when CSS is present and scripting is not? I don't
think so.

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

You are confusing cause and effect. What you describe is the effect of a
wrong design decision: to create widgets that do not work without scripting
in the first place.

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

True. However the problem of a requirement for a non-native event registry
and different DOMs would remain.

>I think I would rather just see the addEventListener 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.addCssListener('.xx_validateDateField', 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.

There can be silent failure without that as well.
--
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>

[Jorge]

On Jul 19, 10:06*am, dhtml <[e-mail]:

On Jul 18, 6:13*pm, Thomas 'PointedEars' Lahn <[e-mail]>

There's no way to detect "onmouseover" on the iphone and there
probably won't be.

No, there aren't onmouseover events, but we've got the much more
interesting touch events and gesture events containing TouchEvent and
GestureEvent objects...

Hence dragging could be implemented as: the fingertip moves a certain amount
of length units off the first recognized position. *Dropping: fingertip
position is no longer recognized while the dragged object is positionedover
a target that can handle the action.

In the latest iPhone.

Not in the latest iPhone, but in the latest version of its software :
iPhoneOS (v 2.0).

A lot of users have older iphone.

Most of them are already upgrading (online and free of charge) to
version 2.0 right now.

--Jorge.

[dhtml]

On Jul 19, 2:37*am, Thomas 'PointedEars' Lahn <[e-mail]>
wrote:

dhtml wrote:

Thomas 'PointedEars' Lahn wrote:

dhtml wrote:
Peter Michaux wrote:
dhtml wrote:

>
Please revise your vocabulary. *handleClick(), func1() and func2() are _not_
event handlers.

func1 and func1 are callbacks for two different, unrelated objects
that do not know about each other. Each concerned with a click event
on the element.

Using setAttribute/removeAttribute to [un]register callbacks is not
guaranteed to work and in many browsers, it won't.

If func2 needs to be removed (during execution of the loaded page),
then there aren't any reasonably good options.

>
Add: using the usual methods. *As I said before, the event handler attribute
value defines the primary event listener. *There is no good reason why
secondary, third aso event listeners could not be added to the element, and
it fact it is possible.

Remove: using the data stored in an event registry object; its unregister
method can try reading the `onclick' property.

So now we're using a Registry.

One could argue that there are no "pages requiring a lot of 'javascript'"
had the author designed with graceful degradation and code minimization (I
mean reducing the code to its essentials, not trimming whitespace) in mind.

I've worked on two corporate apps had a lot of javascript.

>

The handling would be either: 1) *a script error if the event handler
attribute was used. 2) *no interaction if the event handler wasn't
attached.

That is not handling,

The "result" would be either (1) or (2)

>
The tooltip belongs to an element, so it belongs in its start tag or
content. *What is an "empty panel div"? *What would be its use?

Usually a tooltip is implemented with one div. Only one tooltip should
ever be shown at a time.
<div id="tooltip'></div>

To have a panel or tooltip HTML in the HTML source can sometimes be
simpler than creating strings of HTML in the source code, and can also
allow for custom HTML.

<div id="user-panel'>
<h4>User Panel</h4>
<div id="user-panel-contents'><!-- xhr-driven contents --></div>
</div>

These can also be added in the tooltip.js or panel.js, but would then
require some sort of config param to be passed in to configure the
panel or tooltip.

>
And therefore you are not in a position to lecture others about it.

This sort of comment isn't useful. It isn't related to the
discussion.

>
And you can see my argument below. *Don't play stupid.

Again.

>
You are wrong, as I have explained. *If fingertip/stylus graffiti works(and
I have seen the former working IRL), it is entirely possible to implement
"onmouseover" there. *

The "pointing device" hovering "over" an object would no be
detectable.

>

Hence dragging could be implemented as: the fingertip moves a certain
amount of length units off the first recognized position. *Dropping:
fingertip position is no longer recognized while the dragged object is
positioned over a target that can handle the action.

What you are describing sounds like the touchmove event.

And there was an update for the older iphone that supports the touch
events.

>

Drag/drom would require at the very least, some sort of adapter function.

No, it would not.

Well, because it would require checking touchmove events, not
mousemove.

>

But you have to find it first.

getElementById does a pretty good job.

No, it does not. *You have trimmed the essential part of my statement: you
have to find the *offending* element first.

Capturing bubbled events and checking the target is another good strategy.

That is beside the point.

My point is that there is more than one useful strategies for dealing
with event handling and considering multiple concerns and constraints,
such as load time, user experience, and code organization.

In RIAs I worked on, there have been callbacks [un]registered, as a
result of other events. The registration happened either:

1) library code
2) page implementation code

The registry was useful to
* avoid replacing a previously registered callback
* manage [un]registering during page execution
* create an abstraction where the callbacks don't know about each
other
* add callbacks to document, window, or other objects that aren't HTML
* provide a common methodology that we all agreed on and understood.
* add callbacks to elements whose HTML event handler doesn't work
properly (body)

It does have some advantages.

Name one.

Good abstraction

Garrett

PointedEars

[Thomas 'PointedEars' Lahn]

dhtml wrote:

Thomas 'PointedEars' Lahn wrote:

>dhtml wrote:

>>Thomas 'PointedEars' Lahn wrote:
dhtml wrote:
Peter Michaux wrote:
>dhtml wrote:

Please revise your vocabulary. handleClick(), func1() and func2() are
_not_ event handlers.

func1 and func1 are callbacks for two different, unrelated objects
that do not know about each other.

There is only one thing that could be considered a callback here: the
callable object created from the intrinsic event handler attribute value.
(Have I already recommended you revised your dictionary?)

And although both calls do not need to operate on the same object (the
handling event does not need to be the target of their operation), a
relation between them cannot be denied.

Each concerned with a click event on the element.

No doubt about that.

Using setAttribute/removeAttribute to [un]register callbacks is not
guaranteed to work and in many browsers, it won't.

I did not suggest using setAttribute/removeAttribute, *you* did. IOW, it is
just another straw man argument.

If func2 needs to be removed (during execution of the loaded page),
then there aren't any reasonably good options.

Straw man again. func2() does not need to be removed.

>Add: using the usual methods. As I said before, the event handler attribute
value defines the primary event listener. There is no good reason why
secondary, third aso event listeners could not be added to the element, and
it fact it is possible.

Remove: using the data stored in an event registry object; its unregister
method can try reading the `onclick' property.

So now we're using a Registry.

I beg your pardon? I have never denied the necessity of an event registry
for removing event listeners before.

>One could argue that there are no "pages requiring a lot of 'javascript'"
had the author designed with graceful degradation and code minimization (I
mean reducing the code to its essentials, not trimming whitespace) in mind.

I've worked on two corporate apps had a lot of javascript.

This does not mean anything.

>>The handling would be either: 1) a script error if the event handler
attribute was used. 2) no interaction if the event handler wasn't
attached.

That is not handling,

The "result" would be either (1) or (2)

Yes (there should be no quotes), but that is still not handling anything.

>The tooltip belongs to an element, so it belongs in its start tag or
content. What is an "empty panel div"? What would be its use?

Usually a tooltip is implemented with one div.

The usual way is not necessarily the correct one.

Only one tooltip should ever be shown at a time.

Non sequitur.

<div id="tooltip'></div>

To have a panel or tooltip HTML in the HTML source can sometimes be
simpler than creating strings of HTML in the source code, and can also
allow for custom HTML.

Again, non sequitur. I have never suggested anything else.

<div id="user-panel'>
<h4>User Panel</h4>
<div id="user-panel-contents'><!-- xhr-driven contents --></div>
</div>

These can also be added in the tooltip.js or panel.js, but would then
require some sort of config param to be passed in to configure the
panel or tooltip.

Since such content would not degrade gracefully, it should be generated
entirely dynamically. Empty elements in the markup like this one are nonsense.

>And therefore you are not in a position to lecture others about it.

This sort of comment isn't useful. It isn't related to the
discussion.

Yes, it is. You have talked cluelessly about accessibility.

>And you can see my argument below. Don't play stupid.

Again.

Stupid is as stupid does. Do not write stupid things if you do not want
others to comment on them, especially do not ask stupid questions then.

>You are wrong, as I have explained. If fingertip/stylus graffiti works (and
I have seen the former working IRL), it is entirely possible to implement
"onmouseover" there.

The "pointing device" hovering "over" an object would no be
detectable.

True.

>>>But you have to find it first.
getElementById does a pretty good job.

No, it does not. You have trimmed the essential part of my statement: you
have to find the *offending* element first.

>>Capturing bubbled events and checking the target is another good strategy.

That is beside the point.

My point is that there is more than one useful strategies for dealing
with event handling and considering multiple concerns and constraints,
such as load time, user experience, and code organization.

True. However, with "Unobtrusive JavaScript" load time is greater, user
experience is less likely to be positive, and code is organized in a sense
that rips it further apart which makes debugging a lot harder. I do not to
see why this could be considered a Good Thing.

>>It does have some advantages.

Name one.

Good abstraction

Abstraction, granted. But in which way good, exactly?
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn wrote:

dhtml wrote:

>Thomas 'PointedEars' Lahn wrote:

>>dhtml wrote:
Thomas 'PointedEars' Lahn wrote:
dhtml wrote:
>Peter Michaux wrote:
>>dhtml wrote:
Please revise your vocabulary. handleClick(), func1() and func2() are
_not_ event handlers.

func1 and func1 are callbacks for two different, unrelated objects
that do not know about each other.

There is only one thing that could be considered a callback here: the
callable object created from the intrinsic event handler attribute value.
(Have I already recommended you revised your dictionary?)

And although both calls do not need to operate on the same object (the
handling event does not need to be the target of their operation), a
relation between them cannot be denied.

Should have been:

And although both calls do not need to operate on the same object (the
handling _object_ does not need to be the target of their operation),
a relation between them cannot be denied.

>Capturing bubbled events and checking the target is another good strategy.
That is beside the point.

My point is that there is more than one useful strategies for dealing
with event handling and considering multiple concerns and constraints,
such as load time, user experience, and code organization.

True. However, with "Unobtrusive JavaScript" load time is greater, user
experience is less likely to be positive, and code is organized in a sense
that rips it further apart which makes debugging a lot harder. I do not to
see why this could be considered a Good Thing.

Should have been:

True. However, with "Unobtrusive JavaScript" load time is greater, user
experience is less likely to be positive, and code is organized in a sense
that rips it further apart which makes debugging a lot harder. I do not see
_how_ this could be considered a Good Thing.
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee