-
Notifications
You must be signed in to change notification settings - Fork 162
-
Notifications
You must be signed in to change notification settings - Fork 162
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
deprecation warning upon compile #3
Comments
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
Technically, that first 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 Many thanks, |
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 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, |
I'm saying it does compile under Sass 3.3. Here's a quote from @jedfoster — who emailed me about testing it…
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 I agree that this is a less than optimal solution, but it was the only thing we could do given the current state of |
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 Before: http://cl.ly/image/3u0i3I133I3D After: http://cl.ly/image/3K1D0L2z021p If indeed you cannot ever use 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. |
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. |
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 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> */
}
} |
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 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) |
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.
The text was updated successfully, but these errors were encountered: