forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin <forr...@kegcl.demon.co.uk>
Subject Re: General approach to backward compatibility (was: Re: Cleaning up html-processing)
Date Fri, 07 Oct 2005 17:21:05 GMT
On Fri, 2005-10-07 at 06:22 -0400, addi wrote:
> 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.

Yes adding a note to docs sounds good. My concern was a maybe and
I did say unlikely. 

Kevin

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


Mime
View raw message