See also: IRC log
JibberJim: I am jim and might be connected to Joost
Bjoern is on IRC and is Bjoern
Travis: Just got dumped in the group, work for Dave Massy in IE (Dave regrets that he is still in bed asleep...)
Fabien Gandon: Here because I missed my plane... we are developing a front end to a semweb application and I thought I could sleep here
AvK: Anne van Kesteren, work at Opera, good at naming methods
AR: Arun Ranganathan, AOL AC rep and CD distributor
DS: Doug Schepers, 6th sense. We do software development metrics. I am also in SVG and WAF
CMN: Chaals, from Opera, chair of this group.
NR: Nandini Ramani, chair of SVG, from Sun, also work on JCP and have a graphics hardware background
MC: Marcos observing from WAF group, PhD student at Queensland University of Technology.
<chaals> http://www.w3.org/mid/45B63FFF.4050806@sun.com message from Ellen about liaison
NR: Java Certification Requests JSRs 280,287,290 have a huge dependency on Web API (and other groups) as do CDF and SVG WG's
<chaals> NR: There is a big dependency on DOM from all over the place, but in this case the JCP (Java Community Process) is the one most urgent...
NR: JSR 280 (DOM API package) depends on DOM core L2/L3 and DOM EVT L2/L3 Other similar dependencies, but JSR-280 is first. Want to talk about ProgressEvent, MouseWheelEvent - ElementTraversal - Event Groups - REX and Media Access Events
NR: We're waiting on some clarifications:
<bjoern> those proposals should be in http://dev.w3.org/cvsweb/~checkout~/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html except for some mouse wheel prose
NR: initProgressEvent - if the total in unknown, what do you do? Java cares about exceptions
<bjoern> (actually, the .xml version has a few more details than the .html version, but it's done either way)
NR: We're happy with MouseWheel
event - it needs to be published
... Can we have a timeline?
<bjoern> Well, as I understand it NR wants to know when we can gurantee that we won't change the interface
<bjoern> as far as I am concerned, that's certainly not before we enter CR
<bjoern> when we enter CR, Q2 2007 perhaps?
<chaals> Ideally, yes...
NR: Some sort of guarantee is needed yes.
<bjoern> I am waiting for the group to come up with the missing features we agreed to put in, like soft keys, long key press events, keypress, ...
NR: JSR 280 plans to be submitted to JCP 2 April, so like to have something before then.
<bjoern> I doubt we'd be in CR by then
<chaals> Apart from those do you have other issues?
CMN: My understanding is we're waiting on some events that were assigned to Maciej and Robin.
<bjoern> chaals, me? I don't think so, no.
CMN: So we need to agree to drop them, or get them written.
AvK: We do feel the keyCode mapping is important to get interop
<bjoern> (well, there is the ecmascript dom binding spec that dom3ev depends on in some way, but I assume that's not too big an issue)
Travis: Are there standard keycodes? defined by Unicode or similar
CMN: You can either use symbols or codes for keys - important for modifier keys and keys
JL: One of the DOM specs does list all of them.
<bjoern> they are not specified
<bjoern> other than that of course
Appendix A, DOM Level 3 - http://www.w3.org/TR/2003/NOTE-DOM-Level-3-Events-20031107/keyset.html
AvK: that's a new feature
<bjoern> these are key identifiers though, not "key codes" as in .keyCode
AvK: keyUp / keyDown / keyPress
also differ about what you get
I have an Action Item on this, but it differs across browsers and
it's tough to find out
JL: Is there any motivation for fixing keyCode, or just have keyIdentifier
CMN: If browsers agreed to pull it out then replacing would be okay, but otherwise I think we need to fix.
AvK: We could postpone it to a seperate draft
<bjoern> +1
<chaals> if we postpone the key stuff, would that give us a spec going to last call, bjoern?
<anne> we'd have to do another WD first since we added stuff
<schepers> that's fine
<bjoern> well this isn't the only thing
<schepers> what else?
<bjoern> the group also wanted to add e.g. longkeypress, and solve the mobile / soft key issue
<schepers> that's all key stuff
<chaals> Yeah, if we postponed all of those.
<bjoern> if we postpone all open issues, then we're about ready for lc yes
<schepers> so, the only open issues are keycodes, longkeypress, and mobile / soft key issue?
<bjoern> there is also http://www.w3.org/2005/06/tracker/webapi/issues/79 which is kinda related
<bjoern> and the ecmascript dom bindings spec is missing, which shouldn't stop us imo
<chaals> http://www.w3.org/2005/06/tracker/webapi/
<bjoern> Hixie also had some concern about the current mouse wheel event design, I'm not sure I understand his issue though
<schepers> ok, thanks, bjoern... that's also keyboard stuff
<bjoern> but that's about all I can think of, yes
<schepers> CMN: we can take it to LC and he can raise the issue then
AvK: The issue is you can't cancel the horizontal wheel, but can the vertical
CMN: I suggest we strip out the keyboard issues which are holding back DOM 3 events
<trackbot> Created ACTION-226 - Write spec for keyboard stuff [on Doug Schepers - due 2007-02-01].
CMN: DS action is covering longkeypress and all the rest of the keycodes
<chaals> BH, wanna put out a draft ready to propose as last call, given that you don't have to have keyboard things in it?
<trackbot> Created ACTION-227 - Create spec covering keycodes, longkeypress, and mobile / soft key issue [on Doug Schepers - due 2007-02-01].
TL: The use case of pressing two buttons at once isn't important?
<bjoern> I can prepare a new draft early next month; I would suggest to publish that as wd with a short review period and if nothing comes up publish the lc shortly after.
<schepers> bjoern++
<chaals> Great. Let's make that our plan of record.
RESOLUTION: Prepare new draft for publication as a WD next month, and if nothing comes up, LC shortly after
NR: ElementTraversal, like to include it in DOM 3 Core
CMN: In DOM3 core, or just as a spec?
<bjoern> We cannot add new feature to DOM 3 Core, it'd have to be a separate spec or a new DOM Level/version
NR: Just as a spec
<bjoern> note that robin wrote http://dev.w3.org/cvsweb/2006/webapi/ElementTraversal/ some time ago
CMN: We can produce the ElementTraversal spec, if you can give us a Member to help do that.
<bjoern> for the ElementTraversal test suite in particular...
CMN: Find an Editor, and you can have it.
NR: Will find an editor for it.
RESOLUTION: If Nandini gets an editor for ElementTraversal, then someone will be making it happen.
NR We would like event groups. OK, we could live without it if we can have the other stuff
NR: Important thing is to get it out there - I believe it's ready to go
CMN: Allegedly ready for LC
... We don't have an editor for it, and it's not a core
deliverable
NR: If it was ready, it could be made to LC
CMN: Would need to get someone to
review it, and would be happy if it was a positive one.
... If someone from SVG group or similar did the review, then
as Chair I'd be happy to also say yes to LC
NR: What should total be when it's not known - large number, negative, zero ?
<chaals> http://www.w3.org/2005/06/tracker/webapi/issues/104
CMN: Large number is worst, don't mind 0 or -ve one
NR: -ve sounds slightly more appropriate
<chaals> http://dev.w3.org/cvsweb/2006/webapi/progress/Progress.html
SomeoneWe have made it unsigned, so can be zero but not -1 without a painful change
RESOLUTION: Make the total of a progress event when the total is unknown 0
CMN: Are we happy it's in the
NULL namespace?
... We are
RESOLUTION: Editors should clarify the NULL namespace and clean up the text
TL: Just need to make sure Event Spec and Progress spec agree
<Travis> CMN: Does progress event bubble?
<Travis> NR: Yes it does bubble.
AvK: if we don't bubble we have an increase in performance.
CMN: Does anyone have a use-case for bubbling the progress event?
AvK: meaning that a use-case for bubbling that is not already addressed by the event capturing?
CMN: The progress event will not bubble, but should be cancellable.
DS: What will the "default action" be? Use case: the UA provides a progresss bar, but you don't want to it work--you want to provide your own.
CMN: You want to be able to tell the UA that it didn't notice.
AvK: We need to have a far more complete use case here...
JL: We should be general, so that in some future scenario it may be possible.
AR: it might make sense, if the actual "loading of the event" can be cancelled, then the progress notification should be cancelled--however, if the loading was stopped, then no more notifications of progress would be sent! So...
CMN: the other use case, of preventing the default UA action is probably the most compelling... meaning, it's sufficient to make the event cancellable.
<Travis> CMN: Switching over to File upload...
DS: If you hit the stop button, does the XHR stop too?
JL: Testing would be very interesting if progress events could be sent for synchronous XHR... Stop would just stop the XHR... The use case here is that you might like to see the progress of something being uploaded, then being downloaded.
AvK: for <input type=file> this is just a ProgressEvent, rather than just a general progress.
CMN: We have to have this upload progress for file upload.
AvK: [looking at the spec] we have preload, postload (mentioned in the current draft). We have to ensure that UA's fire the correct progress event type. there's no need for a 'stop' because 'load' fires when its done and 'start' is implicitly the first event fired...
DS: seems sensible.
CMN: ...When the loading starts (the first progress event fires), it may tell you the total size of the thing going up or down. Use case: grab the first progress event, use the total to set up the progress bar size...
AvK: You just need to know how much to fill the progress bar
CMN: We should ask the SVG implementors why they added 'start' /'stop' and see if we can remove them.
AvK: lengthComputable should be dropped, because total is 0...
RESOLUTION: Drop lengthComputable
<trackbot> Created ACTION-228 - Ask SVG implementors if they have any problem with us simplifying progress event types [on Charles Mccathienevile - due 2007-02-01].
DS: checking for any more action items on ProgressEvent...
NR: When is this going to get published?
CMN: We're trying to publish this as soon as we can
<anne> http://lists.w3.org/Archives/Public/public-webapi/2006May/0000
AvK: Some descriptive text will need to be added to clarify some properties..
CMN: Do we care about knowing something that is zero size, or something that is unknown? It's a fairly degenerate case when you get a 0 length transfer, and you're still waiting for a progress event--it doesn't make sense... If total is zero, then 1) you're transferring a zero length [something], and 'load' will follow... So, we don't need lengthComputable.
AvK: total is zero if it's not known; lengthComputable is dropped, and rename loadprogress to progress?
CMN: Seems like: 'uploadprogress' and 'progress' Implementors should be queried, and we should try to stick with their names...
DS: I don't know how widely deployed these names have been in existing implementations.
CMN: We'll see of implementors object, and we'll take it from there. Any more issues for ProgressEvent?
RESOLUTION:drop start and end event types, add uploadprogress, rename loadprogress to progress
NR: Is there a date for this then?
CMN: This week I will try to publish a revised edition, and perhaps LC by mid-feb (perhaps a bit optimistic).
Travis: get doesn't give me anything, I don't know what this method does
Avk: you need this with the DOM
it is convenient
... macth and matchAll may be were better
Travis: just concerned by the length of the name?
Avk: yes
<bjoern> my 2 EUR on that: http://lists.w3.org/Archives/Public/public-webapi/2006Dec/0098
DS: long name can be aliased and will be
AR: you can alias but you shouldn't have to depend on alias
Charles: long names make sense to me ... even when they are a pain to type.
DS: e.g. nodeListBySelector for matchAll
AVK: a correct name would be getElementByGroupOfSelector
Travis: let's look at the issue of returning an element vs. a set of elements
AVK: getElement and getElementList
Travis: you missed the "s" : getElementByGroupOfSelectors
<marcos> object.getElementBySelectors("#fdsdsf");
<marcos> object.match("#fdsdsf");
<chaals> document.getElementListBySelectors(".extension")
<marcos> object.matchAll("#woop")
<bjoern> o.cssQuery('#woop')
DS: synonym for selector?
Marcos: "match"
Travis: match doesn't give you an idea of what is matched.
Marcos: the argument is what specifies what is matched
Travis: clarity and consistency vs. what already exists
Charles: the argument is not
enough, you don't see what the method does for you.
... "get" is much clearer
AR: what about the additional S
at the end?
... ElementList is not a real structure it is just a
plural.
<chaals> so
getElementBySelector and getNodeListBySelector ?
JL: in the future we may have methods returning text nodes
<bjoern> not via CSS Selectors.
<marcos> getTheListOfElmementByTheSelectorAsDefinedInTheSelectorSpec()
<bjoern> selectNodes and selectSingleNode (XPath) do this
<anne> http://www.w3.org/TR/DOM-Level-3-Core/core.html
Travis: if it retuens a Node List it will be confusing (really is a not live list of element)
DS: what about getListBySelector(...)
AR: what about defining List as a
real structure.
... what about a straw poll?
Charles: we rule "match"
out? [we do]
... we have "get" and "getAll"
... current proposals getElementBySelector
getNodeListBySelector getElementListBySelector
Travis: selector plural or singular is fine.
AVK: a concrete counter proposal must replace everything which is removed.
DS: getElementBySelectors for the first thing that matches any of these selectors (1+)
Travis: getAllElementsBySelectors returns a node list of all ellements matching any of these selectors (1+)
Charles: getListBySelectors is shorter but not short enough to be justified so... discarded.
<schepers> [more discussion about names]
<bjoern> I am +1 on http://lists.w3.org/Archives/Public/public-webapi/2006Dec/0098 ...
AR: getStaticNodeListBySelectors would be exact naming but we don't want that.
Charles: we are left with getElementBySelectors and getElementListBySelectors
DS: ok but they are not short enough but they are descriptive
Charles: in the absence of consensus on other proposals the issue is resolved
AR: I want to hear from the mailing-list if there is an alternative to getElementListBySelectors or someone defines ElementList.
<trackbot> Created ACTION-229 - Update and publish the editor draft and request feedback for the mailing-list [on Anne van Kesteren - due 2007-02-01].
RESOLUTION: The names will be getElementBySelectors and getElementListBySelectors
Meeting is adjourned for lunch - start again at 2H30 PM
<chaals> Rhys presents a bit of what UWA is about...
<chaals> http://www.w3.org/2006/webapi/group/timeline - an interesting work of fiction
Charles: XHR, could be last call since november.
AvK: I suggest we have a review period of 3 weeks to 1 month.
Charles: Hey, it is Australia Day. Time off for me and Marcos
RESOLUTION: Request transition of XHR to be last call for a period of 1 month from when it gets published
Charles: this will hopefully happen next week. Need to talk to dino
Charles: XHR2
AvK: xhr2 will add new events and so on. and it will relate to ProgressEvents.
Charles: any idea when a first draft might be coming
AvK: after a month or two, depends on the Access-control document
AvKWindow is hard to define it because it is so closely related to the HTML
AvK: should we make this timeline public
Charles: I'm ok with that
RESOLUTION: publish the timeline in public list
<trackbot> Created ACTION-230 - Publish the timeline to the public [on Charles Mccathienevile - due 2007-02-01].
Charles: DOM3 Core - need to ask bjoern
Charles: DOM 3 Events needs to be published as a WD, so we can ask for Last call on it soon.
Charles: Chaals: ECMAScript bindings for DOM has no editor
Charles: Network. We are currently editing that, and chaals and gorm are looking to have a draft by feb. (Gorm does the technical bit, I am going to do the admin stuff for the document and publish it).
Charles: Chaals: Persistent Storage, DOM 3 XPath: they both need an editor
AvK: lots of work has been done on persistent storage, by mozilla an WhatWG
Charles: Drag and drop is going a bit slow, it would be nice to have a last call by september
<Hixie> (isn't drag-and-drop just a matter of copying and pasting the whatwg text?)
<anne> (I think so)
Charles: Chaals: Progress Events last call by end of feb
Charles: Chaals: File Upload...
AR: it is at an early stage
Charles: REX is waiting for an editor
Charles: Selectors API to be published as working draft "now".
<trackbot> Created ACTION-231 - Publish Selectors API [on Dean Jackson - due 2007-02-01].
Charles: hopefully we will have a Last Call by sometime in feb
Charles: Element Traversal...
Charles: I like the idea, but I'm not sure if I want to edit it
<chaals> File Upload...[ assorted unminuted discussion of file upload...revolving around security issues, the suggestion that it should be based on HTML input type="file" (or not), and what happens when people can replicate file upload boxes.]
<chaals> Orphan specs:
<chaals> DOM 3 Xpath, Persistent Storage, apparently Window
<chaals> and things that we don't *have* to do according to our charter: Element Traversal, REX (both of these are waiting for love from the SVG/JCP people who want them so soon)
<chaals> and ECMAScript bindings for DOM (just plain orphaned with no friendly aunt on the horizon)
Charles: all these orphan specs... any takers?
TL: I might take one.. I will let the group know
Charles: persistant storage will probably be a smaller job than window. How about Jim does window
<Hixie> Window will be a huge job
<anne> so many weird quirks
JL: I'll be happy to do it
<anne> (in XHR, Window prolly too)
<Hixie> (i'm actually not convinced you can do Window outside of HTML)
<anne> you should be able to implement it outside of HTML...
<Hixie> not really sure how
<Hixie> it embeds so tightly with HTMLDocument
<Hixie> and with navigation in general
<anne> but navigation isn't HTML specific...
<Hixie> anne: well, if Window is in its own spec, which spec is going to define how you do content sniffing when you do window.location.replace()?
<anne> Hixie, well, HTML could define how loading a resource works
<Hixie> (can't rename that interface for back compat reasons, imho)
<Hixie> anne: resource loading is very tightly bound to the updating of properties on the Window object during history navigation
<anne> (fair enough)
<anne> hmm, painful
<Hixie> see http://whatwg.org/specs/web-apps/current-work/#navigating and http://whatwg.org/specs/web-apps/current-work/#history
<Hixie> it's also very tightly defined with JS' global scope
<bjoern> test suite...
<chaals> indeed...
<anne> bjoern, well in theory someone else should do that
<anne> for XHR it was useful that I wrote one while writing the spec
Charles: as bjoern mentioned, test suites are important... anyone keen to write a test suite? I have someone to do the test suites for Progress Events and Drag and Drop
AvK: I've produced a test suite for XHR... and did some testing on window
<anne> (The test suite for XHR is non-comprehensive fwiw.)
AvK: progress events are difficult to test. The test suite needs to be developed closely with other specs like XHR. it's best that the editor is not involved in designing the test suite
<javaGal> +1
<anne> http://tc.labs.opera.com/apis/XMLHttpRequest/
<anne> http://tc.labs.opera.com/html/
<chaals> mjs, current plan is to hand Window to JibberJim 'cause it seems you are busy...
<chaals> Do you have any tests for specs that you can share (or someone with lots of time wanting to produce same)?
<JibberJim> mjs, of course if you'd rather keep ownership...
<chaals> ?
<mjs> I'd love to have JibberJim's help if he's willing to be co-editor and if we have general agreement on the right direction for the spec
<mjs> JibberJim: do we have general agreement? I know we disagree on a bunch of things, but I don't know if the contents and style of the Window spec are among them
<JibberJim> I thought we pretty much agreed on that last time
<mjs> let's discuss briefly and find out
<mjs> my basic thoughts on the Window spec:
<mjs> - other than current contents, the main missing features are timers and details of the language binding, otherwise nothing really needs to be added
<mjs> - in terms of spec lawyering detail, the main thing that needs fixing is updating the Location object properties to be defined in terms of the latest relevant URI RFCs
<mjs> - timers should be written using nominally language-independent IDL, but with special conversion rules for JavaScript so you can just pass function objects or srings to be eval'd
<mjs> - language bindings should be normative and defined w/ very clear conformance requirements for implementations, including details for JS of what to do for wrong types, what properties should be shadowed, etc
<JibberJim> I don't think we disagree there
<JibberJim> we might disagree on what to do with wrong types etc.
<mjs> well, I think what to do with wrong types should be determined by testing what existing implementations do
<JibberJim> then we won't disagree :)
<mjs> primarily MSIE, Firefox, Safari, Opera
<JibberJim> So if you're happy to have me help - we should set up some time to go through what needs doing and divide the work up?
<mjs> sure
<mjs> the four biggest work items are timers, updating Location stuff to latest RFC, JS bindings and Java bindings
<anne> Location stuff should also be made reusable for other specs
<mjs> anne: how so?
<Hixie> HTMLAnchorElement has a bunch of similar APIs
<mjs> ah
<Hixie> would be nice to define them in the same place
<mjs> it's really a pretty crappy API
<mjs> but I will keep that in mind
<Hixie> you'll get no argument from me there
<Hixie> but it's in active use
<Hixie> so...
<mjs> basically the idea of replacing the URL by pieces is silly for many of the available pieces
<mjs> doesn't really do anything you couldn't do w/ relative URLs
<Hixie> again, totally no argument from me
<Hixie> the Web provides a compelling counter argument, however
<mjs> I'm not saying anyone should change it
<mjs> this is just my token complaint
<mjs> sometimes one's mind rebels slightly at speccing out things that are unconscionably bad albeit widely used
<chaals> In the EXI room - a presentation on EXI followed by discussion.
<chaals> use a schema to get a rough idea of the thing you are encoding, to optimise...
<chaals> Questions for WebAPI?
<chaals> APIs - want to have information about schemas,; also for XHR encoing stuff on the fly. particularly relevant for small fragments due to the way the optimisation works
<chaals> Data models - Can EXI encode HTML?; REX - EXI supports document fragments. Will those be the same?
AR: XHR and schema could be prblematic. And XHR is not used much for XML. What's the use case for schema?
SW: You use the schema to get an idea of what the content looks like, so you have a better idea of how to compact...
John: You don't have to use schema, but if you have it then it can help you. It isn't a strict contract, it's hints
AR: So you would want to see browsers understand EXI so they coul use it for XHR (etc)
John: Right. They could encode anything, but you can build in knowledge for common stuff e.g. html, svg, ...
DS: Are schemas stored on receiving device?
SW: Internal representation has to be shared at each end. Either because you know a priori, or because you share dynamically
John: Either schema is deployed (for common stuff) on the phone already, or for shiny new stuff we add an API for dealing with teh schema.
DS: Support for mixed namespaces?
John: Yes.
DS: So is there a win where you have mixed-namespace random content? Some along aschema some not?
John: Yes. You can ynamically collect moreschemas for things that appear later...
DV: Even with partial schema you do get an improvement in transmission.
DS: How would things like getElementByTagName work?
John: Through the API you get something that looks like the original document?
AvK: Are there restrictions on characters that can be used?
answer: not really
AvK: Should be possible to do in XHR - question is how to post EXI content?
John: Should be feasible
[discussion on the details]
PLH: Not so convinced - you cannot conneg on a POST
John: Yes, but you can use OPTIONS method to negotiate first.
PLH, AvK capitulate unconditionally and are driven into servitude... (more or less)
AR: True, but not enough yet... from WebAPI we don't yet have enough of a stack for this.
DS: What do you need from us, when?
John: Some user gesture to turn on/off EXI ...
SW: We should have a bit of follow on. You need to know more than just about EXI - there is also a potential to ask what schemas you know
John: Yeah, which is another piece on top (it is more complex than the schemaless case)
Kimmo: Any time last week is good. But we are aiming for First Public Draft in early March, Last Call in summer.
GW: Most of the questions will not be in the FPWD, but in stuff for the end of the year...
DS: Getting a tutorial and so on would help...
GW: Right. Giving everyone a pony would be good PR too...
<anne> so what are the questions?
<anne> HTML, XML -> works
<anne> schemas -> hah
<anne> REX -> hah
<anne> XHR -> works
<anne> APIs -> maybe
<arun> Anne, what do you mean XHR works?
<arun> in conjunction with EXI?
<anne> yeah
PLH: EXI didn't define media type, justtransfer encoding. Does WebAPI have a mechanism for controlling one or other of those.
<arun> I'm not sure that mere content negotiation is sufficient. once you get responseXML, you can't do anything with it unless ua understand the format. which it probably won't.
JL: You can set the header for content-encoding...
PLH: What if the encoding is not supported?
AvK: Nothing works, at the moment... you request something you can't deal with.
SW: Do you do RDF in WebAPI?
CMN: CMN: Not really. There was an idea to do it but we don't have any resources for it at the moment. RDF group are interested, maybe. How would you do Efficient RDF?
SW: Would potentially be worth making a special schema for it in the future. Not our priority at the moment.
John: We handle, in principle, any kind of grammar
Travis: Do you support non-well-formed XML?
John: in principle it can be done
PLH: There are a couple of things explicitly supported already
AvK: So you could already support HTML - DOM <-> EXI, without real loss
<chaals> [discussion about terminology]
SPG: EXI is also interesting in that it allows you to send native binary content. It might be intersting to see if there is something we could do with DOM to handle that...
John: Good point. Typed APIs could be interesting
DS: SVG path element has a really obtuse micro-syntax that could handle some compression ... we allow people to normalise stuff. It might be good to look at compressing that in a regular way ... suspect SVG might be one of the few formats that has their own microformat...
CMN: And all the microformats out there in the world
John: Also comes up in customer land a lot. once you define a type (such as this) you can do that. [chasing out ideas about how EXI might make the microformat things like path more interesting to be represeted as real XML]
<chaals> break time.
DJ: I resigned from W3C. You'll
have a new contact in a month or so.
... My departure is 95% certain
CMN: Notes that WAF is meeting in
April - Brisbane, AU
... A few people will be there - including Cameron, Anne.
... I'd like to meet in Australia.
... What do other people think?
<Travis> I believe that I could participate in Austrailia--though I could loose some sleep over it...
CMN: I'd like to meet before WAF rather than after.
DS: Might be tough for me.
JL: I hope to be able to come - possibly depends on who is paying the bill.
NR: I might be able to attend.
AR: It's possible for me. Lots of
other factors to consider - like workload and visas.
... Maybe someone else from AOL could attend.
TL: When would the next meeting be?
CMN: We're planning for 3 or 4
this year
... We'll have to start talking on the phone also.
DJ: I suggest checked where people will attend. It could be Europe, Australia, USA, etc.
CMN: We could host in Oslo. Or
Germany so Bjoern could attend.
... I'm planning that we attend the Technical Plenary in
Boston, November.
<chaals> bjoern, if we have a meeting near you, is there a good time that you expect to be available between now and september?
<bjoern> I am not here during the games convention, other than that I don't have plans for 2007 yet
<bjoern> end of august apparently
<bjoern> like 22-26 or so
<chaals> oki, let's avoid those dates for a face to face where we hope you can attend
CMN: We have a few accessibility issues - like how to make mouse stuff accessible.
AL: Like scrollwheels, such as
don't make it necessary to use the scrollwheel.
... I think it is the job of the operating environment to
handle this.
... If elements and widgets could expose that they are a drag
target and a drag source then the environment could expose
functionality.
<anne> * notes there's a "draggable" attribute in HTML5...
<anne> (and in IE, Safari)
TL: Are you talking about rules for dragging - like point here and hold?
AL: No. Just that the environment
should take care of this.
... Do you intend to allow drag from the desktop into a web
app?
CMN: Not at the moment.
... It's outside our scope at the moment.
... This doesn't mean we don't have it in mind. It's not a
requirement, but we're thinking of it.
AR: Maybe it is the environment's requirement to integrate with the Web spec.
AvK: Things like context menus seem more appropriate to a language like HTML5.
AL: We want the assistive
technology to be able to access the APIs.
... With new Web 2.0 the assistive technologies know when
things have changed, but don't know if the change is important
enough to notify the user.
... We've addressed some of this stuff in ARIA
<anne> http://www.w3.org/TR/xbl/#the-eventxbl
AL: I want to be able to work out what caused a change in the DOM, and then query why the change was made.
TL: This would be useful to security - able to distinguish between user initiated requests rather than script initiated.
AL: I want to know the fundamental event that created the change.
DJ: What is being proposed?
AL: Think about this. I'll get a
proprietary API working to show that it is useful.
... If that works then I'll bring it up to you.
CMN: This sounds like Events, which is close to last call.
AL: Within a year or so is ok.
CMN: Please review the events
spec and suggest where you think it would fit in.
... We have no plan to do Events 4 yet.
[group discusses ARIA and adoption]
AL: I think many of the things in
ARIA will inform the HTML specification.
... At the moment it is a long way in front of HTML.
... We've had many UI controls in the desktop world for years
that are not available in HTML, and hence are done with JS and
are less accessible.
AvK: It takes a long time to get interoperability.
<aaronlev> http://developer.mozilla.org/en/docs/Accessible_DHTML
AL: Here are some examples. They should degrade in browsers that don't support it.
DS: We should look at how to get something like this in SVG.
AL: We looked at this and discovered that we need to define a lot of new roles, relationships, etc.
DJ: So the action for this group is to keep your work in mind?
AL: Yes. THe P&F group might
not be tracking your work on the DOM so much.
... Even by publicizing this stuff we make things better.
<aaronlev> http://developer.mozilla.org/en/docs/Key-navigable_custom_DHTML_widgets
AL: We publish some tips and tricks for interoperability.
sshhh. darobin is here.
<chaals> lunchtime.
<schepers> http://dev.w3.org/cvsweb/2006/webapi/ElementTraversal/source/ElementTraversal.xml?r1=1.1
<schepers> AVK: conformance req should be in intro; intro needs work; needs examples and, for example, text; refs should have a note that it would be filled in later; or RFC2119 and relationships should be dropped or put in the intro; acknowledge me, says anne
<anne> and the only conformance term you need here is "must"