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 -~----------~----~----~----~------~----~------~--~---
