-HTML (was Re: Back/foward/home function code)
___
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
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
> 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
ab
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 be
> 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
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
> > 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.
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
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 eff
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.
>
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
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
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
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 alternati
>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,
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
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
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 th
lopment 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. Loo
> 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
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-
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 do
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 st
> > 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.
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 [EMA
> 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
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 essential
> 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 las
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 HT
On Mon, Nov 18, 2002, David A. Desrosiers wrote:
> We shouldn't follow AvantGo, because we aren't AvantGo, and we
> aren't trying to replace them.
When investigating a bug report I found out that we are the "GNU based
version of AvantGo"[1] ;-)
BTW, don't download the Plucker document from the s
> 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
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, an
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
> 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/patter
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 o
lt;[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.
> 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
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 standard
> 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">
Hi,
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 instructs Avantgo to go one page b
40 matches
Mail list logo
