Ok... Can we, for argument sake, in the parser have it translate the pods://avantgo/back link to a link to the prior page?
I think this solves alot of the problems. --Wes ----- Original Message ----- From: "David A. Desrosiers" <[EMAIL PROTECTED]> To: "Plucker Development List" <[EMAIL PROTECTED]> Sent: Tuesday, November 19, 2002 11:12 AM Subject: Re: Back/foward/home function code > > > 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 > _______________________________________________ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
