Re: "modern&qu ot; javascript...
dhtml wrote:
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? When?
Again, when?
No, it is not.
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 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.
Nothing you said is exactly new here, but most of what you said is simply wrong.
>
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.
>
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" is unreliable at best.
So that nothing works when CSS is present and scripting is not? I don't
think so.
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.
>
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.
>
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>
dhtml wrote:
On Jul 17, 10:01 pm, Peter Michaux <petermich...@g mail.comwrote:
>
Event handler attributes are fine for small sites, but don't scale
well.
>On Jul 17, 7:38 pm, RobG <rg...@iinet.ne t.auwrote:
>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.
>>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:
>>>Furthermor e, 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();" ... >
>>>On Jul 16, 10:00 pm, RobG <rg...@iinet.ne t.auwrote:
>>>>On Jul 17, 8:34 am, Peter Michaux <petermich...@g mail.comwrote:
>>>Furthermor e, 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();" ... >
>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.
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.
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.
event handler in the javascript.
Now there are two places where event handlers are modified.
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.
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(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.
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.
>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.
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.
>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.
function to be called and the functions it is calling were instantiated.
Using bottom scripts has been shown to significantly decrease page
load time.
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.
an option to hide those widgets by using CSS and unhide them with
javascript.
think so.
If javascript is not enabled, then the user would not be able to use
those widgets anyway.
those widgets anyway.
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.
>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.
and different DOMs would remain.
>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.
>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.
--
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>
Comment