10

I am used to using the   HTML character to visually fill out the width and/or height of tables so they are used to their full potential:

So that instead of this: I get this:
table without the non-breaking space table with the non-breaking space
                                                                 
Looks much better, right?

I use a string of non-breaking spaces within the cell that doesn't use its space within the table optimally.

However, since I think a few months, the parsing of the non-breaking space character in tables has changed, and now I get this:

While the images are neatly evened out, and the table with both cells still renders at the width of the post, there is an empty space rendered to the right of the table, outside of both cells, which can be navigated to using a scrolling bar. But this is completely useless, and both uses up space and is bad UI/UX design.

What's strange is that I use the exact same trick in the top table here, and it renders like I'm used to - that is, without the extra space and the scrollbar - which makes me think this 'problem' is site-dependent.

The documented case here happens on Worldbuilding, here. There is no difference in behaviour between creating an answer or a question.
After testing it on Arts & Crafts, I get this same new behaviour (also both in questions and answers) where I'm certain it wasn't the case before.

Does anyone know why and/or when this happens?

It might have something to do with whitespace:nowrap of the <th> elements. When removed, the table behaves like I remember it.


Environment this behaviour is seen on:

  • Windows 10 Pro, 21H2
  • Firefox 95.0.2 (64-bit) (I was able to reproduce it in Edge 97.0.1072.62 (64-bit), without plugins)
  • Scripts: Privacy Badger, Decentraleyes, HTTPS Everywhere, and Tampermonkey with AutoReviewComments, FlagFilter, Helpful Moderator Userscripts, kbd formatting button for stackexchange, StackExchange Moderator Tools Improved
  • Screen resolution: 1920 x 1200

(I've brought up the possibility of implementing a custom method of evening out the width of the cells in my other question here.)


Related table experiments in the Formatting Sandbox

21
  • 2
    What sites do you see this on?
    – Laurel
    Jan 16 at 14:25
  • 2
    Without links to posts which exhibit the various behaviors, or demonstrating the actual behaviors within this question, there's not going to be much which we can do to address this. We need to be able to see the actual pages where the differences exist to see what's causing things to be different. There are a variety of things which could cause the differences. Without links to pages where there are differences in rendering, we would just be guessing, which is effectively useless. In other words, without links to actual examples, this question is, unfortunately, a waste of time.
    – Makyen
    Jan 16 at 15:45
  • 1
    Also: you need to include information about the environment you're using to display the page, including: the operating system, browser, browser version, the width of the window you're displaying these in, and any userscripts which you're using, as all of those could impact how such things are rendered.
    – Makyen
    Jan 16 at 15:48
  • 1
    If you're wanting to control the size, and thus, to an extent, placement, of the images you are including in your post, then you should be using actual HTML <img> tags and explicitly specify the width and height. Using &nbsp; to affect spacing can work, but is unreliable and often doesn't account well for different sized viewports.
    – Makyen
    Jan 16 at 15:55
  • 1
    @Makyen Thanks for your response. I'll add the information, and will add a link to the question I was writing up once I've finished it :) But if I use the <img> tags, I will also lose a lot of the space because the aspect ratios don't add up - the space from the image to the left of the table in my question here will just get redistributed.
    – Joachim
    Jan 16 at 16:19
  • @Joachim If you want specific placement, then it's on you to determine the exact sizes for the images, including accounting for differing aspect ratios. If you're wanting specific spacing, you might try adding additional elements to force it (e.g. a 1 pixel high blank image with a specific width). Yes, it's more involved, but you're the one that wants to have a specific layout. To get it, you have to work with what's available given the restriction on HTML in SO Markdown. The only thing on SO which allows explicitly specifying a particular width is HTML <img> tags.
    – Makyen
    Jan 16 at 16:28
  • 2
    @Makyen Be that as it may, that's not the question here: here I'm asking if anyone knows why this behaviour has changed (if it indeed has, which is something I have to proof first, indeed). I'll update the question once I have working examples. I think your last response would be a good comment for the question I linked to in my post, though, but there I'm also asking for the possibility of implementing something to help with spacing.
    – Joachim
    Jan 16 at 16:31
  • 1
    Yes, we'll need a specific link to the post, instead of saying: "The documented case here happens on Worldbuilding.", and going to the site doesn't show the post in question.
    – Rob
    Jan 16 at 16:43
  • @Makyen Added link to the post in question. I was able to reproduce it in the newest version of vanilla Edge.
    – Joachim
    Jan 16 at 16:49
  • 1
    Nothing here or in your provided example indicates that the behavior has changed. Thus, it's impossible to answer the question which you've asked.
    – Makyen
    Jan 16 at 17:38
  • 1
    We can, however, tell you how to prevent that. You currently append a large quantity of &nbsp; HTML entities to one of your columns. These are placed immediately to the right of the last image in that table cell, which is where you put them. If you don't want the table cell to be extended to the right, then place those &nbsp; HTML entities immediately after a <br>, so they start at the left of the cell. While doing so requires a different number of &nbsp; HTML entities to achieve what you desire, it still works (and you have an already existing blank spacer line which can be used).
    – Makyen
    Jan 16 at 17:44
  • 1
    @Makyen, spec. this comment: No, it is not: I cannot prove the behaviour has changed, because it has changed. Hence my question: "has it changed?". Furthermore, I shouldn't have to be able to prove it, because as stated I think it has changed based on experience. And whether it has changed can be answered by those who know or can inspect the code from before.
    – Joachim
    Jan 16 at 19:27
  • 2
    And I thank you and @Rob for helping me out with the issue of using proper markdown or supported HTML, but, again, the question is whether the behaviour of the &nbsp; has changed. The <br/> trick works well, however (see this post's revision history), so thank you for that solution.
    – Joachim
    Jan 16 at 19:27
  • 2
    @Rob Working at it :) Thanks!
    – Joachim
    Jan 16 at 20:01
  • 1
    Joachim, in reference to this comment, I understand that is not an answer, that's why it's a comment. I understand the question is different.
    – Rob
    Jan 16 at 20:02

