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 <[email protected]>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 <[email protected]>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 < >> [email protected]> 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 <[email protected]>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 < >>>> [email protected]> 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 [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. >>>>> >>>> >>>> -- >>>> 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. >>>> >>> >>> -- >>> 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. >>> >> >> -- >> 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. >> > > -- > 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. > -- 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.
