See also: IRC log
evening all
<shepazu> trackbot, start telcon
<trackbot> Date: 04 March 2009
<scribe> scribe: chaals
<scribe> Scribe: chaals
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.
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.
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.
CM: Couldn't find you last week
CMN: Odd, we were here...
DS: Could send that
quickly.
... basically it says what we said last 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!"
DS: ISSUE-28 doesn't seem like it should be on DOM3 Events. Would expect it to be on CORS
RESOLUTION: Yep, let's 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
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
[scribe: This is really what he said]
scribe: 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 ahve 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 ...
Proposed RESOLUTION: We move to www-dom, and chaals will send reminders every month, plus cc minutes and meeting notice to public-webapps with reply-to set for www-dom
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. 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 ahve 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 this issue [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 this issue [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, due in 2 weeks [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, due in 2 weeks [on Doug Schepers - due 2009-03-11].
<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)
<smaug> oops
Meeting Adjourned
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/RESOLUTION: Doug, STFU!// Succeeded: s/minutes/minutes and meeting notice/ Found Scribe: chaals Inferring ScribeNick: chaals Found Scribe: chaals Inferring ScribeNick: chaals Present: Chaals Shepazu Smaug Carmelo Found Date: 04 Mar 2009 Guessing minutes URL: http://www.w3.org/2009/03/04-webapps-minutes.html People with action items: chaals olli schepers[End of scribe.perl diagnostic output]