forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From addi <>
Subject Re: General approach to backward compatibility (was: Re: Cleaning up html-processing)
Date Fri, 07 Oct 2005 10:22:21 GMT
On Friday October 07 2005 3:06 am, Ferdinand Soethe wrote:
> 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!

Just piping up to say that I definitely agree that this is a fix that needs to 
be addressed.  I think an explanation in the upgrade docs will suffice.

- Addi

> 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
>    html-code.
>    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).
> wdyt?
> --
> Ferdinand Soethe

View raw message