> Because a page might want to provide back functionality through a link.
This is akin to people removing titlebars, disabling right-click,
and a whole host of crippling features that don't do "What You Expect(tm)"
from them. If you want a page to go back, provide a normal href to the last
page you were on.
[page a] -follows link to-> [page b]
[link on page b called "Back" <a href="a.html">]
Simple.
> 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 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.
> And users might want to view these pages with Plucker, unaware of the
> technical caveats.
Should we support Java and Flash too, because those are used as
well?
> 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.
Fortunately for me, the "real world" is my world, and I work within
it. I create pages which conform to the standards, look very good in _every_
browser they are presented in (11 total browsers that I test on), and
validate in every way (look at the Plucker homepage for one example).
I can't speak for those who don't know how to write HTML in a
compliant fashion, but then again, if it isn't valid, why should someone
expect a browser (or PDA application for that matter) to "compensate" for
someone else's bad HTML?
> 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:
http://www.openswf.org/
Did you know that PHP can output directly to Flash, as well as
decode .swf files back into their native "tongue", so you can modify them?
If it was proprietary, it would be illegal (via the DMCA) to re-implement
these techniques.
> 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.
> 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".
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.
Tables are for tabular data. Period. It's also in the spec.
CSS is for layout. HTML is for structure.
> Most of time clients didn't care about Netscape. All they knew was IE.
And if you write your HTML (and CSS) properly, they should never
have to care, because it will "Just Work(tm)" if they decide to switch to
Netscape instead of IE.
Witness the online banks lately who are trying to block people who
use non-IE browsers. The irony in that, is that they couldn't figure out how
to make it work with Netscape/et al, so they force you to use the _most
insecure_ browser out there, for financial transactions (and spend much more
time and energy, i.e. dollars, making it work with IE "better" than
Netscape, thus reinforcing my earlier point, that it takes MORE time to make
it work with _one_ browser, than it does to write it properly, and have it
work with ALL browsers).
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.
> (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.
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.
> But what about the efforts to produce a conduit? Bill Nalen is working on
> one. And I'm considering creating one for JPluck.
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.
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.
> This will provide AvantGo-like functionality. If a good, working conduit
> ever comes into existence Plucker will be seen as an AvantGo replacement.
Also keep in mind that AvantGo has a set of patents around how they
use their client-server architecture to deliver content. The design I've
proposed several times over the past few years here on the lists gets around
those restrictions, and since Plucker is client-driven, not server-driven,
there are already ways we extend where AvantGo does not.
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've been
dealing with them since 1997/98, and still have a hand-written Christmas
card from their senior team, including their 3.0 software on CDR, and some
other stuff they were ponying around back then.
It was the price of AvantGo's "solution", and the incredible lack of
flexibility of it that led me to seek alternatives, and it's directly how I
found Plucker (plus playing around with Mark's cool webcam on
rubberchicken.org =)
AvantGo has also had a history with the Plucker project, in more
ways than the obvious. Let's just say that there have been some legally
questionably "incidents" coming out of the avantgo.com domain aimed directly
at the plkr.org server some time ago, until I had their netblock blocked a
couple of clicks upstream from me. They've been tame ever since.
> In fact, I believe that many people already see Plucker as an AvantGo
> replacement, seeing that it does things miles better.
Plucker is functionally superior to the capabilities that AvantGo
provides, for several reasons, the largest of which is that it is openly
documented and contains source. If AvantGo and Plucker were 100% identical,
Plucker would still win on those two counts. To that end, I've slapped up a
quick rundown of what Plucker can do, versus what AvantGo can do, which you
can find here (thanks to Blake Winton for helping me fix up some of the
points):
http://www.gnu-designs.com/code/a-vs-p.html
> 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.
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.)
All in all, a good discussion. Keep it coming.
d.
_______________________________________________
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
