The bug here was that disabling a plugin included thru goodstuff, like
htmlscrubber, caused it to be added to disable_plugins, and those plugins
were never loaded, so could not be re-enabled. Fix by allowing them to be
force loaded when appropriate. (Also that allows disabled plugins to still
record their setup options when dumping a setup file.)
The styling of labels on the form largely obsoleted the special styled ol,
so just a few br's sufficed. Using an ol like that was not too semantically
right (probably?) and could cause problems with customized local.css.
* calendar: Shorten day names, and improve styling of month calendar.
* style.css: Reduced sidebar width back to 20ex from 30; the month calendar
will now fit in the smaller width, and 30 was feeling too large.
The key is using width: auto; overflow: auto; -- this allows the div(s) to the
left of the floating sidebar to be resized to fit next to it, and prevents
any clear: both from pushing the div down below the end of the sidebar.
Many thanks for the Hurd wiki's developers for originally figuring this out.
The edit page recently developed the same problem with its textarea, now
that a sidebar can appear on that page too. In editpage.tmpl I needed to
add a new div around the editcontent textarea, as the above styles cannot
be applied directly to textareas. The textarea's own width is reduced to
98% because at least in chromium this avoids it getting unnecessary
horizonatl scrollbars when a sidebar is displayed next to it.
http://bzed.de/posts/2010/05/new_css_for_bzed.de/
smcv: [10:59:01] is the logical thing you want a <div> whose meaning is "the bits the sidebar is allowed to accompany"?
bzed: [10:59:14] yeah
bzed: [10:59:58] then you could just ensure that this part is as high as the sidebar
smcv: [11:02:44] wrapping a <div> around the sidebar, content and comments seems like the way forward, then