Bundled jQuery UI seems to be missing some css definitions in Elgg 1.8.1

I'd like to use some jQuery UI widgets, namely tabs and progressbar, in a specific plugin view. I had a look at the bundled UI javascript code, and it contained all these plugins - so far so good. However when I called the tabs and progress bar initialization on certain nodes, they did not seem to render properly - as if the javascript did not execute.

Bit of investigation in Firebug showed that the js part executed just fine - for example the progressbar node got populated with the following css classes: ui-progressbar ui-widget ui-widget-content ui-corner-all. However none of these classes are defined in the default css views. On the other hand, some UI classes are defined, e.g. autocomplete and datepicker classes.

So what's the deal here? Shall I got to the jQuery UI Theme page, download my own theme, and register and load the css when necessary? Even so, I don't see why certain UI widgets' and plugins' source would be included, but not the associated css classes.

  • Andras, I believe the core team decided not to include the jquery ui css libraries at all (it is a indeed quite heavy on load times). I believe only some of the ui styles made it to Elgg's css, e.g. datepicker.

    I think you will need to download and register your own css.

  • @Ismayil I see, and I have no problem with that at all, but in that case the js includes should be consistent with the css includes. Otherwise it's just a bunch of unusable javascript which adds to the overhead.

  • I agree. From what I understand it is an intention to build a jquery ui theme from within elgg without using themeroller. So far, I think the ui is used in datepicker only and that has been styled. I think the tabs will eventually be included as well.

  • I don't we ever reached a solution on this. Here are the issues:

    1. jQueryUI JavaScript and CSS are really big

    2. Curverider included a custom jQueryUI in Elgg releases 1.0-1.7 for JavaScript and no CSS

    3. Curverider included a full jQueryUI JavaScript file in an early version of 1.8 and custom CSS for the datepicker

    4. We cleaned up the datepicker CSS and added autocomplete CSS, but other than than we did not change what Curverider had done

    5. We were hesitant to include a full theme because so little of jQuery UI is used by core Elgg (just datepicker and autocomplete plus some behaviors for widgets).

    6. We were hesitant to include a custom jQueryUI JavaScript package because we thought there would be problems with some plugins wanting features x and y while other plugins wanting y and z. They would all override the default Elgg jQueryUI JavaScript include and the plugin that loaded last would win. Instead we loaded the whole thing so that plugins can use any feature, but they have to include the relevant CSS.

    I suppose one solution is to include the entire jQueryUI JavaScript but break a CSS theme into component views. Plugins could then include the components that they need.

    I'm definitely open to suggestions on this!

  • I think it makes sense to include the entire jQueryUI js library so that everything is available.  If the weight of the css is the issue, the css could be broken down and registered individually in the core, so that devs just have to load what they need.

     

    So for Andras' example, progressbar javascript exists already, so that's set up.  He would just have to include

    elgg_load_css('progressbar');

    to include the relevant css, which was previously registered in the core.

    This would give devs all of the classes they need, without having to supply their own css files which in many cases may be clones.  The core then has all of the javascript/css necessary, the tradeoff then is the weight of the css vs. developers typing 1 line of code.

  • Cash, thanks for explaining, I missed the issue you outlined under point 6.

    Following up on Matt's suggestion for custom loading css, I just checked the file sizes in a full-featured UI 1.8.16, the compressed javascript is a heavy 206KB (there is slight difference against the Elgg bundled minified js which is 198KB - not sure why), while the css is 33KB. Unless images are preloaded (I don't think so), the css represents roughly 1/6th of the javascript code in volume. I'm not sure that justifies keeping a single monolithic javascript file and slicing up the css code.

  • Good point. So it looks like the options are

    1. Include full packages of both

    2. Chop up the JavaScript and include the full CSS

    3. Chop up both the JavaScript and the CSS

    If an Elgg site switched to using Google's cdn for jqueryui, it is likely that visitors already visited a site with it and have it loaded.

    Should we just load the whole thing and sites that care about performance have the option of loading their own slimmer down version or switching to a CDN?

  • Should we just load the whole thing and sites that care about performance have the option of loading their own slimmer down version or switching to a CDN?

    I would say yes.

  • >> Should we just load the whole thing and sites that
    >> care about performance have the option of loading
    >> their own slimmer down version or switching to a CDN?

    > I would say yes.

    second that.

    i have a lot of cons too.. but all in all i think the 206kb (maybe) loaded when a user visits a site for the first time is nothing compared to the ui features gained.

  • Some points to keep in mind:

    1. There was a reason you built the entire register_js and load_js functionality

    2. Only 2 views are currently using jQuery UI

    3. We have just thrown out jquery.forms out of the head

    4. Milestone for 1.9 states "Performance"

    My preference would be to chop everything up, both js and css, and make it available to developers to load. I would really like to see out-of-the-box Elgg as lightweight as possible. 

    Core js + core css + core sprites + jquery + jquery ui + all the plugin js = very slow pages.

    Let's make it as modular as possible.