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.
