Manuel,
First of all, thanks loads for helping out with this!
On Jul 30, 2005, at 11:32 PM, Manuel Mall wrote:
Got the Forrest installation and site generation sorted out.
Just as an observation the site claims to be HTML 4.01 compliant but
when you
submit it to the W3C validator it fails validation. Basically we are
making
an unsubstantiated claim on compatibility here. The problems seems
however to
be mainly in Forrest and I have lodge an issues with them. However, I
do
wonder if we have to remove the compliance claim (the W3C HTML 4.01
logo)
until we are really compliant? BTW, the Forrest site which uses the
same skin
has the same problem.
We currently use Forrest 0.6. Forrest 0.7 was recently released, and it
was on my personal ToDo list to convert to 0.7.
Changing the forrest skin is described here:
http://forrest.apache.org/docs_0_60/your-project.html#skins
Another observation: FOP being a project under the XML family
shouldn't we
have an XHTML compliant site? I am guessing that this is a Forrest
skin issue
as well?
That would be great. I believe that 0.7 brings Forrest closer to that
XHTML reality. In order to make the site XHTML compliant, we may have
to convert the site to either forrest 0.7 or 0.8-dev (not yet
released).
Last observation: The compliance page (table columns) looks ugly under
Firefox. Its fine under IE 6, Opera, Konqueror. The problem is the
right
floating background image under external links which Firefox seems to
ignore
when calculating cell widths causing cells to overflow into their
neighbours.
Not sure what we can do about that its just a bit sad if our site
looks bad
under the most popular open source browser.
True. The Compliance page is actually an 'ihtml' page. I used this,
because Forrest had significant difficulties with the FOP Compliance
page. I essentially created an HTML page, and then passed it through
Forrest unmodified.
Back to the compliance page. I assume what is required is some
indication of
1.0dev compliance vs 0.20.5 compliance. To achieve that we could:
a) Add extra columns, eg.
Support (0.20.5) | Support (1.0dev)
Basic | Extended | Complete | Basic | Extended | Complete
That is what I originally proposed, and is what I believe makes the
most sense. Doing it this way seems like it'd be the easiest to
separate and compare the differences between 0.20.5 support & 1.0dev
support.
...
b) Add extra columns like
Support
Basic | Extended | Complete
0.20.5| 1.0Dev | 0.20.5| 1.0Dev | 0.20.5| 1.0Dev |
...
c) Leave the column structure as is and record it in the column
values, i.e.
instead of "Yes" we could have a list of version numbers eg. "0.20.5,
1.0dev". If its partial its indicated in brackets behind the version
number.
Option c) is probably the easiest to manage as the table structure
doesn't
change as we add/remove releases from the table. b) is probably the
easiest
on the eye for a quick visual comparison but with each release
added/removed
the whole table structure changes making it work intensive to maintain.
Feedback please
BTW, one other option is to convert this page to a OpenOffice.org
Writer format. Forrest has a plugin which converts OpenOffice.org
Writer documents to Forrest HTML/XHTML documents. It's very nifty, and
works fairly well.
Manuel
Thanks again, Manuel!
Regards,
Web Maestro Clay
--
<[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet
