Web API WG Teleconference
10 Apr 2006


Hixie, Dave, Doug, Chaals, St├ęphane, Jonas
IanD, Christophe, Robin, Anne


Group Misc

Window and XHR publication status (Published - good job folks)

who is on the hook for persistent storage? Ian (not here)

DOM3 XPath - will let you know this week.

Drag and Drop - due in April with internal draft this week.

Chaals is inclined to schedule this for publication in May.

DOM 3 Events

Issue-56? (Mouse wheel)

Doug has posted his concerns with hixie's proposal

Wouldn't mind two different wheel events

No answers to Stefans question to the MMI WG

<ssire> see http://lists.w3.org/Archives/Public/public-webapi/2006Feb/0131

on multiple device issue

<ssire> my suggestion would be to postpone multiple input devicves

<ssire> to a future input configuration language or so

Chaals proposes to delay issue 56 and 55

In regards to HTML Events, there was no objection to genericizing specific events where appropriate.

JS: On new track pads, you can use two fingers to scroll in any direction.

There is also a new mouse with a track pad on top ...

There are also track balls than can be mapped as a pointer or a scrollbar

with behavior changed through pressing a button.

Chaals ponders about cutting the call short, but first asks if we are all in agreement on issue 59?

Issue 59 - window.history -> http://www.w3.org/2005/06/tracker/webapi/issues/59

should the window spec include history? No one objected.

JS: It is a very small addition.

DS: ideally, history ought to take into account AJAX

DR: also states within pages, e.g. slides in a presentation

<chaals> Proposed resolution is that we have history as a number.

<chaals> ACTION: Doug to raise an issue on history and Ajax

DS: we should address history and AJAX at some point.

<trackbot> Created ACTION-132 - Raise an issue on history and Ajax [on Doug Schepers - due 2006-04-17].

DR: what about states within a page?

<chaals> RESOLUTION: We have window.history as a number as currently implemented - this closes ISSUE-59

<chaals> RATIONALE: This is implemented interoperably, is reasonably useful, even if it doesn't solve the universe's problems

<chaals> DR: Do operations on history reload the page.

DR: interoperability problems today with history operations, some reload the page some don't

IH: you can't rely on caching
... the spec has to be very clear what happens if it does reload

<chaals> RESOLUTION: We don't require reloading or not in using history.

<chaals> RESOLUTION: It's too hard a requirement to implement that consistently

<Hixie> well, that's not the reason to not require it; the reason to not require it is that some UAs simply can't (no memory, etc)

DR: what about behavior with fragment histories?

Seems pretty reasonable to cover ...

IH: no point in reloading for jumps to same page as already in memory. This case is covered in WhatWG Web Apps 1 draft

<sicking> RESOLUTION: the window 1.0 spec can include description of what happens when the 'back' url is simply a different id-fragment in the same page. I.e. that scrolling rather then reloading should take place

<sicking> RATIONALE: it is not a hard requirement for UAs and it is useful

Issue 75 Is Method Case sensitive -> http://www.w3.org/2005/06/tracker/webapi/issues/75

RESOLUTION: method will be case sensitive. That closes ISSUE-75

e.g. post is not the same as POST

<chaals> RATIONALE: Because the HTTP spec says sop and it makes sense to do it like that

Issue 66 null defaultView required? -> http://www.w3.org/2005/06/tracker/webapi/issues/66

<chaals> adjourned - go do action items and track issues to resolution so you can mention it next time.

Summary of Action Items

Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2006/04/10 18:55:04 $