RE: Non-HTML (was Re: Back/foward/home function code)

2002-11-24 Thread Chris Combs
> Won't that catch valid things like CDATA?

Yep. 

--
- combs
[EMAIL PROTECTED]


> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of MJ Ray
> Sent: Wednesday, November 20, 2002 21:30
> To: [EMAIL PROTECTED]
> Subject: Re: Non-HTML (was Re: Back/foward/home function code)
___
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev



Re: Non-HTML (was Re: Back/foward/home function code)

2002-11-20 Thread MJ Ray
Chris Combs <[EMAIL PROTECTED]> wrote:
> s/<\![^>]*>//g;

Won't that catch valid things like CDATA?
-- 
MJR

___
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev



Re: Back/foward/home function code

2002-11-20 Thread Bill Janssen
> As Plucker continues to rise, I would offer that Plucker chooses the
> best practices, in the form of documented W3C and ISO standards,
> instead of picking up the bad practices of the withering commercial
> off-line browsers.

Indeed.  I'm spending my time working on CSS support, not worrying
about some odd feature some other soon-to-bankrupt commercial venture
has mistakenly introduced.

Bill

___
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev



Re: Back/foward/home function code

2002-11-20 Thread Bill Janssen
Please add a feature request to the bug tracker.

> Wesley Mason wrote:
> > Ok...
> > 
> > Can we, for argument sake, in the parser have it translate the
> > pods://avantgo/back link to a link to the prior page?
> > 
> > I think this solves alot of the problems.
> 
> I totally agree. This is the best solution for now.
> 
> 
> Regards
> -Laurens
> ___
> plucker-dev mailing list
> [EMAIL PROTECTED]
> http://lists.rubberchicken.org/mailman/listinfo/plucker-dev

___
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev



Re: Back/foward/home function code

2002-11-20 Thread Bill Janssen
> Can we, for argument sake, in the parser have it translate the
> pods://avantgo/back link to a link to the prior page?
> 
> I think this solves alot of the problems.

It would if the distiller kept that info, but it doesn't (and it would
be very difficult to keep it correctly, since the order in which pages
are gathered doesn't really depend on the links which point to them).

Bill
___
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev



Re: Back/foward/home function code

2002-11-20 Thread Laurens M. Fridael
Dave Maddock wrote:
> I think this is a great idea.  I'd be willing to help out.  I've been
> meaning to write a guide for Pluckerbooks (with an ebooks slant of
> course) for some time, but it would be nice to have an 'official'
> plucker guide.

Great! I'll start on it in December. Hopefully I'll have something to show
early next year.


Regards
-Laurens

___
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev



Re: Non-HTML (was Re: Back/foward/home function code)

2002-11-19 Thread David A. Desrosiers

> > Yes!  We want  in Plucker now!

> I enjoyed the Python comment next to the 'blink' on the list of currently
> unimplemented tags in the Parser (TextParser.py, around line 855). Props
> to whoever wrote that in.

Appears to be Ondrej back in Parser.py, almost to the day 11/22/99.

For those that don't remember him, Ondrej Palkovsky[1] and Holger
Duerer wrote the first Python iterations back in 1999 that replaced the
awk/perl code we were using, and it was the first to use "disconnected"
fetching mode. Previously, you had to cradle your Palm, and a single .pdb
was created at sync time on your Palm, one... record... at... a... time.



[1] http://www.penguin.cz/~ondrap/

d.


___
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev



Re: Non-HTML (was Re: Back/foward/home function code)

2002-11-19 Thread Robert O'Connor
On 20 Nov 2002 at 0:55, MJ Ray wrote:

> Robert O'Connor <[EMAIL PROTECTED]> wrote:
> > -Others: maybe the "marquee" tag from MSIE 3.x days, and all the other non-
> > standard crap that has come and gone over the years.
> 
> Yes!  We want  in Plucker now!

I enjoyed the Python comment next to the 'blink' on the list of currently 
unimplemented tags in 
the Parser (TextParser.py, around line 855). Props to whoever wrote that in.
 
> Seriously, has anyone who asks for support for standards-breaking actually
> thought the effect of it through to a conclusion?  I think Plucker should be
> praised for taking a reasonably pure-standards approach on this.  It's the
> only way that you can hope to keep things sane *and* moving forwards.

I agree 100%. 
I am amazed that any web designer which has struggled with the pain of having to deal 
with the 
woes of proprietary browser tags in years gone by, and is now working on Plucker with 
a bona-
fide chance to shape their own future of their distribution medium tools, would opt 
for 
pollution of them by standards-breaking non-HTML.

Best wishes,
Robert
___
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev



Re: Non-HTML (was Re: Back/foward/home function code)

2002-11-19 Thread MJ Ray
Robert O'Connor <[EMAIL PROTECTED]> wrote:
> -Others: maybe the "marquee" tag from MSIE 3.x days, and all the other non-
> standard crap that has come and gone over the years.

Yes!  We want  in Plucker now!

Seriously, has anyone who asks for support for standards-breaking actually
thought the effect of it through to a conclusion?  I think Plucker should be
praised for taking a reasonably pure-standards approach on this.  It's the
only way that you can hope to keep things sane *and* moving forwards.

___
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev



Re: Non-HTML (was Re: Back/foward/home function code)

2002-11-19 Thread Fringe Ryder
At 11:54 PM 11/19/2002  +, Robert O'Connor wrote:

On 19 Nov 2002 at 15:22, Fringe Ryder wrote:

