- From: <boyerj@ca.ibm.com>
- Date: Wed, 14 Nov 2007 09:35:41 -0600
- To: public-xhtml2@w3.org
- CC: xhtml2-issues@mn.aptest.com
This is a multipart message in MIME format.
--=_alternative 0079B90488257333_=
Content-Type: text/plain; charset="US-ASCII"
1) The phase attribute should have an additional possible value of
"target".
It is odd that you can handle an event in the capture phase and you can
handle it in the target+bubble phase, but that you cannot say you only
want to handle the event if it is the target phase only. Note that the
term "target phase" actually does appear,
I know you have a way of doing that using a target ID, but I'd like to be
able to do it without IDs for a variety of reasons having to do with
limitations of XML IDs at both design time (e.g. easily re-using XML
fragments) and run-time (e.g. IDs within XForms repeats).
2) Moreover, I would like to express the point of view that the proper
default *should* be "target". Most frequently one wants to capture an
event happening directly to an element, not to that element or its
descendants. XForms is rife with examples. Suppose you have this:
<input ref="some/node">
<label>This is <output ref="../label"/></label>
<action ev:event="xforms-value-changed">
<!-- Do some stuff -->
</action>
</input>
If the value of "some/node" changes, then clearly we want to "Do some
stuff". But the output in the label also gets an xforms-value-changed
when the value of some/label changes. This event bubbles up to the input
and voila, we "Do some stuff" that we should not be doing.
It is just wrong that one should have to put an ID on the input and put an
ev:target on the action to indicate the input ID. The above is clear, and
if I want to capture events that are bubbling, I should have to say so.
3) Finally, I believe you should add the keyword "bubble" and perhaps have
it mean the same thing as the current "default" keyword. First of all,
"default" is a horrible way to describe the default. Second of all, I
proposed above to change the default, and if you accept that proposal,
then default won't be the default anymore. As this is a major revision of
XML Events, I believe you should be able to do this.
So you do need a new way to describe the phase currently called "default".
One problem with calling it "bubble" is that you do seem to be defining
the bubble phase as excluding the target phase. It was not previously
clear to me that the were separate; I thought the target phase was just
the first part of the bubble phase, but maybe that's because of how
default was defined.
I can see at least a little utility in being able to capture an even only
if it was targeted at a proper descendant; I can't say I have a strong use
case to present though. But if the bubble phase does exclude the target
phase, then it seems like you will need a way to say target+bubble. For
symmetry, I'll bet you need capture+target too. The only names that come
to mind right now are"ascent" (target+bubble) and "descent"
(capture+target).
John M. Boyer, Ph.D.
STSM: Lotus Forms Architect and Researcher
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com
Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
--=_alternative 0079B90488257333_=
Content-Type: text/html; charset="US-ASCII"
<br><font size=2 face="sans-serif">1) The phase attribute should have an
additional possible value of "target". </font>
<br>
<br><font size=2 face="sans-serif">It is odd that you can handle an event
in the capture phase and you can handle it in the target+bubble phase,
but that you cannot say you only want to handle the event if it is the
target phase only. Note that the term "target phase" actually
does appear, </font>
<br>
<br><font size=2 face="sans-serif">I know you have a way of doing that
using a target ID, but I'd like to be able to do it without IDs for a variety
of reasons having to do with limitations of XML IDs at both design time
(e.g. easily re-using XML fragments) and run-time (e.g. IDs within XForms
repeats).</font>
<br>
<br>
<br><font size=2 face="sans-serif">2) Moreover, I would like to express
the point of view that the proper default *should* be "target".
Most frequently one wants to capture an event happening directly
to an element, not to that element or its descendants. XForms is
rife with examples. Suppose you have this:</font>
<br>
<br><font size=2 face="Courier New"><input ref="some/node"></font>
<br><font size=2 face="Courier New"> <label>This is <output
ref="../label"/></label></font>
<br><font size=2 face="Courier New"> <action ev:event="xforms-value-changed"></font>
<br><font size=2 face="Courier New"> <!-- Do some
stuff --></font>
<br><font size=2 face="Courier New"> </action></font>
<br><font size=2 face="Courier New"></input></font>
<br>
<br><font size=2 face="sans-serif">If the value of "some/node"
changes, then clearly we want to "Do some stuff". But the
output in the label also gets an xforms-value-changed when the value of
some/label changes. This event bubbles up to the input and voila,
we "Do some stuff" that we should not be doing.</font>
<br>
<br><font size=2 face="sans-serif">It is just wrong that one should have
to put an ID on the input and put an ev:target on the action to indicate
the input ID. The above is clear, and if I want to capture events
that are bubbling, I should have to say so.</font>
<br>
<br>
<br><font size=2 face="sans-serif">3) Finally, I believe you should add
the keyword "bubble" and perhaps have it mean the same thing
as the current "default" keyword. First of all, "default"
is a horrible way to describe the default. Second of all, I proposed
above to change the default, and if you accept that proposal, then default
won't be the default anymore. As this is a major revision of XML
Events, I believe you should be able to do this.</font>
<br>
<br><font size=2 face="sans-serif">So you do need a new way to describe
the phase currently called "default". One problem with
calling it "bubble" is that you do seem to be defining the bubble
phase as excluding the target phase. It was not previously clear
to me that the were separate; I thought the target phase was just the first
part of the bubble phase, but maybe that's because of how default was defined.</font>
<br>
<br><font size=2 face="sans-serif">I can see at least a little utility
in being able to capture an even only if it was targeted at a proper descendant;
I can't say I have a strong use case to present though. But if the
bubble phase does exclude the target phase, then it seems like you will
need a way to say target+bubble. For symmetry, I'll bet you need
capture+target too. The only names that come to mind right now are"ascent"
(target+bubble) and "descent" (capture+target).</font>
<br>
<br><font size=2 face="sans-serif">John M. Boyer, Ph.D.<br>
STSM: Lotus Forms Architect and Researcher<br>
Chair, W3C Forms Working Group<br>
Workplace, Portal and Collaboration Software<br>
IBM Victoria Software Lab<br>
E-Mail: boyerj@ca.ibm.com <br>
<br>
Blog: </font><a href=http://www.ibm.com/developerworks/blogs/page/JohnBoyer><font size=2 face="sans-serif">http://www.ibm.com/developerworks/blogs/page/JohnBoyer</font></a><font size=2 face="sans-serif"><br>
<br>
</font>
--=_alternative 0079B90488257333_=--
Received on Wednesday, 14 November 2007 15:38:51 UTC