David A. Desrosiers wrote: >> 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.
I mentioned The Onion to illustrate that HTML in the real world is sloppy. Sure, they should get their act together. Again, I'm not saying the "back" usage is right, I'm saying it happens. I have to dig up a better example. >> 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.. Not necessarily. "back" and "forward", "up", "down" should be seen as metaphors. Most people think of web browsing as "going" from one place to another, as in "visiting a site". In fact, humans use a lot spatial metaphors in their language and conceptual system. (Source: "Metaphors We Live By", a well-known book on the subject by George Lakoff and Mark Johnson.) Is this off-topic or what? ;-) > 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? The HTML DOM is a W3C standard, and JavaScript is an official standard as well(ECMAScript). I'll dig up a good example. > Then use connection-based forms, or NPH to do that work. Perhaps > XForms is what you really desire: http://www.w3.org/MarkUp/Forms/ XForms is not yet supported by the major browsers, is it? It's still a candidate recommendation. Sure, there's always the latest and greatest most standardized approach, but if you need results now you can't always have it your way. If you really want the cleanest approach then the browsers should support XSLT so we can just the deliver XML and the stylesheets and truly have a clean separation between content and presentation. However, even if they did, older browsers would continue to be used and would still have to be supported. You can't just dismiss an audience, because this or that standard is now approved by W3C. People may be using PCs that won't even run the latest Mozilla, IE, or Opera. It's just unrealistic to expect 100% compliance with standards from every client that connects. Standards are good, and necessary. We agree on that. The reality is that the popularity of the web has grown at too high a rate for standards committees to keep up. The "browser war" is also to blame. >> 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. The user might expect that pressing the enter key will submit the form, since that's how it works by default in the major browsers. Interfering with this is not a good idea from a usability standpoint. (Ironically, disabling the enter key behavior requires a JavaScript hack.) >> 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. Sorry, I still don't follow. You can determine the record id of the back link only if one page references the target. So if you have A->C B->C and want to have a back link in page C, then there's no way of figuring *at document creation time* which link, A or B, that should be. > Ugh, it uses Flash and requires Javascript to process it. No thanks Well it was an example of Flash usage, and not of HTML. The bad thing is that they have no alternative for Flash whatsoever. Still the Flash usage is very nice. > 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. This also depends on the client. Again, the situation is much better now, so you will have an easier time explaining it to the client and actually implementing a good solution. >> 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/ > I said *without* using CSS. I was trying to illustrate my point that back in the NS4/IE4 era you *had* to use tables for layout because CSS wasn't properly supported then. >> AvantGo obviously favors its registered content providers. > > And fines them steeply for allowing anyone but AvantGo in. I didn't know that. All the more reason to get back at them. ;-) >> 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. Good. Will take a stab at it next month. Expect something early in the new year. > 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). People will have to review it and comment on it. I can't figure this all out on my own. Regards -Laurens _______________________________________________ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
