Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@forrest.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Date: Thu, 6 Oct 2005 23:48:50 +0200
From: Ferdinand Soethe <ferdinand@apache.org>
Message-ID: <93871253.20051006234850@soethe.net>
To: dev@forrest.apache.org
Subject: Re: Cleaning up html-processing
In-Reply-To: <43458197.80508@apache.org>
References: <12910221548.20051001120150@soethe.net>
 <1128181000.4059.16.camel@k2.flat5> <1713436992.20051002222052@soethe.net>
 <1128359625.4131.26.camel@k2.flat5>
 <20051003223538.GA19659@igg.indexgeo.com.au> <434221F7.8030509@apache.org>
 <1394004578.20051004154102@soethe.net>  <4342ACCE.1010104@apache.org>
 <1128457052.4034.20.camel@k2.flat5> <4342E5E6.4060608@apache.org>
 <1537279799.20051005082657@soethe.net> <1128535140.4408.12.camel@k2.flat5>
 <01916306.20051005232702@soethe.net> <1128551051.4156.21.camel@k2.flat5>
 <1888817027.20051006084255@soethe.net> <1128623254.4150.10.camel@k2.flat5>
 <123025089.20051006210119@soethe.net> <43458197.80508@apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Ross Gardler wrote:

> Any solution applied to SVN should not change existing behaviour, even
> if that behaviour does not suit you.

> Make it configurable or, if you are using 0.8-dev you can simply add a
> project locationmap with a match for the stylesheet you don't like and
> provide your own modified one in your project. No need to create a whole
> new skin.

Hmmm. This comes as a bit of a shock as it basically means that all
the changes to the skinning that I did during the last few month would
have to made configurable (Nobody mentioned this when I discussed them
on-list).

In a case like this table-element (or my earlier fixes with ID)
this would require switches in a number of different places, in my view a
nightmare to write, document and maintain.

I understand that the above rules apply to changing existing
_features_, but should we really apply them to bugfixes and changes
that make Forrest behave as documented?

For example: The state of the table-element processing that Kevin
observed as 'working' was only after I had applied some first repairs
that stopped Forrest overwriting _any_ class-attribute with
'ForrestTable'. Since in our docs we suggest customizing Forrest by
inserting custom class-attributes and styling them with extra-css, I
considered this a bug to be fixed. And still do.

So pls let me know what you think. The changes to the 0.7 fix branch can
easily be rolled back if need be. To roll back the changes to 0.8 I'd
probably need some help as they go back some month.


--
Ferdinand Soethe