Re: [haml] From LESS to SCSS: joys and miseries
Since Sass is a CSS3 superset, @import foo.css must work as it does in CSS
Nathan,
we're agree that @import foo.css should work as it does in CSS, there is
no contradiction with my proposal. Proposal is just and only about extending
of @import foo. This command is SASS-specific, so it wouldn't ruin the
consistency if you allow one more extension besides .sass and .scss to be
processed. Again to sum up:
@import foo.css will work as it does in CSS
@import foo will include contents of foo.(sass|scss|css)
Variables tend to do nearly as good a job of reducing the repetition in
every case we've seen.
And here I speak of the feature extensively used via LESS previously, not
dreamy one.Think of properties as already defined variables. In this way
you're not pushed to define variable every time. Especially in minor cases
when something should be repeated no less than twice or thrice. Let's
compare.
$body_lineheight: 1.5;
$paragraph_color: #999;
body { line-height: $body_lineheight; color: #111; ... }
p{ line-height: $body_lineheight; color: $paragraph_color; ... }
li { color: $paragraph_color; ... }
body { line-height: 1.5; color: #111; ... }
p[ line-height: body['line-height']; color: #999; ... ]
li { color: ['p']; ... }
--
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] From LESS to SCSS: joys and miseries
Since Sass is a CSS3 superset, @import foo.css must work as it does in CSS
Nathan,
we're agree that @import foo.css should work as it does in CSS, there is
no contradiction with my proposal. Proposal is just and only about extending
of @import foo. This command is SASS-specific, so it wouldn't ruin the
consistency if you allow one more extension besides .sass and .scss to be
processed. Again to sum up:
@import foo.css will work as it does in CSS
@import foo will include contents of foo.(sass|scss|css)
Variables tend to do nearly as good a job of reducing the repetition in
every case we've seen.
And here I speak of the feature extensively used via LESS previously, not
dreamy one.Think of properties as already defined variables. In this way
you're not pushed to define variable for every repeated property. Especially
in minor cases when it should be repeated no less than twice or thrice.
Let's compare.
$body_lineheight: 1.5;
$paragraph_color: #999;
body { line-height: $body_lineheight; color: #111; ... }
p{ line-height: $body_lineheight; color: $paragraph_color; ... }
li { color: $paragraph_color; ... }
body { line-height: 1.5; color: #111; ... }
p[ line-height: body['line-height']; color: #999; ... ]
li { color: p['color']; ... }
--
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] From LESS to SCSS: joys and miseries
On the subject of property extraction, I am -1.
Pertinent to the general discussion, here's a blog post I wrote about how we
approach the Sass language design process and the thought process we go
through:
http://chriseppstein.github.com/blog/2010/08/16/sass-language-design/
The goal should not be less lines of code, but rather more maintainable
code. Sure you can save a little typing by extracting a property, but as
Nathan pointed out there's a lot of opportunities for unmet expectations
with such a feature. They might expect the cascade to apply or they might
make a change to an extracted property and not realize or want that change
to propagate. When these unexpected things happen, the time savings of not
refactoring to extract a variable (which has a very clear purpose for
re-use) is lost tenfold.
Chris
On Fri, Mar 18, 2011 at 11:42 PM, Alexander Sergeyev etorea...@gmail.comwrote:
Since Sass is a CSS3 superset, @import foo.css must work as it does in
CSS
Nathan,
we're agree that @import foo.css should work as it does in CSS, there is
no contradiction with my proposal. Proposal is just and only about extending
of @import foo. This command is SASS-specific, so it wouldn't ruin the
consistency if you allow one more extension besides .sass and .scss to be
processed. Again to sum up:
@import foo.css will work as it does in CSS
@import foo will include contents of foo.(sass|scss|css)
Variables tend to do nearly as good a job of reducing the repetition in
every case we've seen.
And here I speak of the feature extensively used via LESS previously, not
dreamy one.Think of properties as already defined variables. In this way
you're not pushed to define variable for every repeated property. Especially
in minor cases when it should be repeated no less than twice or thrice.
Let's compare.
$body_lineheight: 1.5;
$paragraph_color: #999;
body { line-height: $body_lineheight; color: #111; ... }
p{ line-height: $body_lineheight; color: $paragraph_color; ... }
li { color: $paragraph_color; ... }
body { line-height: 1.5; color: #111; ... }
p[ line-height: body['line-height']; color: #999; ... ]
li { color: p['color']; ... }
--
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] From LESS to SCSS: joys and miseries
Thanks for the input.
1) We decided not to allow .css files to be imported largely for reasons of
consistency. It would be confusing if you could do @import foo.sass and
@import foo.scss, both of which would be equivalent to @import foo,
while @import foo.css would work completely differently. Since Sass is a
CSS3 superset, @import foo.css must work as it does in CSS, so we made the
decision to disallow importing of .css files altogether. Yes, it's minorly
annoying to rename them to .scss, but ultimately I think it's worth it to
avoid the confusion of having @import work inconsistently.
2) We've considered adding this feature several times, but two things have
stopped us in the past. The first is that the semantics are unclear; there
are many cases where the selector value would be ambiguous or would might
require full resolution of the cascade to determine exactly. This issue
could potentially be avoided or worked though, but for the second issue: we
have yet to see a convincing use case for directly accessing selector
values. Variables tend to do nearly as good a job of reducing the repetition
in every case we've seen. If you have a use where this isn't true, do show
us and we'll look it over.
- Nathan
On Thu, Mar 17, 2011 at 4:36 AM, Alexander Sergeyev etorea...@gmail.comwrote:
Salute to developers.
Hitherto I have used LESS, and after reading rapturous reviews on SCSS
(3.0.25) am giving it a try. A few hours of training and converting
stylesheets passed, and as it frequently happens — joys come with miseries
hand in hand.
1. Primary stylesheet (let's call it index.scss) begins with dependencies
import. SCSS doesn't include *contents of *reset.css, colorbox.css,
miscjs.css, etc if that files' extension is not .scss (or .sass). But, hey,
it's not convenient to rename such files if you update them from third-party
sites. For example, when new version of Colorbox rolls out, I just replace
old colorbox.css with a new one. Or when Eric Meyer rolls our updated
Reset.css, I just download drop it into assets folder of the sites I
maintain. And now you ask me to complicate things with a renaming step.
My proposal on how imports should be handled:
@import reset; // Include contents of reset.(sass|scss|*css*)
@import reset.css; // Leave it as it is, i.e. @import url(reset.css)
2. Neither @extend is applicable nor variables are elegant solution when I
need to inherit *a **single property *of some element. Maybe I've missed
something, but with SCSS I can't do as follows
p { color: body['color']; }
--
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.
[haml] From LESS to SCSS: joys and miseries
Salute to developers.
Hitherto I have used LESS, and after reading rapturous reviews on SCSS
(3.0.25) am giving it a try. A few hours of training and converting
stylesheets passed, and as it frequently happens — joys come with miseries
hand in hand.
1. Primary stylesheet (let's call it index.scss) begins with dependencies
import. SCSS doesn't include *contents of *reset.css, colorbox.css,
miscjs.css, etc if that files' extension is not .scss (or .sass). But, hey,
it's not convenient to rename such files if you update them from third-party
sites. For example, when new version of Colorbox rolls out, I just replace
old colorbox.css with a new one. Or when Eric Meyer rolls our updated
Reset.css, I just download drop it into assets folder of the sites I
maintain. And now you ask me to complicate things with a renaming step.
My proposal on how imports should be handled:
@import reset; // Include contents of reset.(sass|scss|*css*)
@import reset.css; // Leave it as it is, i.e. @import url(reset.css)
2. Neither @extend is applicable nor variables are elegant solution when I
need to inherit *a **single property *of some element. Maybe I've missed
something, but with SCSS I can't do as follows
p { color: body['color']; }
--
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] From LESS to SCSS: joys and miseries
I can see how point (2) could be very useful and concise if implemented!
On 17 Mar 2011, at 11:36, Alexander Sergeyev wrote:
Salute to developers.
Hitherto I have used LESS, and after reading rapturous reviews on SCSS
(3.0.25) am giving it a try. A few hours of training and converting
stylesheets passed, and as it frequently happens — joys come with miseries
hand in hand.
1. Primary stylesheet (let's call it index.scss) begins with dependencies
import. SCSS doesn't include contents of reset.css, colorbox.css, miscjs.css,
etc if that files' extension is not .scss (or .sass). But, hey, it's not
convenient to rename such files if you update them from third-party sites.
For example, when new version of Colorbox rolls out, I just replace old
colorbox.css with a new one. Or when Eric Meyer rolls our updated Reset.css,
I just download drop it into assets folder of the sites I maintain. And now
you ask me to complicate things with a renaming step.
My proposal on how imports should be handled:
@import reset; // Include contents of reset.(sass|scss|css)
@import reset.css; // Leave it as it is, i.e. @import url(reset.css)
2. Neither @extend is applicable nor variables are elegant solution when I
need to inherit a single property of some element. Maybe I've missed
something, but with SCSS I can't do as follows
p { color: body['color']; }
--
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.
