Just to clarify some of my commments - I hope I didn't come across too harsh.
Essentially, the three tools: TableSorter, TablePager, and TableSearch
are all, obviously, possible using server-side tech, and have been for
quite some time. However, what these plugins afford is a faster
response time for users who have the features to enjoy it.
To make full, unobtrusive, use of this in one of your own
applications, probably the best way to do it would be to do something
like:
// Remove the server-generated pager (still usable by disabled users
or search engines)
$("ul.pager").remove();
// Add in the "enchanced" pager for JS-enabled users
$("table").pager();
And the same would go for any other plugin that adds in some portion
of server-side functionality.
--John
On 9/12/06, John Resig <[EMAIL PROTECTED]> wrote:
> > Hmm, I'd like to voice a big concern for functionality like this, as
> > it is invisible to non-JavaScript users... Having JavaScript features
> > which do not degrade is bad for impaired users, but it also affects
> > search engines and their use.
>
> This feature has no possible applications for search engines - there
> is no reason to index results based upon the letter 'a'. Additionally,
> impared users already have tools to help them to search through pages
> faster, by keywords - which is something that this helps them to do
> (as all the results are already on one page).
>
> Obviously this is impractical for anything beyond a couple hundred
> results, but the benefits of having an instantly-responsive UI far
> outweighs the, virutally non-existant, downside to this plugin.
>
> > You cannot link to any of the later
> > pages, and even if you could (e.g. through a #-href trick) the search
> > engines would not see a difference between any of the pages and most
> > likely direct you to the first page.
>
> Ok, well, that's an issue that's completely unrelated to Javascript,
> or the plugin itself. This is a feature that I've been working to add,
> but I've put on the back-burner while fixing bugs. Eventually all
> items on the page are going to point to category-based designations,
> like: "DOM/Traversing/find.html"
>
> > Slightly related... in my most recent project I'm working with an
> > XHTML/CSS/JS design that actually uses jQuery to finish the design
> > (by adding wrapper divs and icon placeholders and whatnot). With JS
> > disabled, the design looks incomplete. I'm very annoyed at the
> > designer, but unfortunately there is no time or money to redo it, so
> > I'm stuck with it.
>
> That's why it's important to build designs the degrade nicely when
> Javascript it turned off, when CSS is disabled, when doing a print
> layout, or any combination of the above. I agree with another post
> saying that Klaus has done an excellent job taking this into
> consideration - as it's a concern of his.
>
> > Many jQuery users seems to suffering from "if all you have is a
> > hammer, everything looks like a nail" syndrome and it worries me a
> > bit :/.
>
> The pager plugin was designed to only be used in instances where you
> already have a long list of stuff, and simply want to improve its
> usefulness - not the other way around. As is the TableSorter plugin,
> or any others that work in this manner. If you want something that
> "fails gracefully" that is left as an exercise for the developer to
> complete. Adapting the tablesorter or pager plugin to fail gracefully
> is painfully trivial - and I'm not even entirely sure why this is an
> issue.
>
> --John
_______________________________________________
jQuery mailing list
[email protected]
http://jquery.com/discuss/
