David A. Desrosiers wrote: >> If you have a structure. A->C, B->C then you might actually want back >> functionality. Otherwise you have to create two copies of C (A<-C1, >> B<-C2) wasting bandwidth and space for what is essentially the same >> page. > > This makes no sense to me whatsoever. You don't need more than one > copy of C at all, just keep referencing C from wherever you call it. > This is how the web works. I don't see why you need to duplicate > information just to link to it from two different places.
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/ 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. If you visit a random page in a site, for instance, arriving via a search engine, then a link labeled "back" makes no sense at all. But these links do occur. Sloppy as they may be. > Actually, pods was designed for doing disconnected form validation, > and generating dynamic pages in response to user input on the client > device proper, not for hijacking standard webpage navigation > elements. This developer guide might provide more insight: > > http://www.avantgo.com/doc/archive/36/pods36.pdf I'll take a look at that. > ..and incredibly easy to exploit. I'd love to see a list of sites > that are still using this antiquated approach to insecure form > validation. Client-side form validation is only a bonus. Rather than requiring a roundtrip to the server, which is definitely an issue on a slow connection, you can do basic form validation on the client. (Some web application frameworks take care of this automatically. They generate the form including JS validation code for the client.) The server validation is of course what the application should rely on, but there is a place for basic client-side validation as well. 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. 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. > To the end user, they tap a link, and are brought back to the page > from whence they came. None of this involves parsing AvantGo's > proprietary pods:// style linking mechanisms. Since we already know > what page the back _arrow_ brings us to, it's a simple matter to > write that record id into the element that contains the proprietary > pods:// string. It can be a literal search and replace (and IMHO, it > should be, we shouldn't be "parsing" these for anything other than > immediate replacement/removal). 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. >> Complicated as FMX may be, designers do produce some nice content >> with it once in a while. > > Until it is 100% fully open, or browsers support it internally, it > will still remain a third-party add-on, and not used by that many > people. Does it work in text-mode browsers Flash does have a lot going for it for the end-user. For a start it is a small download, even for modem users. Second, you can do things that ordinary HTML just cannot do(or not well). I've seen online stores that are fully Flash-based and communicate to the server back-end using XML. 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. > Here's yet another place I see amateurs butchering their userbase by > replacing standard navigation elements with Javascript dropdown > menus, or using Shockwave for basic navigation elements. 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. >> Yes, but back then tables were the *only* viable method of laying >> out your pages in a way that wasn't visually boring. CSS was >> horribly broken in NS4. > > Netscape 4.xx _never_ supported CSS. It supported a subset of CSS > through JSSS, Javascript Style Sheets 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. >> (Actually, the Netscape4-specific JavaScript stylesheets - a variant >> of CSS - did work reasonably well.) People just had to make do with >> tables. > > Funny, I don't recall ever having to fall back on tables just to > make my websites look non-boring. I guess each artist carries a > different paintbrush. 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? ;-) >> I believe the AvantGo servers do the page conversion and that client >> just displays the parsed HTML. > > Ahem, and it has another suspiscious use as well. I tested this with > one of my pages just to try to prove a point awhileback. AvantGo obviously favors its registered content providers. There's probably a way for content providers to signal that the content on their site has just been updated so that the AvantGo spider retrieves the page. Or maybe they do it on scheduled basis, I don't know the specifics. 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? > Dedicated conduits are a restriction, not a feature. It means you > are locked to the platform that the conduit runs on. Still, there's no reason not to mention it. And I maintain that a HotSync conduit is easier for ordinary users. I remember being very impressed by the functionality when I installed AvantGo for the first time. > This particular addition doesn't necessarily take anything away, at > this point, but the larger issue is contining to follow in the > shadows of AvantGo's proprietary extensions to the HTML > specification. I think the goal, along with replacing simple things > like this, should be to educate content providers to fix their pages > to be compliant with the HTML specification, and other ways to > increase their readership. I've had quite a bit of good luck doing > this in the past few years. Some tell me to pound sand, and others > actually work with me to clean up their pages. 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? 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. Regards -Laurens _______________________________________________ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