> At 10:53 PM 11/19/2002  +, Robert O'Connor wrote:
> >On 18 Nov 2002 at 21:43, Laurens M. Fridael wrote:
> > > complying with W3C standards is hardly a priority or
> > > even a consideration.
> >
> >I would tend to differ on that point.
> >
> >Over the next few years, Plucker is going to become the dominant force as
> >it continues to
> >mature and the commercial alternatives wither. AvantGo, in particular is
> >on the downgrade, with
> >a delisted stock, layoffs, CEO resignations, and sagging sales.
> >
> >As Plucker continues to rise, I would offer that Plucker chooses the best
> >practices, in the
> >form of documented W3C and ISO standards, instead of picking up the bad
> >practices of the
> >withering commercial off-line browsers.
>
> Hmm... what about those of us who want the tool to work in as many 
cases as
> easily-possible, rather than being holier-than-thou and refusing to 
work on
> sites because they have innocuously-broken code?
>
> (This doesn't refer to the "back" functionality; I don't care about
> that.  I use Plucker for content, not for buttons.  It just refers to the
> board-mentality that Plucker should be less tolerant of errors than any
> browser, instead actively refusing to touch sites with even the most minor
> of transgressions.)

*I* am not going to:
(a) work on crap non-standard proprietary non-HTML.
(b) offer support on mailing lists on how to use crap non-standard 
proprietary
non-HTML.
(c) maintain the extra work to maintain compatibility of crap non-standard
proprietary non-HTML, as they change underfoot since they aren't standard.
(d) document them all and how to make them work.
(e) maintain the docs.

Robert, I'm not clear that you've done any parser work anyhow; I don't 
expect you to work on it.  You did the Desktop, which is also extremely 
important and impressive, and very content-agnostic.  But do you notice any 
prejudicial tone in your message?
"crap non-standard proprietary non-HTML"

Nobody asked for support of that specifically.  Sure, some "non-standard" 
HTML, depending on whose standard (W3 or the real world/market.)  Sure, 
some crappy HTML that would have been standard if not for the fact that a 
color (to use your example) wound up not in the standard or a tag got 
misused in a common fashion.  Certainly not any "non-HTML", unless you 
define "non-HTML" the way David does, as disqualifying a document that has 
a single malformed comment tag, for example.

I have made several parser changes recently, and would consider doing some 
to expand Plucker's usefulness should a common not-quite-standard usage be 
interfering broadly with usage.  Things that are perhaps supported by all 
four major browsers we might want to consider.  Purity that substantially 
reduces functionality is useless.

Which is nice, but currently (for me) academic.  No such features are 
annoying me.  I never noticed the example you used, the non-implemented 
color code, perhaps due to a certain level of color blindness.  I don't use 
"back" buttons; the browser's history is good enough for me since it DOES 
take me back where I came from.  And I have scripting (and cookies 
generally) disabled in my browser (Opera), so I don't tend to see sites 
that require them and would fail in Plucker.  But the philosophy remains 
none-the-less: I want Plucker to be useful more than I want it to be an 
arrogantly useless tribute to a standards body.

On the bright side, right now it's both a tribute to a standards body AND 
useful, at least to me.  But if we should have to pick a direction in the 
future, I vote "useful."  And, as long as nobody screams too loudly, I'll 
code it too.

-Tony McNamara-

___
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev


Re: Back/foward/home function code

2002-11-19 Thread Fringe Ryder
At 10:53 PM 11/19/2002  +, Robert O'Connor wrote:

On 18 Nov 2002 at 21:43, Laurens M. Fridael wrote:
> complying with W3C standards is hardly a priority or
> even a consideration.

I would tend to differ on that point.

Over the next few years, Plucker is going to become the dominant force as 
it continues to
mature and the commercial alternatives wither. AvantGo, in particular is 
on the downgrade, with
a delisted stock, layoffs, CEO resignations, and sagging sales.

As Plucker continues to rise, I would offer that Plucker chooses the best 
practices, in the
form of documented W3C and ISO standards, instead of picking up the bad 
practices of the
withering commercial off-line browsers.

Hmm... what about those of us who want the tool to work in as many cases as 
easily-possible, rather than being holier-than-thou and refusing to work on 
sites because they have innocuously-broken code?

(This doesn't refer to the "back" functionality; I don't care about 
that.  I use Plucker for content, not for buttons.  It just refers to the 
board-mentality that Plucker should be less tolerant of errors than any 
browser, instead actively refusing to touch sites with even the most minor 
of transgressions.)

-Tony McNamara-

___
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev


Re: Back/foward/home function code

2002-11-19 Thread Laurens M. Fridael
Robert O'Connor wrote:
> On 18 Nov 2002 at 21:43, Laurens M. Fridael wrote:
>
>> complying with W3C standards is hardly a priority or
>> even a consideration.
>
> I would tend to differ on that point.

You're quoting out of context! I already had a lengthy discussion with David
about this. I'm not going to explain my point of view again.


Regards
-Laurens


___
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev



Re: Back/foward/home function code

2002-11-19 Thread Robert O'Connor
On 19 Nov 2002 at 11:12, David A. Desrosiers wrote:

>   Ugh, the worst of the offenders. There are no forms on the Onion's
> website, yet they still need to rely on this pods://avantgo/back syntax?
> Useless. On that page, _ALL_ articles reference index.html, and to all
> articles, index.html is their parent. The << "The Onion" link that brings
> you back could just as easily been a link to index.html, just like the
> _millions_ of other fully functional websites around the world do it. I
> guess this is the AvantGo'ish hack for history.back() in Javascript, and on
> this site, is a completely moot example, since it doesn't actually explain
> the use of it any further.

I agree 100%.
The only possible reason that I can see for it, is that it is one less link to queue, 
because 
it isn't a true hyperlink, it is an embedded command. 
I don't know how it is in AvantGo, since I haven't used it in about a year, but in 
Plucker, 
many of the sites require breadth first, and breadth first maintains a queue of all 
links until 
the end until it sees if it has already been retrieved. 
So in the onion case:
-With regular links to index.html: 10 extra links are queued and get time is spent 
checking, 
and seeing that it already been downloaded.
-With "back" commands: no extra links queued, no memory required to store this link 
until the 
end.

