Use href instead of @import for CSS

It is not PHP but a CSS command.

Drupal compresses your CSS files in a single .css file and tells the browser to use it by using @import CSS command.

The @import command in CSS has been supported since IE4. I'm therefore flagging this as by design.

I agree that @import works in any browser in actual use today, but it does have downsides. Specifically, if you try and do a "save whole web page" command in some browsers (eg, Firefox 2), it won't traverse to download files referenced by @import. It will grab those specified with an href, but not @import.

Is there a reason we use @import, other than to prevent Netscape 4 from loading the file? (That's the only argument I am aware of in favor of @import, and it ceased to be relevant years ago.)

There are some discussions about @import vs link. http://www.google.com/search?q=%40import+vs+link+CSS

It is true that you cannot save @import'ed CSS file. This is annoying.

I can't tell which one we should choose but I attached a patch to test it.

I got a "patch unexpectedly ends in middle of line" message when trying to apply this, but it worked anyway. The attached is just a reroll that shouldn't have any messages. It works for me as advertised both with CSS caching on and off.

Via Google, the only reason I could find to use @import in the HTML file itself was to keep Netscape 4 from reading it. There is no other purpose. My suspicion unless corrected by someone who's been around Drupal longer than I have is that it was used for that back in 2002 and left in even though it no longer has a purpose, Netscape 4 being extremely dead. I did, however, find this page (http://www.bluerobot.com/web/css/fouc.asp/) which indicates that using @import can sometimes cause issues for modern versions of IE (IE 6, anyway). I am therefore marking this RTBC.

Multiple spacing errors....

+1 on concept.

dot (string concat) rules; there is always a space on both sides of a dot unless the space is between and a quote (either single or double) -- there is never a space between a quote and a dot.

Re-rolled

I often wondered why we were using @import instead of linking, or, for that matter
[link rel="stylesheet" type="text/css" href="style.css"/] - which I find even more semanticly tidy.

Using the css import syntax just makes parsing harder for some tools.

I imagined there was a reason once upon a time to make that choice. If not, then I certainly vote for a tidy-up.

Look for more @Import . You will find quite a number. there are regexps in common.inc , color.module , explicit references in theme.inc ./misc/maintenance.tpl.php ./themes/garland/page.tpl.php ...

The idea is good but the implementation is extremely sloppy. The diff does not even have the -p (or -F^f ) argument.

chx: those regexps in common.inc , color.module I think should remain. They appear to ensure that @imports get priority over other css, which would be correct behaviour.

I have re-rolled a patch which replaces all @imports I could find in core except one which is in themes/garland/minnelli/style.css. I don't know how to replace that neatly.

Rerolling for HEAD.

This replaces all @imports except for:

- Those in minielli's CSS file.
- Those in the regexes to parse and compress stylesheets.

I don't have a problem with that, because the goal here is to get rid of @import in style tags, not to rid the world of them completely. I also don't know anywhere near enough about the regex magic happening there to even attempt to refactor it to do something else with those.

Actually, I do know how to deal with minelli's CSS file: http://drupal.org/node/141725

Once that goes in, we just rename minelli's CSS file to something else and it automatically inherits Garland's CSS without needing the @import.

I don't know where that last reroll went, but here it is again, taking http://drupal.org/node/141725 into account. It doesn't deal with Minelli, though, because I don't have access to rename files in CVS. :-) Dires/Gabor, I can do a delete/add for it and include that in here if you'd like.

Why does some of this patch use LINK and some use STYLE? To include multiple styles per page, we need to use LINK multiple times, not STYLE.

Great patch idea though!

OK, link it is then.

This version removes all instances of <style> and @import from core and replaces them with <link />. (There's still some @import appearing in the CSS aggregation regex code, which is fine and I don't want to touch.)

The sole exception is the @import in minelli,css, which should be handled by renaming the file and removing that line so that the new theme info file format can pick up Garland's CSS automagically. I can't rename a file with a patch, so that will be a separate issue for the committers to do manually, basically. :-)

Given the issues with @import (above) and some discussion in IRC, I think it's reasonable to call this a bug, not a feature change.

I know I mentioned this elsewhere, but would it make more sense to use a theme function, which would allow the developer to decide which version, link or @import, to use.

I'm sure link vs @import comes down to personal preference.

No, it does not. See comments #3 and #5. The @import method has known issues, for which the fix is to not use it. The only reason one would ever need @import in the HTML file itself is to hide CSS from Netscape 4, which we do not support anyway.

Adding a theme function would also be a performance hit, as its two extra function calls per stylesheet.

ah, understood.

Patch rerolled for latest HEAD. It seems to work nicely in all my testing. I'm marking this 'critical' as it is definitely time to switch over (NS4 is not a reason anymore).

One more problem in this context I faced recently is that '@import' doesnt support urls with escaped characters (ampersands). For example <style type="text/css" media="all">@import "/drupal/gallery2/main.php?g2_view=imageframe.CSS&amp;g2_frames=slide%7Cpostage";</style> does not work. It works however if '&' is replaced with '&'. On the other hand '&' inside the document does not validate cleanly against (x)html. This is not an issue when using <link rel="stylesheet" type="text/css" ... (works nicely with &). Not sure this is a browser bug (FF2) though.

Re-rolled patch with trailing CRs stripped. This patch looks ready to go to me.

@profix898 see the comments on the creating patches page on stripping windows line endings.

@bennybobw: I'm using TortoiseCVS (http://drupal.org/node/113172) to create patches for over 2 years now and it has never been a problem ... Your (hopefully smart) editor or cvs utility unifies the line endings anyway.

Any news here? Any chance to get this in?

Committed to CVS HEAD. Great work all! :)

@profix898: FYI, when I was on a PC I had to create a patch with TortoiseCVS and then open it in Notepad++ to convert line endings to UNIX, as TortoiseCVS it doesn't by default. This is needed to Windows line endings don't infect Drupal. :)

Quick question: is there a 5.x solution for this?

Seems in some point it drifted into 6.x ...

thanks!