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
