Hi Waldemar, On Fri, Oct 29, 2010 at 4:19 PM, Waldemar Kornewald <wkornew...@gmail.com> wrote: > Hi Yuri, > > On Fri, Oct 29, 2010 at 10:37 AM, burc...@gmail.com <burc...@gmail.com> wrote: >> Hi Waldemar, >> >> On Fri, Oct 29, 2010 at 2:05 PM, Waldemar Kornewald >> <wkornew...@gmail.com> wrote: >>> Hi Carl, >>> >>>> 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: >> Do you agree with that "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"? > > I keep getting misunderstood, so I'll just simplify it. Forget all my > proposals. My primary proposal is: > "Let's have exactly one official standard, no matter if it's (2) or (4)." > What I don't want is (1), (2), and (4) living side-by-side as they do now. > > Do you agree that we should have a standard? Just a standard? Or standard for some problem related to django?
> If the answer is "yes", then which one should it be? > A: (4) for CSS and Sass/etc. > B: (2) for CSS, (4) for Sass/etc. > >> If you do, then you understand that you're trying to impose a standard >> for django users that is really unnecessary for them? >> You're free to allow such perversion with your app, but please don't >> try to put this into django. >> >> Why can't you read css files, transform their paths to absolute, merge >> files, and then write paths back as relative to merged files? > > That's method (2) which only works well for CSS. Django doesn't support Sass. Django doesn't support media compression. Why django should have this stupid standard? Related to your media compressor, i'd prefer not (2) or (4), i prefer this one I described above: 1. Your compressor starts after media is gathered with staticfiles into a single place. (All relative paths are valid at this moment!) 2. You read css files, transform their url paths to absolute, merge files, and then write back into user specified directory with paths rewritten as relative to merged files location. 3. If you're copying images, you can put images to whatever folder you want, but they should still work. Your compressor should make it possible to work after your compression if you'll just put that folder to media server. That way, every compressor is compatible with each other if their output is set to compressor-specific folder. This doesn't impose any standard of writing urls in their files on django users -- they do what they did before they have any staticfiles support. -- Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov, MSN: bu...@live.com -- 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.
