• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7848 for generic doc work for TWiki-6.1.1. Use View topic Item7851 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.
This issue has already been discussed on IRC and been reported on TWiki:Plugins/TablePluginDev on 27 Oct 2006. So here's the bug item now.
During recent changes to the TablePlugin table attributes are added to the local style of a table, paralleling the html attrs that are generated already. This prevents skins to theme tables properly. The situation before (no local style) was also broken in a way because any skin theme would prevent user settings in a %TABLE{}% to have no effect.

Remember the priority of html and css:

  1. low prio: html attrs (e.g. <td bgcolor="..." >)
  2. medium prio: skin css (e.g. in colors.css td {background:...;})
  3. high prio: local css (e.g. <td style="background:...;">)
  4. very hight prio: skin css marked important (e.g. in colors.css td {background:...!imporant;})
  5. ultimate prio: local css marked important (e.g. <td style="background:...!important;">)

The solution is to distinguish site preferences in %TABLEATTRIBUTES% from explicit user settings given in %TABLE{}% Desired outcome:

  • TABLEATTRIBUTES in WebPreferences or TWikiPreferences shall not generate local style settings but only the html attrs (low prio)
  • Skins can override html attrs by their own css (medium prio)
  • Users can override skin css by having an explicite %TABLE% tag that generates both: html attrs + css (high prio)

Right now, skins have to make use of !important to theme tables which in turn is breaking user settings again as the TablePlugin generats attributes of prio low+high, whereas skins themes have medium prio currently.

So we only have to find a way to prevent web/site level %TABLEATTRIBUTES% to generate local css and distinguish this from explicit user settings in a %TABLE{}%. Skin themes kick in in between.


It would be useful to start with a static html page with the necessary code: at least 2 tables, and local css.


Why? I think I've been clear above. This is a plain perl job in the TablePlugin core to add a flag that prevents inline styles in the markup under certain circumstances.


That would be easy to test and hack up. But make sure the tests pass visually (TestCaseTablePlugin).


Can we please use CSS classes instead? The explicit styles are a complete and utter PITA to other plugins (such as EditRowPlugin).


I fixed that by implementing the following precedence:

  • the TABLEATTRIBUTE settings can be overridden by a skin's css
  • the TABLE tag overrides any skin's css

The TestCaseTablePlugin now also pass using NatSkin.

-- TWiki:Main.MichaelDaum - 23 May 2007

Summary TablePlugin: css attributes priority of site/web preferences too agressive
ReportedBy TWiki:Main.MichaelDaum

SVN Range TWiki-4.1.1, Sun, 04 Feb 2007, build 12769
AppliesTo Extension
Component TablePlugin
Priority Normal
CurrentState Closed

Checkins TWikirev:13857 TWikirev:13860
TargetRelease minor
ReleasedIn 4.2.0
Edit | Attach | Watch | Print version | History: r15 < r14 < r13 < r12 < r11 | Backlinks | Raw View |  Raw edit | More topic actions
Topic revision: r15 - 2008-01-22 - KennethLavrsen
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2022 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback