+
+> Although I understand the need to improve CSS inclusion, I wonder why you are
+> proposing concatenating CSS rather than including them as several `<link
+> type="text/css" href="FILE.css" rel="stylesheet">` lines
+> in the header: unless I am missing something, I see this as far more simpler
+> than concatenating them.
+>
+> This would imply that a template variable `CSS` is added to the page
+> template, to be filled with those lines.
+>
+> Whatever solution is used, I agree that such a thing would be useful:
+> adding CSS (rather than replacing the existing one) should be easier.
+>
+> -- [[Louis|spalax]]
+
+>> One big request is more efficient than lots of small requests,
+>> if we model the CSS as all changing equally infrequently.
+>> In terms of bytes, each file needs some code in the HTML `<head>`,
+>> plus the HTTP request and response headers, plus the actual file.
+>> On the first page-view, a visitor will have to download all the CSS anyway
+>> (one request/response pair per CSS file). On subsequent page-views, there
+>> will be one request/"304 Not Modified" response per CSS file, unless the
+>> CSS files can be marked "to be cached forever" (which can be done if
+>> they have content-based filenames).
+>>
+>> In terms of time, [[!wikipedia HTTP_pipelining desc="according to Wikipedia"]]
+>> browsers don't generally pipeline requests, so the page won't finish
+>> loading until one round-trip time per uncached CSS file has elapsed.
+>>
+>> Having lots of small files with content-based filenames would be the
+>> next best thing - not particularly efficient on a generic web server,
+>> but they could at least be marked as "cache forever" in server
+>> configuration. I'd be OK with doing that if it makes ikiwiki more
+>> maintainable, but I don't think concatenating all the CSS at
+>> compile time is actually going to be a problem in practice.
+>> The individual small files are still going to be available
+>> for the wiki operator to edit.
+>>
+>> If some CSS files change with a significantly different frequency,
+>> *then* it might become worthwhile to separate them, but I don't
+>> think that's the case (apart from possibly local.css, which is why
+>> I'm not sure whether to include it in this).
+>> --smcv
+
+>>> I must admit that I am not aware of how those several CSS inclusion lines
+>>> tend to make browsing less smooth. Please withdraw my comment.
+>>>
+>>> As you pointed out, CSS inclusion is more painful than it should be, and
+>>> your proposal seems to answer that. Go ahead! --[[Louis|spalax]]
+
+> Concatenating the theme css as is done now results in files that are
+> unecessarily large with a doubling of a lot of selectors etc. It only makes
+> sense for changes that should be local.css anyway. Catted css is inefficient
+> both while downloading and while rendering. I've disabled the catting in the
+> makefile to avoid this on my personal site. In my view it would be better for
+> theme developers to work from the basewiki style, if lazy just add their
+> changes to the end of it, or if speed is of secondary importance @import it.
+>
+> The advanced melding of stylesheets discussed sounds quite complicated with
+> likely useability problems when the site don't quite look as expected. Hunting
+> down the problematic css will be difficult.
+>
+> Are there parsers that remove double defined selectors according to cascading
+> rules as is done in browser? This would at least produce cleaner css but the
+> useability problems would remain.
+>
+> When using complete themes and hunting that last bit of speed a config option
+> to turn off local.css would probably be a good idea? Plugin css is difficult.
+> A choice between a plugin complete theme or a local.css (or @import from it)
+> would be a simple solution that lets you choose how you prioritize speed
+> vs convenience. --[[kjs]]