forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ferdinand Soethe <>
Subject General approach to backward compatibility (was: Re: Cleaning up html-processing)
Date Fri, 07 Oct 2005 07:06:45 GMT

Ross Gardler wrote:

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

Yes 'others' please do!

Problem is the interpretation of bugs and features here and I really
think community should clarify this once and for all.

For better understanding:

1. The old behavior will overwrite any class-attributes in
   table-elements (of any type of document) with class="ForrestTable"
   and also set borders= and other presentational attributes right in the

   My view is that this is broken functionality because

   - it makes it impossible to custom format a table with a custom
     class-attribute and css (a documented feature).

   - it goes against our concept of using css as much as possible.

   In fact, a final solution should go even one step further and
   replace all presentational attributes in table with css-styling
   in the stylesheet.

   In summary: I consider the changes to be fixes.                                       

2. Any change in existing behavior has the potential to break
   somebody's Forrest even if it is just fixing a bug.

   For example: If somebody tried using their own class-attributes for
   table (which had no effect because it was swallowed) they will now
   find their custom class tables to have no borders and no more
   padding and will have to add extra-css to get them back.

   (Pls. note that non-customized tables (without class-attributes) will
   continue to work as before!)
   I figured that this would be considered to be an improvement
   because people who added class="xyz" in the first place likely did
   so to customize design, but who knows ...

3. While I accept the general policy of maintaining backward
   compatibility, I think this should be limited to documented features
   and should always consider what is involved in achieving that goal.

   We should _not_ end up creating super complex stylesheets or
   bazillions of configuration options to ensure backward
   compatibility for bugs or leftovers from previous re-factoring
   steps (in this case moving from a non-css to a css-based design).

   Especially if all that is required on upgrading would be a piece of
   css added to the extra-css in ones project. (A step which I agree
   should be documented in the upgrade info).


Ferdinand Soethe

View raw message