See also: IRC log. Note that the order of discussion in these minutes has been edited to group discussions together according to topic.
Find All Open Issues For DOM3 Events and Update the Specification
DS: Not yet done. Would be good to start. Hold over until next week.
RESOLUTION: Extend ACTION-1 to a week from today.
Add a diagram about wheel axes etc
DS: Not so important. Does look more fun
though... in two weeks.
... Is not completely silly because we can use it as a reference for people to
look at.
CMN: Agree. Illustrations and simple examples are actually important.
RESOLUTION: Extend ACTION-6 by a week.
http://www.w3.org/2008/webapps/track/actions/16 and http://www.w3.org/2008/webapps/track/actions/17 - Carmelo to look at latest draft, and start writing tests...
CMN: Suggest we hold off action 17 until we have
a latest draft - depends on upcoming agenda item...
... have you started writing tests?
CM: Yeah, and submitted some.
DS: Haven't looked at them yet though.
CMN: let's change the action item to "write more tests!"
RESOLUTION: Extend ACTION-17 until we have a draft, change ACTION-16 to "Write more tests".
http://www.w3.org/2008/webapps/track/issues/28
DS: ISSUE-28 doesn't seem like it should be on DOM3 Events. Would expect it to be on CORS
RESOLUTION: Move ISSUE-28 to CORS
DS: Have a suspicion that not all the issues we
have are listed in tracker.
... http://www.w3.org/2008/webapps/track/issues/27
ISSUE-27 also seems to belong to CORS
RESOLUTION: Move ISSUE-27 to CORS
Propose some wording to resolve ISSUE-44 by saying that it depends on the language where the event goes
DS: Have a local copy of this. Says what we said last week.
DS: Is there anything we can do in the spec that willhave an effect on Firefox?
OP: I won't change anything this late
CMN: We won't change Opera 10 this late either.
DS: So looks like Keyboard stuff won't get sorted until next releases
OP: Indeed...
DS: Tempted to just change the Keyboard model
completely to avoid breaking web pages (as opposed to just tweaking it a
bit)
... problem with documenting existing behaviour (which is important) is that
when all behaviour is idiosyncratic, ...
... If Firefox changes things that they thought was more sensible, they break
pages. But I guess people know that Opera and Firefox are different, and so
... I guess this is applicable to keyboard
DS: so to work across browsers I would do
something not much better than sniffing to see what capabilities are in the
browser and if it didn't have them I would switch to do different behaviours on
different things.
...With the load event I punted to the individual language. Fortunately it is
clearly defined in SVG and has been for a while. For HTML I am happy tohave
Hixie solve the problem but I am not sure it is a solvable problem. No matter
what you do you will break content. I would like to have language that says
:this is what you should do. But languages may define other things"
CMN: That is what I thought you were going to do.
DS: No, I just left it up to individual languages.
CMN: I would be pleased if you did define some default behaviour, then noted things may be different.
DS: Anyone else have an opinion about the previous topic?
OP: I would like to define our behaviour, of course :)
DS: I wonder if someone could be smart, and if people are sniffing on browser version they get something that says "if you don't have method X, do some things that are unrelated to X" (e.g. people test on filters to see if things are IE, then do something else).
CMN: Yes, but not always.
... I understood Doug would say it is possible for languages to define what
they want for load, and would note what HTML does, but say langauges should
generally, and User Agents should expect generally something like SVG.
... which I believe would effectively be defining what you are already
doing...
OP: Does SVG define Load or SVGLoad?
DS: Defines the SVGLoad event, but then says "oh, you can also use the load event, with the same behaviour"
OP: Are there SVG1.1 errata?
... I think it was changed a bit...
<scribe> ACTION: schepers to research what SVG defines for load. [recorded in http://www.w3.org/2009/03/04-webapps-minutes.html#action01]
<trackbot> Created ACTION-318 - Research what SVG defines for load. [on Doug Schepers - due 2009-03-11].
OP: 1.1 doesn't say much about load event.
Mentions SVGload, triggered when some element has been fully parsed. This is
quite different.
... but SVG has the same attribute name (different event but same
attribute).
DS: Believe we defined it more clearly in SVG 1.2 but not convinced that we got it right.
OP: SVGload isn't related to the document, but to elements
DS: Wouldn't necessarily define it the way SVG
defines it. Would define its default in a way that makes sense, and talk about
the differences that exist between HTML and SVG
... SVG tiny 1.2 talks more about progress load event.
<shepazu> http://www.w3.org/TR/SVGTiny12/interact.html#LoadEvent
DS: SVGload is deprecated and only for backwards
compatibility. For load, the event is triggered when the element and dependent
resources are loaded (and scripts are interpreted)...
... Seems like SVG isn't the right model to copy either
RESOLUTION: Extend ACTION-312 by a week.
DS: Going through the mailing list to find stuff
to do with D3E is really tedious and onerous
... we constantly talk about events, but very often it is not relevant to DOM
3 Events - keywords come up in other contexts too. Was wondering if it would be
appropriate to make a new mailing list.
CM: Probably a good idea
OP: There is an old DOM mailing list
CM: I have had the same issues
CMN: Is old DOM mailing list public?
CM: Think so...
<shepazu> http://lists.w3.org/Archives/Public/www-dom/
OP: There is a problem that people only check webapps list
CMN: So what if we move to www-dom, and send a
reminder every month to webapps that DOM 3 stuff is on www-dom? (for developers
who don't look at other lists much)
... and cc minutes of DOM 3 stuff (with another reminder)
DS: how about Bcc minutes to public-webapps
CMN: Better to send to webapps, with ReplyTo to www-dom
DS: We could try that for now. I imagine we will hear complaining... There is some traffic already ...
RESOLUTION: We move to www-dom, and chaals will send reminders every month, plus cc minutes and meeting notices to public-webapps with reply-to set for www-dom
DS: Didn't get a chance to do as much as I would
like with this. There are two different camps...
... The people who say mutation events are awesome, love them, have
implemented them in JS or something...
CMN: I believe that the ARIA folks, or at least Rich Schwerdtfeger, is in that camp
DS: ...and then there are the browser implementors
OP: Was talking with our accessibility guy today
about this and seems that they only need the DOMattrmodified event. Which is
not one of the evil ones.
... don't understand the reason for that. But ...
... wonder if they could have ARIAattrmodified or something. There is some
accessibility software that will change attributes on the page and then check
what has changed.
... they are using domattrmodified for that.
DS: I think they also need to know when the text
changed as well
... after a complex change of text.
OP: Why would that be?
CMN: Because assistive technologies need to know when things have changed.
OP: This is not about implementation, it is about what web developers can use. The internal implementation can use something else.
DS: Maybe we should comment during ARIA last call
that they are relying on a relatively costly mutation event and ask if they can
define something more targeted like ARIAattrmodified
... suspect they will not be comfortable doing that, but we could work with
them to define that.
OP: yeah...
DS: That would be relatively trivial, and much lower cost than the generic one.
CMN: At the very least, it opens a dialogue that we probably need to have.
DS: Mozilla has stated that they will not implement [I forget which]
OP: Domnoderemoved, probably. I know of no reason not to implement it, given that we implemented another one, although it could be better to remove both. I am worried about back compatibility because some web pages do use these things.
DS: They only use the ones that are implemented.
OP: Only gecko implemented DOMattrmodified event, doesn't implement DOMnoderemovedfrom/insertedtoDocument
DS: Think we should open topic of removing or
reworking them.
... there are script librarians who say they need them, but they cannot be
relying on them because they are not implemented.
... First step is to find out what is implemented.
OP: When Jonas was proposing removing/changing things, it was only evil things.
DS: If nobody is going to implement something, I am not going to put it in the spec. What we could do is make the mutation events spec, and script libraries could conform to them - a copy/paste of the mutation events from DOM3 events. D3E could go with a cleaner model, then people would not have to rely on script libraries. Nobody is relying on any of this working in browsers, where it oesn't.
OP: Could document what I found implemented...
... would be great if someone from Opera could comment on this.
<scribe> ACTION: Olli to publish what he has found about mutation event implementation [recorded in http://www.w3.org/2009/03/04-webapps-minutes.html#action02]
<trackbot> Created ACTION-319 - Publish what he has found about mutation event implementation [on Olli Pettay - due 2009-03-11].
<scribe> ACTION: Chaals to get someone at Opera who understands event implementation to comment on mutation events [recorded in http://www.w3.org/2009/03/04-webapps-minutes.html#action03]
<trackbot> Created ACTION-320 - Get someone at Opera who understands event implementation to comment on mutation events [on Charles McCathieNevile - due 2009-03-11].
CMN: Latest formal spec is 2007. We should probably publish something soon.
DS: Can have a new draft proposal in two weeks
<scribe> ACTION: schepers to provide new draft ready to publish as Official draft on /TR [recorded in http://www.w3.org/2009/03/04-webapps-minutes.html#action04]
<trackbot> Created ACTION-321 - Provide new draft ready to publish as Official draft on /TR [on Doug Schepers - due 2009-03-18].
<scribe> ACTION: chaals to notify public-webapps that discussion has shifted to www-dom [recorded in http://www.w3.org/2009/03/04-webapps-minutes.html#action05]
<trackbot> Created ACTION-322 - Notify public-webapps that discussion has shifted to www-dom [on Charles McCathieNevile - due 2009-03-11].
CMN: Would be useful to give a couple of days before discussing things on www-dom. (But I will send minutes there already)
Meeting Adjourned