Re: [Radiant] Styles n Scripts feature request
On Jul 15, 2008, at 12:28 PM, Tim Gossett wrote: That said, I think I like Sass much more than both Haml and regular CSS (I still haven't used it enough to have a firm conclusion). It's much simpler than Haml and doesn't have to handle things like running ruby in the middle of your template. And it encourages some very good CSS behaviors. Worth trying for sure. Here, here. SASS actually provides more control than plain old CSS. Here's something I did with SASS when on a golden-ratio trip: SASS really is better than regular CSS in absolutely every way. Really. You don't give up any control at all, and you gain so much. The constants and math stuff is just icing on the cake. The real meat is the nesting of selectors. This is how CSS should have worked. Once you get used to SASS, there is no possible way you can tolerate working with plain CSS for any large layout job ever again. SASS for president! ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Styles n Scripts feature request
On Tue, Jul 15, 2008 at 12:43 AM, Chris Parrish [EMAIL PROTECTED] wrote: Jim Gay wrote: I haven't yet looked at it. I haven't used Sass much. I like some of the features that it adds, but it removes some control and I'm not ready to tackle it yet since I've run into trouble with Haml and the Help extension (it has some lines that are completely ignored by Haml... but they shouldn't be). I too have struggled with Haml. It has some very nice benefits but can also be a real pain too. I've had the same experience with Markaby... I'd love to use it, but there are too many hurdles. ERB usually ends up being s much easier (and there's no processing cost with ERB). That said, I think I like Sass much more than both Haml and regular CSS (I still haven't used it enough to have a firm conclusion). It's much simpler than Haml and doesn't have to handle things like running ruby in the middle of your template. And it encourages some very good CSS behaviors. Worth trying for sure. Here, here. SASS actually provides more control than plain old CSS. Here's something I did with SASS when on a golden-ratio trip: // The golden ratio is (1 + sqrt(5)) / 2 // sqrt(5) ~= 2.23606798 !phi = 3.23606798 / 2 !phiinv = 1 / !phi !phiinvcom = 1 - !phiinv !fnt_size = 12 !line_height = !fnt_size * !phi !full_width = 960 !sidebar_width = !full_width * !phiinvcom !padding = 12 !content_width = !full_width - !sidebar_width - !padding*2 So later on in my Simply Awesome StyleSheet, I have #container :margin 0 auto :width = !full_width + px :position relative :display block hr :display none #content :padding :top = !padding * 2 + px :right = !padding + px :bottom = !padding + px :left = !padding + px :width = !content_width + px So the entire layout can scale by changing one variable. Neat, huh? -- Tim ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Styles n Scripts feature request
You can solve item #2 using r:stylesheet and multiple stylesheet
files. Just like you can use the r:javascript to reference multiple
libraries and create a one-script-to-rule-them-all master to just serve
up one library file, you can also incorporate many stylesheets into one
master.
So you could create:
main.css
main-colors.css
where main.css includes:
... some stylesheet definitions...
r:stylesheet name=main-colors.css /
... the rest of your style definitions ...
then you'd just stick all your colors in... wait for it... main-colors.css
Of course what's missing there is the neat UI grouping that parts tabs
afford. But what's also missing is the hassle of building, testing, and
maintaining a parts structure (abstract_controller really keen on
managing has-many sub-models and I have to build my own new table
structure since Parts isn't really designed for subclassing).
Originally, I debated page parts but decided that, since the audience
was more technical, making them mentally keep track of several separate
stylesheets that aren't conveniently visible via tabs seemed acceptable
and worth the trade off (after all if they can keep track of CSS rules
and their impact on the page, they can juggle 3 or 4 files).
Now, having said all that. Are you using my Sass filter plugin? If
not, I might consider it. Sass has a notation for setting document-wide
constants so you could, say, declare all your color info at the very top
and maybe get by with only one stylesheet. From the Sass documentation:
!main_color = #00ff00
#main
:color = !main_color
:p
:background-color = !main_color
:color #00
More at: http://haml.hamptoncatlin.com/docs/rdoc/classes/Sass.html
I'll respond to item #1 in a separate email.
-Chris
Jim Gay wrote:
I was working to move my page based stylesheets into the
styles_n_scripts extension when I ran into a problem.
I'd love to see 2 features of doing stylesheets in pages:
1) support for radius tags from pages
2) page parts (or something like it)
I have one client that is managing the design of the site, but we're
handling the HTML/CSS. So in the stylesheet, I use something like
#header {
background: url('r:find url=/r:attachment:url name=logo.png
/') no-repeat left top;
}
This allows them to use page_attachments to change images specified in
the stylesheet without needing to muck about in CSS.
Less importantly, I break out the stylesheet into different parts to
make it easier to manage, but also easier for the client to update.
For example, I'll add r:content part=colors / to the body which is
the part of the stylesheet (page) where all of the colors are
specified. The client can go in and go directly to the colors part and
knows enough to edit the part for particular items in the site. I'll
only put the color information in the colors part so that the extra
CSS declarations don't confuse them.
The reason I found this is because of this
http://dev.rubyonrails.org/ticket/10886 which is fixed in the version
of Rails later than what is currently in Radiant. But my form data was
apparently too big to be saved properly by Rails.
___
Radiant mailing list
Post: Radiant@radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
___
Radiant mailing list
Post: Radiant@radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Styles n Scripts feature request
On Jul 15, 2008, at 12:17 AM, Chris Parrish wrote: You can solve item #2 using r:stylesheet and multiple stylesheet files. Just like you can use the r:javascript to reference multiple libraries and create a one-script-to-rule-them-all master to just serve up one library file, you can also incorporate many stylesheets into one master. So you could create: main.css main-colors.css where main.css includes: ... some stylesheet definitions... r:stylesheet name=main-colors.css / ... the rest of your style definitions ... then you'd just stick all your colors in... wait for it... main- colors.css Sorry for the noise. I didn't realize that this was in there. Of course what's missing there is the neat UI grouping that parts tabs afford. But what's also missing is the hassle of building, testing, and maintaining a parts structure (abstract_controller really keen on managing has-many sub-models and I have to build my own new table structure since Parts isn't really designed for subclassing). Originally, I debated page parts but decided that, since the audience was more technical, making them mentally keep track of several separate stylesheets that aren't conveniently visible via tabs seemed acceptable and worth the trade off (after all if they can keep track of CSS rules and their impact on the page, they can juggle 3 or 4 files). I agree. It's not really worth the effort and the existing tags which I overlooked are just fine. Now, having said all that. Are you using my Sass filter plugin? If not, I might consider it. Sass has a notation for setting document- wide constants so you could, say, declare all your color info at the very top and maybe get by with only one stylesheet. From the Sass documentation: I haven't yet looked at it. I haven't used Sass much. I like some of the features that it adds, but it removes some control and I'm not ready to tackle it yet since I've run into trouble with Haml and the Help extension (it has some lines that are completely ignored by Haml... but they shouldn't be). I'll respond to item #1 in a separate email. Thanks! ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Styles n Scripts feature request
Hmm, on re-reading my last answer, I don't like to be so can't-do. So
here's a solution for you...
As I mentioned, your needs involve two static tags. (If used in a
stylesheet, the only way they'd change the stylesheet's output would be
to edit them in that stylesheet. In other words, the stylesheet's
updated_at date would be the true LAST-MODIFIED date for the served up
file).
So while I don't want to start adding these things into SnS, you could
write a simple extension that add these tags yourself. It should be
really simple since I modeled everything after how Radiant handles
creating page tags.
Something like:
sns_custom_tags_extension/lib/text_asset_tags.rb
module TextAssetTags
include Radiant::Taggable
class TagError StandardError; end
desc %{your tag's description here}
tag('url') do |tag|
copy/paste/massage the page's url tag into this tag
end
... same with r:attachment:url ...
end
Bonus points if you figure out a slick way to keep things DRY by reusing
the code from the pages tag definitions.
-Chris
Chris Parrish wrote:
Ok, item #1. Unfortunately, this is hairier than you'd think:
1. Pages have an entirely different context than stylesheets and
their tags don't exactly snap in (what exactly is the parent of a
stylesheet? the slug?) Basically, I'd have to rebuild these tags
for stylesheet/javascript consumption.
2. I built a whiz-bang dependency observer that tracks relationships
for my r:stylesheet andr:javascript tags so that I could
create a better caching mechanism for these files. This caching
was a core goal of this extension. If I go adding page tags, I
risk breaking the caching (some tags, like the ones you've
specified, are really static tags -- the page they're in only
changes if the tag is changed somehow -- but many of the radius
tags are dynamic) Radiant doesn't know which tags are which and,
so, has to assume the worst -- hence Radiant's 5-minute cache.
So, it's not that it isn't doable, it's just that I want to approach
this very cautiously. I figure that someone's eventually going to
come up with a case that will be so necessary as to make me change
this one but man I'm gonna go kicking and screaming ;-)
-Chris
Jim Gay wrote:
I was working to move my page based stylesheets into the
styles_n_scripts extension when I ran into a problem.
I'd love to see 2 features of doing stylesheets in pages:
1) support for radius tags from pages
2) page parts (or something like it)
I have one client that is managing the design of the site, but we're
handling the HTML/CSS. So in the stylesheet, I use something like
#header {
background: url('r:find url=/r:attachment:url name=logo.png
/') no-repeat left top;
}
This allows them to use page_attachments to change images specified
in the stylesheet without needing to muck about in CSS.
Less importantly, I break out the stylesheet into different parts to
make it easier to manage, but also easier for the client to update.
For example, I'll add r:content part=colors / to the body which
is the part of the stylesheet (page) where all of the colors are
specified. The client can go in and go directly to the colors part
and knows enough to edit the part for particular items in the site.
I'll only put the color information in the colors part so that the
extra CSS declarations don't confuse them.
The reason I found this is because of this
http://dev.rubyonrails.org/ticket/10886 which is fixed in the version
of Rails later than what is currently in Radiant. But my form data
was apparently too big to be saved properly by Rails.
___
Radiant mailing list
Post: Radiant@radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
___
Radiant mailing list
Post: Radiant@radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
___
Radiant mailing list
Post: Radiant@radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
