As of r579, multiline selectors are supported in Sass as long as all lines but the last end in a comma. Have fun!
- Nathan Geffy wrote: > I personally don't like using the | in HAML, I'll write a helper or a > stupidly long line if I am being lazy. Thank you for approving of the > SASS comma though, aids readability imo. > > I'll try and take a stab if I get a free moment but I've been slightly > retasked to C# (urgh) for a couple days. > > Geoff > > On Aug 8, 1:58 am, Nathan Weizenbaum <[EMAIL PROTECTED]> wrote: > >> What Hampton's saying is that we've decided to allow multiline >> selectors, but the comma won't be a generalized multiline character like >> the pipe is in Haml. Patches are welcomed; I'd use Max's patch, but I >> don't want to implement it as a preprocessor. I'll code it up sometime >> soon if no one else wants to. >> >> - Nathan >> >> Hampton wrote: >> >>> Because I'm unwilling to budge on the subject. >>> >>> Haml is focused on one-line structural tag elements. It forces good >>> behaviour. >>> >>> Nathan had to work hard to convince me to get this much into Sass. And >>> I'm still not a fan, because I think it throws off the readability of >>> sections of it. It messes with your mental-parser. But, alas I am OK >>> with commas. >>> >>> /me is an opinionated a-hole. >>> >>> -hampton. >>> >>> On 8/7/07, Evgeny <[EMAIL PROTECTED]> wrote: >>> >>>> The comma would be just like the pipe in Haml. >>>> Actually -- why won't Haml use a comma for line-gluing? Other than >>>> the reason Nathan wrote in his last blog post ... >>>> >>>> On 8/7/07, Geffy <[EMAIL PROTECTED]> wrote: >>>> >>>>> Wouldn't it just be needed to add the comma+newline as a line >>>>> continuation pair as all the rules have to be separated by a comma for >>>>> CSS to handle them properly. I would certainly use them as currently I >>>>> have my input[type=blah] and textarea selectors all on one line for >>>>> the same set of rules. >>>>> >>>>> When it comes to outputting the CSS its up to SASS if it stuffs them >>>>> all on one line or across several. >>>>> >>>>> Geoff >>>>> >>>>> On Aug 6, 9:14 am, "Richard Livsey" <[EMAIL PROTECTED]> wrote: >>>>> >>>>>> On 8/6/07, Nathan Weizenbaum <[EMAIL PROTECTED]> wrote: >>>>>> >>>>>>>> Currently, Sass will silently eat all but the last selector. Is >>>>>>>> there >>>>>>>> something I've missed? >>>>>>>> >>>>>>> I'm a little torn about this. It seems to me that if you have a CSS >>>>>>> selector that's getting so long it won't fit nicely on one line, the CSS >>>>>>> design needs refactoring. Like for Max's case, I think the proper way to >>>>>>> deal with that /isn't/ to have a huge selector that refers to every >>>>>>> active element; the proper design is to have an "active" class that is >>>>>>> applied to elements that need this style. >>>>>>> >>>>>> I've been doing this for years and it's an elegant solution which cuts >>>>>> down on redundant logic in the templates. In Rails apps I apply the >>>>>> controller name as the id, and the action as the class and so >>>>>> detecting the active links/sections is very simple in CSS. >>>>>> >>>>>>> I may be totally wrong, though, so I'll take an informal poll. Hamlites, >>>>>>> how often do you feel the need to have multiline selectors? >>>>>>> >>>>>> The only times I've run into this are for the cases already mentioned, >>>>>> highlighting active links and in resetting styles. It's only every now >>>>>> and again, but when it does happen it's unexpected and I do find >>>>>> myself wishing it would work as it does in standard CSS. >>>>>> >>>>>> -- >>>>>> Richard Livsey >>>>>> Head of Agile Development, CitySafehttp://citysafe.orghttp://livsey.org >>>>>> > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
