The new layout of /resources/css introduced in r3018

[papandreou]

There's no doubt that the division into structural and visual css files makes a lot of sense, but it has a serious drawback for my build system because the background-image url()s in the stylesheets are wrong when the source css files are included directly, ie. when not simply using /resources/css/ext-all.css.

Here's an example from /resources/css/visual/button.css:

.x-btn-tl, .x-btn-tr, .x-btn-tc, .x-btn-ml, .x-btn-mr, .x-btn-mc, .x-btn-bl, .x-btn-br, .x-btn-bc{
background-image:url(../images/default/button/btn.gif);
}

Since url()s in css files are relative to the location of the stylesheet, this resolves to <ext dir>/resources/css/images/button/btn.gif, which is obviously wrong (should be /resources/images/...). Of course it works when everything is naively concatenated into <ext dir>/resources/css/ext-all.css, but in my opinion that's not good enough for at least two reasons:

1) Custom build systems that rewrite url()s in css files are going to have problems.
2) It's just good sense to have things work when the css files are used directly, for instance during development.

I propose that you either revert to the old /resources/css layout or make your build system powerful enough to rewrite url()s when the bundles are created. It's not that hard -- the css files are mostly free of hacks and parse cleanly.

Best regards,
Papandreou

[jsakalos]

There is one more possibility, to create a link to images directory at the proper directory tree level so that ../images in css refers to the link.

[papandreou]

Yeah, that would be a good workaround for the current layout. I'd still prefer to have the underlying problem solved, though, so that it doesn't break each time the layout changes, for instance if more levels of subdirectories were added. I also prefer not to have any local modifications to my ext checkout, but maybe that's just me :)

Best regards,
Papandreou

[jsakalos]

You see, the first "modification" is to include individual files - I also do that for development purposes. The link is the easiest to do and you can have it in seconds. On the other hand, Ext devel team has to evaluate your request, find a solution and implement it. That can take days or can never happen if they decide against it.

[papandreou]

I realize that -- this thread is just meant to raise the issue, because it seems to me that a wrong decision was made. I already had an ugly workaround when I started the thread, so I can still get the job done (a preprocessor that prepends '../' if the file doesn't exist). Your symlink idea is quite a bit better. Don't think that I don't appreciate it :)

Best regards,
Papandreou

[jsakalos]

Very good. Do you want me to move this thread to Feature Requests?

[papandreou]

Yes, please. I don't know why I didn't think of posting there in the first place. Thanks!

Best regards,
Papandreou

[jsakalos]

Moved.

[evant]

I don't think it's such a big problem because a majority of users will just use ext-all in full. Having said that, it is a pain to have to modify the urls, another option might be to have them all in the same folder and suffix the visual files with -visual.