13:57
<smaug>
annevk: ping
14:28
<annevk>
pong
14:28
<annevk>
smaug, ...
14:29
<smaug>
annevk: about DOMActivate
14:29
<smaug>
annevk: according to html5 the default action is to dispatch DOMActivate
14:30
<smaug>
where does it say that only the first default action should occur?
14:31
<annevk>
the default action of some form of activation (Enter, clicking, etc.) is to dispatch a 'click' event
14:31
<annevk>
default action of that is to dispatch DOMActivate
14:32
<annevk>
the first element in tree order with activation behavior gets its activation behavior triggered at that point
14:32
<annevk>
reverse tree order*
14:32
<smaug>
annevk: but where does it say that only one DOMActivate gets activated
14:33
<annevk>
DOMActivate is not activated
14:33
<smaug>
I thought all default actions should be triggered
14:33
<annevk>
it's just dispatched
14:33
<annevk>
I would suggest to read http://www.whatwg.org/specs/web-apps/current-work/#interactive1 carefully although I suppose you have already done so... :)
14:33
<smaug>
annevk: I've read it carefully
14:34
<smaug>
how does an element know whether to dispatch DOMActivate or not?
14:34
<annevk>
that doesn't matter
14:34
<smaug>
why not?
14:34
<annevk>
click is dispatched of which the default action is to dispatch DOMActivate
14:35
<annevk>
regardless of which element it is
14:35
<annevk>
click will always have DOMActivate triggered
14:35
<smaug>
what is the target of the DOMActivate?
14:36
<annevk>
the same element as that of the click event
14:36
<annevk>
"must be to fire a further DOMActivate event at the same element"
14:36
<smaug>
<a>foo<button>bar</button></a>
14:36
<smaug>
or, <a>foo<span>clickme</span></a>
14:36
<smaug>
span is the target of the click
14:36
<smaug>
how does <a> know to dispatch DOMActivate?
14:37
<annevk>
DOMActivate would be dispatched on <span>
14:37
<annevk>
and the first element with activation behavior it bubbles through (in the first case, <button>, second case, <a>) will have its activation behavior triggered (submission, following the link)
14:37
<annevk>
it's pretty clear in the specification
14:38
<smaug>
it is not clear
14:38
<annevk>
just read it literally without any bias of what prior specifications might have suggested
14:38
<annevk>
ok, what part is not clear?
14:40
<smaug>
the chapter talks about "interactive" elements
14:41
<smaug>
should DOMActivate be dispatched whether or not click happens inside an interactive element?
14:41
<annevk>
yes
14:42
<smaug>
and it also talks about default action, but not where the default action should be handled
14:42
<annevk>
I suppose that could be made more clear
14:42
<annevk>
I'm not sure I understand that
14:43
<smaug>
all the elements may have default actions
14:43
<smaug>
and also document could have default action
14:43
<smaug>
and it doesn't matter whether or not the target of the event is the element (or document)
14:44
<annevk>
it just defines what the default action of click and DOMActivate is
14:44
<annevk>
for click -> dispatch DOMActivate; for DOMActivate -> activate the first element with activation behavior in reverse tree order
14:45
<smaug>
I understand activation behavior, since that is different than default action
14:45
<smaug>
but default action happens in all tree levels, in reverse tree order
14:45
<annevk>
what do you mean?
14:46
<smaug>
<a> has a default action for click
14:46
<smaug>
in gecko it is currently to dispatch DOMActivate
14:46
<annevk>
it overwrites all that
14:47
<annevk>
as I said, you have to interpret this literally, without bias
14:47
<smaug>
webkit has similar meaning for default actions
14:47
<smaug>
at least it used to have
14:48
<annevk>
for instance, the <a> element is defined to have activation behavior which would be triggered if anyone click on "foo" in the following cases <a>foo</a>, <a><span>foo</span></a>, <a><span>bar<span>foo</span></a>, etc.
14:48
<smaug>
hmm, is the meaning of default action defined anywhere..
14:48
<annevk>
DOM2Events?
14:49
<annevk>
anyway, this new concept comes much closer to what IE (and Opera) do and is a bit more useful for cases such as <a> foo <input type=submit></a>
14:50
<smaug>
DOM2Events doesn't define default actions properly
14:50
<smaug>
it doesn't say whether or not they are happening in node level or document level
14:51
<annevk>
http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-flow-cancelation
14:51
<smaug>
nope
14:52
<smaug>
that just says that event listeners must fire before default action
14:52
<annevk>
hmm, they are happening at node-level I'd say
14:52
<annevk>
not sure how you can test that and I'm also not sure how that's relevant here
14:53
<smaug>
but for all elements there is the default action for "click" event to dispatch DOMActivate if the target of the "click" is the current node
14:53
<smaug>
?
14:53
<annevk>
(well, I see that in Gecko you could get Multiple DOMActivate events now because of how <a>.onclick is handled right now...)
14:54
<annevk>
smaug, yes, the default action of a click event being dispatched is to dispatch a DOMActivate event
14:54
<annevk>
although not for synthetic click events aiui
14:54
<smaug>
but that happens only if the target of the element is the "current" element
14:54
<smaug>
there is after all some sort of posthandleevent phase
14:55
<smaug>
apparently in opera too
14:55
<smaug>
if default actions are node level
14:55
<annevk>
it doesn't happen during the bubbling phase, no
14:55
<annevk>
only when it's dispatched
14:56
<annevk>
I suppose it might be worthwhile to be a bit more explicit about such details in the draft; either in HTML 5 or DOM3Events
15:00
<smaug>
annevk: hmm, but does that meaning of default actions apply to all cases
15:00
<smaug>
how about xbl2?
15:00
<smaug>
at least it used to be possible to define own default actions
15:01
<smaug>
node level, and not depending on whether or not the current node is the target of the event
15:02
<annevk>
I suppose HTML 5 should just be clarified that the click event only does that when the current node is also the target node
15:03
<smaug>
yes, because that is a special case for a default action
15:03
<smaug>
xbl2 still has the way to define default actions
15:03
<smaug>
node level and triggered reversed tree order
15:03
<annevk>
Yeah, much like <html:form> has a default action for 'submit' too...
15:04
<smaug>
so html5 is not at all clear
15:04
<smaug>
it has special meaning for default action in one case
15:05
<smaug>
in gecko default actions happen always pretty much like in xbl2
15:05
<annevk>
what it says sort of implies the special case though
15:05
<smaug>
"implies" :)
15:06
<annevk>
by using "the element" etc. but it can be better :)
15:07
<annevk>
I'd suggest raising it on the list and implementing it as if it was more clear :)
15:08
<smaug>
or maybe I should come up some more reasonable solution for the problem
15:08
<smaug>
special casing default action handling sounds like a hack
15:09
<annevk>
the default action of the click event, if the target node is the same as the current node, is to dispatch a DOMActivate at the current node
15:09
<annevk>
seems reasonable to me
15:10
<smaug>
hmm, yes. that way
15:10
<smaug>
and it should be clear that it is not about interactive elements
15:10
<smaug>
but all elements
15:10
<smaug>
er, all nodes
15:11
<smaug>
(click may happen also on document, I think)
15:11
<annevk>
and for DOMActive you just have event listeners set up at the activation behavior elements and a special flag that tells you whether some element has its behavior triggered already
15:11
<annevk>
or some such
15:11
<smaug>
activation behavior is clear, sure
15:12
<annevk>
oh, ok, I thought there was some confusion about first in reverse tree order, but that might have been because of the multiple DOMActivate events...
15:19
<smaug>
(need to still think about how the click event's default action work with XBL, when there is retargeting happening...)
15:20
<annevk>
hah, have fun with that, while I take a break from this stuff :)
20:06
<hsivonen>
http://htmlpurifier.org/