It is bit dubious though as far as whether functionality goes though. 

Best wishes,
Robert
___
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev



Re: Back/foward/home function code

2002-11-19 Thread Robert O'Connor
On 18 Nov 2002 at 21:43, Laurens M. Fridael wrote:

> complying with W3C standards is hardly a priority or
> even a consideration. 

I would tend to differ on that point.

Over the next few years, Plucker is going to become the dominant force as it continues 
to 
mature and the commercial alternatives wither. AvantGo, in particular is on the 
downgrade, with 
a delisted stock, layoffs, CEO resignations, and sagging sales.

As Plucker continues to rise, I would offer that Plucker chooses the best practices, 
in the 
form of documented W3C and ISO standards, instead of picking up the bad practices of 
the 
withering commercial off-line browsers.

Best wishes,
Robert
___
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev



Re: Back/foward/home function code

2002-11-19 Thread Dave Maddock
>What about writing a Plucker authoring guide, with guidelines specifying
>which parts of HTML are supported, how to achieve particular formatting,
>what to do and what not to do, etc.? Or is there such a thing already?
>I'm planning to write a reference for JPluck that explain how HTML is
>parsed, including a tag-by-tag reference. The Python distiller may do
>things differently, but there definitely is common ground. This reference
can
>become an authoring guide over time. I'm willing to pick up this task.

I think this is a great idea.  I'd be willing to help out.  I've been
meaning to write a guide for Pluckerbooks (with an ebooks slant of
course) for some time, but it would be nice to have an 'official'
plucker guide.

Dave.
[EMAIL PROTECTED]



___
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev



Re: Back/foward/home function code

2002-11-19 Thread MJ Ray
Laurens M. Fridael <[EMAIL PROTECTED]> wrote:
>> it seems that SVG may not be in a happy place for free software
>> either, because of patents held on some of its core methods.
> Akin to the LZW patent used by GIF? I'll take a look.

Actually, I think they're far more pervasive than that.  With the GIF
patent, there was only one and a better format that avoided the patent was
possible anyway.

>> Please, get your hands dirty and start work if you're convinced
>> people will want this.  It may well be the case that you have to
>> maintain a "PluckNGo" branch so as not to load the main code with a
>> lot of unnecessary baggage, but it should be doable.
> Right now, JPluck takes up all my programming time and there's still a lot
> to cover there. Maybe later.

Indeed, I understand that, but I don't think any of the current core have
the right time+willing available to do this for you now, so pleading will
have little effect.  Maybe it will encourage someone new to start
contributing to plucker?  Failing that, it will just have to wait.

MJR

___
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev



Re: Back/foward/home function code

2002-11-19 Thread Laurens M. Fridael
Wesley Mason wrote:
> Ok...
> 
> Can we, for argument sake, in the parser have it translate the
> pods://avantgo/back link to a link to the prior page?
> 
> I think this solves alot of the problems.

I totally agree. This is the best solution for now.


Regards
-Laurens
___
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev



Re: Back/foward/home function code

2002-11-19 Thread Laurens M. Fridael
David A. Desrosiers wrote:
>> No, you don't understand, I'm talking about the link *back* from C
>> to A or B. Look at the The Onion for example.
>> http://mobile.thenion.com/
>  ^o
>
> Ugh, the worst of the offenders. There are no forms on the Onion's
> website, yet they still need to rely on this pods://avantgo/back
> syntax? Useless. On that page, _ALL_ articles reference index.html,
> and to all articles, index.html is their parent. The << "The Onion"
> link that brings you back could just as easily been a link to
> index.html, just like the _millions_ of other fully functional
> websites around the world do it. I guess this is the AvantGo'ish hack
> for history.back() in Javascript, and on this site, is a completely
> moot example, since it doesn't actually explain the use of it any
> further.

I  mentioned The Onion to illustrate that HTML in the real world is sloppy.
Sure, they should get their act together. Again, I'm not saying the "back"
usage is right, I'm saying it happens. I have to dig up a better example.

>> If you have a link labeled "back" then the user expects to go back.
>> Granted, there is a case for not labeling your links "back" since the
>> whole concept of 'going back' is difficult to uphold on the web.
>
> Yep, there is no "up", "back", "deep", "lower" etc. on the web.
> Everything is exactly one link from everything else. The web is flat,
> horizontal. Traversing "up" or "down" a website or "directory"
> structure is just a human misnomer to help understand how the web
> works, but is incorrect..

Not necessarily. "back" and "forward", "up", "down" should be seen as
metaphors. Most people think of web browsing as "going" from one place to
another, as in "visiting a site". In fact, humans use a lot spatial
metaphors in their language and conceptual system. (Source: "Metaphors We
Live By", a well-known book on the subject by George Lakoff and Mark
Johnson.) Is this off-topic or what? ;-)

> I've yet to see it, and see in such a way that uses approved
> standards (i.e. not using Javascript, Flash, ActiveX, etc.). Got a
> link?

The HTML DOM is a W3C standard, and JavaScript is an official standard as
well(ECMAScript). I'll dig up a good example.

> Then use connection-based forms, or NPH to do that work. Perhaps
> XForms is what you really desire: http://www.w3.org/MarkUp/Forms/

XForms is not yet supported by the major browsers, is it? It's still a
candidate recommendation. Sure, there's always the latest and greatest most
standardized approach, but if you need results now you can't always have it
your way.

If you really want the cleanest approach then the browsers should support
XSLT so we can just the deliver XML and the stylesheets and truly have a
clean separation between content and presentation. However, even if they
did, older browsers would continue to be used and would still have to be
supported. You can't just dismiss an audience, because this or that standard
is now approved by W3C. People may be using PCs that won't even run the
latest Mozilla, IE, or Opera.

It's just unrealistic to expect 100% compliance with standards from every
client that connects. Standards are good, and necessary. We agree on that.
The reality is that the popularity of the web has grown at too high a rate
for standards committees to keep up. The "browser war" is also to blame.

>> Of course, forms should be clear and well-designed. But users still
>> make all kinds of mistakes. They might accidently press enter in a
>> text field, thus triggering a form submission.
>
> Then disable that feature. Enter in a form field doesn't always have
> to translate to Enter on a Submit button. Poorly designed forms will
> do this, however.

The user might expect that pressing the enter key will submit the form,
since that's how it works by default in the major browsers. Interfering with
this is not a good idea from a usability standpoint. (Ironically, disabling
the enter key behavior requires a JavaScript hack.)

>> I'm not sure I follow. You can never be sure of the record ID in a
>> back link unless there is only one link to the text record.
>
> Parent. You consolidate the links to the parent by the number of
> times the children reference it. This happens all the time in
> spiders, and I'm sure I could dig up quite a few thesus papers on the
> web describing it.

Sorry, I still don't follow. You can determine the record id of the back
link only if one page references the target.

So if you have
A->C
B->C
and want to have a back link in page C, then there's no way of figuring *at
document creation time* which link, A or B, that should be.

> Ugh, it uses Flash and requires Javascript to process it. No thanks

Well it was an example of Flash usage, and not of HTML. The bad thing is
that they have no alternative for Flash whatsoever. Still the Flash usage is
very nice.

> The client only sees Nike, Coca-Cola, etc. and says "I want that".
> They don't ca

Re: Back/foward/home function code

2002-11-19 Thread Wesley Mason
Ok...

Can we, for argument sake, in the parser have it translate the
pods://avantgo/back link to a link to the prior page?

I think this solves alot of the problems.

--Wes


- Original Message -
From: "David A. Desrosiers" <[EMAIL PROTECTED]>
To: "Plucker Development List" <[EMAIL PROTECTED]>
Sent: Tuesday, November 19, 2002 11:12 AM
Subject: Re: Back/foward/home function code


