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 may be totally wrong, though, so I'll take an informal poll. Hamlites, how often do you feel the need to have multiline selectors? In what situations? Upon reflection, would it be better to abstract that into a separate class, and if not why not? I'm open to adding support for this if it would really be useful, but I have a hunch that this is one of those cases where it's better to make it more awkward so people are discouraged from doing it in the first place. - Nathan Mislav Marohnić wrote: > On 8/6/07, *Max Muermann* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > > Currently, Sass will silently eat all but the last selector. Is there > something I've missed? > > > Sass doesn't know these lines are related and treats each of them as > separate CSS blocks. It doesn't output the first few because it finds > them empty. This certainly is expected behavior, at least to me. > > Sass parser should be expanded to treat multiple lines with same > indentation ending with commas as a single selector. > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
