X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/d86cd924b36ed5625c900bd7bba818c9f91e11be..4729ff0812c1f3d06d98524e2fec232d3bf90513:/doc/todo/concatenating_or_compiling_CSS.mdwn

diff --git a/doc/todo/concatenating_or_compiling_CSS.mdwn b/doc/todo/concatenating_or_compiling_CSS.mdwn
index b9c6234ee..8f35fb552 100644
--- a/doc/todo/concatenating_or_compiling_CSS.mdwn
+++ b/doc/todo/concatenating_or_compiling_CSS.mdwn
@@ -133,7 +133,7 @@ this without that feature initially.
 >> CSS files can be marked "to be cached forever" (which can be done if
 >> they have content-based filenames).
 >>
->> In terms of time, [[!wp HTTP_pipelining desc="according to Wikipedia"]]
+>> 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.
 >>
@@ -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]]