Re: A few strawman proposals: Query Key State, Selector-based Mutation Events Replacement

Hi, Travis-

How about we write these up as Editor's Drafts, to get more precise 
feedback, and consider adding them to the next charter?


Travis Leithead wrote (on 11/30/09 7:22 PM):
> I’ve been meaning to do this for awhile, but over the extended holidays
> I finally had the chance. I’ve quietly added a few strawman proposals
> for next-generation events specs to consider:
>
> · Query Key Status – method for getting key state outside of the
> eventing model

Yup, seems logical.  Obviously needs fleshing out.


> · Selector-based Mutation Events – follow-up proposal to Jonas’ concept
> earlier this year (or last year??)
>
> http://www.w3.org/2008/webapps/wiki/DOM3Events#Proposals
>
> Comments welcome—I have quite a few issues to resolve, but now I’ve at
> least got the proposals out in a public place for inspection :-)

My high-level feedback is that both would benefit from a more explicit 
requirements list, perhaps explaining some of the shortcomings of 
Mutation Events for that one.

* watchSelector's SelectorElementCallback should be a list... there may 
be a DOM mutation that simultaneously fits the match criteria (e.g., 
inserting or removing large fragments)
* Combine both methods into one?
* notifyOnMatch is confusingly named... and could be a third value, "both"
* make some ARIA examples (might help test fulfillment of use cases)

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Received on Wednesday, 2 December 2009 19:02:28 UTC