>
> > No, you don't understand, I'm talking about the link *back* from C to A
or
> > B. Look at the The Onion for example. http://mobile.thenion.com/
>  ^o
>
> Ugh, the worst of the offenders. There are no forms on the Onion's
> website, yet they still need to rely on this pods://avantgo/back syntax?
> Useless. On that page, _ALL_ articles reference index.html, and to all
> articles, index.html is their parent. The << "The Onion" link that brings
> you back could just as easily been a link to index.html, just like the
> _millions_ of other fully functional websites around the world do it. I
> guess this is the AvantGo'ish hack for history.back() in Javascript, and
on
> this site, is a completely moot example, since it doesn't actually explain
> the use of it any further.
>
> > If you have a link labeled "back" then the user expects to go back.
> > Granted, there is a case for not labeling your links "back" since the
> > whole concept of 'going back' is difficult to uphold on the web.
>
> Yep, there is no "up", "back", "deep", "lower" etc. on the web.
> Everything is exactly one link from everything else. The web is flat,
> horizontal. Traversing "up" or "down" a website or "directory" structure
is
> just a human misnomer to help understand how the web works, but is
> incorrect..
>
> > The server validation is of course what the application should rely on,
> > but there is a place for basic client-side validation as well.
>
> I've yet to see it, and see in such a way that uses approved
> standards (i.e. not using Javascript, Flash, ActiveX, etc.). Got a link?
>
> > For instance, if I forget to fill in a required field I'd rather have
some
> > alert notifying me that I forgot that field rather than click, wait, and
> > then find out to my annoyance that I still need to fill it in.
>
> Then use connection-based forms, or NPH to do that work. Perhaps
> XForms is what you really desire: http://www.w3.org/MarkUp/Forms/
>
> > Of course, forms should be clear and well-designed. But users still make
> > all kinds of mistakes. They might accidently press enter in a text
field,
> > thus triggering a form submission.
>
> Then disable that feature. Enter in a form field doesn't always have
> to translate to Enter on a Submit button. Poorly designed forms will do
> this, however.
>
> > I'm not sure I follow. You can never be sure of the record ID in a back
> > link unless there is only one link to the text record.
>
> Parent. You consolidate the links to the parent by the number of
> times the children reference it. This happens all the time in spiders, and
> I'm sure I could dig up quite a few thesus papers on the web describing
it.
>
> > One example is http://www.mycom.nl/ It's a Dutch site, though. I really
> > like the way they've done it. The interface is snappy and responsive. I
> > find this a good example of delivering actual usage with Flash, rather
> > than just providing fancy animations or games.
>
> Ugh, it uses Flash and requires Javascript to process it. No thanks
> (and didn't properly load when both were enabled in my browser anyway).
> Popup windows that remove the titlebar, removing navigation elements, all
> major faux pas when designing HTML pages. Accessibility is apparently not
> one of their concerns, and I'm sure they only care about their IE users
> anyway, so I wish them luck. Oh, also, their error page has 404's on it
(how
> ironic), and a broken image. Someone should buy them a "Learn HTML in 12
> Hours" book or something.
>
> > I agree that there should be fallback behavior. A site should not
> > absolutely rely on its popup menus, etc. But time is money, and
designers
> > won't always be able to provide alternatives for every browser. The
client
> > wants a fancy site, just like Nike, Coca-cola, etc.
>
> The client only sees Nike, Coca-Cola, etc. and says "I want that".
> They don't care how it works, they want it to look like that. I understand
> that, and I've worked under those constraints before, bu

Re: Back/foward/home function code

2002-11-19 Thread David A. Desrosiers

> No, you don't understand, I'm talking about the link *back* from C to A or
> B. Look at the The Onion for example. http://mobile.thenion.com/
 ^o

Ugh, the worst of the offenders. There are no forms on the Onion's
website, yet they still need to rely on this pods://avantgo/back syntax?
Useless. On that page, _ALL_ articles reference index.html, and to all
articles, index.html is their parent. The << "The Onion" link that brings
you back could just as easily been a link to index.html, just like the
_millions_ of other fully functional websites around the world do it. I
guess this is the AvantGo'ish hack for history.back() in Javascript, and on
this site, is a completely moot example, since it doesn't actually explain
the use of it any further.

> If you have a link labeled "back" then the user expects to go back.
> Granted, there is a case for not labeling your links "back" since the
> whole concept of 'going back' is difficult to uphold on the web.

Yep, there is no "up", "back", "deep", "lower" etc. on the web.
Everything is exactly one link from everything else. The web is flat,
horizontal. Traversing "up" or "down" a website or "directory" structure is
just a human misnomer to help understand how the web works, but is
incorrect..

> The server validation is of course what the application should rely on,
> but there is a place for basic client-side validation as well.

I've yet to see it, and see in such a way that uses approved
standards (i.e. not using Javascript, Flash, ActiveX, etc.). Got a link?

> For instance, if I forget to fill in a required field I'd rather have some
> alert notifying me that I forgot that field rather than click, wait, and
> then find out to my annoyance that I still need to fill it in.

Then use connection-based forms, or NPH to do that work. Perhaps
XForms is what you really desire: http://www.w3.org/MarkUp/Forms/

> Of course, forms should be clear and well-designed. But users still make
> all kinds of mistakes. They might accidently press enter in a text field,
> thus triggering a form submission.

Then disable that feature. Enter in a form field doesn't always have
to translate to Enter on a Submit button. Poorly designed forms will do
this, however.

> I'm not sure I follow. You can never be sure of the record ID in a back
> link unless there is only one link to the text record.

Parent. You consolidate the links to the parent by the number of
times the children reference it. This happens all the time in spiders, and
I'm sure I could dig up quite a few thesus papers on the web describing it.

> One example is http://www.mycom.nl/ It's a Dutch site, though. I really
> like the way they've done it. The interface is snappy and responsive. I
> find this a good example of delivering actual usage with Flash, rather
> than just providing fancy animations or games.

Ugh, it uses Flash and requires Javascript to process it. No thanks
(and didn't properly load when both were enabled in my browser anyway).
Popup windows that remove the titlebar, removing navigation elements, all
major faux pas when designing HTML pages. Accessibility is apparently not
one of their concerns, and I'm sure they only care about their IE users
anyway, so I wish them luck. Oh, also, their error page has 404's on it (how
ironic), and a broken image. Someone should buy them a "Learn HTML in 12
Hours" book or something.

> I agree that there should be fallback behavior. A site should not
> absolutely rely on its popup menus, etc. But time is money, and designers
> won't always be able to provide alternatives for every browser. The client
> wants a fancy site, just like Nike, Coca-cola, etc.

The client only sees Nike, Coca-Cola, etc. and says "I want that".
They don't care how it works, they want it to look like that. I understand
that, and I've worked under those constraints before, but believe me, when
you show the client other alternatives, specifically one which will ensure
that their userbase will _increase_ because the site will look good in _all_
of their user's browsers, they are much more enthused, and it takes less
time to design a compatible site, than it does to design an incompatible
one.

> Netscape did support standard CSS. You can link CSS stylesheets using
>  and some of it works. Netscape DevEdge at least claimed NS4
> supported CSS. Sure, CSS in NS4 is *virtually* unusable.

It supported a limited subset of CSS, through the JSSS engine.

> To each their own. I still like to a see a good sidebar done without
> tables and without any CSS. Maybe a trick with  or transparent
> GIFs? ;-)

Nope, not at all. Sidebars are easy with CSS, including spacing,
etc. that will look like a transparent gif if you wish. Here's one quick
example I just googled for: http://www.meyerweb.com/eric/css/

> AvantGo obviously favors its registered content providers.

An

Re: Back/foward/home function code

2002-11-19 Thread Laurens M. Fridael
Blake Winton wrote:
> What do you mean by a "dedicated conduit"?  Plucker has had
> a (Win32) conduit for quite a while now.

Where?


Regards
-Laurens
___
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev



Re: Back/foward/home function code

2002-11-19 Thread Laurens M. Fridael
David A. Desrosiers wrote:
>> 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.
>
> This makes no sense to me whatsoever. You don't need more than one
> copy of C at all, just keep referencing C from wherever you call it.
> This is how the web works. I don't see why you need to duplicate
> information just to link to it from two different places.

No, you don't understand, I'm talking about the link *back* from C to A or
B. Look at the The Onion for example. http://mobile.thenion.com/

If you have a link labeled "back" then the user expects to go back. Granted,
there is a case for not labeling your links "back" since the whole concept
of 'going back' is difficult to uphold on the web. If you visit a random
page in a site, for instance, arriving via a search engine, then a link
labeled "back" makes no sense at all. But these links do occur. Sloppy as
they may be.

> Actually, pods was designed for doing disconnected form validation,
> and generating dynamic pages in response to user input on the client
> device proper, not for hijacking standard webpage navigation
> elements. This developer guide might provide more insight:
>
> http://www.avantgo.com/doc/archive/36/pods36.pdf

I'll take a look at that.

> ..and incredibly easy to exploit. I'd love to see a list of sites
> that are still using this antiquated approach to insecure form
> validation.

