wiki.selfhtml.org grid-layout broken - Maybe a browser bug?

[AndieM]

Pale Moon 33.7.2 (64-bit) (GTK 3)
Debian 12 (stable/Bookworm), using the MX-Repo-Package from Steve Pusser
☑ I tested it with a fresh PM-profile, no add-ons.
https://wiki.selfhtml.org/

Hi,
I'm not sure, if it's a website bug (I'm a bit pessimistic) or a bug in Pale Moon. If it's confirmed, feel free to move this thread.
I just want to make sure, that it's not a problem on my setup first, before opening a bug report.

The selfhtml-wiki (in Germany quite old & known site on html, css, js…) has a layout problem.
It seems like the combined grid-property of the body element is not correctly interpreted, if the width is greater than 40em (…media-query).

As result the layout gets completely broken, with the nav floats above the content, nothing clickable, etc. (See screenshot 1)

The respective css-rule (pretty-printed), looks valid for me, but I am no expert in grid-layout:

Code: Select all

grid: "selfnav selfnav" var(--selfnav-height) 
      "leftnav persnav" auto 
      "leftnav content" auto 
      "leftnav footer " 1fr 
      / var(--mw-panel-width) minmax(1em,60em);

Raw excerpt from the css-file (that is minified…, https://wiki.selfhtml.org/load.php?debu ... n=selfhtml):

Code: Select all

@media (min-width:40em){body{--content-margin-inline:0.75rem;display:grid;grid:"selfnav selfnav" var(--selfnav-height) "leftnav persnav" auto "leftnav content" auto "leftnav footer " 1fr / var(--mw-panel-width) minmax(1em,60em);column-gap:0.7em;padding:0}}

The Error console and the Developer Console are completely empty:

Code: Select all

(none)

It might be a bug in parsing the combined grid-property?

Because if I extract the `grid-template-areas`-part and add it manual with the Inspector (…or via userscript), than the website renders afaict as the property specifies it. (Also adding -rows and/or -columns with the respective content doesn't alters the rendering further for me.)
(Screenshot 2, don't know if the `leftnav`-column is rendered as it intended, but that's another question):

Code: Select all

grid-template-areas: "selfnav selfnav" "leftnav persnav" "leftnav content" "leftnav footer "

Can somebody confirm, that it's a general problem with PM on the website?
Did I miss something?

Off-topic:
Kind of funny …and not : if you can read up the information on the css properties for the hot fix on the same site that shows the problem…

[Moonchild]

Not sure who designed that mediawiki theme but I really don't think it will render well in a lot of browsers.
I loaded it up in Edge and even there the site looks half-broken to me and has a really strange page layout. (very similar to the result you achieved with grid templating correction, but with a few more visual effects filled in).

[adoxa]

It doesn't like grid containing var; here's a userstyle to fix it (along with the missing logo, due to unsupported aspect-ratio).

Code: Select all

@-moz-document domain("wiki.selfhtml.org") {
  body {
    grid: "selfnav selfnav" 2.5em "leftnav persnav" auto "leftnav content" auto "leftnav footer " 1fr / 19vw minmax(1em,60em)
  }
  .self-logo {
    height: var(--logo-size)
  }
}

Alternatively, here's a Modify HTTP Response filter, which also fixes colors (unsupported light-dark, assumes light) and the bottom navigation bar (assuming a minimum width of 42em; unsupported @container).

Code: Select all

[["wiki.selfhtml.org",["/mediawiki\\.legacy/",["/aspect-ratio:1/1/g","height:var(--logo-size)","\" var(--selfnav-height)","\" 2.5rem"," var(--mw-panel-width)"," 19vw","/light-dark\\(([^,]*),var\\(.*?\\) ?\\)/g","$1","/var\\(--cont-height\\)/g","3rem","/var\\(--cont-arrow\\)/g","1.5rem","max-width:25em;","max-width:unset;grid:\"prev prev main next next\" 3rem / 1.5rem 1fr 1fr 1fr 1.5rem;"]]]]

It doesn't fix the list links (unsupported :has) nor the paragraph chain icon (svg doesn't support style).

[Rolf B]

Moderator note: topic unlocked and post moved to it

Hello,

I'd like to follow up on the locked posting from June, found here: https://forum.palemoon.org/viewtopic.php?f=70&t=32491#p263529. If I am not at the right place here, please tell me how to do it properly.

I am the 2nd chairman of the Selfhtml Verein (uh, I think "nonprofit association" is the english term) and the author of that stylesheet. We are really short-staffed and don't follow the discussions in the Palemoon forum and so we missed this problem.

After some investigation, I found that one hypothesis from the previous thread is not quite right. Adoxy said

It doesn't like grid containing var

- but yes, Pale Moon does like that. The problem is deeper: Pale Moon does not always find the custom properties that are in scope. I tried to reproduce this in codepen, but couldn't. Maybe it is a problem of larger stylesheets?

If you inspect the loaded style sheets for the Selfhtml Wiki, there is a style rule that defines --selfnav-height for html and body. It was :root, but I changed that to reduce a possible source of error. BUT the value is not applied in the grid-property. When I add --selfnav-height: 2.5rem and --mw-panel-width:12rem as style-Attribute to the body (using Pale Moon devtools), then they are used in the grid definition.

Since this stylesheet works with Firefox, Edge and Chromia, I would assume a bug in Pale Moon.

Moonchild wrote

(...) I really don't think it will render well in a lot of browsers. I loaded it up in Edge and even there the site looks half-broken to me and has a really strange page layout.

Which Edge? Hopefully not the pre-Chromium one? As far as I know, the theme does render well with Firefox, Chromia (Android and Windows) and Safari (Desktop and iOS). I use it frequently in Edge (Chromium Edge on Windows). But in June, we rolled out an update, and maybe that led to bad rendering for a short time. And of course I cannot rule out the possibility that you just don't like our layout and consider it broken when it shows up as designed.

The other problems are a different thing. light-dark() is CSS Color Level 5, a working draft, and so at least I should provide a fallback. @container queries are more complicated. They are available since 2023 in all big browsers and since I built several parts of our theme on them, they are difficult to replace.

With improved custom property support on your side and light-dark() fallbacks on our side, Selfhtml should at least work better.

Greetings and have a merry christmas
Rolf

[jobbautista9]

Yes indeed grid should support var() values just fine. I've debugged it deeper and it seems to be caused by the --mw-panel-width custom property using clamp() (CSS Values and Units Module Level 4, still a working draft in the W3C) which is not supported by our CSS engine yet.

The other problems are a different thing. light-dark() is CSS Color Level 5, a working draft, and so at least I should provide a fallback. @container queries are more complicated. They are available since 2023 in all big browsers and since I built several parts of our theme on them, they are difficult to replace.

Unfortunately @container is from CSS Containment Module Level 3 which is also a working draft. Or is it from CSS Conditional Rules Module Level 5 as documented by the MDN? Regardless they're both working drafts...

Off-topic:
I really wish mainstream browsers doesn't just put any feature that is still a draft in a stable release...

[Rolf B]

Hello,

okay, I removed light-dark() and clamp() from the central custom property set and replaced it with @media (prefers-color-scheme:dark) and @media (max-width) and @media (min-width) blocks. Unfortunately, dark mode is also draft material, but now it can be seen as a graceful degradation and not as a negligent blunder as it was before. There was a very aggressive mail that reached us at our project mail address and made us aware of the problem. Guy, thank you for the hint, but trying to insinuate software discrimination was just plain nonsense. Even if we decided to leave your mail in the spam folder (where it landed for me).

Back to topic, some parts still don't look right because they are based on @container queries, but since we try to apply the mobile-first approach, this only causes things to be put under each other (i.E. the forward/backward arrows at the bottom of several pages).

I'd like to keep it at that, the pages seem readable now (Pale Moon 33.9.1), even if they don't look exactly as they are intended to. But that's never the goal.

We will try to monitor this thread for a while, but if there are severe display problems on some pages and we don't seem to react, please contact our support at forum.selfhtml.org (Pale Moon creators and users alike). We really want be readable on Pale Moon because it's one of the last independent browsers.

Greetings and Merry Christmas again
Rolf

[Moonchild]

There was a very aggressive mail that reached us at our project mail address and made us aware of the problem. Guy, thank you for the hint, but trying to insinuate software discrimination was just plain nonsense.

Just as a note: even if the use of drafts being pushed by Chrome and ilk is absolutely to try and push the market for more own self-adoption, that doesn't necessarily mean individual webmasters are deliberately discriminating against choice of browser (even if the outcome is the same). It's only that if there's a clear response to reporting it that indicates no interest in being (at least somewhat) browser agnostic at all.

Sending aggressive e-mails to webmasters to point out web compat issues is the wrong approach. It's actually harming what you're trying to achieve because it's (much!) less likely to get a positive response. I appreciate that it was considered to uptake, regardless, in this case.
It's much better to clearly outline there is a problem, what you've done on your end to try and mitigate, cause (if known) and potentially point to discussion on our forum as a point of reference with a request to look into it. Please follow this guideline in the future

common_sense_is_tingling.jpg

[Gemmaugr]

Hello,

okay, I removed light-dark() and clamp() from the central custom property set and replaced it with @media (prefers-color-scheme:dark) and @media (max-width) and @media (min-width) blocks. Unfortunately, dark mode is also draft material, but now it can be seen as a graceful degradation and not as a negligent blunder as it was before. There was a very aggressive mail that reached us at our project mail address and made us aware of the problem. Guy, thank you for the hint, but trying to insinuate software discrimination was just plain nonsense. Even if we decided to leave your mail in the spam folder (where it landed for me).

Back to topic, some parts still don't look right because they are based on @container queries, but since we try to apply the mobile-first approach, this only causes things to be put under each other (i.E. the forward/backward arrows at the bottom of several pages).

I'd like to keep it at that, the pages seem readable now (Pale Moon 33.9.1), even if they don't look exactly as they are intended to. But that's never the goal.

We will try to monitor this thread for a while, but if there are severe display problems on some pages and we don't seem to react, please contact our support at forum.selfhtml.org (Pale Moon creators and users alike). We really want be readable on Pale Moon because it's one of the last independent browsers.

Greetings and Merry Christmas again
Rolf

Really, thank you for not only coming here and discussing it, but also taking feedback and accommodating the last independent browser (engine)!

As a simple Pale Moon user, it's heartening to see a site developer considering fallback code and browser agnosticism today.

Now, doing a "mobile-first" approach may seem like common sense today when almost everyone has a smartphone (not me though), but that also makes you beholden to googles vertical web integration. Because the majority of smartphones are using googles Android OS (the other biggest is Iphone, using Safari/WebKit that chromium's Blink forked from). Which has googles WebView (chromium-lite) as a default browser and engine for 99% of other Android OS browsers (GeckoView is the 1%, though that's very chromium-like too). Most sites are also written with site frameworks that rely on googles V8 javascript engine (Angular, Next/Node/Vue.js), or coding only for chromium (React.js). Many apps are also using chromium via googles Electron or CEF (Chromium Embedded Framework) or googles Flutter. Sites using google Firebase for a Cloud Computing/CDN is also increasing. The site frameworks also rely on API implementations from google controlled WHATWG. Finally, sites tend to want to have third party injections like google ads, google tag manager, google fonts, etc.

Just something to consider when so much is under the iceberg. The latest may look shiny to a few new, but fallback code endures for most viewers.