WEB API meeting
20 Mar 2006

See also: IRC log


iand, Doug_Schepers, gorm, Jonas_Sicking, anne, Dean, chaals, ssire
maciej, christophe, robin


last week's minutes

<chaals> RESOLUTION: Minutes from last week accepted

<bjoern> ACTION: Charles the working group approved the 2006-03-13 minutes, send them to the public list

<trackbot> Created ACTION-99 - The working group approved the 2006-03-13 minutes, send them to the public list [on Charles Mccathienevile - due 2006-03-27].

document status

<anne> http://dev.w3.org/cvsweb/~checkout~/2006/webapi/XMLHttpRequest/publish/XMLHttpRequest.html

DJ: supposed to have XHR ready for first public

AK: it is

ID: should get XHR spec out in public

GE: what about conformance - do we need to say more?

JS: we have different views on what features we wanyt in spec

AK: no discussion on features, just discussion around those features

JS: that's what I mean, what's goal of the spec etc

<Zakim> chaals, you wanted to say publish early, publish often...

CN: should publish often. we have open issues but we ought to be putting specs out

<bjoern> We should agree to publish "F"PWD of DOM Level 3 Events end of march (27-31), we have some open issues, but that's normal for WDs; just needs SotD section and updated Changes section, I can do that by then.

JS: I agree, we should publish

<anne> I think we should "solve" http://www.w3.org/2005/06/tracker/webapi/issues/42

DS: only reservation is that we may limit our options by publishing too early

AK: should wait for issue 42 before publishing

<Zakim> chaals, you wanted to say that there is no problem changing things from draft to draft

CN: makes sense to publish it but don't wait 3 months between versions, publish smaller changes more frequently

DS: ok so long as we can change things as we refine spec

<anne> I'm ok with that.

CN: set expectation in the status section. if we expect to publish in 3 months then say so

DJ: I can take action to change status to something that can be published

<chaals> ACTION: Dean to work Anne to get teh process/status section etc right for publishing

<trackbot> Created ACTION-100 - Work Anne to get teh process/status section etc right for publishing [on Dean Jackson - due 2006-03-27].

CN: should we publish?

<chaals> RESOLUTION: Request publication of first XMLHttpRequest working draft, with Dino helping to get the right process steps etc

RATIONALE: the spec will benefit from more public comment

<anne> And for the minutes, it will be hosted on /TR/XMLHttpRequest/

DOM 3 events

<anne> Time for misnomers within /TR/ (if there are none today...)

<chaals> [there are heaps of misnomers in /TR/ ...]

