Web API WG Teleconference
27 Mar 2006

See also: IRC log


IanD, Bjoern, Stephane




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

first working drafts for XHR and Window were published

<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

(ISSUE-57) DOM3EV: Attr mutation events optional?

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

(ISSUE-56) horizontal and vertical wheeling

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].

(ISSUE-55) wheelDelta DOM attribute for mousewheel event

AvK: wheelDelta vs. UIEvent.detail

RB: this depends on issue 56

Resolution: issue 55 is pending resolution on issue 56

(ISSUE-54) non-issue regarding MouseEvent.button


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

(ISSUE-53) License terms for IDL and bindings


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]

(ISSUE-52) DOM3EV: DOMTimeStamp - Number or Date in ES?

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

(ISSUE-51) DOM3EV: mobile devices keyboard events additions

<dino> http://www.w3.org/2005/06/tracker/webapi/issues/51


<dino> related to ACTION-25

waiting on RB

(ISSUE-50) Should capturing EventListeners registered on the target fire?


<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].

(ISSUE-49) DOM3EV: dblclick event

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

Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2006-04-09$