Paul, thanks a lot for the first meaningful message in this group.
I, personally, highly support an idea of access to event callbacks.
That's very painful now to keep a track of all the callbacks you set
on the element. I guess, it may be implemented as simple as hashmap -
it's definitely possible to created "named callbacks", let's call (or
name, sorry for such a pun) them so. That's a universal method to
access, trigger, remove and clone specific callbacks. And I really
don't understand why it hasn't been done so far.
On Nov 1, 12:25 pm, Paul Irish <
paul.ir...@gmail.com> wrote:
> In my first email<
https://groups.google.com/forum/#!topic/jquery-standards/0J2jYnAdyow>to
> jquery-standards, I mentioned Resig's presentation
> to some W3C folks <
http://www.slideshare.net/jeresig/jquery-and-the-w3c> a
> while back..
>
> Since then I circulated a few of those ideas within the webkit team at
> google and got some feedback.
>
> Below is a summary of John's feature ideas..
>
> - my own notes in blue..
> - assorted google webkit folks notes (paraphrased sometimes) in green...
>
> *HTML string -> DOM support*
>
> - No good way to do this now
> - Have to create a DOM element and use innerHTML
> - Clunky and quite slow
> - We want:
> - someMethod(“<b>stuff</b>”) ==> [ <b> ]
>
> Yehuda Katz thinks he has a working impl using
> createContextualFragment which offers 6x speed. :) It'd be nice to have a
> better API for it though. e.g. HTMLElement.fragmentFor() or
> fragment.innerHTML
>
> yehuda also said there is a proposal for createContextualFragment to not
> have to have a context to create a <tr>. etc.
>
> also relevant:
https://github.com/kriszyp/put-selector
>
> *Access to event callbacks*
>
> - We want to be able to remove individual callbacks
> - We want to be able to clone callbacks
> - We want to be able to trigger specific callbacks
> - All of this requires access to callbacks
>
> More detail on the use cases would be helpful
>
> *An event for when stylesheets load*
>
> - Right now we have an event for DOM loaded
> - And an event for window loaded
> - But no event for when all the stylesheets load (important for looking
> *Will an element fire an event?*
>
> - For example - if I have a <form> element I want to be able to ask it:
> - “Will you ever, natively, trigger a submit event?” (true)
> - If I ask a <div> if it will trigger a submit event, it will return
> false.
>
> More detail on the use cases would be helpful
>
> *Unique ID for DOM nodes*
>
> - We have to manage callbacks and data that we attach to DOM nodes
> - To do this we have to assign the nodes a unique ID
> - It’d be much better to have a property that took care of this for us
>
> Real maps and WeakMap should be able to solve the same use cases.
>
> *“Late Events”*
>
> - There is no way to ask the browser:
> - “Did an event [foo] already fire on this element?”
> - For example:
> - Did the load event already fire on window? Did the submit event
> already fire on this form? etc.
>
> My hope is that Deferred/Futures/Whatever-they're-called-this-week will do
> this for us. I'm [Alex Russell] working on a proposal to get these into
> DOM as a core type at which point we can start surface them whenever
> we need this sort of API.
>
> *Fast DOM mutation events*
>
> - I know this is being worked on right now (yay!)
> - A way to have fast DOM mutation events would be awesome
> - It could allow for some really slick restructuring of applications
> - And make it easier for us to possibly do caching
>
> Mutation observers<
http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1622.html>are
> currently being implemented in Webkit.
>
> *mouseenter/mouseleave*
>
> - Internet Explorer provides these events
> - They’re terribly useful (make it so that you don’t have to deal with
> event bubbling weirdness)
> - Should be a standard
>
> Dmitri Glazkov also was affirming we need it onhttp://
webk.it/18930
> OMG we need these so bad. mouse tracking is so painful. >_<
>
> *getComputedStyle*
>
> - A complete mess right now
> - There is no consensus over what results should be returned and when
> - There needs to be something declared here - probably a joint venture
> *isCSSAuto*
>
> - There is no way of determining if a CSS property is currently set to
> “auto”
> - This should be resolved, makes it much easier to do some types of
> *A way to sanely toggle visibility*
>
> - If we’re given an element that is display: none and we want to make it
> visible (display: block, perhaps)
> - It is very hard to determine what the right “visible” style should be
> - Especially if someone does:
> - div { display: none; }
> - Hint: It involves nasty use of iframes
>
> @hidden attribute answers this. We're
> looking<
http://bugs.jquery.com/ticket/10485> into
> implementing this in jQuery
>
> *contains() method*
>
> - We have compareDocumentPosition
> - This is OK but contains() is very easy to use (in IE)
> - Easy enough to implement, should be a standard
>
> FF just landed <
https://bugzilla.mozilla.org/show_bug.cgi?id=683852> this
> two months ago. Has been in Webkit for a bit, I think.
> Specced<
http://www.w3.org/TR/domcore/#dom-node-contains> in
> DOM4.
>
> *Better way of sorting nodes*
>
> - We have to use compareDocumentPosition now
> - This is very very slow
> - A numerical index property on nodes would be very useful (like in IE)
>
> Like a sort() method on NodeList maybe?
> *
> *
> *Is a node in an XML document*
>
> - A number of behaviors change when you’re in an XML document
> - (IDs no longer resolve, some properties may not exist - like
> innerHTML, etc.)
> - A way to determine if we’re working against an XML document would help