Hi Waldemar, Thanks for putting so much thought into this issue, and outlining these options in detail. However, I am not convinced that this something Django core should be concerned with. I think we need to maintain a clearer conceptual separation between the various layers of functionality here.
As I read it, your option 4 means putting URLs into CSS files that will not resolve correctly if static files are served directly, unmodified, from their source locations (after being collected from apps) under STATICFILES_URL (because the URLs you give don't begin with a slash, so they will be interpreted as relative to the current location; and if they did begin with a slash, that would break anytime STATICFILES_URL is not a path-less domain). In other words, you are proposing to write CSS files that _depend_ on being run through some kind of combiner/compressor/filter that will intelligently rewrite all their URLs relative to STATICFILES_URL. As a proposal for a "standard," this is a non-starter for several reasons: 1. Not all projects want or need to combine/compress their media at all, and there is no reason they should have to run their CSS through a URL-rewriting filter. 2. Even in projects that do combine/compress media, there are good reasons to want to serve the individual files directly in development (to aid in front-end debugging), and only do the combining/compressing step on deployment to staging/production. 3. Designers and front-end developers working on Django projects should not have to learn some odd way of linking in their CSS, that appears to be wrong according to everything they know about how things usually work. The links they write should make sense to them, not just to some Python developer who invented a new "standard" for them. 4. Django does not provide any built-in tools to combine, compress, or rewrite links in media, so it is certainly not going to adopt a "standard" that requires the use of such a tool. In other words, the only reason a "standard" would even be needed here is because you want to establish a new standard which makes the source CSS files unusable in the absence of a filter which implements the standard! I think the problem here is a desire to conflate multiple issues which are clearer when considered separately. To wit: 1. Links in static files should be written in such a way they work as- is, without knowing what root URL they will be served under (this means relative internal links). 2. Any third-party tool that combines/compresses CSS should be able to take working input files and generate working output files, handling whatever internal links it finds correctly. Both of these seem almost so obvious that they shouldn't require stating at all; you'll also note that they keep the question of internal linkage neatly separated from the presence or absence of a hypothetical compressor/combiner. The only argument you present against this approach is that it's problematic for Sass; considering all of my projects use Sass, I disagree. It simply requires the Sass author to understand the tool they are using and know how imports and paths work (or use a Sass framework such as Compass, which already handles the problem neatly). This is the nature of Sass, is second-nature to any experienced Sass author, and is in no way specific to Django; there's no reason for Django to be providing a solution for it. Carl -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
