X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/5df475c81398b42fa0fa3f710d7268d15ae920ae..f5a1550441a9d58652d93deacc333f143a7ecfbd:/doc/todo/concatenating_or_compiling_CSS.mdwn?ds=inline diff --git a/doc/todo/concatenating_or_compiling_CSS.mdwn b/doc/todo/concatenating_or_compiling_CSS.mdwn index d73a7c921..8f35fb552 100644 --- a/doc/todo/concatenating_or_compiling_CSS.mdwn +++ b/doc/todo/concatenating_or_compiling_CSS.mdwn @@ -151,3 +151,31 @@ this without that feature initially. >> 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]]