Closed rsanchez closed 10 years ago
Yeah, I'm perplexed by that as well. I mean, as far as I can tell, I'm "doing it right."
Everything that is extended is scoped properly to the respective @media
query, and there's no "leakage" or stacking of selectors that isn't intentional. That's actually why I'm doing this in the _unsemantic-grid-responsive.sass file…
$media-query-breakpoint: 767px !default
@import "unsemantic-ie-snap"
@media screen
@import "unsemantic-grid-base"
@media screen and (max-width: $media-query-breakpoint)
@import "unsemantic-grid-mobile"
@media screen and (min-width: $media-query-breakpoint)
@import "unsemantic-grid-desktop"
Technically, that first @media screen
isn't necessary from a CSS standpoint (thought, I guess it keeps print
from being affected). I just have it there so that "global" styles won't be duplicated by the compiler into the scope of the max-width
and min-width
areas.
I've talked to @chriseppstein about it, but I am not really sure what to do in order to make the compiler happy. I'd be much obliged if anyone else — better versed in how the compiler itself works — would care to weigh in.
If it becomes an outright error with Sass 3.3, I'll either list 3.2 as a hard dependency, or figure out a way to work around it. For now, at least it works.
:)
Hello @nathansmith Is a fix for this planned? I'm currently working on a project that needs Sass 3.3, and I would have appreciated to use this great grid framework with the Sass files.
Many thanks, Jean-Philippe
It's been determined that Sass is actually just being paranoid about false positives.
Unsemantic works fine with Sass 3.3 — It's been tested by myself and @jedfoster
He added a flag to disable warnings, because they're meaningless…
github.com/nathansmith/unsemantic/pull/6
So, there's nothing to worry about.
:)
@nathansmith Thanks for the answer. Well, it sure compiles when disabling warnings, but I can't remove them for a whole project containing a lot of Sass files, just to make unsemantic compiles (a little risky, right?).
It means that I can't include it in my current Sass project, I have to make a new one just for unsemantic, with it's specific config.rb file, etc…
It doesn't seems ideal to me. Maybe there's a way to get around this? Plus, when Sass 3.3 will be released as stable (I don't know when it will be, I wasn't able to find a release date), it would be a shame that it doesn't compile as it is.
What do you think?
Thanks, Jean-Philippe
I'm saying it does compile under Sass 3.3.
Here's a quote from @jedfoster — who emailed me about testing it…
I ran Unsemantic against Sass 3.3.0.alpha.69 and got the same warning, but the correct CSS. In my opinion, Unsemantic conforms to the stated spec in regards to media queries and
@extend
. Sass should not be throwing these warnings out.
Like I said, it's just the Sass compiler being paranoid and throwing false positives. But, they're warnings, not outright errors. Which means that the compilation still works just fine.
The disable_warnings
config only silences warnings not errors; Sass will still notify you of any compilation errors.
I agree that this is a less than optimal solution, but it was the only thing we could do given the current state of @extend
in Sass.
So, I just tried it on the 3.3.0.alpha.101 version of Sass. It does throw errors now.
Screenshot — http://cl.ly/image/3Y0a0d3X1w41
I would love to get some feedback from @chriseppstein as to how to make the compiler happy.
Everything is correctly scoped, so I'm not sure why this is an issue.
UPDATE:
Grasping at straws, I tried moving the @import
inside the media query itself, instead of having it imported from within the respective partials, but still get the same error(s)…
Before:
http://cl.ly/image/3u0i3I133I3D
After:
http://cl.ly/image/3K1D0L2z021p
If indeed you cannot ever use @extend
inside a @media
query, I see this as a fault with Sass itself.
Might I ask, @rsanchez — What is it that your project needs from Sass 3.3 that isn't available in Sass 3.2?
I think I'm going to add a Gemfile to the Unsemantic project, specifying 3.2 as a dependency, until this Sass compiler issue can be resolved.
I have the same issue. The current behavior in SASS 3.2 enables some really great, efficient CSS for responsive web design, but it breaks in 3.3.
@mgerring
I really wish they weren't making this an outright error in Sass 3.3, but it looks to be the direction they're heading.
For now, I've just made Compass 0.12.2 (Sass 3.2) a dependency in the Gemfile.
I think I'll eventually just end up including separate files that aren't shared, to appease Sass 3.3 (once it's at a stable release).
@nathansmith You and I should pair for a couple hours on this. I want to find a good solution and/or understand how sass can accomodate your needs in 3.3 when this becomes an error.
@chriseppstein
Sounds good. Just let me know when works for you.
(Feel free to email me or DM via Twitter.)
Could this be worked around if Unsemantic was based around mixins, rather than %psuedoclasses
?
Something like:
@function prepare-grid-width($width) {
$width: strip-unit($width);
$decimal: 0;
$percent: 0;
@if $width % 33 == 0 {
$num: $width * 33;
$one-third: 1/3;
$decimal: $i * $one-third;
$percent: ($num + $decimal) * 1%;
} @else if $width == 100 {
$decimal: 100;
$percent: 100%;
} @else {
$num: $width * 5;
$decimal: $num / 100;
$percent: $num * 1%;
}
@return $decimal, $percent;
}
@mixin grid($width) {
$vars: prepare-grid-width($width);
$decimal: nth($vars, 1);
$percent: nth($vars, 2);
@if $decimal == 100 {
@include clearfix;
clear: both;
width: 100%;
} @else {
float: $lang-forward;
width: $percent;
}
@if $unsemantic-ie7-support {
/* <IE7> */
*width: expression(Math.floor(#{$decimal} * (this.parentNode.offsetWidth - parseFloat(this.parentNode.currentStyle.paddingLeft) - parseFloat(this.parentNode.currentStyle.paddingRight))) + "px")
/* </IE7> */
}
}
@hawkrives
Thanks for this snippet. I will attempt to implement something along these lines, that doesn't affect backwards compatibility too much (though, it might be unavoidable).
I agree, since Sass 3.3 will throw an outright error, this needs to be addressed.
All:
Sorry for the lack of activity on this thread, I've been heads-down working on an iPad app for the last few months, and haven't been able to really do much Sass related in the meantime. ("Real life" FTW)
I'm using Unsemantic on the project I'm working on now, now that I'm back in the land of the living (aka: web development). Yay dogfooding.
I'll be digging in soon, to implement a more long-term solution than just specifying Sass 3.2 as a dependency.
Just a quick update.
It looks like when @at-root
is a feature in Sass, that will solve using @extend
within @media
queries.
https://github.com/nex3/sass/issues/774
I'll be updating Unsemantic when that's available, and it will fix the compile warnings/errors.
I'm happy to say that this has been fixed. Unsemantic now compiles without warnings or errors using Sass 3.3.
http://cl.ly/image/322L3Y3i2w0X
http://cl.ly/image/1l1j2L3O1L3x
Big thanks to @chriseppstein for doing a Google Hangout with me, and explaining how (as of Sass 3.3) %placeholder
scope works with @media
, etc.
Using the latest SASS/Compass, compiling shows the following error:
I'm sure you're aware, just wanted to point it out. Thanks for the code.