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.
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.
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.
Both of the companies mentioned don't make money from the use of their app -- at least not directly.
Sure, you can do all of your purchasing w/ Amazon through their app, but the website remains available if that is more to your liking. For free apps like Google Calendar, this is also the model.
Bloomberg's app is a front-end to the Bloomberg Professional Service (colloquially, "The Terminal") and to read more than a few articles or access any of the data sources, you need to sign up.
Tl;dr It's not cheap
Free trials can be converted on iOS, but -- and correct me if I'm wrong -- require going to a web browser instead of it all happening inside of IAP, although, that could come along at some point...
(Based on no inside information, that might be the case this fall, check back in a few hours to see if it actually comes to pass)
At the very least, if an application absolutely requires an account to function, this should be prominently displayed, and they should explain in technical details what functionality cannot be possibly achieved without logging in. App Stores should reject apps that gate basic phone functionality (like GPS directions or camera access) behind an online account. These things obviously don't require an account to work, because they work on the default apps without accounts.
This is the answer IMHO. I love that Google has been moving this direction with the Play Store, and I'd love to see them continue. Labels with "requires account" or something would be immensely helpful, and would be mandatory if I became ruler of the Play Store.
I was tinkering with some Instagram code the other day and a console message appeared in dev tools saying (roughly) "Did someone tell you to mess with this? If they did, they are probably trying to scam you. Stop what you are doing."
This is really abusive, no wonder they are getting sued by the DOJ.
Then if you don’t want to pay the Apple tax you can subscribe directly. This incentivizes Apple to keep the fees low.
At some point, you have to just admit that as a business you have certain costs that you have to pay to operate. This mentality, that business costs must be borne by customers, is what's leading to all these ridiculous hidden fees and charges at other businesses.
There are many places that do not even accept AmEx specifically because of their fees. Charging more based on card use has always been a thing until the card companies used their cartel like persuasion to not allow that. However, I'm starting to see stores offer different prices for cash/debit than credit. I thought I remembered this being made allowed again, but it's early still.
You as a user feel like you should be able to buy whatever whenever with whatever mode of payment. That's very convenient for you even though you're the one that has decided to use that particular mode of payment even though you know your mode of payment is an absolute pain in the arse for the merchant. Not having you as a customer is a perfectly valid point of view from the merchant.
Alternatively, you could take Apple's example and charge people an arbitrary amount for the privilege of accessing your business and leave the certainty of certain costs for the shmucks.
I 100% believe this should be the case. It's unfair to merchants to take away an arbitrary percentage of their profits depending on which card you want to use.
As it was, sellers would earn 30% less for sales gouged by apple
Interesting that this post got flagged. Y'all are showing your biases. Nothing about this post violated any HN rules.
Anyway, you can set [default] zoom once and enjoy.
Unless you’re in a browser in which no one uses that per-site zoom feature cause it’s not implemented cause no one uses it. In this case, you can embrace the simplicity or use StyleBot.
I just switched the resolution to 1024x768, and now the same ~12px is "larger" and easier to read without needing to increase my browser zoom.
There's an obvious visual difference between the two.
Alternatively:
1px = (1/96)in
1pt = (1/72)in = (1/72)*(96/72)*(72/96)in = (96/72)*(1/96)in = (4/3)*1px = (4/3)px
9pt = 9*1pt = 9*(4/3)px = 12px
if (host == "tripadvisor.com"_s || host.endsWith(".tripadvisor.com"_s))
m_needsRelaxedCorsMixedContentCheckQuirk = true;CORS is frustrating for a lot of developers as it can be tough to gain a complete understanding of the spec, and an understanding of the same origin policy is required. But implementation of the CORS spec(s) isn't notably different across modern browsers, now that IE is out of the picture. CORS was a real nightmare in IE. Microsoft even introduced an XHR cousin named XDR in IE10 to handle cross-origin requests, and it wasn't even a complete implementation of CORS.
This is a great resource to gain a more comprehensive understanding: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
That’s my guess.
Anyway, Apple engineers aren't known for their outreach.
> no cookie popups, no "subscribe to our newsletter" slide-ins, no phenomenon where the content loads but then a second later the page resets and re-loads the content again (probably with more ads or something)
to fix rendering layout using tables and cell width to render comment levels.
Just a few lines of CSS and Arc really. That would be a big overhaul only because HN is very small, but not that big in absolute.
Anyway, the "errors" that OP mentions are simply just deprecated attribute styling and like, one or two instances of center tags. Hardly breaking anybody's back to continue supporting those.
It also creates perverse incentives for cards to pass part of the merchant fees back to the consumer as rewards or even cash. Here in the US, 2-3% cash back is typical, driving consumers to prefer credit over other payment methods.
Meanwhile, merchants are forced to bake the fees into the retail price, causing the paradox that those who pay upfront end up spending more for the same goods.
But I also find it too small on my mobile, and increasing the font size doesn't improve things, just makes it necessary to scroll sideways to read the comments.
Overall the font size settings on HN are crap. I really wish @dang would listen to the frequent complaints and fix them.
.comment { font-size: 14pt; } .comhead { font-size: 12pt; }
I set this up many years ago and have not had to touch it since.
Switching to Chrome usually fixes it - but I always question my sanity for about 10 minutes until I try it in Chrome.
The only problem is: Safari has piss-poor ad blockers. Firefox blocks custom system-wide keyboard shortcuts (on Mac).
They even have emulators now. Undoubtedly a change forced on them by the EU.
https://developer.apple.com/support/alternative-browser-engi...
But while your comparison is flawed, I agree with the assertion² that Apple should not be locking user choice like this. The EU agree too, hence Apple's immature little hissy fit nearly breaking their (already "not quite there") offline-first app support for EU users when they were told so.
--
[1] Avoiding the word "monopoly" to pre-counter the sort of "well actually" responses I got about dictionary definitions last time I said something like this.
[2] Unless I'm reading you backwards and you are saying MS should have been able to like Apple currently do!
As for the EU, they have already forced Apple to allow third-party browser engines under the DMA, as well as are forcing Apple to show a "browser ballot" like they made Microsoft do.
Microsoft’s anti-trust lawsuit with the DOJ was 23 years ago. There are people working at Microsoft and Apple who weren’t even alive when that happened.
Times change.
Google might at some point maintain two completely different Chromes targeting iOS, but I doubt anyone else will (including Firefox). Even with Chrome, I wouldn't bet on it. It's a very difficult technical problem with no clear, easily-marketable benefit to most people.
Apple knew what they were doing, they've "complied", but in a way where nobody would bother.
It's not like iOS users care anyway, or they wouldn't use iOS in the first place.