coreui / coreui-pro / 34910797274

96%

main: 94%

push

github

fix(RTL): ask the element for its direction, not the document root (#1303)

`isRTL()` read `document.documentElement.dir`, so a component inside a subtree
with its own `dir` was answered about the page instead of about itself, in both
directions. It now takes an element and reads its computed `direction`, which
is what the 851 logical declarations in the stylesheet resolve against, so the
script and the layout agree on which way the component is laid out. Without an
element it still answers about the document, and an element outside the
document is answered by the nearest ancestor that declares a direction,
`dir="auto"` included, so a detached element and the same element once inserted
give the same answer.

The tooltip is the exception, and the reason is in our own reboot: `tel`,
`url`, `email` and `number` fields are kept left-to-right whatever the page
does, which is a statement about the value, not about the context. A tooltip
attached to such a field therefore reads the direction of what the trigger sits
in, or it would mirror the wrong way and render Arabic text left-to-right on an
RTL page.

Dropdown and Tooltip are in this change rather than after it. `Dropdown extends
Menu`, so leaving its `PLACEMENT_RIGHT`/`PLACEMENT_LEFT` frozen at import while
Menu asked the element made one object answer the direction question two ways:
measured, two dropdowns in the same `dir="rtl"` subtree opened on opposite
sides, and a submenu cascaded back across its own toggle. Both resolve per
element now, Tooltip through an `ATTACHMENTS` pair per placement rather than a
map baked once at import.

A menu or a tooltip moved to a container leaves the subtree whose direction it
was resolved against, so it carries that direction along and gives it back when
it returns. Within a menu, the submenu placement, the hover-intent triangle and
the submenu keys ask the element they belong to rather than the root toggle.

Calendar, Section Input and Date Range Input had each gro... (continued)

5679 of 6323 branches covered (89.81%)

Branch coverage included in aggregate %.

57 of 58 new or added lines in 13 files covered. (98.28%)

10963 of 11367 relevant lines covered (96.45%)

471.93 hits per line