Actually, using @import has another side effect too: When saving the page, not all CSS is saved (depends on browser, of course). Using link makes sure that all CSS is going to be saved.

So unless a robust technical reason is given, I'm in support of getting rid of @imports (only because they're supported and classy, doesn't mean they should be used).

Hojjat (aka Huji)

On Thu, Jun 12, 2008 at 9:28 PM, Chad innocentkiller@gmail.com wrote:

On Thu, Jun 12, 2008 at 12:33 PM, howard chen howachen@gmail.com wrote:

...

A tips from Yahoo:

http://developer.yahoo.com/performance/rules.htm

============== One of the previous best practices states that CSS should be at the top in order to allow for progressive rendering.

In IE @import behaves the same as using <link> at the bottom of the page, so it's best not to use it.

=============

Maybe wikipedia should consider this?

Howard

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Note to others, HTM on the URL should be HTML

-Chad

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Yes, I recall hearing something about this in one of the discussions long ago, or on some article or commit. The original reason for using @import was to separate the CSS1 from the CSS2 rather than sending a CSS1 browser a lot of CSS2 which may break styles since only half of it is actually understood, and it won't validate right at all.

~Daniel Friesen(Dantman) of: -The Nadir-Point Group (http://nadir-point.com) --It's Wiki-Tools subgroup (http://wiki-tools.com) --Games-G.P.S. (http://ggps.org) -And Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG)

Simetrical wrote:

On Thu, Jun 12, 2008 at 2:46 PM, Huji huji.huji@gmail.com wrote:

...

Actually, using @import has another side effect too: When saving the page, not all CSS is saved (depends on browser, of course). Using link makes sure that all CSS is going to be saved.

So unless a robust technical reason is given, I'm in support of getting rid of @imports (only because they're supported and classy, doesn't mean they should be used).

Note that CSS1 user agents will obey <link> but ignore @import, since the latter was not part of CSS1. I'm pretty sure this was part of the original rationale for using @import in some places. This should be considered before changing it. CSS1 user agents are probably not a huge concern anymore, but I'm guessing that CSS1 user agents that try to read CSS2.1 written with no regard for CSS1 compatibility will end up ignoring half the rules and displaying a total mess.

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On Thu, Jun 12, 2008 at 8:24 PM, Brion Vibber brion@wikimedia.org wrote:

It's to keep Netscape 4 from loading the CSS2 stylesheets, freaking out, and becoming completely unusable because it thinks it knows CSS2 but was so woefully bad at it that it just messes everything up.

In these days where Netscape 4 is pretty much dead, we might consider dropping that -- at least if there actually *is* a measurable improvement to doing so.

It would be nice if there were some other way to scare off browsers that don't understand CSS2.1 even enough to justify fixes files.

Perhaps as an improvement as to how we actually load CSS and JS files. 85% of that kind of ordering is currently done inside of the Skins. And not only that, but when a new skin like Modern comes out, it just goes and duplicates what Monobook does. And even worse, there are the user made skins elsewhere. Those just copy what Monobook does at some point, and never get updated if we ever change that. Additionally, it's quite ugly when you get into things extensions load. Namely if they were created to load a global css/js for a wiki farm. Those extensions have little control over where that stuff is actually loaded, and not only that but if you actually want to have that proper control, the alternative is to just hack the skins you're using. Kinda ugly (This is the one of the reasons I have my own dedicated skins repo).

Perhaps we could improve the system by making generation of the list of css/js files to load (and what order to load them). Something like a system where we identify script/style dependencies and have the system automatically order them. In addition to that, we could identify things like if they should be conditional (for IE primarily...) to make it easier to add new fixes files. The primary relevance here, is that it's easier to create a system that does automatic creation and ordering of the files if they just generate a stack of script and link elements.

One of my ToDo's was improving MediaWiki's support for script libraries and stuff like jQuery, YUI, Scriptacious, etc... Part of that was also adding in a bit of support for allinone because these commonly end up loading multiple extra js/css files, and it piles up the HTTP Requests.

~Daniel Friesen(Dantman) of: -The Nadir-Point Group (http://nadir-point.com) --It's Wiki-Tools subgroup (http://wiki-tools.com) --Games-G.P.S. (http://ggps.org) -And Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG)

Brion Vibber wrote:

Huji wrote:

...

Actually, using @import has another side effect too: When saving the page, not all CSS is saved (depends on browser, of course). Using link makes sure that all CSS is going to be saved.

So unless a robust technical reason is given, I'm in support of getting rid of @imports (only because they're supported and classy, doesn't mean they should be used).

It's to keep Netscape 4 from loading the CSS2 stylesheets, freaking out, and becoming completely unusable because it thinks it knows CSS2 but was so woefully bad at it that it just messes everything up.

In these days where Netscape 4 is pretty much dead, we might consider dropping that -- at least if there actually *is* a measurable improvement to doing so.

-- brion

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l