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.
