Seems more reasonable than how it looked at first.
Since the page where the bug manifests itself already has responsive CSS
styling, we can quirk TextAutoSizing to skip adjusting for it, at least
until we figure out why we are calculating RenderBlockFlow width inconsistently:
https://bugs.webkit.org/show_bug.cgi?id=275223
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...
Other big players, such as Amazon, simply negotiate the Apple tax – instead of paying the 30%.
Naturally, Apple doesn't tell you how often and for whom it breaks its rules.
Any app whose purpose is to allow users to access subscription content works this way.
Netflix would be another common example of an app that is used to access subscription content and is not useful without an account.
If your app is free, but a subscription to your content is not, the most common practice is to not allow users to pay the subscription fee through your app at all. If users can't pay through your app, then Apple doesn't get a dime.
Maybe I'm misunderstanding what you mean, I'm genuinely interested.
I usually disagree with Apple's restrictions, but isn't this (rather clearly) under the Enterprise application exception (App Review Guidelines 3.1.3(c), and indirectly 4.8)? This is, clearly, an enterprise product (you can't even register with this version unless you're a company). Do you actually knows the rules or are you just spewing garbage out of your mouth?
Actually, won't third-party mail applications also be in violation of the purported restriction because, by the nature of being a mail application, needs to log in before any use? You should actually point out which rule/s are being broken because despite honest attempts to find the alleged rule being broken... I simply don't see that rule/s.
They let me in, after a few hoops. This was in 2016-2019 (but now they are PWA)
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.
Almost all of the warning and errors are related to using obsolete Element attributes and invalid <table> definitions. Those shouldn't need any larger rework to clean up.
I don't say this trying to imply that HN needs to fix these or are being lazy in not doing it. YC has priorities and provide HN for free. It's totally up to them whether fixes are worth it, I just wouldn't expect it to be a huge lift.
A semantically correct HTML would be something like a frontpage with an <ol> and the comment section would be a series of nested <article> each with a <header> containing the author a <time> and an extra bonus if the parent/context/sibling links can go under a <nav>. And the separators between the header elements should not be a text content pipe character `|` but rather a CSS border-inline-start: 1px solid currentcolor;
A minimal and semantically correct HTML does not only offer superior experience for users of assistive technology, it also make your page machine readable, so users can install browser plugins to e.g. do something useful with the <time> element, and ultimately makes your page much easier to style with CSS.
Whoever is currently maintaining the codebase has taken years. They have been making changes to the HTML of the site: SVGs were added for the voting arrows as the first example I can think of, so its not like its being left to languish completely. They just don't care.
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;
Seems to be specifically for (not) upgrading images and videos from http to https, nothing else.
I don't hate CORS when writing my own stuff, to be clear. Adding Access-Control-Allow-Origin: * to my own website's headers is easy enough. I hate when I'm using a website and something doesn't work and I look at the console and see CORS errors. Opening the same website in Chrome usually works.
I hate CORS.
Do you have some examples of this?
Looks like it's a bug on their side and this is a bandaid?
That will presumably live forever.
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+
This also came to my mind.
Yes and so it makes sense today because CSS pixels are resolution independent. If something worked on 1024x768 monitors in 2007 but is too small on your monitor today then the problem is with your settings not the website.