Client-side form validation is only a bonus. Rather than requiring a
roundtrip to the server, which is definitely an issue on a slow connection,
you can do basic form validation on the client. (Some web application
frameworks take care of this automatically. They generate the form including
JS validation code for the client.)

The server validation is of course what the application should rely on, but
there is a place for basic client-side validation as well. For instance, if
I forget to fill in a required field I'd rather have some alert notifying me
that I forgot that field rather than click, wait, and then find out to my
annoyance that I still need to fill it in.

Of course, forms should be clear and well-designed. But users still make all
kinds of mistakes. They might accidently press enter in a text field, thus
triggering a form submission.

> To the end user, they tap a link, and are brought back to the page
> from whence they came. None of this involves parsing AvantGo's
> proprietary pods:// style linking mechanisms. Since we already know
> what page the back _arrow_ brings us to, it's a simple matter to
> write that record id into the element that contains the proprietary
> pods:// string. It can be a literal search and replace (and IMHO, it
> should be, we shouldn't be "parsing" these for anything other than
> immediate replacement/removal).

I'm not sure I follow. You can never be sure of the record ID in a back link
unless there is only one link to the text record.

>> Complicated as FMX may be, designers do produce some nice content
>> with it once in a while.
>
> Until it is 100% fully open, or browsers support it internally, it
> will still remain a third-party add-on, and not used by that many
> people. Does it work in text-mode browsers

Flash does have a lot going for it for the end-user. For a start it is a
small download, even for modem users. Second, you can do things that
ordinary HTML just cannot do(or not well). I've seen online stores that are
fully Flash-based and communicate to the server back-end using XML.

One example is http://www.mycom.nl/   It's a Dutch site, though. I really
like the way they've done it. The interface is snappy and responsive. I find
this a good example of delivering actual usage with Flash, rather than just
providing fancy animations or games.

> Here's yet another place I see amateurs butchering their userbase by
> replacing standard navigation elements with Javascript dropdown
> menus, or using Shockwave for basic navigation elements.

I agree that there should be fallback behavior. A site should not absolutely
rely on its popup menus, etc. But time is money, and designers won't always
be able to provide alternatives for every browser. The client wants a fancy
site, just like Nike, Coca-cola, etc.

>> 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.
>
> Netscape 4.xx _never_ supported CSS. It supported a subset of CSS
> through JSSS, Javascript Style Sheets

Netscape did support standard CSS. You can link CSS stylesheets using 
and some of it works. Netscape DevEdge at least claimed NS4 supported CSS.
Sure, CSS in NS4 is *virtually* unusable.

>> (Actually, the Netscape4-specific JavaScript stylesheets - a variant
>> of CSS - did work reasonably well.) People just had to make do with
>> tables.
>
> Funny, I don't recall ever having to f

Re: Back/foward/home function code

2002-11-19 Thread Laurens M. Fridael
MJ Ray wrote:
> There's a conversation just started on [EMAIL PROTECTED] and
> it seems that SVG may not be in a happy place for free software
> either, because of patents held on some of its core methods.

Akin to the LZW patent used by GIF? I'll take a look.

> Please, get your hands dirty and start work if you're convinced
> people will want this.  It may well be the case that you have to
> maintain a "PluckNGo" branch so as not to load the main code with a
> lot of unnecessary baggage, but it should be doable.

Right now, JPluck takes up all my programming time and there's still a lot
to cover there. Maybe later.


Regards
-Laurens

___
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev



RE: Back/foward/home function code

2002-11-19 Thread Blake Winton
> > 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)
> This makes no sense to me whatsoever. You don't need more
> than one copy of C at all, just keep referencing C from
> wherever you call it. This is how the web works. I don't see
> why you need to duplicate information just to link to it from
> two different places.

Okay, I've got two pages, A, and B.  Both have a link to C.
I want to put a "Back" link on C.  Which page does it point to?

> > However, some functionality, like client-side form 
> > validation, is nice to have, though.
> ..and incredibly easy to exploit. I'd love to see a list
> of sites that are still using this antiquated approach to
> insecure form validation.

I used to use client-side form validation _all_ the time.
Not as a replacement for server-side validation, but as a
way to short-cut most of the errors the client might get,
since it's a lot faster than having to make yet another
connection to the server to find out what's wrong.

> Yes, and some are blatently violating the GPL with it 
> too, still an open issue with the core Plucker team,
> and one which should be resolved soon.

Oooh!  This sounds like a teaser for some good news.
I can't wait.

> > 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.

What do you mean by a "dedicated conduit"?  Plucker has had
a (Win32) conduit for quite a while now.

> it still tethers your Palm to the cradle until the entire
> content is fetched and delivered, something Plucker does
> not do, thankfully.

And that's why I uninstalled the Plucker conduit a week after
installing it.  :)

> I think the goal, along with replacing simple things like
> this, should be to educate content providers to fix their
> pages to be compliant with the HTML specification, and other
> ways to increase their readership.  I've had quite a bit of
> good luck doing this in the past few years. Some tell me to
> pound sand, and others actually work with me to clean up
> their pages.

I think that the goal should be to produce a browser that
handles as many things as it can without becoming too slow.

