WebKit fix: Quirk news.ycombinator to skip TextAutoSizing | Hacker News Reader

WebKit fix: Quirk news.ycombinator to skip TextAutoSizing

github.com

213 pointsmkurz142 comments

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.

This is an example of somewhere a comment would actually have been useful.

I mean, it's explained very clearly in the commit message that's linked?

    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

That's even better than a comment, because you can git blame for it and get the full context of the issue (from the bug thread that proposed it to all of the documentation of the investigation done for both bugs)

I very much disagree that it's better than a comment. The git blame log will over time get layered on as changes are made to various lines, meaning you have to dive for the original message, assuming one is even there (many a time I dig for commits, only to see that the commit message doesn't answer the question of motivation very well or at all). A short comment in the code makes it obvious.

Is this the reason that Chromium based browsers always change font sizes for me on here? Since I'm visually impaired and have set my text sizing pretty large, I have that issue on multiple sites, including Hacker News. It's a bit of a gamble how large text will be when I refresh the page.

Interesting Q, I've used it at 140% in stock Chrome, for about a year, and haven't noticed an issue on refresh, but...idk, I feel like I did once a couple weeks ago. Can't trigger it now though

I have experienced the same on other sites as well, with large text size. It sounds like this bug could fit.

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...

Apple's guidelines are meant to be broken anyway. Bloomberg's app (Bloomberg Professional) is unusable without an account, which is 100% against iOS guidelines, but who cares?

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.

Apple made the rules for their convenience and benefit. They aren’t breaking them. They are adjusting them to once again be in line with their convenience and benefit.

Blah blah, that's just word play. I am always amazed by the defense that Apple apologists come up.

I wasn’t apologizing for Apple. I actually pretty dislike Apple but that doesn’t change the fact that you can’t break the rules when you make the rules.

>you can’t break the rules when you make the rules.

This is really abusive, no wonder they are getting sued by the DOJ.

Who’s being abused by Bloomberg Professional requiring an account?

GP is surely talking about Apple changing/breaking the rules when they want to, as being unfair.

I wish Apple had never abandoned the rule that you need to be able to subscribe in the app at the same listed price as on the web.

I don’t, it’s anticompetitive. Sellers should be able to pass platform fees on to consumers, otherwise there’s no incentive for Apple to decrease those fees, there’s no feedback in the system.

Then if you don’t want to pay the Apple tax you can subscribe directly. This incentivizes Apple to keep the fees low.

Totally disagree. As a customer, I should not have to pay more or less for an application depending on what phone or computer I use to buy it. This would be like charging the customer more when they use an American Express card to buy your product, just because AMEX charges merchants more.

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.

> just because AMEX charges merchants more.

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.

I'm actually OK with businesses deciding to not take a certain kind of credit card or them going cash only. Fine, go ahead and lose me as a customer. Just don't nickel and dime me because you're too cheap and stubborn to accept the tiny gross margin difference between one card and an another.

Think of it as a discount in the other direction.

Hidden fees remove any consumer-side pressure on credit cards to lower their costs.

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.

If Amex started charging 30% fees you'd definitely see people charging customers more.

You absolutely will eat the extra charges, the question is will you bear the brunt directly with a behavior targetted at you uniquely or will the company just raise the cost of the product for everyone and have everybody pay more even if they get a fat pay day when they don't end up paying the platform overhead tax.

I agree up to a point. Credit card fees are pretty low, overall, so a business deciding to charge me a few percent more if I pay with AmEx vs Visa feels like they're just being petty. But with the App Store, it's a significant chunk of the purchase price -- a business wanting to pass on a 30% increase in their costs seems reasonable.

It's a ~43 % increase, not 30 %. Apple takes 30 %, so you would have to increase the price by ~43 % to cover it.

> At some point, you have to just admit that as a business you have certain costs that you have to pay to operate.

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.

> This would be like charging the customer more when they use an American Express card to buy your product, just because AMEX charges merchants more.

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.

This would be fine if apple would either waive their tax, or allowed the seller to list for the (base price) + (apple tax).

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.

Why are apps that require accounts against the guidelines? Don't lots of apps require accounts such as Google Calendar or 1Password?

Maybe I'm misunderstanding what you mean, I'm genuinely interested.

> Bloomberg's app (Bloomberg Professional) is unusable without an account, which is 100% against iOS guidelines, but who cares? Other big players, such as Amazon, simply negotiate the Apple tax – instead of paying the 30%.

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)

