From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1139 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Wiki for musl? Date: Wed, 13 Jun 2012 20:21:40 -0400 Message-ID: <20120614002140.GL163@brightrain.aerifal.cx> References: <20120613181426.GA10035@brightrain.aerifal.cx> <20120613183956.GL17860@port70.net> <20120613185127.GA29433@intma.in> <408C4093A95A4EF69AB0357291066A7F@lightcubesolutions.com> <20120613195450.GJ163@brightrain.aerifal.cx> <29654F593379412DB2311B0EFF7CADAE@lightcubesolutions.com> <20120613200006.GK163@brightrain.aerifal.cx> <20120613230947.GA66841@intma.in> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1339633573 10790 80.91.229.3 (14 Jun 2012 00:26:13 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 14 Jun 2012 00:26:13 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1140-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jun 14 02:26:12 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Sexsy-0000Od-AC for gllmg-musl@plane.gmane.org; Thu, 14 Jun 2012 02:26:04 +0200 Original-Received: (qmail 25978 invoked by uid 550); 14 Jun 2012 00:26:04 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 25970 invoked from network); 14 Jun 2012 00:26:03 -0000 Content-Disposition: inline In-Reply-To: <20120613230947.GA66841@intma.in> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:1139 Archived-At: On Wed, Jun 13, 2012 at 07:09:47PM -0400, Kurt H Maier wrote: > On Wed, Jun 13, 2012 at 04:00:06PM -0400, Rich Felker wrote: > > > > I was thinking more along the lines of AJAX for realtime update of the > > preview alongside the text (ala Stack Overflow), submission without > > reloading the whole page, etc. Not just visual presentation of the > > page. > > There are such things possible with ikiwiki. If your interested in > current status, you can glance over the discussions on ikiwiki.info, > such as http://ikiwiki.info/todo/mdwn_preview/ > > The specific feature you're talking about on stack overflow hsa been > cloned a bunch of times in general-use libraries. For an example of 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. > that, see http://code.google.com/p/pagedown/source/browse/ -- which can > be shoved into just about any wiki program. (incidentally, ikiwiki uses > markdown by default, but any (or multiple) markup compilers can be used. > the traditional 'easy' setup involves a post-commit hook on the server > that triggers a recompile of the wiki whenever someone checks in the > source.) Nice, so it's all static aside from edits? > The default ikiwiki theme and css is very sparse, but there are quite a > few drop-in replacements for them that look fancy and ajaxy. 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. 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. > Please keep in mind that lots of people still don't like using this sort > of thing. For the record, I'm one of them. 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. Rich