(I've found that asking people to fix their pages has been
 almost as useful as pounding sand, and so would rather have
 a client that's liberal in what it accepts, and does its
 best to render whatever crap it's given.)

Of course, this is the beauty of Open Source.  People can
submit patches to drive the product in the direction they
want it to go.

Later,
Blake.

___
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev



Re: Back/foward/home function code

2002-11-19 Thread MJ Ray
Laurens M. Fridael <[EMAIL PROTECTED]> wrote:
> [...] 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. [...]

There's a conversation just started on [EMAIL PROTECTED] and it seems
that SVG may not be in a happy place for free software either, because of
patents held on some of its core methods.

[...]
> 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. [...]

Please, get your hands dirty and start work if you're convinced people will
want this.  It may well be the case that you have to maintain a "PluckNGo"
branch so as not to load the main code with a lot of unnecessary baggage,
but it should be doable.

___
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev



Re: Back/foward/home function code

2002-11-19 Thread David A. Desrosiers

> 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.

This makes no sense to me whatsoever. You don't need more than one
copy of C at all, just keep referencing C from wherever you call it. This is
how the web works. I don't see why you need to duplicate information just to
link to it from two different places.

> I believe this is actually what the AvantGo people had in mind with the
> pods:// syntax.

Actually, pods was designed for doing disconnected form validation,
and generating dynamic pages in response to user input on the client device
proper, not for hijacking standard webpage navigation elements. This
developer guide might provide more insight:

http://www.avantgo.com/doc/archive/36/pods36.pdf

> However, some functionality, like client-side form validation, is nice to
> have, though.

..and incredibly easy to exploit. I'd love to see a list of sites
that are still using this antiquated approach to insecure form validation.

> 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.

To the end user, they tap a link, and are brought back to the page
from whence they came. None of this involves parsing AvantGo's proprietary
pods:// style linking mechanisms. Since we already know what page the back
_arrow_ brings us to, it's a simple matter to write that record id into the
element that contains the proprietary pods:// string. It can be a literal
search and replace (and IMHO, it should be, we shouldn't be "parsing" these
for anything other than immediate replacement/removal).

> Complicated as FMX may be, designers do produce some nice content with it
> once in a while.

Until it is 100% fully open, or browsers support it internally, it
will still remain a third-party add-on, and not used by that many people.
Does it work in text-mode browsers?

Here's yet another place I see amateurs butchering their userbase by
replacing standard navigation elements with Javascript dropdown menus, or
using Shockwave for basic navigation elements. If I can't navigate the site
using a browser with all scripting features (and color) turned off, then I
don't visit the site, and consider it "under development", i.e. unfinished.

> 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.

Netscape 4.xx _never_ supported CSS. It supported a subset of CSS
through JSSS, Javascript Style Sheets, which was a (yet another) failed
attempt at trying to support the standards before the full specification was
agreed-upon. ALL browsers tend to do this, including IE, Mozilla, Konqueror,
Opera, and others. "Selective" specification compliance is what gets them
into trouble. (IE's "box-model" flaws, Konq's lack of z-index support, etc.)

> (Actually, the Netscape4-specific JavaScript stylesheets - a variant of
> CSS - did work reasonably well.) People just had to make do with tables.

Funny, I don't recall ever having to fall back on tables just to
make my websites look non-boring. I guess each artist carries a different
paintbrush.

> 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.

Yes, and some are blatently violating the GPL with it too, still an
open issue with the core Plucker team, and one which should be resolved
soon.

> 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.

Ahem, and it has another suspiscious use as well. I tested this with
one of my pages just to try to prove a point awhileback.

I unblocked avantgo.com's netblock, sat with AvantGo's latest client
in POSE on my machine, requested my page through the "Open Page" function in
AvantGo's application, and watched the referer and useragent logs on the
server-side.

As expected, my POSE session _never_ hit the page directly. My
request was proxied through ami.avantgo.com's server, which fetched it, then
served it up to my AvantGo session in POSE. I changed the page very
slightly, but in a noticable way, and requested it again, and was served the
_same page_ as before, unmodified, without a second hit to my server from
AvantGo's domain. This indicated to me that the page was now stored on
AvantGo's servers (without my con

Re: Back/foward/home function code

2002-11-19 Thread Laurens M. Fridael
David A. Desrosiers wrote:
> [page a] -follows link to-> [page b]
>
> [link on page b called "Back" ]
>

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 bro

Re: Back/foward/home function code

2002-11-18 Thread David A. Desrosiers

> 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" ]

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-onl

Re: Back/foward/home function code

2002-11-18 Thread Laurens M. Fridael
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



Re: Back/foward/home function code

2002-11-18 Thread David A. Desrosiers

> 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



Re: Back/foward/home function code

2002-11-18 Thread Laurens M. Fridael
David A. Desrosiers wrote:
> I submit that the Onion website, or any other site
> using the pods:// style linking, is geared to be driven by a very
> specific (AvantGo) client application, and we shouldn't be trying to
> replicate that. We should instead try to educate these content
> providers, and show them that using industry standards and practices
> is the best way to reach their audience.

First of all, educating these content providers takes time (and they might
not listen or even understand what you're saying). 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). 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.

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. 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. 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.


Regards
-Laurens


___
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev



Re: Back/foward/home function code

2002-11-18 Thread Fringe Ryder
At 07:53 PM 11/18/2002  +0100, Michael Nordström wrote:

On Mon, Nov 18, 2002, David A. Desrosiers wrote:
>   Show me where in the HTML spec, pods:// appears as a valid protocol.

Well, if support was added for the javascript version that Robert
mentioned then it wouldn't be such a big deal to support pods, too.

Can't say I understand the benefit of using these "history back" links,
though; when you create a site you usually know what page it should
go back to, so why not use that link from the very beginning? Using
a "history back" link can never guarantee what page you will go back
to.


I agree in application... when reading a Plucked document especially, I 
want specifically to go back to where I just came from.  But I'm rather 
unlikely to pull out the stylus to click on an element for it anyhow; I've 
got back mapped to a hardkey.

In reality, I've built quite a number of websites where "back" is relative 
to which path I took.  For hypothetical example, a description of a Ford 
Mustang could come from "Cars" - "Muscle" - "Ford Mustang", or from "Cars" 
- "Ford" - "Ford Mustang" or from "Classics" - "Ford Mustang" or even from 
"Movies" - "Gone in 60 Seconds" - "Cast: Eleanor".  Most news pages have 
links to the same story in several categories, such as Top News, Financial, 
People, etc.

Which brings up an orthagonal question for me.  The links don't get 
crossed-out on one page when the same destination has been visited from 
another page.  Do they get stored multiple times even though Plucker knows 
to only pluck each once, or is that just a UI issue?

-Tony McNamara-

___
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev


Re: Back/foward/home function code

2002-11-18 Thread David A. Desrosiers

> Well, if support was added for the javascript version that Robert
> mentioned then it wouldn't be such a big deal to support pods, too.

And let's not forget, parsing Javascript doesn't mean adding a
parser, like HTML (though, for small history.back() stuff, we could do easy
regex/pattern matching). Actually dealing with Javascript requires that we
_execute_ Javascript, not parse it, and adding a Javascript execution engine
to Plucker is a HUGE waste of time, IMHO, and I'm sure Mike agrees. =)

> Can't say I understand the benefit of using these "history back" links,
> though; when you create a site you usually know what page it should go
> back to, so why not use that link from the very beginning?

We are in full agreement here. Lots of eye-candy for very little
benefit overall. I submit that the Onion website, or any other site using
the pods:// style linking, is geared to be driven by a very specific
(AvantGo) client application, and we shouldn't be trying to replicate that.
We should instead try to educate these content providers, and show them that
using industry standards and practices is the best way to reach their
audience.


d.


___
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev



Re: Back/foward/home function code

2002-11-18 Thread Michael Nordström
On Mon, Nov 18, 2002, David A. Desrosiers wrote:

>   Show me where in the HTML spec, pods:// appears as a valid protocol.

Well, if support was added for the javascript version that Robert
mentioned then it wouldn't be such a big deal to support pods, too.

Can't say I understand the benefit of using these "history back" links,
though; when you create a site you usually know what page it should
go back to, so why not use that link from the very beginning? Using
a "history back" link can never guarantee what page you will go back
to.

/Mike

___
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev



Re: Back/foward/home function code

2002-11-18 Thread Wesley Mason
David,

On the most part, retaining the spec 100% is great.  But in this case a few
of the sites (or more) were made for Avantgo, we can't deny that.  Providing
a little 'extra' support for their links would help us see the sites more as
intended.

I'm sure someone could browse their developer section to get an idea what
tags would be beneficial/resonable to emulate.  Because as much as you
expect 100% html, you just not gonna get it 100% of the time.  Adding little
tricks like this and little helpers ('blue' = '#FF') to smooth over not
100% w3c standard will come a long way to making plucker easier to use
(overall).  Even if that's not one of the main project goals.  And overall
it should be within acceptable limits, time and effort wise.

--Wes (the lurker?!?)



- Original Message -
From: "David A. Desrosiers" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, November 18, 2002 12:45 PM
Subject: Re: Back/foward/home function code


>
> > This way a parser can support AvantGo pods:// URLs. For instance the
link
> >  instructs Avantgo to go one page back in
> > its history. It would be nice if the Viewer supported this as well.
There
> > are some AvantGo sites that use these links. (The Onion for example.)
>
> Show me where in the HTML spec, pods:// appears as a valid protocol.
>
>
> d.
>
>
> ___
> plucker-dev mailing list
> [EMAIL PROTECTED]
> http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
>

___
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev



Re: Back/foward/home function code

2002-11-18 Thread David A. Desrosiers

> This way a parser can support AvantGo pods:// URLs. For instance the link
>  instructs Avantgo to go one page back in
> its history. It would be nice if the Viewer supported this as well. There
> are some AvantGo sites that use these links. (The Onion for example.)

Show me where in the HTML spec, pods:// appears as a valid protocol.


d.


___
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev



Re: Back/foward/home function code

2002-11-17 Thread Laurens M. Fridael
Robert O'Connor wrote:
>
> However, I would much prefer to see it as a  href="javascript:history.back()"> That is the W3C standard way for a
> back hyperlink. The pods:// protocol is not any standard, it is
> something proprietary and closed. It may be better for Plucker to
> encourage the standards instead of the proprietary things, especially
> from companies that may fold up shop soon.
>

Well the parser(s) could support both the JavaScript and the "pods://"
syntax. The point is that the correct function codes (and/or arguments)
should be inserted in the text stream.


Regards
-Laurens

___
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev



Re: Back/foward/home function code

2002-11-17 Thread Robert O'Connor

> A useful addition to the Viewer would be a function code (in a text record)
> that instructs the Viewer to go back or  forward in the document's history,
> or to the document's home page.
> 
> This way a parser can support AvantGo pods:// URLs. For instance the link  href="pods://avantgo/back"> instructs Avantgo to go one page back in its
> history. It would be nice if the Viewer supported this as well. There are
> some AvantGo sites that use these links. (The Onion for example.)

I agree that it would have some use, as far as a smaller queue for the breadfirst 
parser to 
have (since many pages will have a link to home, and perhaps a back in some places).

However, I would much prefer to see it as a  That 
is the 
W3C standard way for a back hyperlink. The pods:// protocol is not any standard, it is 
something proprietary and closed. It may be better for Plucker to encourage the 
standards 
instead of the proprietary things, especially from companies that may fold up shop 
soon.

I don't know if there is a javascript for home though. It isn't really a home in most 
browser 
senses though, since the home can be different in Plucker, since there can be a list 
of links 
to many channels as the home, and the "home" link at the bottom of one individual 
website  is 
usually meant as a link back to the main page of that website's channel, not back to 
the 
homepage of the list of links.

Best wishes,
Robert

___
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev