> Second, the content providers may want to keep the "history back" links > because they actually want this functionality(and sometimes it does come > in handy).
Browsers already provide this functionality, why should it be duplicated at the client-side in the HTML itself? I don't see the point. > Third, it makes Plucker look bad. Most users will only notice that the > links do not work, they don't care about the underlying technical reasons. Plucker works with valid HTML content. If I write a custom app, and have content providers using my custom application syntax, and I point a non-sanctioned application (Plucker) at that same content, and it fails, why should the blame fall on Plucker? Now, to be clear, I actually use some custom schemes in my local parser stuff here (which should make its way publically "Soon(tm)") such as: pdf://path/to/some/actual/file.pdf pg://location/to/a/Project/Gutenberg/etext.txt doc://path/to/a/Microsoft/Word/document/online ..and others. However, I encapsulate these in my tools, and don't export that syntax onto the public internet, where other tools would be able to interact with it. > Now, for some irony: the "industry standards and practices" are to target > the dominant browser, complying with W3C standards is hardly a priority or > even a consideration. ...for you. Others think very differently. > I've done web development for four years and I always faced an uphill > struggle when I tried to explain to my boss or my clients that the sites > should work in all browsers(and thus comply with common standards). All > they see is the site working fine in IE, so why should they bother with > Netscape? Time is money after all. It takes _more_ time and effort to make the site work with IE specifically, than it does to make it work with all of the browsers (incidentally, Netscape is not standards-compliant. Currently Mozilla is the only standards-compliant browser out there. IE is the worst offender). > Likewise, AvantGo is still the dominant handheld browser and I believe > that incorporating some of AvantGo's functionality, while not > standards-compliant, will help Plucker in the long run. I don't. We shouldn't follow AvantGo, because we aren't AvantGo, and we aren't trying to replace them. We're also not a web browser. d. _______________________________________________ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev