Apparently it's a workaround until <a href="https://bugs.webkit.org/show_bug.cgi?id=275223" rel="nofollow">https://bugs.webkit.org/show_bug.cgi?id=275223</a> is understood and fixed.<p>Seems more reasonable than how it looked at first.
There are two previous discussions on WebKit's Quirks.cpp [0] here:<p><a href="https://news.ycombinator.com/item?id=33207685">https://news.ycombinator.com/item?id=33207685</a><p><a href="https://news.ycombinator.com/item?id=26165357">https://news.ycombinator.com/item?id=26165357</a><p>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?<p>[0] <a href="https://github.com/WebKit/WebKit/blob/84ae355619354ee1bfa7daaa1fc95565a6726be3/Source/WebCore/page/Quirks.cpp">https://github.com/WebKit/WebKit/blob/84ae355619354ee1bfa7da...</a>
Looking at the html of HN's pages, can't blame them really.<p>Running though <a href="https://validator.w3.org/" rel="nofollow">https://validator.w3.org/</a> , the result is abysmal.<p>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?<p>But after having a closer look at the PR, the 1900 LOC monstrosity Quirks.cpp actually seems to exist with lots of things like<p><pre><code> if (host == "tripadvisor.com"_s || host.endsWith(".tripadvisor.com"_s))
m_needsRelaxedCorsMixedContentCheckQuirk = true;
</code></pre>
Fixing CORS issues has never been easier
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: <a href="https://bugs.webkit.org/show_bug.cgi?id=245612" rel="nofollow">https://bugs.webkit.org/show_bug.cgi?id=245612</a>
> we can quirk TextAutoSizing to skip adjusting for it, at least
until we figure out why we are calculating RenderBlockFlow width inconsistently:<p>Looks like it's a bug on their side and this is a bandaid?<p>That will presumably live forever.
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. <i>At the very least</i> 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.<p>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 <i>something</i> related media playback or recording stopped working on Safari.<p>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.<p>See <a href="https://news.ycombinator.com/item?id=40134383">https://news.ycombinator.com/item?id=40134383</a>. On BrowserStack, still no Safari dev tools on iOS 17.4+
TIL that <i>it's not just me</i> 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.