Hi, WebAPI fans-

The minutes for the DOM3 Events telcon on 19 March 2008 can be found here:

 http://www.w3.org/2008/03/19-webapi-minutes.html

Or as text below:

   [1]W3C

      [1] http://www.w3.org/

                               - DRAFT -

                       Web API WG Teleconference
                              19 Mar 2008

   [2]Agenda

      [2] http://www.w3.org/2008/webapps/wiki/19_Mar_2008

   See also: [3]IRC log

      [3] http://www.w3.org/2008/03/19-webapi-irc

Attendees

   Present
          Doug, aemmons, Carmelo, smaug, Travis

   Regrets
   Chair
          Doug

   Scribe
          Andrew Emmons

Contents

     * [4]Topics
         1. [5]mousewheel
         2. [6]Key event sequence model
         3. [7]cmd +/-
         4. [8]scroll event
         5. [9]mousewheel event revisited
         6. [10]keyboard identifiers and keyboard events
         7. [11]Key Events
     * [12]Summary of Action Items
     _________________________________________________________



   <trackbot> Date: 19 March 2008

   <shepazu> [13]http://www.w3.org/2008/webapps/wiki/Key_event_order

     [13] http://www.w3.org/2008/webapps/wiki/Key_event_order

   <smaugAfk> Zakim: ??P20 is me

   <scribe> Scribe: Andrew Emmons

   <scribe> ScribeNick: aemmons

   <shepazu> [14]http://www.w3.org/2008/webapps/wiki/Telcon_procedures

     [14] http://www.w3.org/2008/webapps/wiki/Telcon_procedures

   [15]http://cgi.w3.org/member-bin/irc/irc.cgi

     [15] http://cgi.w3.org/member-bin/irc/irc.cgi

mousewheel

   <shepazu>
   [16]http://www.w3.org/2008/webapps/wiki/Mousewheel#Proposal_1:_Singl
   e_Event_With_Multiple_WheelDeltas

[16] http://www.w3.org/2008/webapps/wiki/Mousewheel#Proposal_1:_Single_Event_With_Multiple_WheelDeltas

   DS: There are two proposals
   ... Was not clear the first time I wrote it
   ... First proposal is a single event, second has two events

   TL: I read AvK's response

   DS: My testing did not validate this

   <mjs> I remember that at a past f2f we decided a single event was
   not workable, for compatibility reasons

   <mjs> in other words, it would be a compatibility hazard to have
   mousewheel fire for non-vertical wheel action

   TL: We need to keep backward compatibility in mind but should focus
   on the ultimate end game

   DS: There is nothing we can do about old apps, some people will have
   older browsers,
   ... Let's focus on a real solution

   <shepazu> mjs, can you join the telcon?

   <mjs> shepazu: I'm hungry and I'd like to get some lunch, but I can
   join briefly if you guys need me to recapitulate the compatibility
   issues

   <mjs> I thought I summarized them pretty well here:
   [17]http://lists.w3.org/Archives/Public/public-webapi/2006May/0029.h
   tml

[17] http://lists.w3.org/Archives/Public/public-webapi/2006May/0029.html

   <shepazu> mjs, my testing showed that not to be the case, can you
   supply a test that shows it?

   <mjs> showed what not to be the case?

   TL: The above mentions stair-stepping issue and incompatibility with
   a single event

   <mjs> The compat issue is, specifically, 'Content using the existing
   nonstandard "mousewheel" event. In this case, it is assumed that the
   event is for a vertical scroll only, and apparently content depends
   on the delta not being 0.'

   <shepazu> mjs, case 1) is what I tested against, and the mighty
   mouse and trackpad, at least , worked fine

   <shepazu> I don't know about the content

   CM: Google maps depends on delta is not zero

   <mjs> the mac trackpad and mighty mouse do not generate "mousewheel"
   events for scrolls that are purely horizontal

   TL: In other words the event only fires if there is a real delta
   change

   <mjs> for reason of the compat issues above

   <mjs> we never fire a mousewheel event with a wheelDelta of 0

   <mjs> we have an internal separate horizontal only wheel event

   <mjs> I should go to lunch

   <mjs> if you guys are still at it in 45-60 min I can call in

   <shepazu> mjs, please send a detailed email

   <mjs_lunch> shepazu: my email from 2 years ago was already detailed

   <shepazu> not detailed enough

   <mjs_lunch> then you need to tell me what your remaining questions
   are

   <shepazu> "apparently content depends on the delta not being 0" is
   vague

   <mjs_lunch> this was cited by many people at the f2f

   <mjs_lunch> I did not consider it a controversial point

   <shepazu> ok

   <mjs_lunch> apparently someone on the call confirmed that Google
   Maps for one depends on this

   <shepazu> I'd like to see more details

   DS: We will address it later, in 45 min

   <shepazu> thanks

   DS: I would like to see compelling evidence that web application
   rely on this and in particular that they cannot change
   ... By default wheelDelta is always the 'most significant' of the
   two - it will never be zero

   TL: What is wheel delta? Is it an alias of the other two? A
   direction vector?

   DS: Should wheelDelta be only the y?

   TL: wheelDelta is in the wild

   DS: May be good to have wheelDelta only the y

   AE: Then we'd have the issue of a mousewheelevent fired with
   wheelDelta of 0

   DS: That is correct, content out there will have to check that the
   wheel delta is not zero

   <shepazu> if ( !evt.wheelDeltaX && 0 == evt.wheelDelta) {...}

   AE: Having two events makes content creation harder

   TL: Generally speaking the fewer events fired the faster performance
   can be

   <shepazu>
   [18]http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0169.h
   tml

[18] http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0169.html

   <shepazu> "For existing apps, it doesn't seem like it would be that
   hard to short-circuit the mousewheel event handlers to check for a
   non-zero wheelDelta before continuing with the code."

   DS: If you look at any code that deals with the wheel, their all
   using something different
   ... (reads various events)
   ... I htink it would be great is we supplied a 'patch' library
   ... Here is the old way, here is the new way, here is the patch
   between

   TL: Examples, non-normative

