Web API meeting

 

 

RB: announces DOM Level 3 Events namespaced event discussion

RB: It might be useful agreeing that we need some mechanism for events - namespace or prefix or something
... anyone doesn't think we need any kind of convention for identifying unicity

RESOLUTION: We need a namespacing mechanism (as in, some kind of disambiguating identifier)

RB: Anyone want QURIs a la Mark Birbek?
... Prefix approach a la CSS

<mjs> I'm having trouble hearing

RB: e.g. name convention, like -foo-mything
... There is Qname register
... Status Quo

JS Think I have an option d - have namespaces, but let all functions that don't use NS suffix to use the null namespace

<mjs> I think option d is the status quo

scribe: so existing functions can be used without needing namespace.
... all events defined today exist in the null namespace

RB: I can live with that.

GE: Isn't that status quo?

RB: No, currently they are in the xml namespace

JS: There is a catch-all if you listen without defining a namespace

<mjs> I think that is also a valid option to be considered

<mjs> My summary of the fourth option:

<mjs> As in the current Note, all non-NS functions would use the null namespace;

<mjs> but also, all standard events would be in null namespace instead of XML events namespace

<mjs> and special wildcarding behavior of null would be removed

<Christophe> that sounds reasonable to me

mjs: thinking about it...
... to compare to pro con list.

RB: AddeventListener keeps 5 arguments but hopefully can go to 4 dropping groups

MJS: Less need to use NS* unless you are using custom events.
... we would still need to have them.
... Bjoern proposed removng them by making namespaceURI read/write, but not sure that is a good idea.

RB: Is simpler than the Bjoern gambit

MJS: Simpler to implement, conceptually simpler.
... little harder to use with custom events.
... requires more surface area on API

RB: Not more than Bjoern gambit since we still need ways to register prefixes

MJS: Think that would be less than have NS*

JS: Concern with prefixes - the entire namespace thing gets complicated because people get confused
... envisioning that only advanced users will have to know about namespaces for events.

MJS: Remember the idea of using null as a namespace ccame up before - why di we dismiss it?

RB: Bjoern didn't like it

<bjoern> The DOM WG didn't like it either...

CMN: If we let people off namespaces, are we inviting them to learn about them badly later?

MJS: Makes it pretty easier for people to get it...

CMN: Agree

DJ: Are we saying null matches XML events namespace?

RB: People can use addeventslistenerNS

DJ: But then it is a different event

JS: What specs use namespace?

RB: Xforms, SVG would have to be changed.

<mjs> SVG says events are in the xml-events namespace

<mjs> at least in SVG 1.2, dunno if it is in 1.1

DJ: Xforms doesn't use that yet - uses XML events 1.0 DOM 2

RB: So SVG is only known user.

<bjoern> DOM3 L&S, DPF also

<JibberJim> DOM3 L&S should be killed

<bjoern> (and sXBL)

DJ: Think the process of letting simple things be simple and hard things be possible is cool. Question is whether we are breaking someone else's stuff...

RB: Everyone agreed that it is nice?

MJS: THink it is good, but would like a little more thinking time. Think I liked it on mailing list, and don't recall why it didn't work for us.
... for user agents with existing non-standard events, should they put them in a namespace?

RB: We can't break stuff. If there is a transition strategy that works, they should be in a namespace

DJ: There is nothing to stop people just adding things to the null namespace.

JS: Yes, that is a concern.

<bjoern> Well, making addEL namespace-ignorant achieved exactly the desired compatibility...

DJ: The argument from TAG will possibly be that you are allowing people to just add events randomly, a la -foo-mythingo

MJS: We could draft a monster list of things we accept there...

RB: to be effective you would need implementations to check that list

MJS: No, this is in terms of dispatching. This says "anything outside this list must be namespaced"

RB: We can say that without listing existing events

DJ: You mean content is compliant, or that implementations would block events not in the magic list?

MJS: Not about implementations blocking events, or content being compliant. This proposal is that if you add a new event you must not have it in ull namespace unless it is in the grandfathered list of things we know. To ensure future events don't infringe on the namespace, we need to know what the events in the null namespace are.
... som comment about "future ones" isn't enough- you need to define what there is as a present one.

