[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120614034600.GM163@brightrain.aerifal.cx>
Date: Wed, 13 Jun 2012 23:46:00 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Wiki for musl?
On Wed, Jun 13, 2012 at 11:10:06PM -0400, Kurt H Maier wrote:
> 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
See below...
> > 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.
I understand how it works.
> > 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
Just because this is the way broken sites are done doesn't mean it has
to be that way. Suppose instead you do something like this. When the
client sends the submission to the server, the server generates the
updated contact then does a DOM-level diff of the old and new
versions, then sends a representation of the diff across to the
client-side js that incorporates it into the DOM there.
No ugly duplication, eh? And the ajax code is nearly 100% generic and
site-generic.
Rich
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.
