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
opinion).
Ross
