Avoid interfering with layout of tables with absolutely positioned content

[paulwarren-wk]

Fixes #632

Reason for change

The viewer currently interferes with the layout of tables that contain absolutely positioned content. The problematic situation is this:

    <div class="page" style="position: absolute">
        <table>
            <tr>
                <td>
                    <div style="position: absolute">1,000</div>
                </td>
            </tr>
        </table>
    </div>

The viewer then adds position: relative to the <table> tag, which means that the absolutely position <div> is now positioned with respect to the wrong parent.

The viewer adds this class, because it is used to place the table export icon in the top left of the table.

Description of change

The viewer no longer adds an export handle if absolutely positioned content is found within the table.

It would obviously better to enable the export functionality, as the presence of the table tags means that the export should work (where previously it didn't on most ESEF filings), but it's not at all trivial, as the <table> tag is likely to be rendered is some random location.

Steps to Test

Check that the layout of the sample document on #632 is now correct when loaded in the viewer.

review:
@Arelle/arelle
@paulwarren-wk

[aviary-wf]

Security Insights

No security relevant content was detected by automated scans.

Action Items

• Review PR for security impact; comment "security review required" if needed or unsure
• Verify aviary.yaml coverage of security relevant code

---

Questions or Comments? Reach out on Slack: #support-infosec.

[brettkail-wk]

I worry this will break/remove the handle from Workiva-generated documents, which use position:absolute on all <div> within a <table> but I believe position the <table> in a specific/non-random place (test).

[paulwarren-wk]

Yes, it looks like the table has been carefully constructed to ensure that it's position and size matches the rendered content, so in this case if we were to put the handle at the top left of the table, it would work.

We could potentially detect that the table has non-zero size, and show the handle in that case, but we still have the issue that adding position: relative may interfere with the layout. In this example, the cell contents are positioned relative to an enclosing <div> which happens to have the same position as the <table> element, so adding position: relative has no impact. But, an innocuous change like adding a top margin to the table, means that adding position: relative breaks the layout because the cell contents are positioned relative to a different location.

We could find the minimum top and left positions of all the absolutely positioned children, and put the export handle at that location, although we'd need to take care that the children are actually position relative to the table or some parent.

Elsewhere, we've discussed replacing all highlighting / borders / annotation with constructs that are positioned relative to to the top of the document, but would be a significant change, and would require recalculating positions if the window gets resized.

[brettkail-wk]

I saw a link to this blog post over the weekend, which seemed promising:

Once you can use this freely, you’ll have to care less about exact DOM positioning of elements (aside from accessibility concerns). The way it is now, the element you want to position relative to another has to be a child element and for there to be a positioning context to work within. This can dictate where elements go in the DOM, whether or not that makes sense.

Looks like Firefox intends to prototype, which is promising.