I think the patch issue is because you didn't use "git format-patch;" the problem is that it doesn't include various bits of metadata (commit date, author name, etc.).
On Mon, Mar 31, 2008 at 8:07 AM, Garry Hill <[EMAIL PROTECTED]> wrote: > > > 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 -~----------~----~----~----~------~----~------~--~---
