Skip to content

.import(basePath) plugin to read and inline @imported stylesheets #32

Closed
wants to merge 1 commit into from

6 participants

@eknkc
eknkc commented Mar 1, 2013

Hi,

Created an @import disk read plugin (#24). It just goes in a depth first search and merges the css ast into current one. Not sure if it's the way you'd want to implement though. Feels kinda ugly.

@ForbesLindesay

+1000 for this feature, haven't had a chance to look at your implementation.

@ai
ai commented Mar 3, 2013

It will need for me too, to move from Sass :).

@ai
ai commented Mar 6, 2013

Maybe we need different keyword @include 'path'? But for me it’s OK now :).

@ForbesLindesay

Why does it need to be a different keyword? It'd be cool to have plugable name resolution so that you could do a node.js/npm style lookup of installed css.

@ai
ai commented Mar 6, 2013

@ForbesLindesay it is just idea :-).

Real problem, that plugin must lookup in several dirs. For example, Rails has a lot of assets dirs.

@kristoferjoseph

+1 On the necessity of this plugin.

Any feedback yet on what would be needed to merge it?

@tj
rework member
tj commented Mar 9, 2013

I wouldn't mind this one being a third-party plugin as well as far as the lookup techniques etc go, I don't think many people actually use vanilla @import anymore but there's also that being a collision as an issue. I wouldn't mind @import foo, @import ../foo/bar etc as things we touch and quoted ones remain vanilla, tough call. It also depends on the extname too, we use .styl because of css-whitespace and our stylus syntaxes

@kristoferjoseph

Are you saying you would be ok with:

@import ../fwee imports fwee.css and fwee.styl for inclusion in the current rework
@import "../fwee" or @import url("../fwee") would do the seldom used vanilla import

Does this work?

I feel like anyone interested in using rework would probably not be using vanilla imports though no?

@ForbesLindesay

Personally I'd much rather we handled the string based version. I.e. optimise the vanilla case so it can actually be used.

@kristoferjoseph

@ForbesLindesay I think we are talking about two flavors of "vanilla" here. For clarity the one I am talking about is the worst practices one where the @import URL is included by the browser. I feel that for this case it would be best to basically concat the files when reworked since most people would not want multiple http requests and each browser does something different with it.

There is a cool recommendation for the @import where you can specify which CSS file to load for the browsers current media query, but it isn't implemented and in its current state would slow page load a bit anyways. Rework could support this recommended functionality *somewhat by creating an @media block from the information in the @import https://developer.mozilla.org/en-US/docs/CSS/@import.

An issue with just adding the contents of another file is that rework processing starts to become order dependent, which I don't think is wanted. For instance if each file has a variable block at the top you need to make a call as to how to define scope. A common pattern I see with stylus users is they have their variables in a separate file all together and import them into files that use them. In the current rework spec I am not sure how this would work. Would you require duplicating variable definitions at the top of each file then process the variables at import time before inclusion? Would you merge variables? Would it be last in wins as far as overriding variable values?

@tj
rework member
tj commented Apr 4, 2013

leaving out of core for now

@tj tj closed this Apr 4, 2013
@anthonyshort

I actually think you could get away with not needing this if you're using something like Component. If your CSS is really modular you could probably get away with not caring about the order of the files and just concat everything and run Rework over it.

@tj
rework member
tj commented Jun 3, 2013

yea you can definitely get away from it with a small makefile or other build tool. for some plugins like vars you'd have to do a single pass otherwise you lose all that data though hmm..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.