RE: Non-HTML (was Re: Back/foward/home function code)
> 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)
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
> 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
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
> 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
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)
> > 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)
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)
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)
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
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
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
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
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
>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
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
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
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
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
> 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
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
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
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
> > 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
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
> 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
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
> 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
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
> 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
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
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
> 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
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
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
> 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
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
> 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
