What are the semantics of @import #64

Closed
ForbesLindesay opened this Issue Mar 31, 2013 · 10 comments

Comments

Projects
None yet
2 participants

I apologize for this being a little off topic, but I want the opinion/help of as many people as possible. I'm trying to understand what the correct semantics for @import statements are in various situations, and to this end I have prepared the following gist:

https://gist.github.com/ForbesLindesay/5280494

Owner

tj commented Apr 4, 2013

just a simple include IMO

Actually, I've since read https://developer.mozilla.org/en/docs/CSS/@import which suggests otherwise:

These rules must precede all other types of rules, except @charset rules; as it is not a nested statement, it cannot be used inside conditional group at-rules.

Also, what if I have three style sheets:

fixture.css ->

.foo {
  bar: 'baz';
}

foo.css ->

@import "fixture.css"
.foo {
  bar: 'foo';
}

bar.css ->

@import "fixture.css"

and the html:

<link href="foo.css" />
<link href="bar.css" />

is that inlined to:

.foo {
  bar: 'baz';
}
.foo {
  bar: 'foo';
}
.foo {
  bar: 'baz';
}

Which could be reduced to:

.foo {
  bar: 'baz';
}

Or

.foo {
  bar: 'baz';
}
.foo {
  bar: 'foo';
}

Which would reduce to:

.foo {
  bar: 'foo';
}

These are really big semantic differences

Owner

tj commented Apr 4, 2013

oh I thought we were speaking in terms of what the @import plugin would/should do, not what browsers do

Well, I'm asking both. What should an @import plugin do, and what do browsers currently do. I'm actually inclined to think browsers might have it right in this case. If I have 100 components all depending on normalise.css I probably just want it included once. Which would suggest it should go at the top. Which means @import statements only really make sense at the top. The only sad thing being you don't then get nesting, but rework doesn't have that anyway.

Owner

tj commented Apr 4, 2013

I'd expect the least magic possible personally, to just inline where I put it, not to hoist things around and mess with precedence, or perhaps that could be some @include rule but that requires parser changes

Yes, but the least magic is probably what it currently does, i.e. syntax error anywhere but the top of the document.

Since that would be very restrictive, you could still support @import path media-query syntax as currently supported by browsers. I quite like the idea of supporting @import parent-selector path media-query as well.

Then you could possibly have another plugin for nested @import statements.

Owner

tj commented Apr 4, 2013

for core i'd be happy with a really simple browser-ish implementation, we can just leave anything more complex to third-party

Cool, thanks for the input.

Owner

tj commented Apr 4, 2013

actually might still be best to leave out of core, not sure, with SPDY stepping in real CSS @import might actually be useful in the near future

True, SPDY should help, I still think there's an issue with resolution paths, but there you go.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment