jQuery Forum

John,
How is jQuery UI going to be packaged? Can dimensions become part of
jQuery UI (in a way that makes it easy for people to get only that
file?)
Mike

I agree with Mike, bundling dimensions might be the best option for the moment in the interest of time.
~Sean
<div><span class="gmail_quote">On 9/8/07, <b class="gmail_sendername">Mike Alsup</b> <<a href="mailto:malsup@gmail.com">
malsup@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
John,
How is jQuery UI going to be packaged?  Can dimensions become part of
jQuery UI (in a way that makes it easy for people to get only that
file?)
Mike
On 9/8/07, John Resig <<a href="mailto:jeresig@gmail.com">jeresig@gmail.com</a>> wrote:
>
> Hi Everyone -
>
> I landed the Dimensions' .offset() method into core today, with a ton
> of help from Brandon. My primary justifications for doing so were:
> 1) To remove a common dependency for most plugins, including, most
> notably, jQuery UI.
> 2) To centralize the development of one of the most commonly used plugins.
>
> The file size hit is rather small (comparatively) - currently about +900b.
>
> Now, I integrated it into the build system and ran it against some
> jQuery UI demos, but then I hit a snag. A vast majority of jQuery UI
> plugins look for other methods that are included by Dimensions
> (.position() and .outerWidth(), for example) - thus removing the most
> important reason of including .offset() (since you'll have to include
> Dimensions, regardless).
>
> So, I'm stuck right now. I've backed it out of the build process, but
> it's still in jquery/src/. I'm not sure what the right step is, going
> forward. Ideally, I want to be able to run jQuery UI without the need
> for Dimensions (which is what I was hoping for with offset.js). Is
> this possible? and more importantly: Is this possible by tomorrow?
>
> Honestly, I'm not sure if it's possible - and if that's the case, I'd
> like to hold off on automatically including it in the builds until we
> can figure out how it would be best used. Any input on this matter
> would be greatly appreciated.
>
> --John
>
> >
>
</blockquote></div>

We're already planning on that - having it be included in the "master
file" that you download through the download builder.
So, in that respect, jQuery UI would be "solved" - but I guess I was
hoping to extend this beyond just jQuery UI, since a number of plugins
require dimensions (pretty much every "dhtml" plugin).
So, yep, simply continuing to include it in the builder is an obvious
solution - I was just hoping that we could shoot for better.
--John

If certain methods from 'dimensions.js' are used alot perhaps they
should also be in core?
Would it be costly in terms of size to include these methods?

> If certain methods from 'dimensions.js' are used alot perhaps they

John,

> If I had the option of using jQuery with or without the Dimensions Plugin,

- booger
functions that are commonly used in dimensions.js either need to be in
core or in dimensions.
functions that are not used very often can be moved into the client
plugins themselves
but i guess u know that already :s

> > If I had the option of using jQuery with or without the Dimensions Plugin,
> > I'd always use the version w/the Dimensions Plugin built in.
Yeah !
dimensions.js packed is up to 5Ko if I remember well. If it was me I
would include it in jQuery itself, if not, it should definitely be in
the core of jQuery UI.

>> > If I had the option of using jQuery with or without the Dimensions
>Plugin,
>> > I'd always use the version w/the Dimensions Plugin built in.
>
>Yeah !
>dimensions.js packed is up to 5Ko if I remember well. If it was me I
>would include it in jQuery itself, if not, it should definitely be in
>the core of jQuery UI.
I'd rather see it included with the core jQuery library. I'm in the boat of
people who don't mind seeing the library grow a little bit. To me anything
under 30K is acceptable. I also see the Dimensions plug-in as really crucial
for anything other than just basic DOM insertion.

Right now, we're looking at the difference between high 24k/low 25k
without and high 25k with .offset() included. (900 bytes, total) So
filesize is much less of an issue here.
Off-list, Brandon brought up an excellent point: "Honestly, we are the
only library that doesn't include such dimensions oriented methods in
the core."
Which is a really important point. I think we could see a definite
increase in interesting applications with the default inclusion of
this method.
And Yehuda brought up: "We don't have an offset method because it's in
a plugin, as per jquery's philosophy; our lack of bundling technology
is hurting us on that front"
I do, definitely, think that bundling (having a good downloader
application) is one piece of the puzzle - but it also adds a severe
level of complexity to the library - no longer is jQuery a
drop-dead-simple, everyone uses the same file, include.
Honestly, I don't think we'd be having this discussion if .offset()
wasn't already in a plugin - it would be the obvious choice to have it
be included, by default. It's such an essential piece of functionality
that its loss is a serious gap for the library. (loss in the sense of
being "not immediately available")
I've now added .offset() back into the default build with the hope
that the UI code (and other plugins) will be able to transition away
from it's .offset() to the new core .offset(). I no longer expect this
to happen this weekend, but it would be good to have this happen as
soon as possible, once the code arrives.
--John

