I'm new to bower/git/nodejs and using the SCSS from a css framework. Previously I would just download the framework CSS and just include it in my website. Then write scss and include that as a separate file.
I followed the directions on foundations site: http://foundation.zurb.com/docs/sass.html
I'm getting the following warnings which I imagine can't be good. I have sass 3.3 installed.
What am I doing wrong?
But, as it's a warning not an error (for now!)
you can add
disable_warnings = true
to your config.rb.
I expect foundation will update that stuff before it becomes completely deprecated.
The authors of Sass typically roll out backwards incompatible changes in 2 stages. First they will release a version that warns you that the feature you're using is not going to work in a future version but it still works in this version. Then they'll release a version where the feature is changed/removed.
In this case, manipulating global variables is changing. This is perfectly valid in 3.2, but gives deprecated warnings in 3.3:
$foo: blue;
.foo {
$foo: red;
}
It still works, though. To properly do the same thing in 3.3 (or to silence the warnings), the code should be written like this:
$foo: blue;
.foo {
$foo: red !global;
}
The addition of the !global flag makes the code incompatible with 3.2, which is all the warning is telling you.
Since this is a 3rd party library, I would recommend either ignoring it (though I suppose you're getting a lot of these warnings every time it compiles) or downgrading to 3.2 until the library has been updated to be compatible with 3.3.
Related
I am trying to replace the deprecated org.jasig.maven:sass-maven-plugin:1.1.1, which uses Ruby (not working with Java 11) with the io.github.cleydyr:dart-sass-maven-plugin:0.3.0, which uses Dart Sass, in order to compile sass and generate css files.
The plugin works correctly but I noticed the following differences in the CSS files:
sass-maven-plugin
dart-sass-maven-plugin
font-size: 12pt;
font-size: 16px;
background: #f51313;
background: rgb(245, 19, 19);
Are these differences due to the different implementations of SASS or something is going wrong during the compilation? The only related documentation I found is the following question. Is there any other documentation that I can see the differences?
In Visual Studio I'm using Gulp to compile Sass, using gulp-sass 4.0.2. When I use map.get() to get a mapped value, I get an error in Task Runner Explorer, but when I use map-get(), it works fine. So apparently it recognizes the latter syntax, but not the former.
Is there any documentation on these 2 different syntaxes, details on which is compatible with what, etc.?
In this documentation there is one mention of the map-get() syntax at the top, with no explanation or details. And in this documentation there's no mention of the map-get() syntax at all.
I am working on a project with some of use on Xcode 7.2 and some on 7.3 (including myself). We don't want to force everyone to upgrade to 7.3 (most would also have to update their OS and we are closing in on release date).
If I use #selector() as advised by Xcode for the new syntax anyone running 7.2 is unable to compile the project as they get an error. Using Selector("…") allows the project to compile on all versions but it creates a warning that I would love to suppress (with a TODO next to it for removal once everyone has upgraded).
Is there any way to suppress this warning, or should I just live with it for now as a price of being fast to upgrade?
Update: By adding #objc before the function in question the original warning changes to Use '#selector' instead of explicitly constructing a 'Selector', and it is willing to make the change for me making the code un-compilable on Xcode 7.2 or earlier.
As the issue isn't a deprecated method neither of the two existing answers work in this case (I would use the #avaliable option to continue getting warnings about any other deprecated methods and make case-by-case decisions on each though).
There is a workaround:
#available(iOS, deprecated=10.0)
func _Selector(str: String) -> Selector {
return Selector(str)
}
But you have to use _Selector instead of Selector in your code, And I'm not sure if Apple approves of this, so before submitting to AppStore, I Suggest remove #available(iOS, deprecated=10.0).
Credit of using #available goes to Daniel Thorpe for his answer here
Isn't this working?
On your target Build settings: All
Apple LLVM Warnings - Deprecated fonctions -> NO
After a marathon coding session, where I added too much code without keeping track of everything, I now have an app that probably has some iOS 5.0 and 5.1 specific enums, calls and frameworks, however, I want my app to support iOSes back to 4.3.
I was hoping that there was an easy way of setting Xcode to compile as if it were compiling for iOS 4.3, so that I would get errors for all of the offending code that needs to be conditioned out, and/or alternatively coded, for older iOS.
I thought I'd get that by using the compiler option:
-D__IPHONE_OS_VERSION_MAX_ALLOWED=__IPHONE_4_3
but that ends up generating error in system header files, not my code.
Given that most enums and frameworks have their availability included in the header files, I have to think that there is an easy way to do what I need.
Has anyone managed to do such a thing without resorting to downloading older Xcodes with old SDKs? There I may run into the issue of Xcodes that won't function properly under Lion (which is what I am running).
UPDATE: It appears as though I can't install Xcode 3.2.6 on Lion. I now will have to find a Snow Leopard Mac, unless I find a way to use compiler options or forcing Xcode to use old SDKs...
Here is a sample of what #mattjgalloway's answer did for me:
Lumin App Group
/Users/mz/Dev/Working/Lumin/Lumin/MyUIScreen.m
'brightness' is deprecated: TOO NEW!
'brightness' is deprecated: TOO NEW!
'brightness' is deprecated: TOO NEW!
'brightness' is deprecated: TOO NEW!
/Users/mz/Dev/Working/Lumin/Lumin/LuminViewController+Share.m
'TWTweetComposeViewController' is deprecated: TOO NEW!
'TWTweetComposeViewController' is deprecated: TOO NEW!
'TWTweetComposeViewController' is deprecated: TOO NEW!
/Users/mz/Dev/Working/Lumin/Lumin/LuminViewController.m
'scrollView' is deprecated: TOO NEW!
'connectionWithMediaType:' is deprecated: TOO NEW!
'connectionWithMediaType:' is deprecated: TOO NEW!
'AVCaptureDeviceSubjectAreaDidChangeNotification' is deprecated: TOO NEW!
'setSubjectAreaChangeMonitoringEnabled:' is deprecated: TOO NEW!
Very nice.
I placed the following in my project's .pch file, and am planning on doing so for all projects:
#if DEBUG
#define __IPHONE_OS_VERSION_SOFT_MAX_REQUIRED __IPHONE_OS_VERSION_MIN_REQUIRED
#import "MJGAvailability.h"
#endif
For any project, I am now automatically watching for SDK issues based on the earliest iOS I am targeting. While there still may be SDK changes I have to worry about, at least I know of most framework additions that are unavailable to an older iOS release.
Take a look at my MJGAvailability.h here on GitHub. Basically it defines the right preprocessor #defines so that newer APIs will look like they're deprecated, so you get a compiler warning. There's some documentation at the top of the file, but basically you just do this in your PCH file:
#define __IPHONE_OS_VERSION_SOFT_MAX_REQUIRED __IPHONE_4_3
#import "MJGAvailability.h"
For if you want to support down to iOS 4.3.
It's certainly not 100% foolproof, but I find it incredibly useful for doing what you're asking.
If you want to suppress a warning because maybe you know that it's OK to use that API (you've surrounded it with a respondsToSelector for example) then you can do something like this:
UINavigationBar *navBar = self.navigationController.navigationBar;
if ([navBar respondsToSelector:#selector(setBackgroundImage:forBarMetrics:)]) {
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wdeprecated-declarations"
[navBar setBackgroundImage:[UIImage imageNamed:#"navbar_bg.png"] forBarMetrics:UIBarMetricsDefault];
#pragma clang diagnostic pop
}
Sorry; completely blew that answer the first time. Let's try this again...
Deployment Target sets the lowest OS version you will work with.
SDK sets the highest OS version you will work with
Between Deployment Target and SDK, you have to conditionally check for APIs. See the SDK Compatibility Guide for details on that.
You probably just want to use the old SDK instead.
The easiest way to use old SDKs with newer versions is to save a copy of the .sdk directory and copy it into the new version when you upgrade.
You can, however, download the old stuff, too. Apple just hides it. Start in the Downloads for Apple Developers. Find the copy of Xcode you want. Download Xcode 4.1 for Snow Leopard; it includes iOS SDK 4.3. You can install it in parallel with Xcode 4.3, but you don't have to. Mount the disk. Open a terminal (it's just easier that way). Go to /Volumes/Xcode/Packages. You'll find all the SDKs there.
You can try installing it directly, and that may or may not work for you. You can also unpack the .pkg and get the files you want. I typically use a program called The Unarchiver. It can unpack just about anything. That'll give you a directory that includes a file called "Payload". If you double-click that, it'll expand (it's just a tar.gz that they don't include the extension on). That will give you the Platforms directory. Copy that into the Platforms directory in your copy of Xcode and you should be golden.
All that said, I once I've gotten the system working pretty well, I usually switch back to compiling with the latest and using deployment target. It makes it easier to collaborate with others who don't have the old SDK. And Apple may or may not reject due to linking with an old SDK. They've done that in the past; I don't know the current situation there (haven't had it come up in a while). But I'd tend to recommend submitting something built against the latest.
I recently installed Chirpy v2.01 for Visual Studio 2010 and am very excited about the features it offers. I'm running into some issues in the LESS domain, however.
As a first step, I copied over my existing .css file to a new LESS file. I immediately am getting two errors. The first is due to a CSS "filter" property that I have set:
div.someClass {
filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#aaaaaa', endColorstr='#000000');
}
This apparently is because the filter value is not technically valid css. LESS has a workaround for this, via escaping. Adding a tilde in front of a quoted section tells LESS to keep the value as-is. The following change should resolve the issue:
div.someClass {
filter: ~"progid:DXImageTransform.Microsoft.gradient(startColorstr='#aaaaaa', endColorstr='#000000')";
}
Upon saving the file, I still receive an error in the visual studio error console along these lines:
Error 54 Expected '}' on line 2 in file 'C:\Users\Administrator\Projects\Project\Content\test.chirp.less':
[1]: body {
[2]: filter: ~"progid:DXImageTransform.Microsoft.gradient(startColorstr='#aaaaaa', endColorstr='#000000')";
----^
[3]: } C:\Users\Administrator\Projects\Project\Content\test.chirp.less 2 5 Project
The .css files are never generated so long as this error comes up. I came across the following site that seems to describe the issue I'm having, but in a more generic DotLess .NET package. I tried adding this package to my project, but it didn't make a difference. It also looks like it relies on the server to handle the .less to .css conversion, instead of the IDE, as chirpy does.
The second error that I constantly receive, though it doesn't seem to actually stop the generation of the .css files, is the following:
Error 53 Fatal error, cannot continue: null cannot be converted to an object C:\Users\Administrator\Projects\Project\Content\test.css 1 1 Project
I'd really love to use the LESS functionality that Chirpy offers, but until I can figure out why these errors are happening, I'm limited to using it for mash.
you have to understand that Chirpy is simply using dotlesscss internally to transform the less into css.
So any bug in dotless also applies to Chirpy.
We have patched that bug quite recently and a new dotlesscss version is upcoming.. But how long it will take until Chirpy updates to the new version is up to the Chirpy developers..
greetings Daniel
I wrote a similar VS extension that compiles less but it uses less.js directly and doesn't depend on dotless. Check it out.