W3C

- DRAFT -

Hypertext Coordination Group Teleconference
12 Mar 2010

See also: IRC log

Attendees

Present
Plh, Kazuyuki, Debbie_Dahl, Doug_Schepers, Steven, ChrisL, paulc, Janina, Shepazu
Regrets
Robin, Berjon
Chair
Chris
Scribe
ddahl

Contents


<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> 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> 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> 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> 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> 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 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> 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> http://www.w3.org/mid/4B888B0A.6080104@w3.org

<shepazu> http://dev.w3.org//2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#event-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 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> http://dev.w3.org//2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-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 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 http://www.w3.org/2010/03/12-hcg-minutes.html#action01]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2010/03/12 22:42:24 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/actualy/actual/
FAILED: s/doug: I could see an/debbie: I could see an/
Succeeded: s/...I could see an actual/debbie: I could see an actual/
Found Scribe: ddahl
Inferring ScribeNick: ddahl
Default Present: Plh, Kazuyuki, Debbie_Dahl, Doug_Schepers, Steven, ChrisL, paulc, Janina, Shepazu
Present: Plh Kazuyuki Debbie_Dahl Doug_Schepers Steven ChrisL paulc Janina Shepazu
Regrets: Robin Berjon
Found Date: 12 Mar 2010
Guessing minutes URL: http://www.w3.org/2010/03/12-hcg-minutes.html
People with action items: doug janina

[End of scribe.perl diagnostic output]