is it really that hard? consider the following system: * the group code.css are looked for in a different folder (I believe there was support for that allready, but a rewrite rule to map code.css.pagename to $$pub/css/pagename.css might be handy. Perhaps even map code.css.page.name to $$pub/css/page/name.css to allow easy css file organisation) * a command [(css pagename)], placed in the header or similar, to add a .css file to the end of the css list. (Theres a list, right? You add or replace the last placed commands, the rest are inherited? :p)
and done? Well, you get the picture. It may be neccesary to have a special page for css file includes, .css pages, so that lower level headers don't need to include a .css command, and css files are inhereted as expected. In fact, this may have to be treated differently from header files, such that all higher level .css pages are taken into account. I suggest the following system: * code.css.* pages are looked for in $$pub/css, preferably with a rewrite rule so as to use normal .css filenames. * pagename.css pages are used to list the code.css files to include. All .css upwards in the hierarchy are taken into account, unlike headers where only the closest page is looked at. * [(css pagename)], [(css +pagename)], [(css -pagename)] replace, add or subtract to the css file list respectivly, only on the page they are included on. Example: ---- !! Files: !!! public/css/: * default.css * moonlight/default.css * moonlight/special.css !!! pages/: * css * example * group.css * group.normal * group.special !! Pages: !!! css default !!! example some text that recieves only default.css !!! group.css moonlight.default !!! group.normal some more text that recieves default.css and moonlight.default.css !!! group.special [(css moonlight.special)] even more text that recieves only the moonlight.special css file. --- does that make sense? Seems to me that everything fits easily into the current system, excepting the rewrite of code.css pagenames which would be nice but not strictly neccesary. Of course, externalising css files will both increase the processing time to create the pages and increase the number of server requests to load the first page, so it's not a strictly positive move. I remember someone doing a diagnostic on boltwire and comparing it to other wiki systems, and Boltwire shining with it's speed and low number of server requests. On Jan 7, 11:43 pm, The Editor <[email protected]> wrote: > It is actually on there... > > "Some kind of automatic system for support of external skin style > sheets. Caching?" > > It's a bit tricky, but we'll see what we can do. > > Cheers > Dan > > On Thu, Jan 7, 2010 at 3:41 PM, Bogdan <[email protected]> wrote: > > I just wanted to rise one more option for the Roadmap list :) > > > I think it is time to move the BW core to more unobtrusive code, > > especially the stylesheet. It's been long time since the separate file > > for the stylesheet is norm of good coding style. Everyone knows that > > it improves the display performance (the external files are cashed by > > the browsers) and the generated html code is far simpler and shorter, > > and also easier to debug and read. > > > Personally I develop my sites in this way (solutions.css.linked page > > gives some solution to that), but currently it's more like a hack of > > the system, than a normal solution. There is some problem with the > > path to the css-file if it is in the field/page folder (which gives > > opportunity to edit it within the system). I place it in the barn/ > > public folder and address it by $$pub/style.css, but this way the > > system variables don't work in the stylesheet. > > > If it is a part of the Core, it could be made as easy as writing > > skin.css so as to be automatically linked to the code.skin. Even if > > there are specific styles for some group of pages they can be gathered > > in some group.css and the system can make a link to this file in the > > corresponding pages following the hierarchical principle in addition > > to the skin.css. > > > The same could be with the unobtrusive javascript. If the system finds > > skin.js it adds a link to it in the head of skin.code. > > > Another option is to make a configuration variables in the site.config > > for the site stylesheet file and the necessary javascript touch to the > > site functionality. > > > I think separate files would make the skin development easier. > > > I would like just to rise the problem, to discuss it with all the > > community and if we find it reasonable, it seems to me it could be > > added in the Roadmap for the near future. > > > Regards, Bogdan > > > -- > > You received this message because you are subscribed to the Google Groups > > "BoltWire" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group > > athttp://groups.google.com/group/boltwire?hl=en.
-- You received this message because you are subscribed to the Google Groups "BoltWire" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/boltwire?hl=en.
