See also: IRC log
<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].
<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/
<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].
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].
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
<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
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
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
+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
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): ..."
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?
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"