As is often the case, there is a trade-off between the convenience of having functionality in a single file, and file size. I often don't need any ajax, but I'm happy to not have to deal with multiple files just to get it.
Personally, I really don't care for "download manager" package builder things. It seems like once you've built a few different versions of jQuery, you've ended up worse off than if you had just used one bigger version and let caching do its thing.
How would including all of dimensions in the core affect the filesize?
And while we're on the subject, how about the form plugin? What's another 8k? ;)
--Erik
<div><span class="gmail_quote">
On 9/8/07, <b class="gmail_sendername">John Resig</b> <<a href="mailto:jeresig@gmail.com">jeresig@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Right now, we're looking at the difference between high 24k/low 25k
without and high 25k with .offset() included. (900 bytes, total) So
filesize is much less of an issue here.
Off-list, Brandon brought up an excellent point: "Honestly, we are the
only library that doesn't include such dimensions oriented methods in
the core."
Which is a really important point. I think we could see a definite
increase in interesting applications with the default inclusion of
this method.
And Yehuda brought up: "We don't have an offset method because it's in
a plugin, as per jquery's philosophy; our lack of bundling technology
is hurting us on that front"
I do, definitely, think that bundling (having a good downloader
application) is one piece of the puzzle - but it also adds a severe
level of complexity to the library - no longer is jQuery a
drop-dead-simple, everyone uses the same file, include.
Honestly, I don't think we'd be having this discussion if .offset()
wasn't already in a plugin - it would be the obvious choice to have it
be included, by default. It's such an essential piece of functionality
that its loss is a serious gap for the library. (loss in the sense of
being "not immediately available")
I've now added .offset() back into the default build with the hope
that the UI code (and other plugins) will be able to transition away
from it's .offset() to the new core .offset(). I no longer expect this
to happen this weekend, but it would be good to have this happen as
soon as possible, once the code arrives.
--John
On 9/8/07, Dan G. Switzer, II <
<a href="mailto:dswitzer@pengoworks.com">dswitzer@pengoworks.com</a>> wrote:
>
> >> > If I had the option of using jQuery with or without the Dimensions
> >Plugin,
> >> > I'd always use the version w/the Dimensions Plugin built in.
> >
> >Yeah !
> >dimensions.js packed is up to 5Ko if I remember well. If it was me I
> >would include it in jQuery itself, if not, it should definitely be in
> >the core of jQuery UI.
>
> I'd rather see it included with the core jQuery library. I'm in the boat of
> people who don't mind seeing the library grow a little bit. To me anything
> under 30K is acceptable. I also see the Dimensions plug-in as really crucial
> for anything other than just basic DOM insertion.
>
>
> >
>
</blockquote></div>

> How would including all of dimensions in the core affect the filesize?
Including everything would be a serious hit - but just .offset() is
nominal - a mere 900 bytes.

John,
While not having to rely on the inclusion of the dimensions plugin would be optimal, I think getting jQuery v1.2 should be a higher priority. I'm of the opinion that unless we're willing to bite the bullet at this time and just include dimensions full tilt, its best to back out offset() from core and revisit this for a future release.
The need to include dimensions is such a minor requirement that I don't believe it to be an issue.
Rey...
<div><span class="gmail_quote">On 9/8/07, <b class="gmail_sendername">weepy</b> <
<a href="mailto:jonahfox@gmail.com">jonahfox@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
-  booger
functions that are commonly used in dimensions.js either need to be in
core or in dimensions.
functions that are not used very often can be moved into the client
plugins themselves
but i guess u know that already :s
On Sep 8, 4:54 pm, "John Resig" <<a href="mailto:jere...@gmail.com">jere...@gmail.com</a>> wrote:
> > If certain methods from 'dimensions.js'  are used alot perhaps they
> > should also be in core?
>
> That's what we're doing - the most commonly used method is .offset() -
> which is what we're including.
>
> > Would it be costly in terms of size to include these methods?
>
> Yes, anything beyond just .offset() would be too costly. (Although, we
> are looking to improve .height() and .width() based upon Dimensions'
> functionality)
>
> --John
<br

Hey John,
the offset method is the most often used method. When you look at the rest of dimensions, you can divide the functionality into two: the convenience methods (scrollTop/height/width and so on) and the methods that cannot easily be reconstructed.
I personally love position, it's new but *very* handy, and I think it would be quite easy to add (please investigate it). outerWidth and outerHeight can be easily reconstructed, but $(window).height() is another big one many many developers need.
There is a need for many methods of dimensions - otherwise, Brandon and me would have removed them if we noticed nobody uses them. If we can get the most important ones to work in the core, I can work around the easier ones with custom methods.
Paul
<div><span class="gmail_quote">On 9/8/07, <b class="gmail_sendername">John Resig</b> <<a href="mailto:jeresig@gmail.com">jeresig@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Everyone -
I landed the Dimensions' .offset() method into core today, with a ton
of help from Brandon. My primary justifications for doing so were:
1) To remove a common dependency for most plugins, including, most
notably, jQuery UI.
2) To centralize the development of one of the most commonly used plugins.
The file size hit is rather small (comparatively) - currently about +900b.
Now, I integrated it into the build system and ran it against some
jQuery UI demos, but then I hit a snag. A vast majority of jQuery UI
plugins look for other methods that are included by Dimensions
(.position() and .outerWidth(), for example) - thus removing the most
important reason of including .offset() (since you'll have to include
Dimensions, regardless).
So, I'm stuck right now. I've backed it out of the build process, but
it's still in jquery/src/. I'm not sure what the right step is, going
forward. Ideally, I want to be able to run jQuery UI without the need
for Dimensions (which is what I was hoping for with offset.js). Is
this possible? and more importantly: Is this possible by tomorrow?
Honestly, I'm not sure if it's possible - and if that's the case, I'd
like to hold off on automatically including it in the builds until we
can figure out how it would be best used. Any input on this matter
would be greatly appreciated.
--John
</blockquote></div>
<br clear="all">
--
--
Paul Bakaus

On Sep 8, 2007, at 8:49 PM, Dan G. Switzer, II