(:template default wrap=inline group=Skins name=-Skins,-*-Archive,-*-Comments,-*-Talk,-*-Draft,-*-Users,-FixFlowTips,-GeminiTips,-TriadTips,-*-RightBar,-Template,-RecentChanges,-RecentUploads,-GroupHeader,-GroupFooter,-GroupAttributes,-PreviewSkins,-SkinAlternative,-SkinChange,-SkinChanges,-SkinConfig,-SkinGuidelines,-SkinList,-SkinsGallery,-SkinTest-Compact,-SkinTests:) (:template each:)
Pukka Float is a skin carefully designed to work for everyone.
What I left out
I didn't implement access keys, because I'm leery of overriding the browser's own hotkeys.
To change the skin's options, all you have to do is (un)comment the appropriate lines in stitch_linked.css and stitch_imported.css. You'll find both of them in the css subdirectory.
If you write some new CSS files to use with the skin, you'll need to add them to one of those files. Which one you should use depends on what browsers the sheet will work in:
Colour scheme niggles
The skin package includes three colour schemes. This setup would be perfect for having extra colour schemes except that we can't have our cake (colour schemes) and eat it (css tabs with current tab marked) too. The reason why is that the selector used to pick out the current tab has a variable in it ($action). If it's in the .tmpl file, PmWiki replaces it with the current action, and it works as expected. If it's in the CSS file, PmWiki doesn't change it to anything useful, so the rule gets ignored. You have two choices:
This also means that a little bit of your configuration gets lost when you update the skin, but so long as you copied, not cut it from the colour file, or also stored it in the colour file, it's only a minor hassle.
Contribute a script
If you are annoyed by the minor hassle explained above, and know PHP, feel free to contribute a script that fixes the problem. I've figured out a basic plan of attack:
Styling the sidebar
I know that sooner or later someone will want to apply a background colour or border to the sidebar and have it continue down to the footer, even when the content column is longer than the sidebar. You can't do that in the obvious way (
Hi-fi or Columns mode
Works well in:
Likely to work well in:
Buggy but mostly readable:
Won't even guess about:
Lo-Fi or Flowed mode
Every browser with any CSS support can cope with lo-fi mode, though there may be minor rendering errors, e.g. in Internet Explorer 4. There are no columns, and more internal navigation links are visible. Browsers without CSS support will see a boring-looking but perfectly functional page, with titleblock first, then content, then sidebar, then footer.
How is it accomplished?
Simple CSS that's widely supported is applied. Then the tougher CSS is applied via "@import 'styles.css';". The precise syntax is important as it determines exactly which browsers can load those sheets (see details at http://www.dithered.com/css_filters/css_only/import_single_quotes_no_url.html).
The internal navigation links in the header and footer are hidden with a method simplified from the example at http://blog.tom.me.uk/2003/09/13/skipadeedoodah.php. (Navigation links do not appear on focus in this skin.)
The modular CSS is stitched together for page serving with the technique from http://www.fiftyfoureleven.com/sandbox/weblog/2004/aug/css-php-organized-optimized/. The skin has two stitched stylesheets instead of just one, so that lo-fi mode has some styling. I tried this technique to improve performance (fewer file requests to the server), and was delighted to find out that it made configuration much easier too!
The hi-fi layout uses the principle from http://www.alistapart.com/articles/negativemargins/. The sidebar is set in ems rather than % because it doesn't break so quickly in Internet Explorer: you can narrow the window to ~400px instead of just ~600px before the sidebar runs out of room and drops. Both columns use double divs because it's so much less hassle when styling.