features useful for jQuery, annotated

[Paul Irish]

In my first email to jquery-standards, I mentioned Resig's presentation to some W3C folks 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 at computed styles)

       FF landed this recently (http://bugzil.la/185236) , webkit's still waiting on it (http://webk.it/38995)

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 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 on http://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 between the CSS and DOM working groups.

     AFAIK, Tab's revised CSSOM helps here.

Anne van Kesteren's draft, actually.  It needs more work, but it's the direction we want to go.

http://lists.w3.org/Archives/Public/www-style/2010Feb/0004.html http://dev.w3.org/csswg/cssom/#resolved-values  

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 animations

More detail why?

Corey just posted detail on this one, actually: https://github.com/jquery/standards/issues/16 

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 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 this two months ago. Has been in Webkit for a bit, I think. Specced 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

You should be able to check elem.ownerDocument, right?

[Paul Irish]

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.

Wild. Andy E wrote about this exact application of weakmaps today:

http://whattheheadsaid.com/2011/10/es6-a-quick-look-at-weak-maps

[Maxim Kazantsev]

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

>    at computed styles)
>
>        FF landed this recently (http://bugzil.la/185236) , webkit's still
> waiting on it (http://webk.it/38995)
>

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

>    between the CSS and DOM working groups.
>
>      AFAIK, Tab's revised CSSOM helps here.
> Anne van Kesteren's draft, actually.  It needs more work, but it's
> the direction we want to go.http://lists.w3.org/Archives/Public/www-style/2010Feb/0004.htmlhttp://dev.w3.org/csswg/cssom/#resolved-values
>

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

>    animations
>
> More detail why?
> Corey just posted detail on this one, actually:https://github.com/jquery/standards/issues/16
>

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

[Jake Verbaten]

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 

Yes HTML String -> DocumentFragment would be awesome. This will solve a lot of use cases for templating engines. 

However having a magical method that just creates dom nodes from HTML is waiting to be abused. I'm always worried adding such methods encourages people to write spaghetti code with in-line HTML everywhere in their javascript.

 

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

You can already remove individual callbacks. It doesn't make sense to trigger specific callbacks to me. It does make sense to be able to clone event listeners. What does make  sense is a cloneNode method that clones event listeners.

Yes access to event listeners can be useful but we do need solid use-cases.

 

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.

I'd argue WeakMap solves all of the use cases for this. 

 

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?

Maybe the default order of NodeLists should be more sensible instead?

 

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

You should be able to check elem.ownerDocument, right?

Indeed, Node.ownerDocument.contentType should solve this

 

[Rick Waldron]

Get out of my head, Paul! But seriously, this list is great, the WeakMap id'ing is tight. 

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

This is quite nice to read, considering the recent "proposal" on public-webapps: http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0507.html

/Rick 

[Paul Irish]

On Tue, Nov 1, 2011 at 7:44 AM, Mike Taylor <mike...@gmail.com> wrote:

Are these discussions going to happen elsewhere (preferably somewhere with a public archive) with other browser vendors?

Mike, could you help raise some of them on public-webapps? 

 

[Eli Morris-Heft]

I also just saw a message come across on this group (I think? All the mailing lists are starting to blend together...) about having document.createDocumentFragment(aStringOfHTML), which would do the trick here, I think.

Eli Morris-Heft