On 31 Mar 2008, at 15:46, Nathan Weizenbaum wrote:
> > This has been brought up a couple of times before, and my feeling has > mostly been that using more CSS classes is better. But I'm gradually > being convinced that at least the issue isn't clear-cut enough to make > it worth forbidding rule inheritance (really mixins, in this case). So > I'll accept the patch, but it does need a little cleaning up first. Cool. I thought I'd need some love, but thought I'd wait until I knew it was even wanted. > First of all, the documentation should be moved from the commit > message > to files where the user can get at it. You should give an in-depth > discussion in the Sass reference in lib/sass.rb, and I think this is > useful enough to give an overview in the README. Will do. > > > "git am" doesn't seem to like the patch. "git format-patch > origin/master" with the latest git versions should work for that. Strange, I think it might be because of the instructions in the commit message, and the leading '-' on '-blueoutline'. I only grabbed a working copy of the repo an hour or two before sending the mail, so I don't think I'm out of date. Maybe my version of git is old (1.5.3.4)? > It looks like you've got a few debug outputs still in there. Yes, oops. Only saw them after sending the mail. > In general, I think a better way to go about this would be to avoid > adding new Node types entirely. An include definition is really just > an > array of Nodes; all you need to do when you encounter the include (in > build_tree; you'd probably want to return the include name as a string > from parse_tree) is to add all its children into an array and put that > in a hash (@includes or something) keyed by the include name. Then > when > you see an include directive, just insert all the associated > children as > children of the current node. This way you can avoid all sorts of > string-munging, since you're just dealing with tree nodes. That sounds like a plan, never feels right when you've got a list of 3 string manipulations in a row... > You should also have some error checking and tests for that in > SassEngineTest::EXCEPTION_MAP. Will do. > > > Thanks for the patch! Judging by the number of requests we've had for > this in the past, I imagine it'll be a pretty popular feature. Great. Glad to be of assistance. I'll get back when I've tidied things up. g > > > - Nathan > > Garry Hill wrote: >> Hi, >> >> I don't know if anyone's had this idea before but I've always thought >> that the one thing CSS needs to make it truly useful is some form of >> OO style extension mechanism, i.e. ".rule extends .other-rule" >> >> Since Sass is such a lovely CSS templating language, instead of >> writing my own I've just quickly hacked in a demo of this feature >> into >> the Sass source. Here's the patch on pastie.org: >> >> http://pastie.org/173146 >> >> Just to summarise the checkin message in that git patch, the idea is >> to create a way of defining includes inside Sass, much like ruby >> Modules. From the above pastie this is the syntax i've used: >> >> Any rule starting with a '-' is considered to be a declaration >> of an include (and generates no css on the render call). >> >> Then inside rules you start a line with the '+' character to include >> all the previously defined css declarations into the current context. >> >> E.g. '-blueoutline' starts an include block: >> >> -blueoutline >> :border >> :colour #000099 >> :width 3px >> :style dotted >> >> then '+blueoutline' will include that into your current selector: >> >> .freebie >> +blueoutline >> :font >> size 10px >> :padding 4px >> >> this should generate the following css: >> >> .freebie { >> border-color: #000099; >> border-width: 3px; >> border-style: dotted; >> font-size: 10px; >> padding: 4px; >> } >> >> Note that the 'blueoutline' code isn't output, though it optionally >> could be which might be useful. >> >> Anyway. The code I've used to get this feature working isn't >> particularly pretty, but it works. I would be willing to do more work >> to get it accepted as part of Sass, but I'm obviously not going to be >> able to do that alone. >> >> Would anyone be interested in this as a feature for Sass? I think it >> could be really powerful. Having variables is alright, but sometimes >> you want to include blocks of css into a selector. At the moment the >> only way to do this is to have multiple css classes on an element, >> but >> to me that's exposing too much of how your css is structured to the >> html. I have always wanted to be able to use single class names where >> ever possible and use some kind of inheritance in the css code itself >> to sort out repetitive styles. >> >> Thoughts welcome. >> >> Garry >> >> >>> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Haml" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/haml?hl=en -~----------~----~----~----~------~----~------~--~---
