[wp-trac] [WordPress Trac] #23285: Implement an AMD JavaScript loader in WordPress

[WordPress Trac]

#23285: Implement an AMD JavaScript loader in WordPress
-------------------------------+------------------------------
 Reporter:  auniquename        |       Owner:
     Type:  feature request    |      Status:  new
 Priority:  normal             |   Milestone:  Awaiting Review
Component:  General            |     Version:
 Severity:  normal             |  Resolution:
 Keywords:  reporter-feedback  |
-------------------------------+------------------------------

Comment (by auniquename):

 @scribu - Roger. I've got that now. Though I will use the solution
 outlined later in that ticket. WordPress does not necessarily need to use
 AMD to implement multiple js lib versions dependencies, but why re-invent
 the wheel? Alternatively, if plugin authors are encouraged to bundle and
 isolate jQuery themselves as discussed in that other ticket, then why make
 the jQuery used internally by WordPress available to plugin authors as it
 is now at all? And why is the solution I have arrived at with the
 assistance here not documented? (I know, it is in the jQuery docs, but the
 WordPress codex leads one to register their scripts with dependencies on
 the jQuery included with WordPress)

 @wonderboymusic - Basically, it comes down to using multiple fully css
 scoped jQuery UI themes on a single page that will continue to work across
 at least a few releases of WordPress and jQuery. (If called for, depending
 on how the user sets the plugin options, and without breaking any other
 plugins or native WordPress functionality.) I am not so much concerned
 with what happens in admin as on the front end. I now have a way to make
 WordPress do it by isolating my jQuery and its plugins as discussed (but
 this is not the standard or documented way to use jQuery in WordPress).
 Currently the challenge that I face now that I can reliably isolate jQuery
 and its plugins in WordPress is the failings of jQuery UI itself. When you
 fully css scope a theme (every single css selector, not just the ones they
 scope in the themeroller - to preserve a theme behaviour across mutliple
 jQuery UI versions without collision with other jQuery UI themes from
 earlier or later versions) - you soon discover that many of the jQuery UI
 functions do not really take into account a css scoped theme at all (even
 a partially scoped one as the themeroller does).

 What happens is that things like overlays, and element clones used for
 animations and effects fall out of the css scope by being appended to
 elements (usually body) outside oyour defined css scope - and one cannot
 apply their jQuery UI scoping class to the body of a document without
 potentially affecting jQuery UI themes elements added before or after the
 ones you are working with.

 Hopefully that fills in some of the blanks for you. Right now my issue is
 with overlays (I have my own hack for that and it has been reported in the
 jQuery bug tracker), and with the explode effect falling out of theme
 scope, which has not been reported, and I seem to be unable to register on
 their bug tracker all names no matter how unique (even tried GUIDs) are
 reported as taken. Grrr. So I have registered on their forums to report
 some of this stuff.

 The reason I wanted to use jQuery UI 1.10.0 is that it corrects the dialog
 falling out of scope by allowing it to be appended to the body without a
 hack that adversely affects the body dimensions. i.e. this:
 http://stackoverflow.com/questions/2199888/custom-css-scope-jquery-ui-
 dialog-themes
 is no longer required.

 However now there is the overlay, explode and now button focus and sprite
 issues with the themes.

 So neither product is really ready for what I want to make them do, but it
 is so close... I can taste it.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/23285#comment:6>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software