Including a stray </center> tag within a table cell (within a wikitable, that
is) will ruin multicolumn formatting (in a rather hard-to-localize way).
Version: 1.3.x
Severity: normal
Including a stray </center> tag within a table cell (within a wikitable, that
is) will ruin multicolumn formatting (in a rather hard-to-localize way).
Version: 1.3.x
Severity: normal
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | None | T2209 [DO NOT USE] HTML validity (tracking) | |||
| Resolved | None | T2460 Table rendering bug : extra </center> tags break table columns |
We are not going to implement fix for user errors. Just don't enter
the additional </center> tag.
wmahan_04 wrote:
I'm having trouble reproducing this--could someone make a test case?
zigger wrote:
I don't know if this matches the original reporter's issue, but here's a test
case with an unmatched </center>. In v1.4-prealpha/HEAD it produces an escaped
</center> after a left-aligned "a", while in v1.37wm the cell just has a
left-aligned "a". The unmatched <center> ("d") renders ok in both, but in the
XHTML becomes an unmatched <div> in v1.4-prealpha/HEAD, while v1.37wm has
matched div tags.
{|
| a</center> |
| - |
| <center>b</center> |
| - |
| <center>cccc</center> |
| - |
| <center>d |
| } |
The way we fix tags is wrong, there is a preg_replace using a
set of rules:
<center> to <div class="center">
</center> to </div>
I replaced that to replace blocks instead like:
<center>.*</center> to <div class="center">\1</div>
Unmatched <center> or </center> alone will no more be replaced.