> 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
