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:
- low prio: html attrs (e.g.
<td bgcolor="..." >
)
- medium prio: skin css (e.g. in
colors.css
td {background:...;}
)
- high prio: local css (e.g.
<td style="background:...;">
)
- very hight prio: skin css marked important (e.g. in
colors.css
td {background:...!imporant;}
)
- 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.
MD
It would be useful to start with a static html page with the necessary code: at least 2 tables, and local css.
AC
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.
MD
That would be easy to test and hack up. But make sure the tests pass visually (
TestCaseTablePlugin).
AC
Can we please use CSS classes instead? The explicit styles are a complete and utter PITA to other plugins (such as
EditRowPlugin).
CC
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