<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> "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

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

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

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

keyboard identifiers and keyboard events

Key Events

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