[polyfill] Polyfill the behavior of position: sticky; in thead/tfoot #507
Conversation
| position: sticky; polyfill, and should not be used as such. | ||
| */ | ||
|
|
||
| let LEGACY_POLYFILL_MAP = new WeakMap; |
pzuraq
force-pushed
the
pzuraq/polyfill/polyfill-thead-tfoot-sticky
branch
from
10d86fa to
b67326a
Compare
|
Do we have to reposition on every single cell? Is that possible to reposition for every row since it looks like all cells have the same offset? |
| this.setupResizeSensors(); | ||
| this.setupRowMutationObservers(); | ||
|
|
||
| this.mutationObserver = new MutationObserver(() => { |
There was a problem hiding this comment.
From what I understand, this observer reacts to every DOM event. In a complicated app, we would have lots of DOM events and this would be triggered multiple times. Why is using ResizeSensor not enough in this case?
There was a problem hiding this comment.
It reacts to specifically to children being added and removed, that's what the childList: true option does here. We need to reposition if a node was added or removed, because that node has not yet been positioned and could affect the positioning of other nodes.
This allows us to have a generic polyfill without tying into Ember directly.
|
Table rows have the same issue as |
pzuraq
force-pushed
the
pzuraq/polyfill/polyfill-thead-tfoot-sticky
branch
2 times, most recently
from
d92de6b to
f35ad5d
Compare
The previous implementation of fixed headers/footers wouldn't actually work for headers and footers that have more than 1 row because it fixed td/th elements directly due to a bug in the Edge/Chrome versions of sticky. This PR adds a polyfill which does several things: * It positions the headers/footers correctly individually based on a measurement of the row height * It repositions whenever the row height changes by using a ResizeSensor * It repositions whenever cells or rows are added by using MutationObservers This is definitely suboptimal, but it's much better than our previous setup and should be temporary. The polyfills have been moved into private, and the legacy polyfill has been refactored to match the style of the new one. They're both class based now and use a WeakMap to tie themselves directly to an element rather than the component class itself. This means we don't dirty the component (or modify its hidden class) and we and we keep all of our implementation details completely private. One final change was to add an explicit width on the table itself. The previous hack of setting `width: 0;` doesn't actually work in IE11, it collapses the entire table, so we need to actually set it to the real width (as defined by the columns).
pzuraq
force-pushed
the
pzuraq/polyfill/polyfill-thead-tfoot-sticky
branch
from
f35ad5d to
42cc7eb
Compare
The previous implementation of fixed headers/footers wouldn't actually
work for headers and footers that have more than 1 row because it fixed
td/th elements directly due to a bug in the Edge/Chrome versions of
sticky. This PR adds a polyfill which does several things:
on a measurement of the row height
MutationObservers
This is definitely suboptimal, but it's much better than our previous
setup and should be temporary.
The polyfills have been moved into private, and the legacy polyfill has
been refactored to match the style of the new one. They're both class
based now and use a WeakMap to tie themselves directly to an element
rather than the component class itself. This means we don't dirty the
component (or modify its hidden class) and we and we keep all of our
implementation details completely private.
One final change was to add an explicit width on the table itself. The
previous hack of setting
width: 0;doesn't actually work in IE11, itcollapses the entire table, so we need to actually set it to the real
width (as defined by the columns).