CSS Files vs. #style

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

CSS Files vs. #style

Nevin Pratt
I've read previous posts (by Avi as well as others) saying that they
typically didn't implement the method #style on a component, but instead
typically used #updateRoot: and #resourceUrl: to invoke external CSS
files.  For example, Philippe Marschall wrote the following example of
use (on 7/27/06):

   MyRootComponent >> #updateRoot: anHtmlRoot
       super updateRoot: anHtmlRoot.
       anHtmlRoot linkToStyle: 'wherever/style.css'.
       anHtmlRoot linkToScript: 'wherever/script.js'.

And, of course, this works fine, and presumably allows your web
designers to easily change the CSS layout.

But then, so did the #style method.  And, it also is easy for your web
designers to change the CSS layout-- by toggling the halos and entering
the CSS code in the browser (via the style editor, which is the little
pencil icon when you turn halos on).  And, when they do it this way, it
compiles the CSS code into the #style method of the component, thus
allowing you to carry the styles around with your image.  And that
reduces dependencies, because it keeps everything in the image, instead
of splitting it out into external files.

So, why are folks avoiding the #style method?  What am I missing?

Nevin

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: CSS Files vs. #style

Boris Popov, DeepCove Labs (SNN)
Re: [Seaside] CSS Files vs. #style

Mostly because I never let seaside serve static resources in production but rather detach them from the image for deployment and use apache or s3. I wrote a custom solution for this early on, but I believe FileLibrary will do that for you now. Also, our designer doesn't use the application a whole lot, but rather works with either a new page he writes and styles from scratch, or more commonly now saves the generated one to use as a starting point for improvement. That let's him use the tools he's comfortable with as far as html and css editing goes, as very often code needs to change together with css to achieve certain things, new images added, changed, removed etc.. I will then take the updated styles plus resources, load them up, implement required html changes and voila! Embedded css editing maybe was useful before firebug came out as it let you change css on the fly, but let's face it, firebug does circles around the thing now :)

Cheers!

-Boris
(Sent from a BlackBerry)

----- Original Message -----
From: [hidden email] <[hidden email]>
To: [hidden email] <[hidden email]>
Sent: Sat May 05 18:14:08 2007
Subject: [Seaside] CSS Files vs. #style

I've read previous posts (by Avi as well as others) saying that they
typically didn't implement the method #style on a component, but instead
typically used #updateRoot: and #resourceUrl: to invoke external CSS
files.  For example, Philippe Marschall wrote the following example of
use (on 7/27/06):

   MyRootComponent >> #updateRoot: anHtmlRoot
       super updateRoot: anHtmlRoot.
       anHtmlRoot linkToStyle: 'wherever/style.css'.
       anHtmlRoot linkToScript: 'wherever/script.js'.

And, of course, this works fine, and presumably allows your web
designers to easily change the CSS layout.

But then, so did the #style method.  And, it also is easy for your web
designers to change the CSS layout-- by toggling the halos and entering
the CSS code in the browser (via the style editor, which is the little
pencil icon when you turn halos on).  And, when they do it this way, it
compiles the CSS code into the #style method of the component, thus
allowing you to carry the styles around with your image.  And that
reduces dependencies, because it keeps everything in the image, instead
of splitting it out into external files.

So, why are folks avoiding the #style method?  What am I missing?

Nevin

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside


_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside