User:Rillke/SandboxInfo

The first sample looks good, what's wrong?

Both samples do it wrong, putting a <tr> (table row) directly into a non-table element. Table rows must have a <table> (or <tbody>) as their parent node. If they don't have a table as parent, it is invalid HTML. MediaWiki developers decided not outputting invalid HTML and run HTMLTidy over the parser output before sending it back to the user.

HTMLTidy does its best to guess the sense of what the user wanted to do. In case 1, it first recognizes the <span> element. As a span element must not have block level children elements like tables, it moves the span to the next possible destination, which is inside the next td (table data cell) here. Then, it cares for the broken table: Since the <tr> is directly inside the <td>, it assumes that the user accidentally messed with that line and didn't want a new table.

In sample 2, which just differs by exchanging the span with a div element, it behaves completely different: It extends the table div and the table to the whole page and inserts a new table around the misplaced <tr> nodes.

To conclude: This behaviour is kind of unpredictable; When feeding Mozilla Firefox directly with the invalid HTML, it behaves similar to sample 1 in both cases. Other browsers may do it differently and HTMLTidy may decide at any time to change its behaviour. When it is updated, this construction may break.

How is this related to Template:Building address?

The documentation of Building address recommends: This template shall be added within the template {{Information}}, within the parameter description, at the bottom.

• {{Information}} is a table. Everything that is passed to the parameter description will be inside a table data cell (td) (or inside a td>span which was the situation before this change but this had other side effects or inside a td>div which was removed removed due to the issues shown in sample 2)
• {{Building address}} is a table row (<tr>), not a complete table. It makes use of {{Information field}}
• Effectively, we are placing a table row inside a table data cell (<td>), which is invalid and leads to unpredictable behaviour.

How could the issue be solved?

• With an extra-parameter in {{Information}} which allows inserting a <tr> as a direct child into its <table>-structure
• Wrap a <table>-element around the output of {{Building address}}

Sample 1: When an inline element (span) is used

<table class="wikitable">
<tr>
<td>r1c1</td><td><span class="description">r1c2<tr><td>inner k - moved by HTML Tidy</td><td> inner val - moved by HTML Tidy</td></tr></span></td>
</tr><tr>
<td>r2c1</td><td>r2c1</td>
</tr>
</table>
<h3> A heading </h3>
Following text on the file description page.

Renders as:

r1c1	r1c2
inner k - moved by HTML Tidy	inner val - moved by HTML Tidy
r2c1	r2c1

A heading

Following text on the file description page.

Sample 2: When a block level element (div) is used

<table class="wikitable">
<tr>
<td>r1c1</td><td><div class="description">r1c2<tr><td>inner k - moved by HTML Tidy</td><td> inner val - moved by HTML Tidy</td></tr></div></td>
</tr><tr>
<td>r2c1</td><td>r2c1</td>
</tr>
</table>
<h3> A heading </h3>
Following text on the file description page.

Renders as:

r1c1	r1c2
inner k - moved by HTML Tidy	inner val - moved by HTML Tidy
r2c1	r2c1

A heading

Following text on the file description page.