RB: Whenever there is a new event added, we bugstorm...

MJS: What counts as new?

RB: Something they just made, not things that were already created

MJS: Think it would be more effective to have a list of what are the things people have made now.

RB: With the list, we will miss a couple.
... are you going to tell an implementor that they can't implement an event?

MJS: No, should take things as an erratum

CMN: If you don't have a list, you don't have any namespaced events

RB: If people don't want to do the right thing we can't make them do it...

<anne> [Custom events must be in a namespace.]

MJS: If we want to have conformance criteria, we need to be able to have a test suite...

<anne> there's your conformance criteria

RB: Think that strong language telling people what to do right is as good as we get

<anne> not sure about UAs though

RB: there are events that do clash

MJS: Want a demarcation line so people know what to tell people

JS: It is important to say "don't do this, do that", and why. Most implementors try to do the right thing when they are not feeling lazy.

MJS: Right. We have some stuff internally that we could just namespace to let them go wild
... still think the more unambiguous the spec is, the better.

<scribe> ACTION: Robin to propose some text and see how we like it...

<trackbot> Created ACTION-60 - Propose some text and see how we like it... [on Robin Berjon - due 2006-03-02].

GE: Is events that use namespaces for advanced users? I would say that people doing dashboard are not advanced users

RB: Events added by a vendor in a namespace are one thing, there are events created by a component author using their own namespace. In the second case, the people can be expected to understand namespaces.

GE: The first case is the problem.

<mjs> dashboard.onshow/onhide are not presently events at all

RB: You just cut and paste code

<mjs> they are just user-settable function-valued attributes

<mjs> fwiw

CMN: That is how people have managed to mess up namespaces (which are simple enough for small children to get right, BTW)

<mjs> dashboard object is not even an EventTarget

DJ: they don't cut and paste and learn, they just use the function.

GE: There is definitely a need for it, so

RB: If we had namespaces in '92 it would be easier - they would be in all specs, but...

RESOLUTION: The proposal to use namespaces, but have a default of null namespace for existing non-namespaced events has been accepted

<mjs> I think to be fair we should give bjoern and others a chance to object before finalizing this

<mjs> (even though I like the proposal)

(everyone can object to the decision if they want to...)

RB: Sent email to DOM IG so should wait in case there is a response. Otherwise we can drop the groups stuff.

JS: You can't get reliable firing order from DOM3

RB: Well, it is in event groups.

<darobin> http://www.w3.org/TR/DOM-Level-3-Events/events.html#Event-groups

JS: Thinks XBL can build a custom solution that takes care of firing order...

RB: Triggering order for events is registration order within a group. We could still say that without having groups.

JS: You could still use ?? for propogations

MJS: XBL has definition of bindings and order. So DOM3 can be sufficient, so stop immediate prop does seem like it would be suitable.
... so think there is a valid use case for it.

DJ: So if we create new events, or other W3C groups, do we recommend that they use the null namespace, or make a new namespace?

RB: We should have a general policy that if there are generic things for all languages, they should stay null, otherwise use a namespace
... we could encourage groups to use namespaces.

<mjs> it doesn't have to be "all", just something that isn't clearly specific to a single language (IMO)

DJ: We don't want to set an example that encourages people to add lots to the null namespace

RB: You need to go through the group.

DJ: Think we should have a registry for events

RB: How hard is that to set up?

DJ: SHould be easy
... so people can register stuff in W3C registry using their namespace
... so are we suggesting that W3C groups should use non-namespace events in general

RB: Am fine with that

CMN: Not so pleased

JS: The concern is that we encourage others to use the null namespace

RB: Non-namespaced versions are always there. Other groups tend to do the right thing becausee it is the right thing.

CMN: Concern is that people copy the behaviour of working groups, and add their own null-namespace

DJ: That's why I suggested using XML events namespace

JS: But then you get the problem in that naemspace instead of null

RB: That's the nice thing about registry - you get to tell people they have done something that could be better.
... it doesn't seem like a huge amount of work.

CMN: registries are not such a great idea. Require ongoing commitment, have potential access hassles... that's why namespaces exist.

RB: So could come up with a policy that we can add things to the null namespace because they are legacyevents, or closely related - and anything new we do should have a namespace. Does that work for me?

