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
