There are two previous discussions on WebKit's Quirks.cpp [0] here:
https://news.ycombinator.com/item?id=33207685
https://news.ycombinator.com/item?id=26165357
I wonder how big your site has to be to earn a spot in that file when you hit a Safari bug. Don't suppose Apple publish the criteria anywhere?
[0] https://github.com/WebKit/WebKit/blob/84ae355619354ee1bfa7da...
Looking at the html of HN's pages, can't blame them really.
Running though https://validator.w3.org/ , the result is abysmal.
At this rate, if web browsers started requiring sites to output HTML that is somewhere in the realm of normalcy, HN would sooner shut down than consider ever updating.
I imagine there are some stories out there of people tearing their hair out over issues in prod can’t be reproduced in localhost (or vice versa) due to quirks exceptions.
I seriously thought that implementing some site specific custom rendering behaviour was meant as a joke. Why change html/css for a website when you can just implement some hardcoded site specific behaviour straight in the rendering engine? What could possibly go wrong?
But after having a closer look at the PR, the 1900 LOC monstrosity Quirks.cpp actually seems to exist with lots of things like
if (host == "tripadvisor.com"_s || host.endsWith(".tripadvisor.com"_s))
m_needsRelaxedCorsMixedContentCheckQuirk = true;
Interestingly there seems to be a few quirks for twitter.com, but none for x.com. I assume that'll lead to some regressions?
Unfortunately these hacks last forever and can cause other problems. My web browser extension had to add a hack to work around WebKit's YouTube hack: https://bugs.webkit.org/show_bug.cgi?id=245612
> we can quirk TextAutoSizing to skip adjusting for it, at least until we figure out why we are calculating RenderBlockFlow width inconsistently:
Looks like it's a bug on their side and this is a bandaid?
That will presumably live forever.
I am confused. What part of the hacker news web source was more difficult to change than the source code for my web browser?
This feels like a poor solution to the problem. As much as I like HN, browsers changing to maintain the status quo is a terrible idea. At the very least there should be a user controllable array of domains to apply this to in the config rather than a single magic string for one website.
Do other browser vendors add special cases in their codebase for specific sites? It seems like a really bad idea.
Since around 2020, I've been working on an app that makes heavy use of audio playback and recording. I feel like I am frequently making Safari specific updates because something related media playback or recording stopped working on Safari.
I don't recall this kind of regression ever happening with Chromium-based browsers or Firefox. It feels weird in 2024 to be adding work-arounds and hacks specific web browsers and anecdotally, it seems to be getting worse.
See https://news.ycombinator.com/item?id=40134383. On BrowserStack, still no Safari dev tools on iOS 17.4+
Is this triggered by HN being a table-based layout? Shouldn't this then affect way more sites?
TIL that it's not just me who finds the default text size on HN to be excruciatingly tiny. I'd presumed that it was just an unfortunate side-effect of aging and poor vision!
Awesome, time to submit a ticket to WebKit to auto-adjust HN's default text size to 16px like everybody else instead of 12px. It made sense in 2007 when your resolution was 1024x768.
A quick glance at the title made me hope HN would finally allow screen-responsive auto-wrap of text lines. Its 2024 now and we know a thing or two about good vs bad UX.
OT but what's up with the spam comments? What's the purpose?
Apparently it's a workaround until https://bugs.webkit.org/show_bug.cgi?id=275223 is understood and fixed.
Seems more reasonable than how it looked at first.