1 Answer 1

10

There has been no change

There's nothing to explain here. There has been no change in how tables render with respect to this issue. There is no per-site difference. You are misremembering what you've done/seen in the past and/or confusing between the rendering of two different pieces of Markdown.

Your examples are different on different sites

Your example table in this question puts the images and &nbsp; HTML entities into a table body cell (a <td>), while your example answer puts the &nbsp; HTML entities into a table header cell (a <th>). These elements have different CSS.

Table header cells, <th> elements, have the following CSS which table body cells, <td> elements, do not have:

.s-table th {
    font-weight: bold;
    color: var(--fc-dark);
}
.s-table thead th {
    vertical-align: bottom;
    white-space: nowrap;
    background-color: var(--black-025);
    line-height: 1.15384615;
}

This partially overrides the <td> and <th> CSS of

.s-table th, .s-table td {
    padding: 8px;
    border-top: 1px solid var(--bc-medium);
    border-left: 1px solid var(--bc-medium);
    border-right: 1px solid var(--bc-medium);
    vertical-align: middle;
    color: var(--fc-medium);
    text-align: left;
}

The CSS is very similar to what it was years ago

This CSS has only changed a bit over the time tables have been a feature on SE. On 2020-11-13, about 10 days prior to tables being available on SE, the CSS for these elements was:

.s-table th,
.s-table td {
    padding: 8px;
    border-top: 1px solid var(--black-100);
    border-left: 1px solid var(--black-100);
    border-right: 1px solid var(--black-100);
    vertical-align: middle;
    color: var(--fc-medium);
    text-align: left
}
.s-table th {
    font-weight: bold;
    color: var(--fc-dark)
}
.s-table thead th {
    vertical-align: bottom;
    white-space: nowrap;
    background-color: var(--black-025);
    line-height: 1.15384615;
    text-transform: uppercase;
    letter-spacing: .05em
}
.s-table thead th:not(.s-table--bulk) {
    font-size: 11px
}
.s-table tbody th {
    font-weight: normal
}
1
  • 4
    Ah, thank you very much, Makyen! Also for your patience! The <th> vs <tr> is a very good observation. Implementing your <br> trick also works to get rid of the scroll bar. I'm checking out multiple ways of rendering tables. I'll add the link once it's done.
    – Joachim
    Jan 16 at 20:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .