See also: IRC log
<chaals> ACTION: Chaals to send last week's minutes to public
<trackbot> Created ACTION-110 - Send last week\'s minutes to public [on Charles Mccathienevile - due 2006-04-03].
RESOLUTION: last week's minutes accepted.
<anne> http://dev.w3.org/cvsweb/~checkout~/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html
<darobin> http://www.w3.org/mid/i03g2259avunb9tp8qffdml1pgvb4ptkt5@hive.bjoern.hoehrmann.de
RB: while on Publications, bjoern sent in a status report on DOM3
<darobin> * updated SotD section
RB: of the 4 things he lists, #3 is up for grabs
<darobin> * updated list of changes
<darobin> * updated Acknowledgements
<darobin> * updating 1.5.2 to list all event
<darobin> types in place of the placeholders
RB: as is #4, which is most important
... we'll leave them to bjoern for the present
<anne> Is #4 not already in the Note?
RB: does anyone want to write up a rationale why we are dropping Focus events?
<anne> (except of course that we removed some and added some, but that should be trivial)
GE: we don't think people use them
... that was the rationale
<anne> (well, the 2003 Note)
<Hixie> "The DOMFocusIn and DOMFocusOut events were dropped in this draft in response to implementation feedback (there were no significant implementations)."
CMN: I wrote something to XForms which could be reused
RB: who wants to write up rationale for security in DOM3
<chaals> ACTION: Doug to write a section on security considerations raised by the DOM 3 spec.
<trackbot> Created ACTION-111 - Write a section on security considerations raised by the DOM 3 spec. [on Doug Schepers - due 2006-04-03].
<darobin> ACTION: RB to write description of how other specs achieve comaptibility with D3EV
<trackbot> Created ACTION-112 - Write description of how other specs achieve comaptibility with D3EV [on Robin Berjon - due 2006-04-03].
RB: anyone have anything left on action102 by
bjoern?
... okay, then, we can't have an ETA for pub until we hear from Bjoern
AvK: are we publishing Working Drafts first?
RB: I think so
<dino> WD first
AvK: if we are, then we can vote on it today
<Hixie> if we go to LC then we'll have to go to WD before going back to LC, according to W3C process
<Zakim> chaals, you wanted to prefer WD first
RB: that removes some of the late-date screaming, and we should show it to other WGs first
CMN: I think it's better to go to WD sooner
rather than later
... we might not need to request transition
RB: I think that's correct
AvK: does this take into account if other WGs are working on it?
RB: no, this assumes that one WG takes it from start to finish
CMN: transitioning between groups doesn't need particular approval
<anne> +1 to WD first
+1 WD
Resolution: we will have a Working Draft
<dino> when?
RB: I'm tempted to say next week, or this week if possible
<chaals> [as soon as bjoern has something, and he is encouraged to publish faster rather than more perfect]
<darobin> RATIONALE: even if it's a short WD, it'll have the other WGs look at it, which we need
RB: at latest, next Monday?
<chaals> ACTION: Dean to work with Bjoern to get a draft of DOM3Events out ASAP
<trackbot> Created ACTION-113 - Work with Bjoern to get a draft of DOM3Events out ASAP [on Dean Jackson - due 2006-04-03].
RB: let's move on to issues, from the bottom
<darobin> http://www.w3.org/2005/06/tracker/webapi/issues/57
RB: have people had time to review it?
... let's resolve to accept it, given no objections
<darobin> RESOLUTION: accept BH's proposal in the issue
AvK: I think we've covered these
RB: I think it's best to keep multiple devices out of this
<Zakim> chaals, you wanted to note that in Apple it *is* multiple input devices
RB: C is best, but it breaks legacy
CMN: we should wait for Maciej, but it's not
proven that it breaks legacy...
... building new events is painful in terms of scalability
... a solution where we add attributes to getting the source of the event
might be best in the long run
AvK: what do we need to know?
RB: we need to know how much B and C would break legacy
MJS: C would most likely break existing content
because they wouldn't check for type
<Hixie> doesn't seem _that_ unlikely, have you guys seen the crazy code out there?
scribe: we might have problems with B if wheeldelta is 0
<anne> AK: we can rule out (c) I guess...
CMC: if we assume that they don't check for
type...
... with a wheel event
... it might not be a major break
CMN: C makes the most sense
<dino> darobin, there is a q
<darobin> so what? :-D
RB: no, because we might have to check for typing, and it might also have x/y done at the same time
DS: are we talking about breaking content or Implementations?
<Hixie> :-)
MJS: I'm talking about breaking content, which would be undesireable
<Zakim> chaals, you wanted to wonder if content will break under 2-d motion if it assumes 1-d
<Hixie> IH: If we have horizontal scrolling cause the same event, then content that uses onmousewheel="" and cancels the event will break horizontal scrolling in UAs
MJS: we're not talking about absolutes, we have 2 different proposals that work and don't break content, so we should go with one of them
<Hixie> anne: or mousewheel and mousewheelx
<mjs> let me type an example: <div onmoushewheel="document.getElementById('someotherelement').style.position += event.detail; event.stopPropagation();">
<anne> Hixie, that's better actually :)
<mjs> er, .style.y I mean
<mjs> if you make something that scrolls another element vertically when wheeling
DS: I think that breaking a little content is not that bad
<Hixie> using a new name doesn't break existing content
<anne> fwiw, I'm with the mousewheelx proposal
<Hixie> using an old name in a different way breaks content
<chaals> CMN: I am prepared to suggest that if there is only minimal content using khtmlHorizontalWheel, I don't mind abandoning it...
<mjs> you really don't want horizontal wheeling to cause the vertical wheeling effect
<mjs> I think either (a) or (b) is acceptable since it won't have that side effect
<chaals> ... but I don't think that horizontal wheeling being applied to content that only anticipated 1-directional scrolling is going to confuse people doing the actual wheeling.
<dino> +1 to (a) or (b) not (c)
<Hixie> chaals -- i gave a case earlier where it does
<chaals> ... and C has the benefit that it scales to another wheel, or another mouse
<anne> mjs, no
DS: I just want to point out that going with "wheel" instead of "mousewheel" means we don't have to worry about legacy content
<chaals> CMN: The case that concerns me is the one Ian mentioned, of a scroll that cancels something else.
RB: since consensus isn't forthcoming, I propose that we send mail to the list
<chaals> ACTION: Gorm to make a proposal from opera on multiple wheels
<trackbot> Created ACTION-114 - Make a proposal from opera on multiple wheels [on Gorm Eriksen - due 2006-04-03].
<scribe> ACTION: anne to write up a proposal to deal with the mousewheel issue
<trackbot> Created ACTION-115 - Write up a proposal to deal with the mousewheel issue [on Anne van Kesteren - due 2006-04-03].
[[editor's note - that should have been on Ian Hickson]]
<scribe> ACTION: DS to write up a proposal to deal with the mousewheel issue [recorded in http://www.w3.org/2006/03/27-webapi-minutes.html#action08]
<trackbot> Created ACTION-116 - Write up a proposal to deal with the mousewheel issue [on Doug Schepers - due 2006-04-03].
AvK: wheelDelta vs. UIEvent.detail
RB: this depends on issue 56
Resolution: issue 55 is pending resolution on issue 56
http://www.w3.org/2005/06/tracker/webapi/issues/54
AvK: MS IE has a interface for this, but
everyone else uses W3C tech
... I don't think that this is possible right now... maybe for a later
version
Resolution: keep mouse events as is, not include MS model
http://www.w3.org/2005/06/tracker/webapi/issues/53
CMN: this is uncomfortable, because it's tricky
to change license terms
... or we could just change the bindings
MJS: part of the problem is that it's not clear
if it's the document license, or the interface license
... which means that you legally aren't able to extend the interfaces
DJ: if we make the IDL available in a separate file, we could put the license in that file alone
<Hixie> (mozilla is an lgpl implementation)
<mjs> webkit is an lgpl implementation as well
MJS: we could also just specify that in the doc, but the license is not compatible with LGPL, and copyrighting APIs seems silly
<sicking> Hixie, trouble :)
RB: I might could take an action to talk to people inside w3c about this
<Hixie> of course, mozilla doesn't use the idl directly, so it wouldn't matter
<Hixie> and i'm guessing the same applies to webjkit
<Hixie> webkit
<mjs> Hixie: if they have read the spec, I think that legally makes it a derivative work
<Hixie> that's a pretty oppressive interpretation
MJS: I would be most happy if we either put
them both under a liberal license (MIT)...
... or to put them in the public domain
<mjs> Hixie: US copyright law sucks
JS: those sound good to me
<Hixie> mjs: so a css implementation is a derivative work of the spec?
JS: it's not really what the law says, but rather if there is any doubt at all
<anne> mjs, khtmlHorizontalWheel also implements WheelEvent?
<mjs> Hixie: I don't think so
<Hixie> what's the difference?
<mjs> Hixie, unless the spec includes something that would be a portion of the implementation
<mjs> Hixie: for instance, if the spec included IDL and the implementation did too, that would arguably be a derivative work
JS: CC might also be good
<Hixie> mjs: but neither mozilla nor webkit use the idl anyway :-)
<mjs> Hixie: they both have IDL for (some) of the same interface
RB: no, the license must be a w3c license, the question is which part is under which license
<Hixie> mjs: fair enough.
<Zakim> chaals, you wanted to suggest that Maciej take this up directly since the licenses are claimed to be compatible with (L)GPL
MJS: no, w3c is not compatible with LGPL
CMN: I think Maciej should bring up the issue with Ian Jacobs
Action MJS to talk to Ian Jacobs about licensing issues
<dino> maciej, please email ij@w3.org (Ian Jacobs) and CC me.
<scribe> ACTION: MJS to talk to Ian Jacobs about licensing issues [recorded in http://www.w3.org/2006/03/27-webapi-minutes.html#action11]
<chaals> [You should also cc team-legal@w3.org IMHO]
<Hixie> yeah, should be Number.
<anne> +1 to number
<gorm> +1 number
RB: I think that it should be a number
... and it's easier to fix the spec rather than 4 implementations
JS: is this a DOM2 feature, too?
RB: yes
<dino> xsmiles doesn't use Batik
JS: is that going to be an issue?
... it's fine to change, but people might complain
RB: we'll cross that bridge when we come to it, and I'm not sure it's was ever implemented
Resolution: DOMTimeStamp should have number as the ECMAScript binding
I agree with hixie
RB: hixie, will you find out what current UAs do?
IH: ok
<dino> Ian isn't in the system yet :(
<mjs> gorm: I'm not sure what that is saying, but current Safari definitely has it as a Number
<scribe> ACTION: IH to investigate current implementations behavior for timestamp [recorded in http://www.w3.org/2006/03/27-webapi-minutes.html#action12]
<dino> http://www.w3.org/2005/06/tracker/webapi/issues/51
http://www.w3.org/2005/06/tracker/webapi/issues/51
<dino> related to ACTION-25
waiting on RB
http://www.w3.org/2005/06/tracker/webapi/issues/50
<anne> +1 to keep the spec as is
JS: most implementations and content do it one way, Spec says something else
<anne> https://bugzilla.mozilla.org/show_bug.cgi?id=235441 ?
JS: use cases for both, and you can always test
for it...
... but should we change the spec or the implementations?
... Safari has already changed it in their unpublished code, but Mozilla is
afraid to because of content
MJS: there are scripts out there that try to
bridge IE and other behavior, and it might get broken
... I don't think that there are many people relying on it
JS: a lot of users don't know how their own
code works
... so it's a problem for them
MJS: I think it's mainly a few script libs that need to trickle down
AvK: Opera was correct from the start
... and there wasn't much content
<mjs> in the bugzilla bug someone mentioned an issue with XBL
<mjs> does anyone know what the issue is? (Hixie?)
Resolution: keep the spec as is, and get Firefox to change
<anne> mjs, I recall someone said that was a non-issue
<chaals> [agree with Ian - clarifying the bit in the spec that caused confusion is a smart move]
Resolution: ... but we should clarify the language in the spec
AvK: bjoern added an example
Sction: JS to make sure the spec is clear as regards issue 50
<scribe> ACTION: JS to make sure the spec is clear as regards issue 50
<trackbot> Created ACTION-118 - Make sure the spec is clear as regards issue 50 [on Jonas Sicking - due 2006-04-03].
<anne> +1 to dblclick
RB: would that be an alias for evt.details=2?
MJS: no, it's its own event, and it's implementation-specific
JS: it acts very erratically across platforms
<anne> http://testsuite.org/dom/events/types/dblclick/001.htm
<gorm> -1 to resolution now
AvK: it shoudl be platform-specific when it's dispatched
RB: we need details on how it's currently implemented
AvK: 2 clicks is clear, but 2 dblclicks is not always allowed
<chaals> [think we should adjourn and get some more data]
<mjs> what happens if you rapidly click 4 times?
<darobin> ACTION: AK to check what various browsers and platforms do wrt to dblclick, and which of click or dblclick fires first [recorded in http://www.w3.org/2006/03/27-webapi-minutes.html#action14]
<trackbot> Sorry, couldn't find user - AK
JS: which fires first, click or dblclick? what if you cancel click?
<darobin> ACTION: AV to check what various browsers and platforms do wrt to dblclick, and which of click or dblclick fires first [recorded in http://www.w3.org/2006/03/27-webapi-minutes.html#action15]
<trackbot> Created ACTION-119 - Check what various browsers and platforms do wrt to dblclick, and which of click or dblclick fires first [on Anne van Kesteren - due 2006-04-03].
<darobin> RRSAgent: make minutes
<chaals> bye all
<anne> So we need more testcases for dblclick...