- From: Deborah Dahl <dahl@conversational-technologies.com>
- Date: Fri, 12 Mar 2010 17:46:53 -0500
- To: <public-hypertext-cg@w3.org>
http://www.w3.org/2010/03/12-hcg-minutes.html
(note, some member-only links are included)
and below as text:
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Hypertext Coordination Group Teleconference
12 Mar 2010
See also: [2]IRC log
[2] http://www.w3.org/2010/03/12-hcg-irc
Attendees
Present
Plh, Kazuyuki, Debbie_Dahl, Doug_Schepers, Steven, ChrisL,
paulc, Janina, Shepazu
Regrets
Robin, Berjon
Chair
Chris
Scribe
ddahl
Contents
* [3]Topics
1. [4]action item
2. [5]deprecating DOMACtivate event
* [6]Summary of Action Items
_________________________________________________________
<trackbot> Date: 12 March 2010
<scribe> scribe: ddahl
action item
close action 47
close action-47
<trackbot> ACTION-47 Ask richard to send message about referencing
BCP47 to chairs@w3.org closed
<ChrisL> action-32?
<trackbot> ACTION-32 -- Deborah Dahl to follow up on scxml
implementations from KDE -- due 2009-09-30 -- OPEN
<trackbot> [7]http://www.w3.org/MarkUp/CoordGroup/track/actions/32
[7] http://www.w3.org/MarkUp/CoordGroup/track/actions/32
<ChrisL> action-42?
<trackbot> ACTION-42 -- Chris Lilley to create telcon time WBS
survey -- due 2010-01-22 -- OPEN
<trackbot> [8]http://www.w3.org/MarkUp/CoordGroup/track/actions/42
[8] http://www.w3.org/MarkUp/CoordGroup/track/actions/42
debbie: action 32 should be continued
chris: did check on script for picking times, but seemed complicated
... action 42
<ChrisL> action-44?
<trackbot> ACTION-44 -- Philippe Le Hégaret to look into funding for
browser testing from Web Foundation and NIST -- due 2010-03-31 --
OPEN
<trackbot> [9]http://www.w3.org/MarkUp/CoordGroup/track/actions/44
[9] http://www.w3.org/MarkUp/CoordGroup/track/actions/44
chris: changing to summer time in North America next week, so Europe
times will be different for the next two weeks, this will affect our
next call
... action 44, not due yet
deprecating DOMACtivate event
<ChrisL>
[10]http://lists.w3.org/Archives/Public/public-hypertext-cg/2010JanM
ar/0031.html
[10]
http://lists.w3.org/Archives/Public/public-hypertext-cg/2010JanMar/0031.html
<ChrisL> hi janina we are about todiscuss deprecating domactivate
chris: seem to have the correct people here
... HTML, WAI, XForms, SVG mention it
debbie: not in VoiceXML or MMI
chris: may not be directly referenced in WAI specs, but "click" is
very mouse-specific
<shepazu>
[11]http://www.w3.org/WAI/PF/adaptable/StatesAndProperties-20051106.
html
[11]
http://www.w3.org/WAI/PF/adaptable/StatesAndProperties-20051106.html
chris: "click" is easier to generate than "activate", so could rely
on it
janina: some take the position that "click" is the generic
"activate"
... others want the semantic distinction
chris: if DOMActivate is deprecated, could modify the documentation
for "click" to describe its semantics as equivalent to "activate"
doug: using a keyboard, tab to a link or button, if you hit spacebar
or enter, would generate a DOMActivate event but not a "click"
event, but now in current browsers you do generate a "click" event
... if UA supports both DOMActivate and click, you could distinguish
between them
janina: no one has come up with different behavior for the two cases
doug: touchscreen and pen interfaces raise issues for possible other
kinds of events, so there might be a number of different ways to
activate something
... WebApps WG will be talking about other kinds of interfaces, but
thinks that we'll have to solve the issue of activation in another
way
... we could resurrect DOMActivate if we need to
... even in deprecating it, we're actually defining it better than
before
... "alternate input device" spec needs to consider these issues
steven: the concern is that in 10 years time we will start hearing
the opposite
... it's good that browser vendors have made click interoperable,
but what's the problem with keeping DOMActivate around as well
... some specs have existing content, why take DOMActivate away?
chris: deprecating means that it should be supported but new content
shouldn't use it
... now click is widely implemented, activate is sporadically
implemented
... most content seems to be looking for a click event
... not really deprecating, but changing focus and best practices
doug: deprecation is a warning to authors
... that a feature will be removed in the next version
... doesn't tell implementations what to do
<paulc> deprecation usually means the feature MIGHT be removed in
the future
<paulc> in my experience the actual removal decision is usually left
to a later decision
(discussion about whether XForms defines or references DOMActivate)
doug: DOMActivate is a general event across languages
... we should adapt to where implementations are at a certain time
... DOMActivate is harming accesibility because we're telling
authors to do something that doesn't work, authors who use
DOMActivate are making their content less accessible
paul: why does "deprecate" mean "will be removed" not "might be
removed" in next version?
... is a warning about a possible future action, not a certain one
... the decision is left to the future version
doug: I agree with deprecate meaning "might be removed"
... this decision was made in consultation with accessibility
janina: in general approves, but not all key people were in on
discussion
... in accessibility we're interested in the functionality, not so
much what it's called
chris: it could be clarified that name is historical and clarify
what the exact semantics is
janina: that would help
doug: I think I covered those concerns in the documentation
chris: if people are hung up on the name that can be explained
... in documentation
janina: WAI-PF took an action to offer an opinion but need more
discussion
<scribe> ACTION: janina to schedule a WAI-PF call on deprecating
DOMActivate and report back to HCG [recorded in
[12]http://www.w3.org/2010/03/12-hcg-minutes.html#action01]
<trackbot> Created ACTION-50 - Schedule a WAI-PF call on deprecating
DOMActivate and report back to HCG [on Janina Sajka - due
2010-03-19].
doug: trying to clarify difference between DOMActivate and
activation behavior.
... activation behavior is made even more explicit in DOM3 events,
one
... is to throw a click event
... we aren't removing DOMActivate from DOM 2 events or even DOM 3
events
... did not remove it, but just deprecated
... if XForms needs DOMActivate, you could keep referring to DOM 2
or define it yourself
steven: then it becomes a different event with the same name
doug: DOMActivate is different XForms is different from HTML because
it's not bound to a UI in XForms
... DOMActivate wasn't specified well in DOM 2, properties not
defined
... well
steven: we list the ones we're expecting but don't define them
<ChrisL>
[13]http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-event
groupings
[13]
http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-eventgroupings
<ChrisL> DOMActivate
<ChrisL> The activate event occurs when an element is activated, for
instance, thru a mouse click or a keypress. A numerical argument is
provided to give an indication of the type of activation that
occurs: 1 for a simple activation (e.g. a simple click or Enter), 2
for hyperactivation (for instance a double click or Shift Enter).
<ChrisL> * Bubbles: Yes
<ChrisL> * Cancelable: Yes
<ChrisL> * Context Info: detail (the numerical value)
steven: we want the same event, we don't want different languages to
have the event "DOMActivate" with different meanings
<ChrisL> click
<ChrisL> The click event occurs when the pointing device button is
clicked over an element. A click is defined as a mousedown and
mouseup over the same screen location. The sequence of these events
is:
<ChrisL> mousedown
<ChrisL> mouseup
<ChrisL> click
<ChrisL> If multiple clicks occur at the same screen location, the
sequence repeats with the detail attribute incrementing with each
repetition. This event is valid for most elements.
<ChrisL> * Bubbles: Yes
<ChrisL> * Cancelable: Yes
<ChrisL> * Context Info: screenX, screenY, clientX, clientY, altKey,
ctrlKey, shiftKey, metaKey, button, detail
steven: these examples are monolithic languages, but XForms is
directed at multiple languages
doug: but there would be only one DOMActivate, the one in XForms,
because other languages don't use it
chris: does HTML5 refer to DOMActivate or click?
doug: it does refer to "click" not sure about DOMActivate, it's
probably not
chris: in DOM 2 events, DOMActivate has some content that click
doesn't
doug: tried to spell out all properties in DOM 3
<shepazu> [14]http://www.w3.org/mid/4B888B0A.6080104@w3.org
[14] http://www.w3.org/mid/4B888B0A.6080104@w3.org
<shepazu>
[15]http://dev.w3.org//2006/webapi/DOM-Level-3-Events/html/DOM3-Even
ts.html#event-flow-activation
[15]
http://dev.w3.org//2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#even
t-flow-activation
doug: also talks about "event order", a sequence for when events are
fired on activation
... the context info actually spells out the default values, every
property will be listed with its default value
... "context info" will probably be changed to "default values"
chris: if someone is looking to see if someone is using a pointer,
and they might not be able to use "click" to get to pointer-specific
stuff, like a screen location
doug: there is nothing here that would tell you that it came from a
key event vs. mouse event
... you could come up with a use case about why someone would want
to know how something was activated
<paulc> I have to leave for another meeting.
doug: could make it so that the value is null rather than zero
<scribe> ACTION: doug to raise issue with accessibility of null vs
zero [recorded in
[16]http://www.w3.org/2010/03/12-hcg-minutes.html#action02]
<trackbot> Created ACTION-51 - Raise issue with accessibility of
null vs zero [on Doug Schepers - due 2010-03-19].
if voice activation, you definitely need to know if the activation
was by voice or by mouse/keyboard, because voice is less certain
so you might not be as sure with voice that you've gotten exactly
what they said
doug: not sure you get that with DOMActivate, either
<shepazu>
[17]http://dev.w3.org//2006/webapi/DOM-Level-3-Events/html/DOM3-Even
ts.html#events-DOM_INPUT_METHOD_VOICE
[17]
http://dev.w3.org//2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#even
ts-DOM_INPUT_METHOD_VOICE
doug: text input distinguishes between multiple input methods
<ChrisL> "Implementations must dispatch the synthesized click event
as described above even if they do not normally dispatch such an
event (e.g. when activation is requested by a voice command, since
this specification does not address event types for voice input)."
debbie: I could see an actual activation by voice -- eg you say
"here's my address" and the address field becomes activated
<ChrisL> it would be selected, not activated
ok, I'll think of some more voice use cases
doug: please read the specification and emails for future
discussions
... suggest that concerns be discussed by email
<ChrisL> I really expected that we would have a resolution here
doug: before we schedule another telecon have some email discussion
<ChrisL> adjourned
s/doug: I could see an/debbie: I could see an
Summary of Action Items
[NEW] ACTION: doug to raise issue with accessibility of null vs zero
[recorded in
[18]http://www.w3.org/2010/03/12-hcg-minutes.html#action02]
[NEW] ACTION: janina to schedule a WAI-PF call on deprecating
DOMActivate and report back to HCG [recorded in
[19]http://www.w3.org/2010/03/12-hcg-minutes.html#action01]
[End of minutes]
_________________________________________________________
Received on Friday, 12 March 2010 22:47:30 UTC