<anne> [good, so we're not breaking any policy]

<chaals> Bjoern, what is the status of DOM3EV - with respect to the timeline?

<bjoern> we should publish WD end of the month

<bjoern> there are some open issues, but that's normal

<chaals> The timeline currently cals for Last call, no?

<bjoern> not ready for LC before april

<anne> http://www.w3.org/2006/webapi/group/timeline

<bjoern> 1 month at the earliest

<bjoern> (from now)

<dino> anne, can you put that in the wiki pls?

<chaals> Bjoern, so end of march for WD, May for Last Call?

<bjoern> that's reasonable

<anne> dino, http://www.w3.org/2006/webapi/group/

<bjoern> gimme the action

<anne> ACTION: bjoern to finish a WD of DOM3EV [recorded in http://www.w3.org/2006/03/20-webapi-minutes.html#action04]

<trackbot> Created ACTION-101 - Finish a WD of DOM3EV before end of March [on Bjoern Hoehrmann - due 2006-03-27].

ID: think there's still lots of work to do

AK: section 4 is mostly coverered

<anne> http://dev.w3.org/cvsweb/~checkout~/2006/webapi/Window/publish/Window.html

<chaals> ACTION: Bjoern to send a mail to the list outlining where DOM 3 Events is at with respect to the timeline, and which issues need to be dealt with

<trackbot> Created ACTION-102 - Send a mail to the list outlining where DOM 3 Events is at with respect to the timeline, and which issues need to be dealt with [on Bjoern Hoehrmann - due 2006-03-27].

Window interface

ID: what do others think? is it fit to publish yet?

AK: still some text to be added for methods and attributes

<chaals> ACTION: Ian to work with Maciej to get something publishable for window...

<trackbot> Created ACTION-103 - Work with Maciej to get something publishable for window... [on Ian Davis - due 2006-03-27].

Drag 'n Drop

CN: would like to get first PWD in may for drag and drop

DS: we saw drag and drop as special case of cut and paste

DJ: what about dragstart events and cursor changes to say whether things can be dropped
... i.e. UI behaviour is different

AK: might need dragover class to style elements
... sharing between drag n drop and cut n paste might not be possible given charter

CN: what Doug said might not be inconsistent with this

JS: the UI part is different

CN: they are clearly related

AK: some definitions for non-visual things can probably be shared, but most things like interfaces, eventing etc. are all different

CN: wait for draft

<chaals> ACTION: Charles to update the timeline for drag/drop/copy/paste/argue-aboutEverything

<trackbot> Created ACTION-104 - Update the timeline for drag/drop/copy/paste/argue-aboutEverything [on Charles Mccathienevile - due 2006-03-27].

CN: any other specs that need timeline adjusting?
... editors, keep an eye on spec. tell us early if we're going to slip

Issues and Actions

<chaals> CMN: Please, if you have an action that closes an issue, and you do it, go close the issue...


AK: we are going in wrong direction with XHR - it's becoming an implementation report rather than spec telling people what to implement
... better to have a clear specification and test suite and build implementation report from that

DS: hear hear

JS: don't think it's an implementation report

CN: kind of with Jonas
... try to do short simple specs especially for version one
... if there are implementations then we shouldn't push away from impl. too hard
... need appropriate balance

AK: making less requirements doesn't make spec shorter
... most authors don't read specs

<schepers> I don't agree with that

AK: better to say what implementations have to do. if they have bugs they can fix them

<chaals> [notes, in passing, that infraware, access, gentech, openwave and some other companies make browsers with real market share, too]

GE: some web developers do read specs

<anne> right, new implementations matter too

GE: do we want spec people can claim conformance to or not?

<bjoern> I agree with anne...

JS: want to get away from conformance issue
... reason to have argument on send issue is that people ought to know if it will work if you have no arguments

<anne> and new implementations! not just existing browsers

ID: would rather have a spec that can be trusted and reflects reality. better to have document that has some conformance than a doc that has no conformance

<anne> I agree with DS

GE: this is only for a short period. make spec that makes sense. should have something better than this in the future

<bjoern> I'd suggest we resolve that we look at issues on a case by case basis, rather than with a "some implementation doesn't do that!" bias; this allows for more flexible discussion on specific issues as they come up.

<chaals> [Yeah, Bjoern, we aren't going to get resolution on this today, but I think that is the pragmatic appraoch in any case]

JS: not black or white. need middle ground where most things work for most people

<anne> how can we be innovative in version 2 if we first have all kinds of backpat issues to solve

<chaals> (No resolution on ISSUE-43 for now)


<schepers> what I said was:

<schepers> 1) we cannot make a brittle spec that just talks about current implementations

<bjoern> let's drop it, we can't make it good enough in a reasonable time frame, and it does not tell us anything we don't know from dom2

AK: should really be in HTML spec

<bjoern> also, it's misplaced in dom3ev, should be in html spec

<schepers> 2) we need to make a forward-looking spec that will unify and simplify ideas

<anne> http://www.w3.org/2005/06/tracker/webapi/issues/45

I agree, this should be in an html spec

AK: don't think we had plans to add onclick event to html events

<bjoern> (we can always publish a later spec if we are concerned that things won't get defined anywhere)

<schepers> anne: I agree, we need to think about a path ahead, not merely pave the road we've already travelled

AK: since we have generalised onfocus and onblur, not much need for HTML section
... should be in HTML spec like SVG

JS: are we planning on cutting out error, load etc

AK: no those are generic

CN: theory behind proposal is that this is a stub chapter and it's not clear why it's there

JS: think I'm for this

<anne> http://dev.w3.org/cvsweb/~checkout~/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-Events-eventgroupings-htmlevents

JS: we've only talked about focus and blur being made generic

AK: those were two events that were specific to HTML

JS: so load event is not going to be in level 3 event?

AK: it is
... it is generic already
... in section 1.5

<bjoern> the section just says "load in HTML means this, error in HTML means that" to clarify the generic descriptions of them

AK: resize is generic too, submit and reset too

<bjoern> (it clarifies, for example, that <img> elements never receive error events ...)

<bjoern> (and there is always http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-eventgroupings-htmlevents you can refer to)

DS: submit and reset are not generic at all
... they have a context in XHTML and xforms

<anne> http://dev.w3.org/cvsweb/~checkout~/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-Events-eventgroupings-basicevents

JS: it;'s more than just the interface they have - they have behaviour

<Zakim> chaals, you wanted to say that if we adopt this we still decide on any events that should be generic

AK: they have generic interface - how are they not generic

CN: if we adopt proposal then we're just taking out the bit that is specifically about HTML and nothing else

<bjoern> IOW, "delete section 1.8.7, no other change"

CN: is anyone specifically concerned about proposal? we can put it back in later

JS: all for it

DS: me too

AK: me too

<bjoern> +1


<chaals> RESOLUTION: remove the HTML specific section in DOM3EV

<gorm> +1

<bjoern> excellent

<bjoern> I'm so happy, I'll do it without ACTION:)

RATIONALE: the html section belongs in an html specification


action-70 -> http://www.w3.org/2005/06/tracker/webapi/actions/70

<bjoern> (this should eventually go into a Everything you always wanted to know about HTML scripts and eventing spec, or DOM Level 3 HTML ...)

<bjoern> (or we contribute our findings to WHAT WG...)

<gorm> we should wait on Maciej ?

<gorm> since he raised it?

it isn't an issue, do we need one?

JS: needs a summary of what we concluded

<anne> bjoern, so we need a specification on onfoo content and DOM attributes...

<chaals> ACTION: Jonas to summarise the discussion in ACTION-70, make an issue and propose to close it.

<trackbot> Created ACTION-105 - Summarise the discussion in ACTION-70, make an issue and propose to close it. [on Jonas Sicking - due 2006-03-27].

<anne> bjoern, that in theory can be reused by other specifications as well, but is in nature HTML specific...

<bjoern> It would say "here are the concepts, terms, ... and here is an example for how to apply it to HTML (normative): ..."

issue-41 -> http://www.w3.org/2005/06/tracker/webapi/issues/41

AK: we should close this

<anne> bjoern, yay

CN: any objections? thoughts?

<bjoern> +1 on removing them if they don't work

DJ: some constants are still in draft

i think we can close this issue - looks like there's agreement on the list

<dino> anne, I see now. Yeah, you just missed a few.

CN: any objections to resolution that we don't have constants?

<chaals> RESOLUTION: We don't have the constants for readyState in XHR

RATIONALE: no current browser does it that way

CN: any other actions?

JS: issue-46?

issue-46 -> http://www.w3.org/2005/06/tracker/webapi/issues/46

GE: should be case sensitive

CN: any arguments for insensitivity? any test cases?

JS: we don't need to check IE since it doesn't do createEvent

<bjoern> (it's case-insensitive in Mozilla and Opera, not sure about others)

JS: thus we can do whatever we like since there's little content out there using it

<chaals> Bjoern, so do you suggets we make it case-insensitive, or beat up on Mozilla and Opera and DTRT?

AK: case comparison is with interface name not event type

<bjoern> case-sensitive please

<bjoern> think createEvent("org.my.event.interface"), case might be significant sometimes

<bjoern> c-s is faster also

<bjoern> and easier to spec

GE: thought that it was insensitive in Opera. can take action to make test case

JS: how can you have initEvent case sensitive?

<bjoern> event names are case-sensitive, that's been in dom3 forewever

DS: even if it is case insensitive in implementations then it's still a very small amount of content

<bjoern> and is well supported by some implementations

DS: right thing to do it to make it case sensitive

GE: can't agree, we need to test it

<anne> bjoern, DOM3EV was never Rec...

JS: agree, need to write test case

DS: should specify what it should do, implementations can change

<chaals> ACTION: Gorm to test whether the names are case-insensitive...

<trackbot> Created ACTION-106 - Test whether the names are case-insensitive... [on Gorm Eriksen - due 2006-03-27].

AK: don't want to break a million of pages

<bjoern> again, implementations may still support 'event', "eVent", ... we don't disallow such extensions

GE: Opera is case sensitive

JS: looks like mozilla is case insensitive

DS: let's test. I'll take action to test on IE7

<bjoern> (IE does not support this at all)

AK: IE7 doesn't have anything new for DOM

<chaals> ACTION: Doug to test on IE7 and see if there really is something there...

<trackbot> Created ACTION-107 - Test on IE7 and see if there really is something there... [on Doug Schepers - due 2006-03-27].

CN: anyone not want this to be case sensitive?

RESOLUTION: We would like to make this case-sensitive - so unless there is something it will break, we will aim to do that.

RATIONALE: it's easier to spec and to implement

<chaals> ACTION: Dean to teach trackbot who I am [recorded in http://www.w3.org/2006/03/20-webapi-minutes.html#action12]

<trackbot> Created ACTION-108 - Teach trackbot who I am [on Dean Jackson - due 2006-03-27].

<chaals> ACTION: Charles to put meeting dates etc on wiki [recorded in http://www.w3.org/2006/03/20-webapi-minutes.html#action13]

<trackbot> Created ACTION-109 - Put meeting dates etc on wiki [on Charles Mccathienevile - due 2006-03-27].

JS: if every implementation does it one way, then hesitate to change it
... there are probably good reasons for it

<schepers> I think that the reason would be "follow the leader"

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