[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 13 Jun 2012 23:10:06 -0400
From: Kurt H Maier <khm-lists@...ma.in>
To: musl@...ts.openwall.com
Subject: Re: Wiki for musl?
On Wed, Jun 13, 2012 at 08:21:40PM -0400, Rich Felker wrote:
> I assume you're talking about the live preview. What about submitting
> changes without reloading the page? To me that makes a big difference
> in the usability impression - avoiding the discontinuity of the screen
> disappearing for a second, the scrollbar getting reset, etc.
Since this was never meant to be how http works, this is a non-trivial
requirement. In fact, it's a general case that the program must be
written from the ground up to support such behavior. The only wiki
software I'm familiar with which provides this sort of functionality is
mojomojo.
> Nice, so it's all static aside from edits?
Not necessarily -- it *can* use cgi or fastcgi for lots of things. But
in its default installation, yes. One exception is for what they call
"discussion" pages -- those get dynamically managed, usually until some
cronjob dumps the data to disk and the site is recompiled. Users don't
notice this process.
> It's not that I want things to "look ajaxy". I don't mind if they look
> like the first websites from the early 90s with no styling, default
> fonts, no custom buttons, etc., but I do like having a responsive
> interface without discontinuities.
This is what I meant by "look ajaxy." http is a fetch/display protocol;
html is a markup language designed to be rendered once. dynamic
document alteration and xmlhttprequest are what ajax is all about.
> For pure static content broken into
> logical pages, I'm perfectly happy without any ajax, but if the site
> is something interactive/editable or an "application" of sorts, I
> don't like it to feel like a second-class citizen in the world of
> applications.
>
> Graceful fallback to non-AJAX when JS is disabled (or in browsers that
> don't support JS) is of course a requirement for an accessible site.
That graceful degradation is a unicorn that has never been caught. The
de facto solution that web people have adopted is in the style of
google: AJAX wherever possible, with a failover site written in regular
HTML. The two front ends share no components and will double your
development and maintenance costs up front. Recently Google has begun
to drop the HTML alternatives; GMail is a notable exception. You should
consider whether it's worth your time to support both front ends; most
places ignore the non-ajax crew. I would prefer not to, but you'll
receive no acrimony from me if you make that decision.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
