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 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)
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'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.
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.
> 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.
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...
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.
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.
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.
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-*).
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.
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 :(
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;
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.
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.
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
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
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.
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".
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.
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.
> 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.
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.
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.
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.
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?
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)
1 reply →
There are two previous discussions on WebKit's Quirks.cpp [0] here:
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'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.
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.
1 reply →
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.
5 replies →
> 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)
2 replies →
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.
14 replies →
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...
I don’t understand how that’s at odds with having spec-valid HTML and CSS
10 replies →
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.
All this has nothing to do with outputting standard conformant CSS+HTML.
1 reply →
And no JS needed for most of the functionality.
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.
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.
https://html.spec.whatwg.org/multipage/parsing.html I really love the length of this page.
1 reply →
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-*).
1 reply →
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.
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.
1 reply →
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).
[flagged]
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
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.
27 replies →
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?
3 replies →
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
2 replies →
I wonder if any of those rules could be (mis)used to workaround or defeat iOs/macOs security features?
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?
3 replies →
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.
1 reply →
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.
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.
This breaks my workflow.
> 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.
6 replies →
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?
[flagged]
[dead]
[dead]
[dead]
[dead]
[flagged]