JS: That gets us back towards the status quo - people are forced to use NS stuff everywhere.
... would rather not enforce that on users too much.

CMN: We either have to push people towards learning namespaces, or live without them. The current approach is nice because it has a transition path from now, but we should set an example of making people learn them.

MJS: Making everything harder for authors is not a good solution to the problem of getting them to do the right thing. We have to make it easy to use and appealing.

GE: collision will only happen if there are more than two events with same name...

RB: in null namespace is the only plalce you are likely to get it.

MJS: Is there are known case of clash?

RB: Have had show/hide, think resize/zoom will clash
... Worked on stuff that would have been a real clash if we hadn't killed it.
... think we can look at the problem of what we do with new events when we hit them.
... for legacy events, we put them in the null namespace. For new things, we can probably find a good transition.
... we are talking about somewhat abstract scenarios.

--break--

<mjs> just for the record once again, Dashboard does not have show and hide events

<mjs> because people seem to keep getting confused on this

<darobin> I guess the fact that I get confused about something this simple yet understand namespaces....

<anne> scribe: anne

<scribe> scribenick: anne

moving forward on other specs

RB: so... other specs
... I think we should be moving forward on all specs

RB: we have two public PWD and one LC in March
... two editors are here

AK: parts are rewritten
... would like a new version of ReSpec

CM: can we have a draft on March first?

AK: should be possible

RB: publish on March six if ok?

[agreement]

Window interface

RB: editors are not here

AK: draft here: http://lists.w3.org/Archives/Public/public-webapi/2006Feb/att-0075/Window.html

RB: need to create text here, can't publish an idea

ID: I can write text, told MS about it

AK: wonders if History is needed because of location.replace and such...
... there's a relation between History and Location...

ID: I can create some text

AK: I volunteer for section 4

<darobin> ACTION: AV to draft section 4 of Window - due 2006-03-06

<trackbot> Created ACTION-61 - draft section 4 of Window [on Anne Van Kesteren - due 2006-03-06].

ID: are we going to specify sizing and moving aspects
... traditional stuff

RB: would be cool if it would be compatible with devices
... they don't have that
... Window is a misnomer too, we do specs that are misnomers
... I would be happy with a subset that we can publish fast

ID: I'll have the text middle of next week

RB: ok!

<darobin> ACTION: ID to have the rest of the text for Window - due 2006-03-01

<trackbot> Created ACTION-62 - have the rest of the text for Window [on Ian Davis - due 2006-03-01].

RB: current feature set is fine?

JS: apart from the large set of interfaces...

GH: would it be a problem?

JS: we can't change it, besides, this seems unneeded
... we simply can't implement the Java IDL, we don't support multiple inheritence
... this is the documentation for the C++ users too, there interfaces matter

GH: I think it makes sense to split the features
... easier documentation, grouping is nice

JS: SVG documents it in one place, and has the separate attributes organized and also all IDLs on one page

ID: so we don't split the interfaces, but do group attributes in separate sections

[agreement]

JS: SVG was soooo good in that!

RB: have a draft march 10, review on monday
... is that possible?

JS: I don't have the same monday

RB: you have a better friday

DJ: I'll do it on Tuesday

RB: Navigator object might be interesting, not sure version 1 versus version 2
... doesn't have to feature complete for FPWD

AK: does FPWD mean /TR/ or dev.w3.org?

[no!]

RB: you can publish to dev.w3.org all the time, just make sure you note it is an editor's draft
... we can do the normal things these days, go straight to PR, have four LCs, whatever

<darobin> http://dev.w3.org/cvsweb/2006/webapi/DOM-Level-3-Events/source/

