Now the toplevel layout is:
<article>
<section><header><nav></section>
<aside>sidebar</aside>
<section>content</section>
<section>comments</section>
<footer>
</article>
And I managed to preserve all CSS ids and names in their prior structure,
so CSS should not need changed.
This is a first pass, it avoids needing to change style.css
except where it refers to tag types.
This goes a bit off the rails at the pageheader with its nested header.
Semantically, there should be an article around the whole page
header, content, and footer. Just as there will be an article around a
whole comment or inlined page header, content, and footer.
But that will mean changing the css that currently refers to pageheader to
refer to the enclosing article instead.
* Ikiwiki can be configured to generate html5 instead of the default xhtml
1.0. The html5 output mode is experimental, not yet fully standards
compliant, and will be subject to rapid change.
Since Firefox version 3, it's done aggressive caching of visited pages, and
does not, by default, check if the cached content is still valid when
reloading or revisiting a page. By default, Firefox seems to not re-contact
the web server at all. Compare with eg, Epiphany and Chromium, which appear
to always check, and get back a 304 when the page is unchanged.
This header makes Firefox do the right thing, at least for html files. It
still over-caches if css, javascript, images, etc, are changed.
I chose not to have it override style.css, because style.css is not really
intended to be edited; the one from the underlay is intended to be used as
a base that local.css overrides.
I chose to use a plugin rather than changing the default behavior, both
because I didn't want to have to worry about possibly breaking backwards
compatability (though this seems unlikely), and because it seemed cleaner
to not include style template parameters in the main page template code.
I suppose someone might want a way to not override the toplevel
local.css, but instead include it as well as foo/local.css. Probably the
best way to do that would be to have foo/local.css @import ../local.css
(modulo browser compatability issues). Alternatively, edit page.tmpl
to always include the toplevel local.css, or swap out this plugin for
another one.
All the other actions are single words (apart from RecentChanges), and
are nouns (apart from Edit); saying "Source" is consistent with "History",
for instance.
* repolist: New plugin to support the rel=vcs-* microformat.
* goodstuff: Include repolist by default. (But it does nothing until
configured with the repository locations.)
The thinking here is that having both a Discussion page and comments for
the same page is redundant, and certianly not what you want if you enable
comments for a page. At first I considered making configurable via pagespec
what pages got discussion links. But that would mean testing a new pagespec
for every page, and a redundant config setting to keep in sync. So intead,
take a lead from my previous change to make inlined pages have a comments
link, and change the discussion link at the top of regular pages to link to
their comments.
(Implementation is a bit optimised to avoid redundant pagespec checking.)
* Wrap header stuff, including actions, in <div class="pageheader">
(there is already a class="header", which is a subset of this, so
using id="header" would be confusing)
* Add class="pagefooter" to the existing <div id="footer">, for symmetry
and style sheet updates, and unless you're using customised versions,
you'll want to rebuild wikis on upgrade to this version to avoid
inconsistencies.
* Allow WIKINAME to to used in footers, as an example of something to put
there.
* Add feeds=no option to inline preprocessor directive to turn off all types
of feeds. feeds=rss will still work, and feeds=atom was also added, for
fine control.
* $IkiWiki::version now holds the program version, and is accessible to
plugins.
Joey Hess
Joey Hess
Simon McVittie
Will Uther
intrigeri
Joey Hess
Simon McVittie
Josh Triplett
joey