You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Pay attention to the `role` attributes: those are highly recommended if you want to have the table behave as such also in accessibility contexts.
91
+
Pay attention to the `role` attributes: those are highly recommended if you want to have the table behave as such also in accessibility contexts.
95
92
While this is not necessarily needed for ordinary tables, this one is required to use `display: block` on the table element (see Development Notes](#development-notes)), which in turn makes these role attributes necessary, still.
96
93
97
94
You can find an example-app in the [GitHub Repo](https://github.com/BernhardWebstudio/svelte-virtual-table/tree/main/example-app).
@@ -113,26 +110,26 @@ As these are not block-type elements, the original intention to use padding as a
113
110
114
111
There are numerous workarounds, that were attempted:
115
112
116
-
-apply a border to `<tbody>`,
117
-
-use `::before`- and `::after`-pseudo elements,
118
-
-increase the height of `<tbody>`'s last- and first-child,
119
-
-use `display: block` on `<table>` and `display: table` on `<tbody>, <tfoot>, <thead>`
120
-
-or use `<tfoot>` and `<thead>` as the elements whose height is changed (and which are kept in the document, no matter if they even have content).
113
+
- apply a border to `<tbody>`,
114
+
- use `::before`- and `::after`-pseudo elements,
115
+
- increase the height of `<tbody>`'s last- and first-child,
116
+
- use `display: block` on `<table>` and `display: table` on `<tbody>, <tfoot>, <thead>`
117
+
- or use `<tfoot>` and `<thead>` as the elements whose height is changed (and which are kept in the document, no matter if they even have content).
121
118
122
119
As an example, the pseudo-element approach would work e.g. like this:
123
120
124
121
```css
125
122
tbody::before {
126
-
box-sizing: border-box;
127
-
content: '';
128
-
display: block;
129
-
height: var(--p-top);
123
+
box-sizing: border-box;
124
+
content: '';
125
+
display: block;
126
+
height: var(--p-top);
130
127
}
131
128
tbody::after {
132
-
box-sizing: border-box;
133
-
content: '';
134
-
display: block;
135
-
height: var(--p-bottom);
129
+
box-sizing: border-box;
130
+
content: '';
131
+
display: block;
132
+
height: var(--p-bottom);
136
133
}
137
134
```
138
135
@@ -141,10 +138,10 @@ This is not the case when scrolling up.
141
138
142
139
Some observations related to this problem:
143
140
144
-
-scrollTop increases with the --p-top
145
-
-changing --p-top and --p-bottom triggers a scroll event
146
-
-scrolling up is not affected
147
-
-unstopped scrolling starts after removing an item from viewport
141
+
- scrollTop increases with the --p-top
142
+
- changing --p-top and --p-bottom triggers a scroll event
143
+
- scrolling up is not affected
144
+
- unstopped scrolling starts after removing an item from viewport
148
145
149
146
The reason is with high probability, that the current calculations are incorrect. Refer to [this codepen](https://codepen.io/BernhardWebstudio/pen/NWggLyG) for some calculation-analysis possibilities.
150
147
@@ -164,8 +161,6 @@ You can pass the prop `requireBorderCollapse` with a value that evaluates to tru
0 commit comments