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"

<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.

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.

Mailing list

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.

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: 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.