> Bloomberg's app (Bloomberg Professional) is unusable without an account, which is 100% against iOS guidelines, but who cares?

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.

I've had two little apps published in IOS store that both required accounts (paid account) that had to be created outside their universe.

They let me in, after a few hoops. This was in 2016-2019 (but now they are PWA)

Honestly, I wish they'd enforce the "require no account" rule more strictly. One of the most annoying things about using a mobile app is when they hit you with the "Sign in or GTFO" page on first run, as soon as you install the app.

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.

> At the very least, if an application absolutely requires an account to function, this should be prominently displayed,

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.

> Apple's guidelines are meant to be broken anyway. Bloomberg's app (Bloomberg Professional) is unusable without an account, which is 100% against iOS guidelines

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.

This has nothing to do with Apple's app store guidelines.

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.

Yet its pages load much faster than most websites, 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), no images only getting loaded and popping in view while you scroll (rather than do it a bit predicatively beforehand so they'd pop in outside of your view to give a less slow impression), etc...

All this has nothing to do with outputting standard conformant CSS+HTML.

I don’t understand how that’s at odds with having spec-valid HTML and CSS

Because updating to become conformant might come with the risk of making it a "modern" overhaul :/

So, I'm fearful of that as most people here, but if any entity can manage a respectful update, it has to be someone Y Combinator can pay.

You don't need

> 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.

And I just want a reasonable font size. On desktop it is miserable -- I always need to zoom to 133% to match the font size I see on other websites. On mobile it is ok.

I use the addon stylus on Firefox and apply a custom css. HN is really easy to customize and it never change.

Yeah, my stylus override for HN is:

.comment { font-size: 14pt; } .comhead { font-size: 12pt; }

I set this up many years ago and have not had to touch it since.

I find it way too small on desktop, but it's not an issue because the browser remembers my zoom level.

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.

Those two things are not related at all though

Because HN's development prioritized "good for the user" over "good for browser developers". https://www.w3.org/TR/design-principles/#priority-of-constit... https://datatracker.ietf.org/doc/html/rfc8890

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.

Apparently not “good for the user”, given how many people here have commented about the increased font size or custom CSS extensions they need to use on HN to make it readable.

And no JS needed for most of the functionality.

I don't know the HN codebase, but based on the HTML validation results I'd be surprised if it took more than a day or two to fix most or all of the issues.

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.

Pretty much all of the HTML validator "errors" warnings for outdated attributes and the like. The "No space between attributes" one is pretty much the only real error.

Pointing the validator at this submission and filtering out obsolete elements/attributes and all warnings/info messages, I still got 221 errors: No DOCTYPE, an script element after closing the body, duplicate element ids, and invalid attributes (not obsolete, they must be be using them like data-*).

None of which are serious errors. Certainly not the type that introduce rendering errors.

The HTML is immaterial. If it parses into the correct DOM (which, by all accounts, it does), there's no reason why the HTML should affect how the CSS renders.

https://html.spec.whatwg.org/multipage/parsing.html I really love the length of this page.

Lives up to its category of "multi page"!

The table based layout is a nightmare for assistive technology though. I can’t even imagine how users who rely on assistive technology use this site (of which I know there are indeed plenty).

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.

If you remove trivial errors for no space between attributes, table formatting, and use of "obsolete" inline styling instead of CSS it really isn't many. Could be cleaned up with a couple days engineering time or less.

I think most people could clean it up within a day, maybe two at most.

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.

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 wonder why browsers don't show a bit of UI that it's in compatibility mode and give a way to disable (or enable for other domains for dev/testing).

When I was at Twitter we had several engineers spend an afternoon trying to figure out why we were seeing different behavior for opening links (IIRC?) on iOS 14.5 (?) versus previous versions. Turns out that the WebKit team in their infinite wisdom had added some sort of change to how this worked several months back, realized it broke Twitter, then committed a change to restore the old behavior specifically for us. Of course, they also didn’t want to keep this around forever, so they also checked the iOS version to disable this behavior after 14.5 (?). Which is all well and good, except they never told us about this at all. So of course we find out about it when I, being well acquainted with Apple’s stupid quirks process, find the Slack thread where everyone is confused what is going on, identify where the bug is coming from, then do a search in WebKit for where they hardcoded the behavior for us. So thanks, WebKit team. You’re really doing a great job pushing web compatibility forward :(

The least they could do, which they don't, is log a console warning when a quirk is activated.

That's actually a great solution.

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."

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;

Fixing CORS issues has never been easier

That's messed up, why should I put up with CORS when others have a special treatment...

Its used here: https://github.com/WebKit/WebKit/blob/dc1354a1d26db54d17f7d3...

Seems to be specifically for (not) upgrading images and videos from http to https, nothing else.

If a browser has too many compatibility issues, users will switch away. Outreach to the sites in question takes time and is often unsuccessful. Quirks is the pragmatic answer.

WebKit is used by the second most popular browser after Chrome. Don't forget iOS users.

https://gs.statcounter.com/browser-market-share

That's an odd way of saying the third most popular browser.

If you click link, look at chart, you'll see they mean second.

That's always confusing. They should have said "the second most popular browser (after Chrome)", or something like that.

"blah blah blah, *second only to Chrome."

My iOS/Safari is so bad, I have both Firefox and Chrome installed as a backup in case it doesn't work. They should start fixing Safari for real instead of adding Quirks.

what’s wrong with ios/safari? i don’t really ever have issues

Safari on MacOS is really nice, fast and offers everything I need... but every 3 months or so I stumble on a website that refuses to work at all - rendering looks off, buttons don't work etc...

Switching to Chrome usually fixes it - but I always question my sanity for about 10 minutes until I try it in Chrome.

It’s the opposite for me. I keep finding dumb bugs in Chromium, when it comes to correct website rendering and event handling (always regressions). Safari and Firefox on the other hand never have those issues.

The only problem is: Safari has piss-poor ad blockers. Firefox blocks custom system-wide keyboard shortcuts (on Mac).

I have bad news for you. On iOS, Firefox and Chrome use the same WebKit as Safari (because Apple doesn't allow third party browser engines on its App store).

Didn't they allow alternative engines recently?

They even have emulators now. Undoubtedly a change forced on them by the EU.

Apparently you are right, they do since around February on iOS 17.4. In the EU only.

https://developer.apple.com/support/alternative-browser-engi...

Neat, question is if any of the browsers actually have had time to make use of it though?

No.

It's not as simple as that, you're basically asking browsers to target a completely different platform, just for the EU users, where iPhones are nowhere near as popular to begin with.

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.

As far as I know a native Chromium port to iOS is well under way. Whether Google will release Chrome is a different question, but I think it's likely. I think Google would love to bring Blink Chrome on iOS everywhere and there is a decent amount of momentum with developers and regulators to pressure Apple into allowing third party browser engines even outside the EU, but that completely goes away, if no actual engine get's ported to iOS. Blink Chrome on iOS probably gets a lot of enterprise web apps to drop WebKit support. That would probably that Chrome gets way more market share on iOS and with it lot's of telemetry for Google and also less money to Apple for default search engine placement. It's not great for the web as a standardized platform, but it will probably happen anyways.

No I agree, that was exactly my point.

It's not like iOS users care anyway, or they wouldn't use iOS in the first place.

The EU is pretty big. For a population of about 450 million people with decent spending power maybe it is worthwhile.

So Microsoft got dragged through anti-trust hell for just bundling IE with Windows and letting you install whatever browser you wanted after that, but Apple gets away with literally banning you from installing the browser you want on your own device, but that's ok? Make it make sense.

The market shifted, and two decades passed. Most importantly the courts have been packed with jurists from the Federalist society, who are libertarian. As a result there are far more judges willing and able to throw out consumer protection cases such as what happened in the 90’s with Microsoft and IE.

MS went through anti-trust investigation for more than just bundling IE, and at the time commanded a much larger market share¹ of desktop computing than Apple do of the mobile market now.

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!

You are not reading me backwards. And MSFT is worse today. I had to make changes at the BIOS level in a new Windows laptop to make it let me install Firefox without creating a Microsoft account. Was an ordeal just to get it to let me log in in the first place with a local only account.

The Microsoft ruling in the US was that Microsoft was forcing third-party OEMs (Dell, HP etc) to ship Internet Explorer, not that they shipped it themselves.

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.

They didn't totally get away with, the EU has set them to rights at least. It's just a shame they didn't use it as an opportunity to do the right thing globally at that point rather than sharding the market.

> Make it make sense.

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.

I don't know about quirks specifically, but often it takes many, many months before a WebKit commit actually ships to end users in Safari.

Anyway, Apple engineers aren't known for their outreach.

I wonder if any of those rules could be (mis)used to workaround or defeat iOs/macOs security features?

I guess a similar thing is happening with GPU drivers and games.

yes, and drivers (used to at least) check the filename of the exe causing unexpected behaviour like performance degradation or even gains in some cases

In cases like benchmarking software, I guess.

Still now I'd say - Counter-Strike 2's release was foreshadowed by nvidia or ATI having cs2.exe in some config files last year.

I hate CORS. Garbage like this is a large reason why. CORS works differently in every browser and every website.

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.

>CORS works differently in every browser and every website.

Do you have some examples of this?

Not anything concrete, just memories of things not working, me looking at the JS console, seeing CORS errors, and seeing it work in Chrome, as I described. And the comment I replied to showed that it works differently between websites, namely:

    if (host == "tripadvisor.com"_s || host.endsWith(".tripadvisor.com"_s))
        m_needsRelaxedCorsMixedContentCheckQuirk = true;

That's a site-specific partial exemption from the same origin policy, as far as i can tell (without further context at the moment). Not a difference in how CORS works generally across Safari.

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

I don't hate CORS from a developer perspective, I hate it from a user perspective, and from a broader "health of the web" perspective. Because, as I said, it works differently between browsers and it works differently between websites within the same browser. Mostly these differences just mean I have to use Chrome instead of my preferred browser.

Interestingly there seems to be a few quirks for twitter.com, but none for x.com. I assume that'll lead to some regressions?

Probably. But I doubt the engineers care about X as they did for Twitter.

Why is that?

I guess because Twitter used to be the place where all the tech people were hanging out and so there was an incentive to make it work properly while now is a bit of a cesspool in free fall and people have moved on to other platforms?

That’s my guess.

I don’t get the impression that many people have moved on, though I could be wrong as my usage of Twitter has decreased “post-X” - but more because the site is so frequently broken! No need for rendering workarounds in browsers if the site breaks itself lol.

It's less that random people have moved and more that the Safari/WebKit engineers have

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+

This has existed for every web engine since time immemorial, calling out Safari is misleading. Firefox calls them "site interventions" and Chrome calls them "patches" rather than Safari/WebKit's "quirks".

And beyond web engines, operating systems have them too - both Windows and macOS have workarounds for popular apps.

gpu drivers with patches for individual games.

Do you have a link to the Chrome site-specific patches directory? As you can imagine, it's pretty hard to search for :P

Is this triggered by HN being a table-based layout? Shouldn't this then affect way more sites?

NO, the URL is hardcoded: https://github.com/WebKit/WebKit/commit/84ae355619354ee1bfa7...

I believe your parent was asking whether the bug this workaround tries to address is caused by HN using tables for layout.

This also came to my mind.

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!

That's not what this is about. This is about fixing a bug in WebKit where HN's font is too large on the first load, then normal on subsequent loads.

https://bugs.webkit.org/show_bug.cgi?id=275221

TIL that IT IS JUST ME then!

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.

> It made sense in 2007 when your resolution was 1024x768.

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.

So why does HN text look so small under default settings on the desktop, and I always need to zoom to 133% to match the font size on other websites (that require no special treatment)? Am I using the browser wrong, or something is not quite right with HN? I am inclined to think the latter.

The font site is 9pt. It's just small. Not sure where someone got 12px from. The measurement is resolution independent, yes.

9pt == 12px on the web. You can check that in Web Inspector in computed styles.

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

https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Values_...

2560x1440 and ~12px on HN looks incredibly small.

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.

Then your setup is not compliant with web standards. Most likely you need to enable DPI scaling somewhere.

Without HiDPI (sic!) scaling that means that a correctly-sized display for that resolution would have a 30" diagonal on Windows (standard PPI: 96) and 40" on Mac (standard PPI: 72). If you don’t have HiDPI (sic!) scaling enabled in your system and your display is smaller than that, then you’re basically browsing everything zoomed out.

I always need to zoom 125-130% on all sites on top of 125% desktop system zoom and HN needs no special treatment. E.g. wikipedia is basically the same.

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.

This breaks my workflow.

I am visually impaired so take this with a grain of salt but HN is so much better to read at 200% for me. Every time it reverts back to 100% I wonder how people spend so much time reading that small text.

There's no one-size-fits all. Use your browser's Zoom feature. It will remember your settings. I find most websites have too big text, so I zoom to 66% on a lot of sites.

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?

Reply on news.ycombinator.com