I think it is clearer to not have such a button appear pre-selected
when entering the signin page, because that may suggest to the user
they don't need to click on it, and yet they do.
- fix url to flickr profile
- remove blogger; google property and uses their openid system;
wants to sign user up for a blogger blog
- remove technorati, which dropped openid provider support
- AOL seems to call it a username, not a screenname
Upstream ships a collection of icons, but the licences of them are very
unclear, since most seem to be taken from the various openid provider
websites. That can't be included in ikiwiki. So, instead hotlink to
favicons of sites, and for large display, include the site name.
Removed vidoop.com, which is gone.
If an url is passed to init as the second parameter, add a "Local Login"
provider, which just links to do=signin.
* openid: Incorporated a fancy openid-selector signin form.
(http://code.google.com/p/openid-selector/)
* openid: Use "openid_identifier" as the form field, as required
by OpenID Authentication v2.0 spec.
I noticed the onload hook running twice sometimes when using chromium.
Change from using arguments.callee.done to a onload_done variable fixed it.
I guess that the callee differed in chromium.
Probably the cause of the problem is that chrome supports both
window.onload and document.addEventListener.
If the server has a clock running a bit ahead of the web browsing client,
relativedate could cause somewhat confusing displays like "3 seconds from now"
for just posted things.
As a hack, avoid displaying times in the future if they're less than a
small slip forward. I chose 30 minutes because both client and server could
be wrong in different directions, while it's still close enough that "just
now" is not horribly wrong.
This adds support for gecko and newer versions of opera
to call onload once the DOM is ready, rather than waiting for
all images in the page to load. Makes relativedate behave
somewhat better.
Dealing with this means jumping into the browser
incompatability waters that I prefer to avoid.
Full solutions for most of the major browsers are listed here:
http://dean.edwards.name/weblog/2006/06/again/
However, no *license* is listed there, so I can't use that code. Also, the more
involved code appears to have various issues (such as the inline IE code not
working via https). So I only added the simple call to a hook needed
for gecko/opera.
It seems that the only standards-compliant way to do this is using the
`defer` attribute to a `script` tag, using an external script that will be
loaded once the DOM is ready, and can call onload. However, that has
browser compatability issues of its own, since not all browsers honor
`defer`.
Perhaps I should really just be using one of the javascript frameworks, that
include code to solve this for the major browsers. But something about them
still puts me off, and this issue is minor enough that I'm willing to live
with incomplete support for now.
* Add an underlay for javascript, and add ikiwiki.js containing some utility
code.
* toggle: Stop embedding the full toggle code on each page using it, and
move it to toggle.js in the javascript underlay.
This is sorta unfortunate, but I don't want turning the plugin on the cause
php to be forked unnecessarily. And moving them back to the plugin page
doesn't make sense in this case.
The info about the cron job was lost (!), as was a paragraph about what
pages the calendar links to.
The CSS docs seems to fit better in the plugin page than the directive
page, moved it back.
Joey Hess
Joey Hess
intrigeri
Joey Hess