<darobin> ACTION: BH also put the HTML version up for D3EV [recorded in http://www.w3.org/2006/02/23-webapi-minutes.html#action05]

<trackbot> Created ACTION-63 - Also put the HTML version up for D3EV [on Bjoern Hoehrmann - due 2006-03-02].

RB: 22nd of March draft available (in final form), 27th of March descision to go to LC or not
... knowing that we can do it (if not possible before) the 3rd of April

<darobin> ACTION: RB ask the CG to review editor's draft after BH has put up the html version, and explain the changes that have been and will be made [recorded in http://www.w3.org/2006/02/23-webapi-minutes.html#action06]

<trackbot> Created ACTION-64 - Ask the CG to review editor\'s draft after BH has put up the html version, and explain the changes that have been and will be made [on Robin Berjon - due 2006-03-02].

[some talk about publishing]

RB: expect a six week LC period
... should be enough to review DOM3EV

JS: we have issues

AK: we should solve those

RB: most are solved I guess
... it's not that bad
... it's on the agenda that we try to solve the issues

Network API

DJ: we should let XHR go first

RB: SVG WG might be able to be convinced to just use XHR
... me for example

CM: I, as member of the SVG WG, would like to use XHR

GH: so we don't do it at all?

RB: no, we postpone it
... probably has a FPWD in May
... push it down to June?
... editor?

GH: I might try to edit a spec
... with help from Charles?

CM: If you push it back to July

RB: we can worry about that later

CM: good thing

persistant storage

RB: done by Ian

ID: early May perhaps

JS: how are proposals done?

RB: anytime, anyday, e-mail the WG

<darobin> ACTION: ID to survey Persistent Storage APIs - due 2006-03-15

<trackbot> Created ACTION-65 - survey Persistent Storage APIs [on Ian Davis - due 2006-03-15].

[15 of March is birthday of RB]

File Upload

RB: by me!
... I'm happy with the timeframe, there was a proposal in the SVG spec once

<darobin> http://www.w3.org/TR/2004/WD-SVG12-20041027/api.html#fileupload

RB: this was to enable to XForms upload within SVG

JS: can script read from the file?

RB: yes
... the idea was that you could pass a file object to an XHR (URLRequest "back then")

<ssire> does the script can read directories ?

GB: so you can't do things on the file system? Thinks of a sandbox...

DJ: building the webOS might be something for the next century...

GB: MS has the ability to do it; heavily in use by IE...

JL: you can control Word through ActiveX too; not sure if it's more web specific than that

JS: I'm worried about security

GB: it's already in Firefox

[more discussion]

Drag & Drop

RB: on DS and CM, probably planned for June

CM: seek inspiration from WHAT
... should work out fine
... we're happy with the timeline, still have time to think about it

RB: Safari supports dragging and dropping interacting with the OS

JL: so does IE

ID: WHATWG splits it out
... in same document and different documents

<darobin> http://www.w3.org/TR/SVGMobile12/svgudom.html#events::ProgressEvent

ID: other section is completely blank

ProgressEvent

RB: I'm editing together with CM and I'm happy with the timeline

Timed Events

DJ: basically doing settimeout as an event system instead of callback

JL: [explains delayed dispatching of events]

XPath

JS: We need a LC

RB: I'm no longer editor, JS is
... we're we have CR now, we have LC

JS: new things added, perhaps WD first
... can have a WD in May or even April...

RB: April?

JS: yeah, can do a WD in April, not a LC

RB: LC in July?

JS: perhaps

RB: we have another intern WD in the mean time
... LC was obviously successful, CR in September
... timeline updated

<JibberJim> come back zakim!

JS: not sure if CSS can be done
... well, if it can be done in the same draft, separate API and such

AK: argh, why not?!

[some discussion on that]

RB: if someone can start a draft, do that, it's just not an official diliverable
... Rex got a small batch of comments
... easy to address, perhaps a next draft in a month

JS: I'm not a big fan, have comments

RB: please send them, I'm planning to address them all in one sweep

[some discussion about Rex]

RB: non-timeline deliverables

[discussion on JSON, scribe lost it for a bit]

Basically, it was about adding native methods so you don't need to use eval()

scribe: which is not in the JS mobile profile (or so)

<?access-control?>

tracked here http://lists.w3.org/Archives/Member/member-accesscontrol-tf/

<gorm> scribe: gorm

<scribe> scribenick: gorm

Opera Demo

<anne> [Gorm explains Opera widgets.]

[Gorms just doing some scribe to feel useful]

[RB Showing demo rom mobile.weatherwalk.com]

JS: good idea to do DOM XSLT spec

<chaals> opera:config#Colors|Background

RB: put it on your todo list dino

DJ: we can go one step further

AK: would like to look into it, but in a few months

JS: yes

RB: not urgent
... useful, lets do it efore 2008

AK: let us look on what is implemented now

[group reading mail from Ray regarding groups in dom3ev]

<chaals> http://www.w3.org/mid/465905FD-255E-4D0B-9C50-3FEAF3CF8C08@personallegal.net

RB: anything else on the XSLT API

<chaals> (opera:config is for Opera 9...)

<scribe> ACTION: JS to mail xslt dom api notes to the group

<trackbot> Created ACTION-66 - Mail xslt dom api notes to the group [on Jonas Sicking - due 2006-03-02].

<scribe> ACTION: GE to verify that the Mozilla implemenation of xslt dom api is compatible withOpera

<trackbot> Created ACTION-67 - Verify that the Mozilla implemenation of xslt dom api is compatible withOpera [on Gorm Haug Eriksen - due 2006-03-02].

<scribe> ACTION: mstachow to verify that the Mozilla implementation of xslt dom api is compatible with Safari

<trackbot> Created ACTION-68 - Verify that the Mozilla implementation of xslt dom api is compatible with Safari [on Maciej Stachowiak - due 2006-03-02].

Topic CDF review

RB: who can attend the meeting Monday Tuesday in Cannes?

[anne, robin]

RB: they do not mention our review
... suggest Anne represents the group speaking about the apis

<anne> http://www.w3.org/TR/2005/WD-CDR-20051219/

AK: all the apis are in the generated spec?
... in section 2 there are two interfaces that are in the windows spec aswell
... there is an object that reference the sv file, you get the document elemnet?
... iwe also specificy contentWindow
... everyone agree on rendering obsolute

JS: contentDocument we can depreceate

[JS: frameElement vs. document.referenceingElement]

JS: inconvinience and sometimes there are no windows

RB: when?

JS: referencing a pure datea document

JL: the window will still be contained

JS: some properties there, would reuse same class
... rather than creating a dummy class
... why not stick it on the document

RB: not interopable with existing content

JS: we can add new things :)