Key event sequence model

   <shepazu> [19]http://www.w3.org/2008/webapps/wiki/Key_event_order

     [19] http://www.w3.org/2008/webapps/wiki/Key_event_order

   TL: Doug and I took a look at the proposal, an informative section
   to describe typical flow of key events
   ... Tried to express in a linear progression
   ... Due to complications like keyRepeat, IME editors, etc,
   ... thought it would be better to express in a state transition
   diagram

   DS: Talked a little about this last week

   TL: I like having an example proposal out there - is a should
   requirement with an emulation layer for example to achieve it

   DS: I would go so far as to say it would be normative
   ... should for emulation layer
   ... May just give events in device sequence
   ... I will draw up state chart diagram

   TL: I like having it clearly specified
   ... Much easier to get it right if it is clear and specific

   <smaug> OP

   OP: I like this as well

   <shepazu> ACTION: Doug to draw up state chart diagram for key flow
   [recorded in
   [20]http://www.w3.org/2008/03/19-webapi-minutes.html#action01]

   <trackbot> Created ACTION-263 - Draw up state chart diagram for key
   flow [on Doug Schepers - due 2008-03-26].

   OP: Had some questions about the second keyPress
   ... Why is there another keyDown in the repeat process?

   TL: You are saying the second keyDown in the list?
   ... We'll try and get it in a form we can visualize better

   DS: I understand the rationale for a single keyDown

   TL: Some browsers have keyPress AFTER keyUp

   DS: I would like for this to be a neat model, if it has to get messy
   to account for what web apps depend upon, so be it

   TL: go for least common denominator, or most common feature, for
   exmaple

   DS: I think we should take content with a grain of salt
   ... - existing content being developed and maintained can be altered
   ... - older content not miantained and is not active looses
   relevance as time goes on
   ... - for every piece of content which relies on one behavior,
   changes there is another piece that breaks in another area

   TL: Minute changes for the better always breaks somebody
   ... Some cases argue it is appropriate given the progress being made

cmd +/-

scroll event

   DS: Pressing because we're already talking about mousewheel

   <shepazu> [21]http://www.w3.org/2008/webapps/wiki/Scroll

     [21] http://www.w3.org/2008/webapps/wiki/Scroll

   TL: Related to OnScroll, related to HTML4?

   <shepazu>
   [22]http://www.w3.org/TR/html401/interact/scripts.html#events

     [22] http://www.w3.org/TR/html401/interact/scripts.html#events

   TL: Doesn't look like it is in the HTML 4 spec

   CM: Perhaps Netscale 3.0

   DS: I came up with a few use cases and requirements
   ... Would be good if you could come up with more and add them
   ... Would be nice to have scrollX, scrollY, offset, whatever in the
   vent
   ... Now they get the event and ask the window how much
   ... I put the idea in for a mode ( pixel, page, screen, etc )
   ... Things that Mozilla does
   ... ex: line scrolls one line of text

   TL: A web-page can have all sorts of fonts and styles

   DS: May be contextual - only for drop-downs, etc
   ... Should this happen at the level of mousewheel?
   ... Have a dropdown - scrolling
   ... If I send a wheel event to browser, that gives one thing
   ... Default action of mousewheel is to through a scroll event
   ... Scroll event knows the element on which it was activated
   ... Can determine what mode it is going to be in
   ... Even a whelleDelta of 4 or 1 is sufficient to scroll a line, for
   a dropdown

   TL: If you can cancelledthe wheelevent, you would not fire the
   default action of scroll event

   OP: Scroll event happens after an event has occurred, cannot cancel
   ... Scroll event is about how much some content has been scrolled
   ... If you look at our pixel scrolling bug, a Mac can generate a
   pixel event and a line event
   ... There are both

   DS: This is happening at the wheel level, not the scroll level?

   OP: Yes - browser gets different kind of events from OS

   TL: I think a wheelevent is caught before any action is taken
   ... Browsers have a default action to cause the viewport to scroll
   ... User should be able to cancel the event and do something else
   ... Mousewheel happens at a higher level of abstraction

   OP: Scroll even is not bound to the wheel event

   DS: Not an absolute relationship but a normal relationship
   ... Looks like we need more work
   ... Like to have more information

   <scribe> ACTION: Doug to research line and pixel mode for mousewheel
   [recorded in
   [23]http://www.w3.org/2008/03/19-webapi-minutes.html#action02]

   <trackbot> Created ACTION-264 - Research line and pixel mode for
   mousewheel [on Doug Schepers - due 2008-03-26].

   DS: Would be nice to keep mousewheel abstract

   OP; What does wheelDelta mean? Corrdinates?

   TL: Could be we report in pixels, lines, etc. Could see being very
   useful

   DS: I made the units role, but we could say what units

   TL: Least common denominator being pixel, fairly standard unit

   DS: Probably a more generalized, set way that this happens

mousewheel event revisited

   DS: Can we get a resolution to add the mousewheel proposal to the
   spec?

   TL: +1

   AE: +1

   CM: +1

   OP: +1

   Resolution: We resolve to add proposal into the spec and to add
   informative wording as to workarounds

   <scribe> ACTION: aemmons to add new mousewheel to the DOM 3 Ev spec
   [recorded in
   [24]http://www.w3.org/2008/03/19-webapi-minutes.html#action03]

   <trackbot> Created ACTION-265 - Add new mousewheel to the DOM 3 Ev
   spec [on Andrew Emmons - due 2008-03-26].

keyboard identifiers and keyboard events

Key Events

   <shepazu> [25]http://www.w3.org/TR/DOM-Level-3-Events/keyset.html

     [25] http://www.w3.org/TR/DOM-Level-3-Events/keyset.html

   DS: Please review within the context of your implementation
   ... Does not address IME very well
   ... charCode and keyCode - only specifies keyCode
   ... no charCode
   ... Because a lot of content relies on charCode, we've been asked to
   define charCodes
   ... Rather than a list, in the appendix of keyIdentifies, should be
   table - charCode, keyCode and keyIdnentifier

   TL: Is charCode the common denominator?

   DS: I think so

   TL: The same charCodes?

   DS: I do not think so

   TL: If we do not specify it and just keep keyIdentifiers, will every
   one use these instead?

   DS: The main problem is not that is is flawed ( not perfect by any
   leans ) simply did not get enough people to say they would implement
   it
   ... If we can get major implementers to implement keyIdentifiers, it
   would be very good

   TL: There is a clear goal to make sure that the standards are
   'sane'. Events we're interested in getting right
   ... I can commit there will be a DOM Level 3 events implementation
   in the future
   ... We want to implement this standard

   DS: We have implementation experience with this
   ... BitFlash has implemented this
   ... Have gotten feedback from content creators that for the most
   part the like it
   ... Get soft1, soft2, etc
   ... One thing they do not like is the U+0032
   ... Unituitive

   TL: Have to consult lookup table, etc

   DS: If you just want the keyboard letter, let the browser do the
   lookup
   ... If you are using a unicode character set, can put in any letter
   you want
   ... Also have the named keyIdentifiers

   TL: Perhaps we keep the key identifier list as is, move the uicode
   key strings to perhaps another property
   ... could supply key or keyIndentifier

   <mjs_lunch> I'm back

   <mjs> if anyone wants to call in, lemme know

   DS: The issue is - there are certain keys that give a unicode value,
   certain keys that do not
   ... We supply a named set
   ... keyIdentifiers say either a named key or a unicode value

   TL: Consider 'A' - string is U+0041
   ... You are suggesting 'A' ( string )

   DS: 'in addition you can type in any unicode value' or just 'A'
   ... Constraint - ally named keys have to be more than X characters

Summary of Action Items

   [NEW] ACTION: aemmons to add new mousewheel to the DOM 3 Ev spec
   [recorded in
   [26]http://www.w3.org/2008/03/19-webapi-minutes.html#action03]
   [NEW] ACTION: Doug to draw up state chart diagram for key flow
   [recorded in
   [27]http://www.w3.org/2008/03/19-webapi-minutes.html#action01]
   [NEW] ACTION: Doug to research line and pixel mode for mousewheel
   [recorded in
   [28]http://www.w3.org/2008/03/19-webapi-minutes.html#action02]

   [End of minutes]
     _________________________________________________________


    Minutes formatted by David Booth's [29]scribe.perl version 1.133
    ([30]CVS log)
    $Date: 2008/03/19 20:15:43 $
     _________________________________________________________

     [29] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [30] http://dev.w3.org/cvsweb/2002/scribe/

Scribe.perl diagnostic output

   [Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.133  of Date: 2008/01/18 18:48:51
Check for newer version at [31]http://dev.w3.org/cvsweb/~checkout~/2002
/scribe/

     [31] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/perofrmance/performance/
Succeeded: s/IE?/HTML4?/
Found Scribe: Andrew Emmons
Found ScribeNick: aemmons
Default Present: Doug, aemmons, Carmelo, smaug, Travis
Present: Doug aemmons Carmelo smaug Travis
Agenda: [32]http://www.w3.org/2008/webapps/wiki/19_Mar_2008
Found Date: 19 Mar 2008
Guessing minutes URL: [33]http://www.w3.org/2008/03/19-webapi-minutes.h
tml
People with action items: aemmons doug

     [32] http://www.w3.org/2008/webapps/wiki/19_Mar_2008
     [33] http://www.w3.org/2008/03/19-webapi-minutes.html

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


   End of [34]scribe.perl diagnostic output]

     [34] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm



Reply via email to