Closed lukeapage closed 11 years ago
that's a strict superset of the existing syntax, i think lukeapage could easily merge the current patch and you could extend the syntax in the next release if users demanded it.
The parentheses make parsing less ambiguous, fwiw. Although the only acceptable production is a url, and I think that either has to be quoted or start with "url"... although someone should read the CSS specs closely to be sure.
Ok will merge tomorrow and make brackets required.. not sure this exact syntax matters too much as long as it is consistent and usable (which I think it is)
:+1:
moved to seperate issues for inclusion in 1.4.1
Whoo-hoo. Your changes look good to me, @lukeapage .
Huge thank you for this feature. Being able to extend vendor css is an awesome feature, thanks!
If I do an @import (less) "myfile.css"
, the css code gets mangled, with white space removal and other changes.
@atomi I think you were expecting the behavior of the "inline" option (which is issue #1209). That's not implemented yet.
@cscott Ah okay, I see. The @import (less) "myfile.css"
option is for less files which for some reason have a fixed non .less extension.
Thanks.
Edit: By the way will the (inline)
option be available for the 1.4.0 release?
@atomi another use of the (less) option might be to import "less-compatible" CSS files (again, with fixed extensions) with selectors you want to extend.
The bug describing (inline) is targeted at 1.4.1, and seems to have been coded and committed already on the 1.4.1 branch. Further discussion should probably happen in #1209.
@cscott Thanks again.
I'm trying to extend selectors from a css file using @import (less)
option as you've described.
I'm able to extend most selectors, but less seems to be having issues extending selectors with number in them - with the error NameError: .span2 is undefined
@atomi if you use inline you cannot access the selectors as less - the file is just plunked "unread" into your output. If you are reading a css file as a less file, it should work as long as the file parses..
How are you "extending".. using :extend()
or are you trying to call a selector as a mixin.. Please post some source.
@lukeapage
@import (less) "vendor/css/bootstrap.css";
#main-content {
.row; // this works
.btn-mini; // this works
.span2; // fails
}
Edit:
I made another test case just to test if this was a problem with the (less)
import option or with less itself or with the bootstrap css file parsing as less.
In a simple selector use case, everything worked as expected. So this is likely bootstrap.css not parsing as a less file correctly. If this is intended behavior, sorry for the extra noise, thanks again.
@atomi please open a new bug for "bootstrap.css not parsing as a less file correctly"
@atomi I suggest you use bootstrap before it is compiled, rather than after, that way you have more control.
otherwise work out why .span2
isn't being picked up and raise a issue - it is almost certainly because it isn't used on its own?
Any progress on this? I want to inline an external css, so I don't have to make an additional request for this (e.g. @import url(http://fonts.googleapis.com/css?family=Lato:300,400,700,300italic,400italic,700italic);
).
@donaldpipowitch import options as a whole are in 1.4.0. The inline option was added to the 1.5.0 wip branch, which is not yet released. I hope to release a beta of it in the next couple of weeks.
Thank you for the update!
We have decided that the best way to handle the import bugs is by having options.
Given the scope of the bugs I feel strongly that the options need to be inline with the actual import statement
I suggest removing
@import-once
and@import-multiple
and allowing options to be passed to the@import statement
Note that import can already be followed by media statements e.g.
The options I propose we support are
?.css
onto the end of url's at the moment to treat as css - a bit of a hack@import-multiple
though not so important if we want to dropso here are some options.
downsides are its a bit confusing with the media query syntax. we could also put the options second and mix them with the media query, defining our own special media query options essentially, but I don't like that in case we conflict in the future with css.
from @jonschlinkert
and variations on the above, such as using closer media query syntax like
I initially disliked @jonschlinkert's options idea, but it does actually allow for setting defaults.. what I don't like is that it looks a bit verbose.
we could also assume
:true
and haveand I am open to any other suggestions.