Bitcoin Forum

So, there's this really annoying and long-standing forum bug that "squashes" the first column in tables (but only after you've posted; it doesn't present during preview).

For example, here's a table from one of theymos' old posts (https://bitcointalk.org/index.php?topic=2818350.msg28856522#msg28856522), as it would appear if not for the presence of this bug:

https://talkimg.com/images/2024/08/27/9ns8g.png

And here's how that table actually displays:

https://talkimg.com/images/2024/08/27/9nIfH.png

The earliest mention of this bug (that I could find) is from 2014:


In that same topic, Foxpup pointed out this hinky bit of CSS:


I don't know who added that CSS, or when it was added, but here's what I think happened:

(*) There's a flaw in original SMF 1.1.19 that makes a variable-length gap appear between a post's icon and its subject (beyond the comment in the CSS, I know this to be the case because that same flaw is present in my own branch of SMF, which is also based on 1.1.19).

(*) Someone attempted repair of that flaw by coming up with a CSS selector to (try to) isolate just the <td>s that contain each rendered post's icon, so that they could fix the width of those <td>s to 26px (which does succeed in repairing the "gap" flaw).

(*) The problem is that the selector they came up with has a flaw of its own: it selects more than just the <td>s with post icons in them, reaching into the post itself and affecting first-child <td>s there, too (it does this, by accident, because of an apparent misunderstanding of descendant selectors (https://www.w3.org/TR/CSS2/selector.html#descendant-selectors): because descendants are a less specific concept than children, there's actually nothing in that selector that prevents it from reaching deeper into the post, affecting <td>s that it was never meant to affect).

I've come up with three ways to fix this bug (I mean, there are many ways, with various pros and cons, but the below three are the ones that make the most sense to me):

Fix A

This just fixes the CSS selector so that it does what the original author clearly intended. I can see an argument for simplifying the selector around a new class added to the relevant <td>s, but, there's also something to be said for just leaving everything the way it is (except for one tiny little selector tweak, that is).


Fix B

This removes the buggy CSS entirely, and then fixes the now-exposed "gap" flaw in a less brittle way. I mean, I get that putting a width attribute on the <td> probably gives modern web devs the heebie-jeebies, but, there's plenty of precedent for that in SMF's ancient markup, and there's no real value in having a very small handful of spots in the markup/styling that try to do things "the right way". I think era-appropriate fixes are fine for SMF, and that any serious attempt to modernize the frontend should be done independently of the legacy frontend.



Fix C

The problem (as I see it) with either of the previous fixes is that they repair the bug for all posts (old and new). I guess most people won't really see eye-to-eye with me on this one, but, I'd prefer it if new posts weren't affected by this bug (obviously) but that older posts were. My thinking is that people have for 10+ years been using all sorts of workarounds and tricks to avoid this bug, and those workaround-remnants are inevitably going to display slightly differently post-fix. From a history-preservation perspective, I like the idea that posts that were constructed in the presence of this bug will not appearance-wise be affected by the fix.



@theymos: That last diff is a little confusing because class="td_headerandpost" is something that's already present in your branch. The relevant change is just to make sure that the icon-containing <td> has a width="26" (same as with Fix B), and that the td_headerandpost <td> comes out either with two classes (class="td_headerandpost with_column_bug") or one (class="td_headerandpost") depending on some predicate that separates old posts from new. If you can pinpoint when this bug was introduced, then you might also consider changing the predicate to account for that (e.g. $message['id'] > 8800000 && $message['id'] < 64471000), so that posts that displayed correctly before this bug, will return to displaying correctly. (Obviously, the message IDs I've used are just examples that need to be replaced with more precise ones.)

I think fix C is the most suitable, without a doubt. Pots from the last 10 years, with tables, were designed to support this bug. No one will keep changing thousands of posts to readjust to the new table paradigm. Therefore, a mixed solution is most recommended.

But you know @PowerGlove, one thing I always found strange is that this error didn't always occur. For example, I have tables that are created automatically via Excel formulas, and when I place the generated BBCode here (https://bitcointalk.org/index.php?topic=5505111.msg64449880#msg64449880), the bug does not occur. Did you understand why?

Other than that, another excellent job, congratulations!  ;)

Yep, I can see what's happening with the two tables in that post: their first columns happen to only contain "rigid" things. If, for example, you changed the second table so that the "POS" column had values in it with spaces (like "No. 1", "No. 2", etc.), then the bug would be visible.

Thanks!

In Katy Perry's singing voice: "I squished a bug, and I liked it; the crunch of its meaty thorax. I squished a bug, just to try it: I hope that theymos don't mind it." :D

OK. This explains the situation a little.
But, I think I've already made other tables where the content has "spaces" and it doesn't happen. Now I don't remember where...  :-X

Either way, we have the solution ready to be implemented. Now we just have to wait for the "borucracy of the authorities".  :P

I think Fix C is the best option.
If I understand correctly this fix won't mess around and change anything in old posts, and I like that more than having old tables looking broken.
All I can say is that every time I tried to make a post with tables I run into problems, and previews almost never look the same as the actual post.

If you find examples that you can't explain then please share them with me.

I can tell you ahead of time, though, that if you find an example of a table that isn't trying to work around this bug, yet still manages to display correctly while having non-rigid items in its first column, then what's likely happening is that each of those items is the same width or narrower than either 26px or some other rigid item that is defining an effective minimum width for the entire column. (After all, one of the workarounds is to intentionally create some kind of width-defining thing for the first column, and sometimes that just happens by chance, like when the column title is a long word that ends up being wider than anything else in the column.)

I don't really care which option is chosen, as long as the result allows for an acceptable width for the Crypto Cards List topic I've got in the Service Discussion though.

It's always weird for the first column to be squished together so that the each word is on a different column. Anyhow, I expect one of these patches to get merged soon, whichever one works best.

I don't construct tables often, but this formatting bug is one that would drive me crazy, if I were not aware of it. I stumbled over this bug only maybe a few months ago. It's especially nasty when the post preview is just fine but the end-result isn't.

I prefer fix C and hope @theymos approves your patch! Squish it soon, please!

I highly hope this patch gets put in production.
I usually post some convoluted tables in my posts.
I often encountered the bug, and the solution is neither simple nor effective.
I have tried to solve one instance of this bad formatting for months, and I found help by 1miau (https://bitcointalk.org/index.php?topic=5492105.msg63922934#msg63922934), but it would be much better if the source of the problem could be fixed.