David A. Desrosiers wrote: >> 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.
Because a page might want to provide back functionality through a link. I agree that it is a "dirty" way of doing things, but, like it or not, desktop browsers and AvantGo do provide this functionality. And page authors do make use of it. And users might want to view these pages with Plucker, unaware of the technical caveats. >> 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? Like I said, ordinary users don't care about the technical aspects. They only care about the end result. > >> 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 fully agree with you that pages should be W3C standards-compliant. All I'm saying is that the real world is different. I'm not saying it's right. Just look at the popularity of Flash. Flash is a proprietary technology. I'd rather see an open W3C standard like SVG dominate, but that's not going to happen considering Flash's current market share. > 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). To be fair, nowadays the browser situation is much better. When I did web development (1997-2001) you still had to struggle with making your pages work with table-based layouts in both Netscape4 and IE4/5. Most of time clients didn't care about Netscape. All they knew was IE. (Besides, Netscape4 has a very bad reputation among developers. In fact, some developers charged double when the goal was to make the page work in both IE and Netscape4.) >> 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. Okay, so Plucker is an offline web viewer, not necessarily a browser. But what about the efforts to produce a conduit? Bill Nalen is working on one. And I'm considering creating one for JPluck. This will provide AvantGo-like functionality. If a good, working conduit ever comes into existence Plucker will be seen as an AvantGo replacement. In fact, I believe that many people already see Plucker as an AvantGo replacement, seeing that it does things miles better. I'm not saying that Plucker should follow AvantGo to the letter. I'm saying that Plucker should replicate some of AvantGo's functionality to make some pages work better. Regards -Laurens _______________________________________________ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
