David A. Desrosiers wrote: > [page a] -follows link to-> [page b] > > [link on page b called "Back" <a href="a.html">] >
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. I believe this is actually what the AvantGo people had in mind with the pods:// syntax. > And thankfully, we can disable that garbage. If you mean Javascript, > look closely at the recent statistics, a large(r) percentage of > people keep Javascript and Java disabled (along with other "active" > scripting technologies) because of the whole host of problems > associated with using it, and the fact that 90% or more of people who > use it, have no idea what they're doing, and end up deploying buggy > code. I agree that JavaScript is abused in the most horrible ways(the dreaded pop-up comes to mind). I run Proxomitron to get rid of the worst behavior, but I don't have JavaScript fully disabled. However, some functionality, like client-side form validation, is nice to have, though. > Should we support Java and Flash too, because those are used as > well? No, but we should try to support the features that are easy to implement. It seems to me that a Back function code isn't difficult to add. The Viewer can already render links and it has back/forward/home functionality. It shouldn't be too difficult to combine this. >> Just look at the popularity of Flash. Flash is a proprietary >> technology. > > No, _Macromedia_ Flash is a proprietary technology, the .swf format > that drives it is not, and you can find all about it at: While it's not proprietary, Macromedia does control the SWF format. And they make sure that Flash MX offers the latest and greatest implementation for authoring SWF content. FMX is a big money-spinner for Macromedia. They have no interest in supporting open standards like SVG. >> I'd rather see an open W3C standard like SVG dominate, but that's not >> going to happen considering Flash's current market share. > > Market share doesn't dictate standards, contrary to popular media > opinion. Standards exist for a reason, and like it or not, they work. Agreed, but it isn't helping SVG. The Adobe SVG plug-in, for instance, is still way too heavy compared to Flash and there aren't enough good SVG authoring tools for designers, nothing that can compare with Flash MX, that is. Complicated as FMX may be, designers do produce some nice content with it once in a while. >> 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. > > ..probably because tables aren't designed to be used for "layout". 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. (Actually, the Netscape4-specific JavaScript stylesheets - a variant of CSS - did work reasonably well.) People just had to make do with tables. > I can't stand seeing web "developers" use 1-pixel transparent gifs > all over the place, in nested tables, just to try to position their > images on the page. Yes, I was guilty of things like that in my past > too, and I learned how to do it right, and I won't ever make those > mistakes again going forward. Yes, but you're not taking into account the importance of corporate image to some people. Your clients will push you to make the page look exactly like their paper brochure. They don't care about the transparent gifs or web-unsafe colors, they only care about what they actually see on their screen. They'll tell you that the Nike or Coca-Cola site does it this or that way, or that Levi's has this cool animation, whatever. To some people image is everything. But we're talking about the past. Back then you had to resort to these hacks. The situation is much better now. > I notified my bank of their "error" in this decision, including > copying them in on several _dozen_ incidents where IE was the direct > cause to people being taken advantage of and robbed through their > online transactions being "peeked" through IE's vulnerabilities. They > soon changed tact, and now accept other browsers. This is a good example of why standards are important, so that people have a choice. >> (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.) > > Sigh. Once again, amateur developers probably did tend to do this, > and I'm sorry it ruined it for the rest of us professional developers. I can assure you that these developers were *not* amateurs. Rather, they were experienced developers, fully aware of the many hoops you had to jump through in order to make the page look the way the client wanted(with Netscape4 being so terribly broken). But again, the situation is better now. > People who use trash tools like Dreamweaver, FrontPage, etc. to do > their "web development" should expect that their pages will only work > in a very small fraction of browsers, such as IE-only or > Netscape-only. Those two tools in particular, are among the > highest-ranked on the ladder of the tools used that generate the most > garbage code. Invalid tags, syntax, completely bogus attributes, etc. Well Dreamweaver MX does a nice job of generating XHTML 1.0 (Transitional, though.) Validator.w3.org reports these pages as valid(not just well-formed). The only thing that it complains about is one or two missing alt attribute for <img> but that's due to the user. You have to be aware of the standards. If you are, you can make DMX work up to spec, rather than let it produce rampant garbage code. > We've all got our conduits and tools that leverage Plucker in > different ways. I have my own, as does Bill, Bill, Chris (IIRC), and > others. This doesn't mean our goal is to try to pry off more and more > AvantGo users, that just happens to be an artifact of our successful > efforts at creating a tool which provides more functionality than > AvantGo provides. With the quality the Viewer it is hard to maintain that it is not an AvantGo replacement, since it does most things much better. It may not be your goal, but people see Plucker as an AvantGo replacement. And if you go the extra mile in supporting some of AvantGo's features that are relatively easy to implement in the Viewer - like the back function - you will ease over the transition. Again, I'm not saying Plucker should duplicate all of AvantGo's functionality. > Commercial companies are actually using Plucker, in their own > products, because AvantGo didn't suit their needs, and these > commercial companies _do_ have a set of conduits which directly > replace the AvantGo userbase functionality. It would be nice if these companies opened the source of their conduit. But I suspect that the conduits are specific to the needs of their company and are not suitable for general use. > Incidentally, despite my "acidic" tongue for AvantGo, I find their > ideas "interesting", but disgustingly implemented, and incredibly > insecure (i.e. "Open Page" within their browser actually proxies _and > stores_ that content on AvantGo's servers, all without telling the > end-user). I believe the AvantGo servers do the page conversion and that client just displays the parsed HTML. (I never delved into the specifics.) Of course this has marketing value since it is the ultimate way of tracking usage and controlling content. They have to earn their money some way. > http://www.gnu-designs.com/code/a-vs-p.html In the interest of fairness you should mention that AvantGo has a dedicated conduit, while Plucker does not. It is still easier to use for ordinary users. >> 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 > ^ could >> make some pages work better. > Yes, could, not should. > I agree, on that clarification. Not everyone uses Plucker for > web-based fetching or content delivery, so we can't lean too far in > that direction, lest we take functionality away from others who use > it for different methods (for me, code review, for others, ebooks, > etc.) > I don't understand how adding a back/forward/home function code will break functionality for other users. You're not taking away anything, you're adding an option. One that fits nicely with the current capabilities of the Viewer. Good discussion, though! Regards -Laurens _______________________________________________ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
