X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/6a1c31fba589eaed8400cf04d57ff067e2f43a89..a6e69822f68864512d49a954a4581511246f0e0b:/doc/todo/concatenating_or_compiling_CSS.mdwn?ds=sidebyside diff --git a/doc/todo/concatenating_or_compiling_CSS.mdwn b/doc/todo/concatenating_or_compiling_CSS.mdwn index ed3f2e846..8f35fb552 100644 --- a/doc/todo/concatenating_or_compiling_CSS.mdwn +++ b/doc/todo/concatenating_or_compiling_CSS.mdwn @@ -108,3 +108,74 @@ extension would have to be locked-down. Perhaps it's better to implement this without that feature initially. --[[smcv]] + +> Although I understand the need to improve CSS inclusion, I wonder why you are +> proposing concatenating CSS rather than including them as several ` 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 ``, +>> 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]]