Re: [haml] declaring top-level classes within a selector
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.comwrote:
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
Re: [haml] declaring top-level classes within a selector
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.
Re: [haml] declaring top-level classes within a selector
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.comwrote:
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.comwrote:
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
Re: [haml] declaring top-level classes within a selector
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.comwrote:
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.comwrote:
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.comwrote:
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
