Precedence handling in TablePlugin seems flawed in case a custom css file (e.g. as part of a custom skin) setting table properties is involved. According to the docs, the precedence should be this (from most important): TABLE{} settings, custom css, TABLEATTRIBUTES settings (e.g. from TWikiPreferences). A problem arises if a table property (like borders) is set through both TABLEATTRIBUTES (e.g. by setting tablerules to none") and, differently, through the css file (eg. setting border: solid for table.td there). As documented, the css settings take precedence, resulting in a table with rules. If one tries to change that for one single table by adding a =TABLE settings giving tablerules none, that setting will simply be ignored.

From a short glance at the code I suggest the following happens: When processing the TABLE setting, TWiki first looks if there is an equal setting in TABLEATTRIBUTES, in which case nothing is done. But in this case the css setting (which is different from both TABLE and TABLEATTRIBUTES) wins, resulting in unwanted behavior.

-- TWiki:Main/MichaelRitter - 10 Nov 2008

Hi Michael, could you post an example where this happens, and a description of what should happen?

-- TWiki:Main.ArthurClemens - 10 Nov 2008

Closing for lack of additional info.

-- ArthurClemens - 11 Sep 2009

ItemTemplate edit

Summary TablePlugin precedence handling is flawed if a custom css (e.g. from a custom skin) is involved.
ReportedBy TWiki:Main/MichaelRitter
Codebase
SVN Range TWiki-4.2.3, Wed, 06 Aug 2008, build 17396
AppliesTo Extension
Component TablePlugin
Priority Normal
CurrentState No Action Required
WaitingFor
Checkins
ReleasedIn
Topic revision: r2 - 11 Sep 2009, ArthurClemens
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy