Re: Simpler loading through jQuery

Peter Michaux wrote:
On Jun 24, 11:53 pm, Garrett Smith <dhtmlkitc...@xxxxxxxxx> wrote:
Peter Michaux wrote:
On Jun 24, 5:46 am, kangax <kan...@xxxxxxxxx> wrote:
Peter Michaux wrote:
On Jun 23, 9:26 pm, David Mark <dmark.cins...@xxxxxxxxx> wrote:
Delegation is
useful, but I don't see how it fits into this puzzle.
One common use of unobtrusive JavaScript is to attach "click" handlers
to elements of interest in the page as soon as possible. The "as soon
as possible" usually means that the element is visible for a short, or
maybe long, time before the handler is attached. That is bad.
By using global delegation, the click handler can be attached to
something that already exists when the document head loads: e.g. the
documentElement. Then the click events on those elements of interest
bubble up to the documentElement and can be handled there. This means
the elements of interest were never simultaneously visible and
unenlivened in the page.
I experimented with this sort of global delegation quite a bit. Wrote
I've been using bubbling for years.

I've been using bubbling for years too: for example, delegation for a
drag-and-drop list where the <ul> element gets mousedown events on the
<li> elements. The issue here is whether or not global delegation as a
general strategy is a good one. I found it not to be a good one for
reasons listed in this thread.


Global delegation works but in the end I didn't think the style of
programming that seems to be natural with this sort of global
delegation was a very nice/the best style of browser scripting.
Could you expand on this?
One real problem is non-bubbling events like focus. I made a stab at
addressing this issue
What is wrong with focusin?

My point was there are non-bubbling event types and so there is no
complete solution using global event delegation based on bubbling
alone.


http://peter.michaux.ca/articles/the-window-onload-problem-really-solved
I don't understand. Your page uses:
| <input type="text" focus="jQuery.ready(event)"
| blur="jQuery.ready(event)">

What is that? It looks like bugs, but I am not sure.

If you discover it is a bug then please let me know.


The attribute names "focus" and "blur" are invalid. Custom attributes for same-named dom properties.


All events go thorough the capture phase so if IE supported the DOM3
event module capture could be used for non-bubbling events. IE doesn't
so capture is out as an option.
I'm not sure what you meant to say, but as you wrote it, that is
incorrect. It is untrue that all events go through the capture phase.

Which DOM2 event types where the event is initiated by user action
does not go through capture?

http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-flow-capture

The only qualification on which events go though capture phase is the
following

"A capturing EventListener will not be triggered by events dispatched
directly to the EventTarget upon which it is registered."

I believe the situation they mean is when a script dispatches an event
on an element using the dispatchEvent method.


That is an incorrect interpretation. What it means is that if the event listener is a capturing listener, and the event is dispatched on the target, it won't fire. An event being dispatched does not mean the "dispatchEvent" method was used.

It is the same in the latest D3E WD (DOM 3 Events, Working Draft)[0]

But, it doesn't actually work that way.
https://bugzilla.mozilla.org/show_bug.cgi?id=235441
https://bugs.webkit.org/show_bug.cgi?id=9127

In fact, Opera has changed its implementation and, upon further
research, it appears that the D3E WD (DOM 3 Events Working Draft) is
different than DOM 2 Events.

From s. 1.2 Event dispatch and DOM event flow[1] contains a diagram
that depicts an event dispatched in a DOM tree using the DOM event flow.

That diagram is followed by the following text:

| Event objects are always dispatched to an event target called the
| event's target. At the beginning of the dispatch, implementations must
| first determine the event object's propagation path. This is an
| ordered list of event targets the object may propagate to. The last
| item in the list is the event's target; the preceding items in the
| list are referred to as the target's ancestors and the immediately
| preceding item as the target's parent. Once determined, the
| propagation path cannot be changed. As an example, in the DOM event
| flow event listeners might change the position of the target node in
| the document while the event object is being dispatched; such changes
| do not affect the propagation path.

So, it seems that according to this working draft, all events *do* have a capture phase. A listener registered for bubbling will not fire on the capture phase.

Keep in mind that D3E is a working draft and not a Technical Recommendation. It is not done and there are compatibility issues at the moment.

For example, D3E says scroll bubbles[1]. AFAIK, onscroll doesn't bubble in major browsers, including IE[2], which has had onscroll for years (deja vu).

In fact, webkit "fixed" onscroll to *not* bubble[3].

Then there is the following text from D3E:
| A DOM application may use the hasFeature(feature, version) method of
| the DOMImplementation interface with parameter values "Events" and
| "3.0" (respectively) to determine whether or not DOM Level 3 Events is
| supported by the implementation. Since DOM Level 3 Events is built on
| top of DOM Level 2 Events [DOM Level 2 Events], an implementation that
| returns true for "Events" and "3.0" will also return true for the
| parameters "Events" and "2.0".

Method hasFeature is very generalized and far removed from the detail about any specific object feature. Expectations that the return value provides useful information about a particular feature may disappointed.

Garrett

[0]http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events-EventTarget-addEventListener
[1]http://www.w3.org/TR/DOM-Level-3-Events/events.html#event-scroll
[2]http://msdn.microsoft.com/en-us/library/ms536966(VS.85).aspx
[3]https://bugs.webkit.org/show_bug.cgi?id=18106
--
comp.lang.javascript FAQ: http://jibbering.com/faq/
.