Ah true. Well I guess in some cases it would be different... but the challenge as you said is both figuring out when it's safe to move a selector... and when it's worth moving one.
On Wed, May 4, 2011 at 6:02 PM, Nathan Weizenbaum <nex...@gmail.com> wrote: > I think the duplication of selectors would make a fully property-centric > stylesheet much larger than a normally formatted one. > > One thing to consider when thinking about re-organizing stylesheets is that > the order of selectors can matter a great deal to the ultimate rendering of > the page. When we do get around to implementing selector optimizations, I > predict that the hardest part will be telling when it's safe to move a > selector from one point in the stylesheet to another. > > > On Wed, May 4, 2011 at 2:01 PM, Aaron Gibralter <aaron.gibral...@gmail.com > > wrote: > >> Ahh ok that totally makes sense (sticking to semantic classes). >> >> I guess the ideal case would be post-processing optimization... Hmm I >> wonder if in most cases a CSS file would be smaller if it was organized in >> "property-centric" manner. I.e. any one css property only appears once per >> stylesheet: >> >> #foo, .bar, .baz #boom .pop { >> font-size: 10px; >> } >> >> #bing, .pong, p, div a li { >> font-size: 11px; >> } >> >> etc... Or is that just craziness? >> >> >> On Wed, May 4, 2011 at 4:37 PM, Nathan Weizenbaum <nex...@gmail.com>wrote: >> >>> In general, we have the philosophy that @extend should be used when >>> there's a semantic relationship between the class being extended and the >>> class doing the extending, and mixins should be used when you just want to >>> apply styles. Using @extend just to apply the same box shadow styles to a >>> bunch of selectors violates this, and so it's not something we want to make >>> easier. I understand the worry about file size, but I think the right way to >>> manage that is either manual stylesheet curation or post-processing >>> optimizations, which is something we've long thought about adding but >>> haven't gotten around to yet. >>> >>> It's worth noting that the @top-level directive you mention wouldn't >>> actually do what you want it to. Each time the mixin you propose would be >>> mixed in, it would create a new top-level selector with the given >>> properties, rather than just @extending the old one. >>> >>> >>> On Wed, May 4, 2011 at 1:04 PM, Aaron Gibralter < >>> aaron.gibral...@gmail.com> wrote: >>> >>>> This is building off what I posted here: >>>> https://groups.google.com/d/topic/haml/2McvrcWhUjo/discussion >>>> >>>> Basically I'm using a lot of compass mixins like `box-shadow`. Now, >>>> let's say I want to repeatedly use: >>>> >>>> @include box-shadow(0 0 0 0.15); >>>> >>>> That will generate this in many places in my stylesheet: >>>> >>>> -moz-box-shadow: 0 0 5px rgba(0, 0, 0, 0.15); >>>> -webkit-box-shadow: 0 0 5px rgba(0, 0, 0, 0.15); >>>> -o-box-shadow: 0 0 5px rgba(0, 0, 0, 0.15); >>>> box-shadow: 0 0 5px rgba(0, 0, 0, 0.15); >>>> >>>> I end up having like 20 * those 4 lines: >>>> >>>> #my-div { >>>> -moz-box-shadow: 0 0 5px rgba(0, 0, 0, 0.15); >>>> -webkit-box-shadow: 0 0 5px rgba(0, 0, 0, 0.15); >>>> -o-box-shadow: 0 0 5px rgba(0, 0, 0, 0.15); >>>> box-shadow: 0 0 5px rgba(0, 0, 0, 0.15); >>>> } >>>> >>>> #my-div2 { >>>> -moz-box-shadow: 0 0 5px rgba(0, 0, 0, 0.15); >>>> -webkit-box-shadow: 0 0 5px rgba(0, 0, 0, 0.15); >>>> -o-box-shadow: 0 0 5px rgba(0, 0, 0, 0.15); >>>> box-shadow: 0 0 5px rgba(0, 0, 0, 0.15); >>>> } >>>> >>>> And so on... that's a whole lot of bloat in the rendered css! >>>> >>>> Of course, it's a whole lot more efficient to do: >>>> >>>> .box-shadow-0-0-0-015 { >>>> @include box-shadow(0 0 0 0.15); >>>> } >>>> >>>> And then wherever I need that box shadow: >>>> >>>> #my-div { >>>> @extend .box-shadow-0-0-0-015; >>>> } >>>> >>>> That ends up producing nicer css: >>>> >>>> .box-shadow-0-0-0-015, #my-div, ... 20 other selectors { >>>> -moz-box-shadow: 0 0 5px rgba(0, 0, 0, 0.15); >>>> -webkit-box-shadow: 0 0 5px rgba(0, 0, 0, 0.15); >>>> -o-box-shadow: 0 0 5px rgba(0, 0, 0, 0.15); >>>> box-shadow: 0 0 5px rgba(0, 0, 0, 0.15); >>>> } >>>> >>>> *However*, this approach is much harder to maintain. I need to keep >>>> track of all of my own classes manually. I end up having a ton of generic >>>> classes like: >>>> >>>> .box-shadow-0-0-0-015 { >>>> @include box-shadow(0 0 0 0.15); >>>> } >>>> .box-shadow-0-0-0-025 { >>>> @include box-shadow(0 0 0 0.25); >>>> } >>>> .box-shadow-0-0-0-035 { >>>> @include box-shadow(0 0 0 0.35); >>>> } >>>> >>>> And it means that my code is not very reusable. >>>> >>>> What I was hoping to achieve was the best of both worlds. I want to have >>>> a mixin that automatically generates a "top-level" class on the fly. This >>>> way I could do: >>>> >>>> #my-div { >>>> @include my-super-box-shadow("bs1", 0 0 0 0.15); >>>> } >>>> >>>> #my-div2 { >>>> @include my-super-box-shadow("bs1", 0 0 0 0.15); >>>> } >>>> >>>> #my-div3 { >>>> @include my-super-box-shadow("bs2", 0 0 0 0.35); >>>> } >>>> >>>> And it would produce: >>>> >>>> .bs1, #my-div, #my-div2 { >>>> -moz-box-shadow: 0 0 5px rgba(0, 0, 0, 0.15); >>>> -webkit-box-shadow: 0 0 5px rgba(0, 0, 0, 0.15); >>>> -o-box-shadow: 0 0 5px rgba(0, 0, 0, 0.15); >>>> box-shadow: 0 0 5px rgba(0, 0, 0, 0.15); >>>> } >>>> >>>> .bs2, #my-div3 { >>>> @include my-super-box-shadow(0 0 0 0.35); >>>> } >>>> >>>> This would be a beautiful combination of efficient CSS output with >>>> highly-maintainable scss code. >>>> >>>> Any thoughts? >>>> >>>> >>>> On Wed, May 4, 2011 at 3:47 PM, Nathan Weizenbaum <nex...@gmail.com>wrote: >>>> >>>>> No, it's not. Why wouldn't you just define the top-level selector >>>>> outside the mixin? >>>>> >>>>> On Wed, May 4, 2011 at 11:41 AM, Aaron Gibralter < >>>>> aaron.gibral...@gmail.com> wrote: >>>>> >>>>>> Does anyone know if it would be possible to write a sass function that >>>>>> could define a top-level selector within another selector: e.g.: >>>>>> >>>>>> >>>>>> @mixin br1 { >>>>>> @top-level .br-1 { >>>>>> @include border-radius(1px); >>>>>> } >>>>>> @extend .br-1; >>>>>> } >>>>>> >>>>>> .foo { >>>>>> font-size: 10px; >>>>>> @include br1; >>>>>> } >>>>>> >>>>>> //=> >>>>>> >>>>>> .foo { >>>>>> font-size: 10px; >>>>>> } >>>>>> >>>>>> .br-1, .foo { >>>>>> border-radius: 1px; >>>>>> } >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "Haml" group. >>>>>> To post to this group, send email to haml@googlegroups.com. >>>>>> To unsubscribe from this group, send email to >>>>>> haml+unsubscr...@googlegroups.com. >>>>>> For more options, visit this group at >>>>>> http://groups.google.com/group/haml?hl=en. >>>>>> >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Haml" group. >>>>> To post to this group, send email to haml@googlegroups.com. >>>>> To unsubscribe from this group, send email to >>>>> haml+unsubscr...@googlegroups.com. >>>>> For more options, visit this group at >>>>> http://groups.google.com/group/haml?hl=en. >>>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Haml" group. >>>> To post to this group, send email to haml@googlegroups.com. >>>> To unsubscribe from this group, send email to >>>> haml+unsubscr...@googlegroups.com. >>>> For more options, visit this group at >>>> http://groups.google.com/group/haml?hl=en. >>>> >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Haml" group. >>> To post to this group, send email to haml@googlegroups.com. >>> To unsubscribe from this group, send email to >>> haml+unsubscr...@googlegroups.com. >>> For more options, visit this group at >>> http://groups.google.com/group/haml?hl=en. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Haml" group. >> To post to this group, send email to haml@googlegroups.com. >> To unsubscribe from this group, send email to >> haml+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/haml?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "Haml" group. > To post to this group, send email to haml@googlegroups.com. > To unsubscribe from this group, send email to > haml+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/haml?hl=en. > -- You received this message because you are subscribed to the Google Groups "Haml" group. To post to this group, send email to haml@googlegroups.com. To unsubscribe from this group, send email to haml+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/haml?hl=en.