RB: I hear your argument, but the windows api is so small that this isn't a big issue

JS: we can always add some other type of mechanism
... the current proposal work for existing, I might be a little teroeticical

RB: you are visionary

AK: security exception, safari didn't like the security issue (objected on public list)

JS: all implementations throw exceptions so we should standarize the exception

RB: good idea

AK: the argument is that they should choose for themselves

JL: they would prompt the user and ask them in they wan't it

<anne> http://lists.w3.org/Archives/Public/public-cdf/2006Jan/0007.html

JS: should be u pthe UA to specify security policy

RB: lets go back to frameElement
... discussion on whree the window object is defined

<darobin> http://www.w3.org/2006/02/01-cdf-minutes.html

JS: what do you mean by "...."?

AK: didn't like it

RB: the exception system doesn't inherit from dom exception
... when another spec would edit a new exception to dom they will also use 83
... can we agree on the comments

AK: the first we advice against

RB: we recommend frameElement, there is no difference

JS: is contentWindow implemented in alot of browsers

AK: yes

GE: where are they documented

AK: in various specs

RB: should start on 91

AK: what do we say regarding security expcetion...use 91?

JS: good idea, don't like that it's a new interface

RB: good idea, how does it translate to bindings?

AK: work with new interface?
... dom ls say they extend it

<darobin> http://www.w3.org/TR/DOM-Level-3-LS/load-save.html#LS-LSException

RB: no, don't think any extend it

JS: maybe dom xpath did it
... dom xpath also creates a new interface

RB: it's important how they work in the bindings
... it doesn't make sense to start at 60 or 80
... the use-case is that they catch runtime exception instead of the sub cases

