Another forum update - cosmetic change

[UCyborg]

Seems the forum was recently updated. I don't remember the extra whitespace between member information and post content in people's posts. Is this just how the default theme that comes with the software is now or are there settings on the server side?

Either way, I prefer the old look, I find the extra whitespace screaming "Hey, look at me!". The old look can be achieved by applying the following CSS:

.ipsComment_author {
  margin: unset !important;
}

Or you could do:

.ipsComment_author {
  margin: 0 10px 0 0 !important;
}

I find this prettier, considering the space on the left. Beauty is in the eye of the beholder, so YMMV.

Edited April 21, 2022 by UCyborg

[NotHereToPlayGames]

I'm always tinkering with my style sheet for much more than just whitespace and I thought the same, what "purpose" did that whitespace serve?

[UCyborg]

After our conversation was ended abruptly in the other thread by the oppressive dictators...new update, new changes. Yes, @mina7601, I also noticed, wanted to reply there, but couldn't for obvious reasons.

Correcting reply counter position on the main page under Topics section for browsers not supporting inset-inline-end CSS property, most notably Chromium <= 86:

.ipsWidget,
.ipsDataItem_main,
.cWidgetComments,
.ipsCommentCount {
  right: 0;
}

"right" indeed works, @NotHereToPlayGames. I suppose new property would be useful in combination with other properties mentioned on that MDN page.

Another change with recent update is font-weight set on elements with the class .ipsDataItem_title, it's used for thread titles on pages where forums threads of specific sub-forum are listed. Noticeable particularly on newer Chromium based browsers.

Before - font-weight: 400

After the update: font-weight: 500

Reverting to old look:

.ipsDataItem_title {
  font-weight: 400 !important;
}

Edited June 11, 2023 by UCyborg
insert->inset

[xper]

Fixed all. Thx.

[NotHereToPlayGames]

15 hours ago, UCyborg said:

Correcting reply counter position on the main page under Topics section for browsers not supporting insert-inline-end CSS property, most notably Chromium <= 86:

"right" indeed works, @NotHereToPlayGames. I suppose new property would be useful in combination with other properties mentioned on that MDN page.

I haven't found a method yet, but I would prefer insert-inline-end: to be replaced with right: by using Tampermonkey instead of Proxomitron.

[UCyborg]

Seems inset-inline-end support can be enabled in Chromium 86 by turning on experimental web platform features (chrome://flags/#enable-experimental-web-platform-features).

I think more technically correct approach in this case in the absence of support for that property would be having another 2 selectors checking HTML document (text) direction, like so:

html[dir="ltr"] .ipsWidget .ipsDataItem_main.cWidgetComments .ipsCommentCount {
  right: 0;
}

html[dir="rtl"] .ipsWidget .ipsDataItem_main.cWidgetComments .ipsCommentCount {
  left: 0;
}

Regarding replacing, I'm not sure it's possible to directly intercept the network request initiated by web browser when it encounters links in page's HTML to external resources from user script, extensions can do that, but what can be done:

document.querySelectorAll('link[rel="stylesheet"], link[rel="preload"][as="style"]').forEach(e => {
  fetch(e.href)
    .then(response => response.text())
    .then(data => {
      const s = document.createElement('style');
      const m = e.getAttribute('media');
      m && s.setAttribute('media', m);
      s.innerHTML = data.replace(...); // replacement logic here - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/replace
      e.parentNode.replaceChild(s, e);
    })
    .catch(err => console.log(err));
});

Basically replacing link elements linking to CSS files with style elements, embedding content of linked CSS files, which may be manipulated before put in place.

[UCyborg]

On 6/9/2023 at 7:51 PM, xper said:

Fixed all. Thx.

What exactly has changed? I've made this thread back in 2022 to point out much larger spacing between user's profile data and the content of the forum post. This was reduced at some point, so I guess someone on the forum side did look at it.

But at present day, after the relatively recent forum update (the one that apparently sent some people into panic mode for the forum not being available for few days), an inconsistency appeared in boldness of fonts between updated Firefox and updated Chromium browsers on the pages with thread lists. See the two images in few posts above (still relevant at the time of writing this post).

Both pictures are from Edge, but the text would still appear like in the first picture in Firefox because there's not much (if any) difference between CSS font-weight values of 400 (before forum update) and 500 (after forum update) on that browser, the value of 500 being used since the update that makes the text noticeably bolder in Chromium.