[css-d] Managing import rules
Hi all, here are my 2 cents on the subject: http://onwebdev.blogspot.com/2010/09/css-managing-import-rules.html HTH ^^ Gabriele Romanato http://www.css-zibaldone.com http://www.css-zibaldone.com/test/ (English) http://www.css-zibaldone.com/articles/ (English) http://onwebdev.blogspot.com/ (English) __ css-discuss [cs...@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Managing import rules
Gabriele, I don't understand : In a past project I used the following approach: @import "base.css"; @import "layout.css"; @import "typography.css"; @import "colors.css"; The server-side developer (who used Ruby) encountered several problems when trying to merge these files properly and in the correct order, Why was it his job (the server-side developer's) to "merge these files properly and in the correct order" ? Surely merging takes place in the browser, not server-side ? Philip Taylor __ css-discuss [cs...@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Managing import rules
On Sep 13, 2010, at 6:58 PM, Philip Taylor (Webmaster, Ret'd) wrote: > Gabriele, I don't understand : > >> In a past project I used the following approach: >> >> @import "base.css"; >> @import "layout.css"; >> @import "typography.css"; >> @import "colors.css"; >> >> The server-side developer (who used Ruby) encountered several problems when >> trying to merge these files properly and in the correct order, > > Why was it his job (the server-side developer's) to > "merge these files properly and in the correct order" ? > Surely merging takes place in the browser, not server-side ? Hmm, just guessing. The files are created by the designer, front-end coder as separate blocks - and maybe they are served that way on a test server prior to going live. To improve performance for the live site, they merged on the server into one file: less http requests for the end user, better minification, more efficient gzip compression (one file !) and so on - faster delivery to the end user, faster browser rendering. PS you do know that @import is a huge slowdown/bottleneck for IE <9 in particular the first @import blocks _all_ subsequent downloads; that is: the 2nd @import has to wait for the 1st to be downloaded etc. PS 2 I always find it cumbersome to work with multiple files like that and I think I've dropped using @import 3 years ago or so. Philippe --- Philippe Wittenbergh http://l-c-n.com/ __ css-discuss [cs...@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Managing import rules
On Mon, Sep 13, 2010 at 4:55 AM, Philippe Wittenbergh wrote: > > On Sep 13, 2010, at 6:58 PM, Philip Taylor (Webmaster, Ret'd) wrote: > >> Gabriele, I don't understand : >> >>> In a past project I used the following approach: >>> >>> @import "base.css"; >>> @import "layout.css"; >>> @import "typography.css"; >>> @import "colors.css"; >>> >>> The server-side developer (who used Ruby) encountered several problems when >>> trying to merge these files properly and in the correct order, >> >> Why was it his job (the server-side developer's) to >> "merge these files properly and in the correct order" ? >> Surely merging takes place in the browser, not server-side ? > > Hmm, just guessing. The files are created by the designer, front-end coder as > separate blocks - and maybe they are served that way on a test server prior > to going live. To improve performance for the live site, they merged on the > server into one file: less http requests for the end user, better > minification, more efficient gzip compression (one file !) and so on - faster > delivery to the end user, faster browser rendering. > > PS you do know that @import is a huge slowdown/bottleneck for IE <9 in > particular the first @import blocks _all_ subsequent downloads; that is: the > 2nd @import has to wait for the 1st to be downloaded etc. > PS 2 I always find it cumbersome to work with multiple files like that and I > think I've dropped using @import 3 years ago or so. > > Philippe My non use of @import comes from reading Steve Souders article "High Performance Web Sites blog -- don’t use @import [April 9, 2009 12:32 AM]" http://www.stevesouders.com/blog/2009/04/09/dont-use-import/ I suppose there may be cogent reasons to use @import in some situations. I have not encountered those in my limited experience. Would definitely be interested in examples if they turn up in this discussion. Regards, Claude Needham __ css-discuss [cs...@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
