forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: Cleaning up html-processing
Date Thu, 06 Oct 2005 22:16:24 GMT
Ferdinand Soethe wrote:
> 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).

Then, if these changes have altered the behaviour for o.7 then this may 
be oversight of the community as a whole. Read on...

> 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.

So, would the locaitonmap route be the right way here, unless...

> 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?

I'm confused by all this, on the one hand someone is saying that it 
breaks backward compatability, on the other hand, someone else is saying 
it never worked before anyway.  My comments so are only in response to 
the concern that it breaks backward compatability, if that is not the 
case then you can ignore my comments.

Ask yourself these two questions, then you'll know whether these changes 
are OK or not. I trust your judgment:

1) Does an HTML page that rendered with 0.7 still look the same when 
rendered with your modified stylesheets?

2) Does an HTML page that failed to render with 0.7 now render?

If yes to both then changes are fine.

If no to the first then changes are not OK unless answer to second is 
yes. In which case the changes will usually be OK (but they need 
documenting in the upgrading to 0.8 documentation).

In the very last instance where it will usually be OK, it is only OK if 
the community see it as OK. One of our community has raised a concern, 
we have to address it. In this case I feel the call is yours as to 
whether the changes stay or not (others will speak up if they have an 


View raw message