Handle CSS dependencies from JS comments

[rxaviers]

As Jörn stated on jquery/jquery-ui#1029 (comment), handle CSS dependencies as discussed.

We've discussed this at the team meeting in Amsterdam. None of the solutions that load CSS through AMD are in a stage where we're willing to commit to them. In other words, specifying CSS dependencies through AMD is far from a 'solved problem', so we're not going to adopt that approach until it works.

Since we want to share the download builder between UI and Mobile as soon as possible, we'll adopt Mobile's approach of specifying CSS dependencies in comments in JS files. We'll port the implementation from their build (or download builder). Mobile used this long enough and never ran into any major problems. Once a better solution emerges, we can delete those comments and adopt the new solution.

The jQuery Mobile download builder already implements this.

[jzaefferer]

Did you get started on this?

PS: I've added a link to the Mobile implementation in the ticket description

[rxaviers]

No, I haven't started. Thank you for the link.

[rxaviers]

First step is to define "Mobile's approach of specifying CSS dependencies in comments in JS files".

It's currently not documented. But, it's not hard to deduce by looking at mobile's source files that it's of the form: //>>css.[shortname]: [relative-path-from-current-file-to-css]

@gseguin (cc @uGoMobi) could you confirm please?

If the above is correct, ui/button.js comment-header would become this. @scottgonzalez @jzaefferer any suggestion?

[jzaefferer]

That looks wrong. "css.button" doesn't match anything currently used in mobile, where you've got "css.structure" and "css.theme". We can use the same pattern in UI, since we also separate structure and theme, and not all components need the theme (like the interactions).

[jzaefferer]

Also the paths are relative from their js root, not from each file, as you can see here: https://github.com/jquery/jquery-mobile/blob/master/js/widgets/panel.js - a path relative to this file would have to go two directories up.

[rxaviers]

That looks wrong. "css.button" doesn't match anything currently used in mobile, where you've got "css.structure" and "css.theme". We can use the same pattern in UI, since we also separate structure and theme, and not all components need the theme (like the interactions).

Ah! I've overlooked that. You are correct. So, it looks like mobile uses "structure" and "theme" as bundle names when building the package.

Also the paths are relative from their js root, not from each file, as you can see here: https://github.com/jquery/jquery-mobile/blob/master/js/widgets/panel.js - a patch relative to this file would have to go two directories up.

You are correct. Although, I think it should be considered a change to either: (a) relative to the current file, or (b) absolute to the project's root. Being relative to the js path seems hard to generalize.

[jzaefferer]

(b) absolute to the project's root.

This seems to me like the better approach, since you won't have to adjust this path when moving files around.

Assuming jQuery Mobile and UI have CSS files in the same folder, they could also keep the path when importing widgets like tabs, instead of having to adjust that to the local file structure.

[arschmitz]

The plan is for mobile to change file structure to match so this sounds good to me

[gseguin]

Shouldn't it be relative to the AMD baseUrl config?

[rxaviers]

Why?

[gseguin]

To be consistent with the AMD modules. I don't have a strong opinion about it, that just seems like another viable alternative.

[rxaviers]

I'm confused. Because on define(), relative paths are relative to the current file.

Anyway, I am just spotting a place that could be improved in my opinion. But, I also don't have a strong opinion about it.

[rxaviers]

@gseguin, @jzaefferer can we import @gseguin's buildCssBundle() code? We'd have to do some tweaks to use the in-memory cached files, and to simplify some dependencies (eg. Project()) in terms of accommodating it to the existing DB environment. But, importing it would be definitely of a great value.