-
Notifications
You must be signed in to change notification settings - Fork 463
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
Implement raw css imports #754
Conversation
Yeah, this is one of those awkward ones where I've vocally disagreed with Ruby Sass about it, but... we have to follow their lead. See @nex3 and @chriseppstein, we're being good! All those +1's be damned. ;) |
Hmm, sorry, but not sure if you mean it's ok or not!? @chriseppstein wrote: "libsass can handle this like Sass does, right now. Additionally, there's really no issue with either Ruby sass or libsass resolving @import "foo/bar" to a css file. The only issue is when the explicit css extension is specified. We would break backwards compat." That's how I have implemented it in this PR!? |
I mean, yes, it's okay. |
👍 |
Please please please merge this |
Not related. Ignore. |
Where is the previous discussion on this you've mentioned? I'm struggling to find documentation on how Ruby sass implements this functionality.
Was stated in #318 (comment) but I see nothing related in the 3.4 changelog. Does Ruby sass have this feature without https://github.com/chriseppstein/sass-css-importer ? |
@xzyfer I meant this one sass/sass#556 |
Does that means it's in Sass at the moment? If so does this go against our road map for 3.4 compat, especially since the Ruby sass team has illuded that a new module system is on the cards for the next version. https://github.com/sass/sass/labels/%40import%20v2 My concern is that if we add this feat in this fashion it's going to become extremely difficult to deprecate, and become non-standard. |
It's not in sass currently IMO, but @hcatlin and IMO @chriseppstein haven spoken for adding it in this form. I'm also for it, since it does not really change the syntax significantly. It's just that we also check for |
I guess my concern is not how easy it is to maintain or the size of the change, as much as it is diverging from Ruby sass. More so since Ruby sass may soon solve this in a different way. We are then stuck with supporting to two ways of doing similar things which will invariably be subtly different. This sounds like a highly demanded feature which will mean people will depend on it. Once people are dependant on a feature removing it is a massive pain. Generally speaking I try to have the mentality that any feature we add is essentially there forever. My preference would be to start the discussion on with @chriseppstein and @nex3 on what imports v2 look be like and get a head start on implementing that. The demand for better imports is greater than say 3.4 query selectors (and probably less work) so it makes sense to prioritise IMHO. Thoughts? |
I more or less agree, but I don't see why we would have to remove it. I agree that this has to stay in, once it is in. But it's merely having another extension to query (which we will have to support forever anyway). |
I think switching between Libsass and Ruby sass should be trivial for developers. We should set the expectation that anything that works in Libsass works in Sass (and vice verse). This is why we're removing Generally speaking if this were a feature Ruby sass was adamant to not implement and we wanted to it would be a different discussion. It's purely because that Ruby sass is seriously considering a solution to this that I'd encourage us to do it the one true way. |
I can only repeat, that this seems already very easy to do in ruby sass. I guess that's the reason why it's not enabled by default.
But it's pretty hard to do in libsass when we only would need to add another extension to the lookup. But I'm OK with whatever the decision is here! IMO we could make it optional or even configurable to add additional extensions to the lookup!? //CC @hcatlin |
A compromise could be outputting a depreciation warning to the console when the CSS loading branch is reached, rather than transparently passing through. It's another discussion, but we should figure out where the line in the sand is for nonstandard (read: not in sass) features. |
I have long voted for this behaviour and fully support it. Just to be clear, the behaviour is that if the |
Yes, only |
🚀 |
This has been niggling at me. The big reason being it introduces unexpected behaviour for people moving from Ruby sass to Libsass. I think we should definitely make this behaviour optional. I know this is not the behaviour I would want in my sass work, and I would need to opt out. I also stumbled across #469 which indicates people are
|
Actually the behaviour of #469 would not change since /*!
Theme URI: http://mywebsite.com
Description: my theme description
Author: whatwedo GmbH
Template: Meola
Version: 0.1
*/
// Parent Theme
@import url("../meola/style.css"); Will still become: @import url("../meola/style.css");
/*!
Theme URI: http://mywebsite.com
Description: my theme description
Author: whatwedo GmbH
Template: Meola
Version: 0.1
*/ So I'm not sure where exactly your concerns are!? |
My mistake I didn't notice the import was a Ok I think I'm misunderstand this. I'm going show myself out now :) |
It's not only the url, but also the explicit
|
2635d43
to
6905879
Compare
sass#318 Refactor lookup code for better readability
@drewwells That is understood however as I stated is not the intent that the
|
@manuelro you'll a recent version of Libsass or node-sass@beta installed to use this feature. |
Please, make the default behavior for libsass match the default behavior for ruby sass. As you point out, it's trivial to add this capability to sass, but it creates an inconsistency in that the behavior of having an extension is different from when it is omitted. We don't like that kind of unpredictable behavior. If people opt-in, they will understand why the behavior is what it is. Because docs. |
If you want to expose configuration that enables this, like sass does, I think that's ok. |
@chriseppstein Does rubygem sass expose a configuration option to allow the inline importing of css files? |
* libsass already support import css after v3.2 (see sass/libsass#754) * support to watch scss files * replace includePaths syntax by @import relative path * rename app.scss to main.scss
I can see this was merged but it's not really working on my side. I'm using node-sass 4.5.3 which uses libsass 3.5.0.beta.2 and
Am I doing something wrong? |
Seeing ~ suggests your using an importer or webpack loader. I suspect
that's what is producing the error. I recommend strongly against rely on
this behaviour. It will be removed in future versions.
…On 19 Aug. 2017 11:33 pm, "Rex" ***@***.***> wrote:
I can see this was merged but it's not really working on my side.
I'm using *node-sass 4.5.3* which uses *libsass 3.5.0.beta.2* and
@import "~vue-wysiwyg/dist/vueWysiwyg.css"; works fine but
@import "~vue-wysiwyg/dist/vueWysiwyg"; does not, saying
Error: File to import not found or unreadable:
~vue-wysiwyg/dist/vueWysiwyg.
Parent style sheet: E:/project/assets/scss/vendor/_vendor.scss
on line 3 of assets/scss/vendor/_vendor.scss
@import <https://github.com/import> "~vue-wysiwyg/dist/vueWysiwyg";
Am I doing something wrong?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#754 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAjZWNy-rs7z8Tpx3KvSNlQvCp2AGm8hks5sZuQygaJpZM4DLXct>
.
|
Not sure what you mean by importer but I'm just using grunt-sass -> node-sass -> libsass to compile the file. I've tried with |
Also refactors the lookup code for better readability!
This is an attempt to fix one of our longer standing issues -> #318
I tried to read all related issues on ruby sass to make this compatible!
This PR allows to import a
file.css
with the following syntax:This will try to resolve the partial as normal, but will also look for
.css
files.Previously this would produces an error if no file could be found.
The old behaviour is still active:
Will result in:
So this should IMO be pretty much backward compatible!
If this is not acceptable by default I suggest to make this configurable!
@hcatlin what do you think?