Weird that’s the same code but just a live preview from codepen.
I can’t seem to reproduce it on my laptop at all. Maybe its a windows problem but I won’t be back to my desktop computer until Monday as I am away on holiday.
Maybe you could put up an online version outside of codepen that shows the problem so that we can discount a codepen discrepancy.
I’ve just changed the borders to red here to see if it throws any light on the problem.
In your screenshot it looks to me as though the border-spacing:0 isn’t being honoured hence the gap (or the border-collapse:separate).
Usually these bugs are easy to squash but unless I see it happening to me I’m just guessing maybe do an inspect with devtools and see if it shows anything odd for those borders or border-spacing.
Literally, “border-collapse: collapse” sets the border-spacing property to zero,
border-collapse: collapse; do much more than setting border-spacing to zero… it merge cells borders as one, but border-spacing: 0; makes borders be adjancent ^^
so border-spacing has no meaning when using border-collapse: collapse
Yes I know all that but you missed the point in that in the last example there are no borders or spacing on the cells themselves. I put the border on something else that covered the cell. If you still see the issue then the problem is something completely different.
In the border-collapse: collapse model the borders are collapsed which means that cells don’t have touching borders. Only some sides of a cell get painted so that no two borders touch. That means that model is no use for the sticky columns because as it slides the borders no longer cover the sticky cells.
That’s why my demo uses the border-collapse: separate model with border-spacing set to zero to allow each cell to have borders all around.
I’m afraid you’ll have to wait until I get back on Monday and test on my desktop to see if I can replicate the problem. I doubt I will be able to replicate it though as those old demos were written on a windows computer and were working fine but maybe something has changed since then :;
I wouldn’t bother looking up those old SO threads as they are full of misinformation and very few have a proper grasp of the table model.
I’ve just had a thought and you’re not using a browser zoom other than 100% are you?
If so then I can replicate the double borders when zoomed larger but I would expect that as zoom often separates borders when zoomed especially on tables. The browser zoom control is really only useful for reading text at a larger size which is why i usually just zoom the text and not the layout.
Remember that browsers remember what sites you had zoomed so if you have accidentally zoomed codepen or other pages that zoom will automatically kick in when you return to those pages unless you reset to 100%.
If that still isn’t the problem then we need a few pairs of new eyes to see if they can see the double borders. @DaveMaxwell, @rpg_digital, (and anyone else) can you guys see the separated borders that the OP is seeing?
If that’s the last demo I posted then yes I didn’t change the small screen display yet so it will be broken on small screens as I haven’t bothered on that test.
Thanks for that. The small screen version only has sticky headers so it really shouldn’t be an issue if the header border is transparent. It’s not something I can debug anyway as I have an iPhone and it’s ok there.
I was more concerned with the large screen version and the double borders on the sticky columns which I am unable to reproduce anywhere and thus very hard to debug
On desktop, I was only able to replicate that with zoom and it only appears when the table elements e.g. table headings were set to sticky — sticky essentially toggles this on and off.
The calculations seem a bit hit and miss with sticky being applied. For instance on opening the web developer window/tab suddenly the transparent gaps disappeared.
I don’t know the solution. I tried a few things but unsuccessfully.
There should be no white gap between the red and green boxes.
Yes that often causes a redraw of the page and it also can change the width/height of the available area which can also trigger or fix a rounding error.
Also the rounding error on zoom will depend on the viewport height when percentage based calculations (like my tables) are concerned. If you grab the browser window and go up one pixel at a time the gap jumps in and out.
These are expected behaviours in my opinion when zoom is being used but to the original posters problem I see no gaps in any of my browsers now that I’m back on a desktop and as you have seen no gap except for zoom either then I feel its a local issue but you never know
That’s one of the fixes I looked at. You can setup an infinite animation using a zero transform. It didn’t work for me, but I may not have set it up correctly. Also seems a bit of a hack.
There are issues on an Android phone though Paul, and that is without zoom applied — or should I say without manually applying zoom.
I guess that’s just an android bug with position-sticky and of course may be a pixel density or resolution issue as well. I wouldn’t actually use sticky like that for small screen anyway as that small screen version was just an afterthought. I would prefer to linearise the whole table like I did in this example.
It does use sticky elements but hopefully not in a way that should cause any problems as its only using top and the odd pixel there shouldn’t matter.
In Chrome on my laptop, the issue is not uniform, not the same issue between all sticky cells. Vertically, the issue is between cells in col1 and col2, but not between cells in col2 and col3. Horizontally, its not between every row, but between rows 1 and 2, then every second row. Between rows 2 and 3 no issue. It there is a conflict between border/margin and positioning, wouldn’t it affect all positioned elements, not just some? Or is that too big of an assumption?
No I see the same in zoom and its not uniform because elements are rounded up and down and the bug can appear in some and not others. It also varies between browsers and platforms.
I’m more concerned with why you are seeing this at a normal zoom and whether we can fix that somehow? As I say I can’t duplicate it on my desktop either (without using zoom) but it may be that your resolution and set up produces the bug. Position:sticky does have to be calculated and like other positioned elements is susceptible to pixel differences in certain situations.
Here’s one last try using box-shadow instead of borders to see if it makes a difference.
No difference. Is it worth submitting as a bug or too early? Surely all same positioned elements are affect the same way, and should display the same? A conflict should affect the same elements the same way. Yes, Windows 11. I haven’t changed default settings, not that I would want or know how to.
That’s a shame as that version doesn’t show any of the problems with zoom that the others do.
Yes I gave an example above in the reply to @rpg_digital of 2 simple divs where the absolute element drifts apart on zoom. I’m assuming that you see the gap by default?
Well there is a conformity in that you get gaps where the pixel measurements are not exact and that may not be every element but there will be logic to it.
You can see that a simple box is mis drawn from this SO question which is due to windows scaling above 100%.
It’s not a bug its a feature
If you read the following article you will get a sense of the scale and scope of the problem from a browser developer.
In other words there is no real solution although some browsers are better than others.
Some windows laptops are set by default to 125% or 150% when they are part of a hi-res screen. You can check your settings like this:
Right-click on the desktop
→ Select “Display settings”
Under the “Scale and layout” section, look for:
3.* “Change the size of text, apps, and other items”**This dropdown shows something like:
100% (Recommended)
125%
150%
If it’s set to 125% or higher, that’s why things might render differently than expected.
To Adjust It:
Choose 100% if you want to match the base CSS pixel grid
Be aware that going down to 100% on a high-DPI screen might make UI text and icons very small
It looks to me as there is no reliable way to handle these pixel differences at the moment because fixing it for the few will break it for the many. You’ll likely have to code with no positioned elements (but even then borders can still be misplaced) to achieve the best degree of success. I have though seen similar questions and problems with flex and grid so it may be that you have to wait for better browsers.
Scale default set at 125% (Recommended), Changed it to 100%, issue rectified. Yeah, everything is a lot smaller. Pity eyesight doesn’t come with zoom.
Thanks.
maybe do an inspect with devtools and see if it shows anything odd for those borders or border-spacing.
“Change the size of text, apps, and other items”**This dropdown shows something like:
To Adjust It: