On 19 Nov 2002 at 16:37, Fringe Ryder wrote: > At 11:54 PM 11/19/2002 +0000, Robert O'Connor wrote: > >On 19 Nov 2002 at 15:22, Fringe Ryder wrote: > > > > > At 10:53 PM 11/19/2002 +0000, 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. > >*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. Perhaps in reading through the archives, you missed: - The coloured element support (colored text, tables, hr, etc), according to W3C specs. - <hr> tag up to a pretty much complete HTML 3.2 spec. - Various other smaller cleanups of things to keep them running properly in a standard way. > But do you notice any > prejudicial tone in your message? > "crap non-standard proprietary non-HTML" That is my opinion, and each component is the chosen word to what I feel is the best possible description. As a near to completely trained medical doctor, one of the top priorities is a complete description. The proposed non-HTML, in my opinion, are: -crap -non-standard -proprietary -non-HTML > Nobody asked for support of that specifically. In the archives, buglist (and in personal emails also) there is now requests for the top 3 that I mentioned: -The mix of non-standard HTML colors. -Office <![garbage]> -pods:// > Sure, some "non-standard" > HTML, depending on whose standard (W3 or the real world/market.) W3C is documented, provides a testable implementation and provides compatibility of Plucker with other tools. Proprietary fly-by-night stuff do not. > 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. The ideas that are good get into W3C after a few years. There was, is, nor will be plans for pods://back as there is already an equivalent elsewhere that behaves in a documented, more extensible way. The eclectic extended named colors have #RGB equivalents and save extra dead weight from a renderer's code. With regards to <![garbage]>, there is a proper way to demarcate comments, in a way that is forward compatible with XML et al. > 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. The initial writing is trivial in the timeframe of a project--it is the long term maintainence that is the killer. This is in addition to the hit in parser speed and the increased amount of time required to maintain function with non-documented items, and also to then maintain backward compatibility with these things as they fade away at the expense of their standard equivalents. > On the bright side, right now it's both a tribute to a standards body AND > useful, at least to me. There has been a high degree of success to date, of people leaving the other proprietary solutions in favour of the Free, standards-based, documented Plucker project. It is useful to me also. Best wishes, Robert _______________________________________________ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
