> No, you don't understand, I'm talking about the link *back* from C to A or
> B. Look at the The Onion for example. http://mobile.thenion.com/
^o
Ugh, the worst of the offenders. There are no forms on the Onion's
website, yet they still need to rely on this pods://avantgo/back syntax?
Useless. On that page, _ALL_ articles reference index.html, and to all
articles, index.html is their parent. The << "The Onion" link that brings
you back could just as easily been a link to index.html, just like the
_millions_ of other fully functional websites around the world do it. I
guess this is the AvantGo'ish hack for history.back() in Javascript, and on
this site, is a completely moot example, since it doesn't actually explain
the use of it any further.
> If you have a link labeled "back" then the user expects to go back.
> Granted, there is a case for not labeling your links "back" since the
> whole concept of 'going back' is difficult to uphold on the web.
Yep, there is no "up", "back", "deep", "lower" etc. on the web.
Everything is exactly one link from everything else. The web is flat,
horizontal. Traversing "up" or "down" a website or "directory" structure is
just a human misnomer to help understand how the web works, but is
incorrect..
> The server validation is of course what the application should rely on,
> but there is a place for basic client-side validation as well.
I've yet to see it, and see in such a way that uses approved
standards (i.e. not using Javascript, Flash, ActiveX, etc.). Got a link?
> For instance, if I forget to fill in a required field I'd rather have some
> alert notifying me that I forgot that field rather than click, wait, and
> then find out to my annoyance that I still need to fill it in.
Then use connection-based forms, or NPH to do that work. Perhaps
XForms is what you really desire: http://www.w3.org/MarkUp/Forms/
> Of course, forms should be clear and well-designed. But users still make
> all kinds of mistakes. They might accidently press enter in a text field,
> thus triggering a form submission.
Then disable that feature. Enter in a form field doesn't always have
to translate to Enter on a Submit button. Poorly designed forms will do
this, however.
> I'm not sure I follow. You can never be sure of the record ID in a back
> link unless there is only one link to the text record.
Parent. You consolidate the links to the parent by the number of
times the children reference it. This happens all the time in spiders, and
I'm sure I could dig up quite a few thesus papers on the web describing it.
> One example is http://www.mycom.nl/ It's a Dutch site, though. I really
> like the way they've done it. The interface is snappy and responsive. I
> find this a good example of delivering actual usage with Flash, rather
> than just providing fancy animations or games.
Ugh, it uses Flash and requires Javascript to process it. No thanks
(and didn't properly load when both were enabled in my browser anyway).
Popup windows that remove the titlebar, removing navigation elements, all
major faux pas when designing HTML pages. Accessibility is apparently not
one of their concerns, and I'm sure they only care about their IE users
anyway, so I wish them luck. Oh, also, their error page has 404's on it (how
ironic), and a broken image. Someone should buy them a "Learn HTML in 12
Hours" book or something.
> I agree that there should be fallback behavior. A site should not
> absolutely rely on its popup menus, etc. But time is money, and designers
> won't always be able to provide alternatives for every browser. The client
> wants a fancy site, just like Nike, Coca-cola, etc.
The client only sees Nike, Coca-Cola, etc. and says "I want that".
They don't care how it works, they want it to look like that. I understand
that, and I've worked under those constraints before, but believe me, when
you show the client other alternatives, specifically one which will ensure
that their userbase will _increase_ because the site will look good in _all_
of their user's browsers, they are much more enthused, and it takes less
time to design a compatible site, than it does to design an incompatible
one.
> Netscape did support standard CSS. You can link CSS stylesheets using
> <link> and some of it works. Netscape DevEdge at least claimed NS4
> supported CSS. Sure, CSS in NS4 is *virtually* unusable.
It supported a limited subset of CSS, through the JSSS engine.
> To each their own. I still like to a see a good sidebar done without
> tables and without any CSS. Maybe a trick with <spacer> or transparent
> GIFs? ;-)
Nope, not at all. Sidebars are easy with CSS, including spacing,
etc. that will look like a transparent gif if you wish. Here's one quick
example I just googled for: http://www.meyerweb.com/eric/css/
> AvantGo obviously favors its registered content providers.
And fines them steeply for allowing anyone but AvantGo in.
> Or maybe they do it on scheduled basis, I don't know the specifics.
It's scheduled.
> To be realistic: there is no such thing as free money. Is there no small
> print on the AvantGo site or in the license that covers this?
Yes, 23 pages of small print.
> What about writing a Plucker authoring guide, with guidelines specifying
> which parts of HTML are supported, how to achieve particular formatting,
> what to do and what not to do, etc.? Or is there such a thing already?
No, but that's a great idea.
> I'm planning to write a reference for JPluck that explain how HTML is
> parsed, including a tag-by-tag reference. The Python distiller may do
> things differently, but there definitely is common ground. This reference
> can become an authoring guide over time. I'm willing to pick up this task.
Remember that there are other tools being used also, including perl
and wxWindows as well, which all handle parsing of tags a bit differently
(granted, the wxWindows bits right now are just calling the Python code, but
that will change soon, to be selectable across other spiders as necessary).
d.
_______________________________________________
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