<bjoern> (the only problem with the numbers is that e.g. in ES you can't tell the difference between a DOMException.code and a FooException.code; so if a method raises both FooException and DOMException they could clash; not that likely in practise though)

<bjoern> (not that I know why they throw a new exception instead of NOT_SUPPORTED_ERR or just return null or something)

JS: exceptions are probably castable

<bjoern> (in Java and other strongly typed languages you don't have any problem even with clashes)

JS: good idea to start with a code
... need some research

RB: next week meeting, good to have something ready during next week
... we can say: "Drop everything, we do it for you"

JS: the place I would look atre at the other dom specs
... will tell them to do it the same way
... looks like they have done it the right way (tm)

RB: the code is wrong
... the idea is probably right

AK: I don't like the security events

JS: when should it fire?
... whe nthe browser is beeing hacked?

CM: may fire a secrity exception when you do something that the security system doesn't allow
... the browser should be allowed to fail silently

<darobin> http://www.w3.org/TR/2005/WD-CDR-20051219/#security-event

<JibberJim> "Security event is a mechanism for notifying non-scripting related security violations. On the other hand, security exception in 2.1.4 is used for notifying scripting related issues.

<JibberJim> 2.2.2 Security Event

JL: it's useful
... would be nice for scripts to know it
... I see use-cases!
... you know it fails, because you will never know if it succede

JS: still not getting it

RB: say you can't reference domain, a smile animation changes the xref to an unrestricted doamin, you cant throw exception because there is no script there
... not a very common use-case, but the only way to singal in this situation
... I think they should keep it
... you know it #"?#?" up

[the use-case]

JL: the use-case word inside an iframe, you wouldn't get any warning in IE

CM: don't say when the doc breaks thru

<darobin> RESOLUTION: referencingElement should be frameElement, and we're doing it

<darobin> RESOLUTION: contentDocument is fine, but we're doing it

<anne> (plus contentWindow)

<darobin> RESOLUTION: the SecurityException is a good idea, but the code is wrong

<anne> (should be 91)

<anne> (or 101)

<chaals> s/code and wording/

JS: one concern is that it's unreliable

<darobin> RESOLUTION: the security event is nice, but it should be defined in greater detail and the first sentence should not say that "a document breaks through the user agent security policy"

AK: not failing silently was a reason for security exceptions
... 2.2.1

<anne> AK: http://www.w3.org/TR/2005/WD-CDR-20051219/#event-propagation

JS: who will set

AK: the script author
... click events in a child doc

JS: by the time you catch it should have gone thru the capture phase, to late to do something

RB: might be to late, but the spec odesn't speci how the capture phase go

JS: the logical, if it goes thru multiple document it should follow the window stack
... and bubble up again

RB: might only buble, not clear to me
... we lack some understanding on how this should fit into the dom

JS: and we need a use-case, I understand for CustomEvents

AK: if you have a SVG child doc, you can do something with it in the parent doc (if i recal correct)

RB: you can do this with cross doc scripting

JS: dispatch a click event on the iframe, then target a click event on the iframe element aswell
... could it be useful to make an event on the outer document if dispatched inside

RB: SVG got something for this

JS: some target, not a fan

RB: does to many things

JS: should use xbl

[rb getting ready to summarize]

JL: don't see any use-cases, not clear what happens

<darobin> RESOLUTION: for DocumentEventPropagation, we don't see use cases, and it's not sufficiently specified for us to be assured of our comments

ACTION AK to send questions to our group that will be sent to the cdf group for clarification

<scribe> ACTION: AK to send questions to our group that will be sent to the cdf group for clarification

<trackbot> Sorry, couldn't find user - AK

<scribe> ACTION: AV to send questions to our group that will be sent to the cdf group for clarification

<trackbot> Created ACTION-69 - Send questions to our group that will be sent to the cdf group for clarification [on Anne Van Kesteren - due 2006-03-02].

RB: anything to add?
... ask to be listed on our web page
... we should say that we work togheter with them

<darobin> ""

<darobin> F2F topic - propogate and capture/bubble in n nested level references

<darobin> F2F topic - window.parent issue

<darobin> F2F topic - Is the Web API WG going to worek with the HTML WG to get XML Events - DOM Level 3 events and namespace aware

<darobin> F2F topic - CDF is not listed as a related WG on Web APIs web page

<darobin> "" --KK

RB: prefer Tuesday 1pm for meeting CDF group

[a little break]

[back]

<JibberJim> scribenick: jibberjim

scribe JL

<scribe> scribe: JL

Open DOM 3 issues

<darobin> http://www.w3.org/2005/06/tracker/webapi/issues/

AvK: I've drafted the letter to the CDF WG as per previous comments, if no-one has comments by tomorrow I'll send it to the group.

RB: Issue 1 DOM events
... Issue 1 apeares to be closed...

JS: The binding should also say what the scope chain an execution context is - what is the execution context?

GE: what should "this" be when the event fires?

JS: It is the object you've attached the event listener to
... if you use addEL - you get either the object if you pass an object to aEL, otherwise it's the object you attached it to.

GE: I'm not sure that is right.

<darobin> http://www.w3.org/mid/53EF21D7-B6B7-4181-A8AA-0F4DED11BA2B@apple.com

RB: In the email issue 13 was addressed, which also addresses issue

<bjoern> (hmm, ym, if I raise an issue and the tracker makes a mail From: bjoern ..., that's faking?)

RB: issue 1

JS: Doesn't seem to define the scope chain.

GE: if you use aEL, it appears it's the object, otherwise when it's an attribute it needs defining

<darobin> lalala ISSUE-13 ISSUE-1

<scribe> ACTION: maciej to define the scope chain of onFoo events reference issue-1

<trackbot> Created ACTION-70 - Define the scope chain of onFoo events reference issue-1 [on Maciej Stachowiak - due 2006-03-02].

JS: I don't think you can actually grab hold of the scope object.

<dino> (but I'll consider it anyway)

JS: but it's just specifying what we do in Mozilla and other browsers

<darobin> http://www.w3.org/2005/06/tracker/webapi/issues/3

RB: Issue-3

JS: this was influenced by the namespaceURI solution, so we deferred it

RB: so lets do it now.
... Bjoern has a proposal to only check when you dispatch an event.
... so no checking on URI's, just checking type is not null or emptystring and is an NCNAME

<scribe> ACTION: BH to write up his proposal into the spec ref. issue-3

<trackbot> Created ACTION-71 - Write up his proposal into the spec ref. issue-3 [on Bjoern Hoehrmann - due 2006-03-02].

RESOLUTION: Accept the proposal in Bjoerns last paragraph

RB: implementors should also note that there were lots of bugs found when researching this!
... Issue-4

JS: do we want willTriggerNS at all?

RB: that's another issue.
... let's leave this one open.

SS: Is there a wildcard event namespace wildcard.

JS: I think it would be useful for type.

ID: Does it make sense to find event type LOAD in any namespace?

JS: I don't see the point in time spent on hasEventListener etc. as we don't need them.

RB: so the use case for them could be that AT tools could introspect another DOM.

MJS: said it was a convincing argument but not enough to solve the problem.

<darobin> chaals, http://www.w3.org/2005/06/tracker/webapi/issues/17

JL: If the only use case for AT tools, then it should be in a seperate AT spec. that includes everything for AT tools.

JS: I agree it's not the place of the DOM to define plugin api's which this seems to be.

CMN: So you don't think that's how AT should work?

JS: I think that AT shouldn't be in DOM spec, as the DOM spec is for page authors.
... AT needs to enumerate all listeners and figure out "what it does".

CMN: The argument likely to come back is being able to find out event listeners would be a huge step forward.

JS: so I'd ask why have it in a DOM specification?

CMN: their rationale is so that it will get done...

JL: AT's can already do this.
... so speccing it as part of DOM3 for the one use case is overkill.

RB: So am I hearing that dropping it is a good idea due to not really meeting the use case and there being many other issues.

RESOLUTION: keep stopImmediatePropogation
... drop willTriggerNS and hasEventListener

<anne> http://www.w3.org/TR/2003/NOTE-DOM-Level-3-Events-20031107/events.html#Events-DocumentEvent-canDispatch

<anne> (that might be a separate issue, I wonder why it's needed)

<bjoern> it's very useful to know which events an implementation can generate...

<iand> RESOLUTION: close ISSUE-4 since we've removed method

<iand> RESOLUTION: close ISSUE-5 since method has been removed

RESOLUTION: close ISSUE-6 as closed namespace issue

RB: Issue-7 - can mouse relatedTarget be null?

RESOLUTION: relatedTarget can indeed be null, close issue-7

<scribe> ACTION: JL investigate onclick/mouseover/mousemove behaviour etc. reference issue-7

<trackbot> Sorry, couldn't find user - JL

JS: I think we should probably leave that to implementations, as different platforms have different conventions
... so we don't want to force implementors to go against that.

<scribe> ACTION: BH remove the restriction on click to fire and add text saying it should follow platform behaviour.

<trackbot> Created ACTION-72 - Remove the restriction on click to fire. [on Bjoern Hoehrmann - due 2006-03-02].

<anne> bjoern, you mean for events that the UA can dispatch, like 'load', 'click', etc. Why?

CMN: I would suggest just removing it, not adding the text

<mjs> hey, I got an action item without even being there :-)

JS: Agree with CMN

RB: issue 9 making click more generic

<anne> http://whatwg.org/specs/web-apps/current-work/#event0

<bjoern> for the same reason that you'd like if (document.getElementById) to work...

CMN: I think it would be a good thing to make click more generic because that was why activate was invented.
... so being able to make click fire activate it would make it possible to identify which type fired.

JS: can you tell from other properties on the event to distinguish event clicks from activates with details.

CMN: implementations can't fake it.

JS: they could fake middle of button if they had a rendering.
... I'm absolutely behind making click fired for all activates.

AvK: we could add something similar to trusted which could be a bit hacky.

CMN: So the use case for knowing how they clicked the button is tracking the user behaviour to improve the interface - good for AT

JS: I can see that but it seems like an edge use case.

CMN: Accessibility edge cases are evil.

AvK: so everyone agrees that click is a generic activator event, and then we can figure out later if we want to distinguish between 2 different sorts of activations.

JS: so we can already tell with a mousedown before click that they used a mouse.

RESOLUTION: A click event is right to be dispatched as well as activate

SS: does that mean you can't create an ACTIVATE event?

CMN: you can, but you should probably fire click as that'll actually do something useful.

RB: Issue-10
... someone needs to create a proposal

AvK: it's defined in the XBL spec.

JL: what's the use case?

JS: in mozilla for example we don't allow keydown events to be dispatched to file control.

JL: in an AT it needs to fire trusted environments

JS: Like we have namespaces because you're not in full control of all code/events on the page.
... I'm not convinced trusted is something we need publically.

CMN: I think the definition of trusted there is a bad, and there are other ways to define which events are trusted.

RB: so are you pushing for keeping it?

CMN: I am.

GE: I'm not sure?

JS: we also use it in greasemonkey.

CMN: we put all these restrictions on userjs specs because we don't know what to trust.

JS: so we need more levels of trust rather than just the "trusted"

AvK: so this doesn't appear to be meeting the use case.

JS: I don't want to trust all events from badsite.

CMN: but I do want to be able to trust events from example.com/

JS: so that would be an entirely different situation.

CMN: so the question is just .trusted enough?

JS: no, because it doesn't meet the multiple site cases

<darobin> ACTION: CM to draft a proposal for .origin (ISSUE-10)

<trackbot> Created ACTION-73 - Draft a proposal for .origin (ISSUE-10) [on Charles Mccathienevile - due 2006-03-02].

RB: issue-11

JS: closed as we resolved to remove hasEventListener above.

RB: issue-12

JS: so the current state of XBL2, even though I'm not happy with is that you don't need any more event API
... we removed originalTarget as you can't get to the shadow tree

RB: I don't think we want to do stuff to support specs in flux

JS: I agree, I don't want to add XBL specific stuff

RESOLUTION: issue-12 don'd do anything specific for xbl

RB: issue-13, I believe people agreed with maciej email
... I think we all agree passing a function is possible, should it also be possible to send an object with handleEvent?

RESOLUTION: issue-13 it should be possible to pass an object with a handleEvent method

RB: issue-14 we've removed the event, so it can be closed.
... issue-15

JS: should the security event be the same event as the error event?

AvK: are load and error mutually exclusive?

JS: sometimes we fire neither, but I don't think we ever fire both
... should non-WF not fire load?

AvK: iframe/object only fire onload, never fire error, only fire load.

<scribe> ACTION: JS to check what happens with well-formed XML content

<trackbot> Created ACTION-74 - Check what happens with non well-formed XML content [on Jonas Sicking - due 2006-03-02].

AvK: it suggests that an error event means we should also display the fallback content when using OBJECT.

CMN: we'll leave it open now.

RB: tomorrow's agenda is pretty much just issues
... Meeting Adjourned