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.
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?
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
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
<chaals> adjourned - go do action items and track issues to resolution so you can mention it next time.