One thing that should definitely be happening is validating the output. I just checked: http://jakarta.apache.org/avalon/index.html
It fails on validating to HTML 4.01 transitional. Check at: http://validator.w3.org/ It fails U.S. Section 508 Guidelines: http://bobby.watchfire.com/ (I don't know what you have to do to get 'Web Content Accessibility Guidelines 1.0' valid...) It passes on CSS: http://jigsaw.w3.org/css-validator/validator-uri.html The forrest team (Bert?) is working on making the forrest output valid. I don't think it would be too hard to get either site to validate. When you run the validators they give you exact details on what you need to change. Robert Koberg liveSTORYBOARD.com 415-615-9079 San Francisco > -----Original Message----- > From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 07, 2002 1:43 AM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: Commons site prototype up > > > > Justin Erenkrantz wrote: > > --On Thursday, November 7, 2002 9:19 AM +0100 Nicola Ken Barozzi > > <[EMAIL PROTECTED]> wrote: > > > >> Actually I prefer the Forrest version in Lynx. > > > > IMHO, links produces better rendering of documents than lynx. The most > > noticable difference is that links can handle columns correctly. links > > follows closer the intention of the site layout than lynx. Perhaps you > > have never tried links (http://links.browser.org/)? (elinks is the > > latest iteration of links code base.) (This is the second time a > > Forrest developer has confused lynx and links.) > > Actually, I saw the question, but I missed your previous explanation, > sorry. > > > My problem with the Forrest skin is the abundance of spacer images. I > > believe they add no value, and for me, they make the site unusable (I > > display all links to images). The avalon-tigris skin does not suffer > > from the spacers. > > The Forrest skin started as a CSS skin only. > The problem is that Netscape 4.x crashes on some CSS, and to have the > best possible user experience with all browsers, we resorted to using > some hacks, while keeping them at a minimum. All the discussions are on > the mailing list archives. > > Currently we are discussing about resorting again to CSS-only, but we're > afraid about Netscape 4 problems and poorer site. > > Suggestions? > > >>> We *must* have the source version-controlled as I'm not going to > >>> be modifying forrest-marked-up text myself - that contradicts > >>> forrest's original purpose. > >> > >> > >> Why may I ask? > > > > > >> From what I can see (as witnessed by the various ASF sites now using > > Forrest), Forrest's generated HTML files are not clean and don't have > > indentation. Therefore, I would not prefer to work on its generated > > HTML files. > > Oops, I read your comment the other way round, I agree with you. > Nobody should ever work on generated HTML files, so it's not a problem. > > Anyway, if it's a user request we can easily put it in the skin > stylesheets indent="true", no big deal. > > > As a point of reference, please compare anakia-generated www.apache.org > > HTML source with the forrest-generated xml.apache.org HTML source. > > IMHO, the anakia-generated HTML is *vastly* superior to the > > forrest-generated HTML. It might just be possible to work off of the > > anakia-generated HTML, but I don't think that's really feasible in > > forrest (as demonstrated by xml.apache.org). > > If this prevents people from wotking on the generated docs, good ;-) > > > Perhaps the original xml.apache.org XML input is just poorly formatted. > > Perhaps. > > This is one thing. The other is that the Forrest skin is not yet self > describing with comments on the various sections. > > >> Anyway, we are working on both wiki-like editing and in-browser > >> editing, so it won't be an issue in the near future :-) > > > > > > I'd never use those mechanisms on apache.org as they don't allow proper > > authentication. (Well, it might if we used SVN not CVS.) A server > > shouldn't be changing content solely because of an activity done on a > > web form. That'd be incredibly insecure for us. > > Locally I mean. > > ATM you can run forrest locally and see real-time results of your edits > through localhost:8888 since we embedded a web server. > > The wiki works on this system. > > > Our webserver shouldn't allow modifications - only committers can do > > commits. And, committers can only commit with CVS on cvs.apache.org. > > Note, the CVS and web servers are distinct in the ASF infrastructure, so > > this introduces another host of problems. > > > > SVNWiki is the exception here because it ties in with the SCM and > > Subversion can authenticate via HTTP authentication mechanisms. CVS > > allows no such thing to occur. > > > >> We would run Forrest cron job on another server, and publish it > >> there. Daedalus synchs his version from that other server (ie pull, > >> not push). > > > > > > How does it pull? rsync? > > > > I've mentioned before the severe drawbacks of a pull-based synch model > > that have nothing to do with technical aspects. Namely that I forfeit > > control of when the site is updated and I can't properly embargo a > > website change. The resulting 'automated' process that dealt with this > > would be much more complicated than the manual 'cvs up' process. > > Actually, having such a process doesn't stop me from publishing a > version before the cron kicks in. > > In the Jakarta site and Xml site CVSes, there *is* a cron job that picks > up the contents, so I don't see the difference in this case. > The real difference is that I don't have to generate the stuff manually, > but for the rest it's exactly the same. > > It prevents users from touching the generated docs instead of the > sources (you know how saving and updating double information sucks > generally). > > Also, it has been noted that the automated process can be made to update > a "dev" version of the site, for staging purposes or the like. > > > Note, I'm a *very* demanding user. So, please don't take any of my > > comments personally, but I expect a lot from my tools. -- justin > > Actually, I'd like to engage in this even more, because demanding users > help make the best products :-) > > So let's get these things sorted out, all of the Forrest developers are > hungry for user feedback (witness 3 developers rushing for a reply on > the same subject lately). > > -- > Nicola Ken Barozzi [EMAIL PROTECTED] > - verba volant, scripta manent - > (discussions get forgotten, just code remains) > --------------------------------------------------------------------- >
