[HN Gopher] WebKit fix: Quirk news.ycombinator to skip TextAutoS...
___________________________________________________________________
WebKit fix: Quirk news.ycombinator to skip TextAutoSizing
Author : mkurz
Score : 197 points
Date : 2024-06-10 08:38 UTC (14 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| matteason wrote:
| 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...
| knallfrosch wrote:
| 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.
| tssva wrote:
| 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.
| pquki4 wrote:
| Blah blah, that's just word play. I am always amazed by the
| defense that Apple apologists come up.
| tssva wrote:
| 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.
| leptons wrote:
| >you can't break the rules when you make the rules.
|
| This is really abusive, no wonder they are getting sued
| by the DOJ.
| 1f60c wrote:
| 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.
| zarzavat wrote:
| 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.
| ryandrake wrote:
| 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.
| dylan604 wrote:
| > 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.
| ryandrake wrote:
| 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.
| recursive wrote:
| Think of it as a discount in the other direction.
| codewiz wrote:
| 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.
| lmz wrote:
| If Amex started charging 30% fees you'd definitely see
| people charging customers more.
| adra wrote:
| 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.
| kemayo wrote:
| 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.
| NorwegianDude wrote:
| It's a ~43 % increase, not 30 %. Apple takes 30 %, so you
| would have to increase the price by ~43 % to cover it.
| talldayo wrote:
| > 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.
| ladberg wrote:
| > 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.
| lililililililll wrote:
| 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.
| bakje wrote:
| 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.
| chrisfinazzo wrote:
| > 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)
| zinekeller wrote:
| > 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.
| djbusby wrote:
| 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)
| ryandrake wrote:
| 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.
| GeekyBear wrote:
| > 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.
| spankalee wrote:
| This has nothing to do with Apple's app store guidelines.
| onion2k wrote:
| 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.
| tda wrote:
| 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
| thepra wrote:
| That's messed up, why should I put up with CORS when others
| have a special treatment...
| its-summertime wrote:
| Its used here: https://github.com/WebKit/WebKit/blob/dc1354a1
| d26db54d17f7d3...
|
| Seems to be specifically for (not) upgrading images and
| videos from http to https, nothing else.
| jorlow wrote:
| 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.
| lye wrote:
| WebKit is used by the second most popular browser after
| Chrome. Don't forget iOS users.
|
| https://gs.statcounter.com/browser-market-share
| tyho wrote:
| That's an odd way of saying the third most popular
| browser.
| Terretta wrote:
| If you click link, look at chart, you'll see they mean
| second.
| stavros wrote:
| That's always confusing. They should have said "the
| second most popular browser (after Chrome)", or something
| like that.
| DANmode wrote:
| "blah blah blah, *second only to Chrome."
| knallfrosch wrote:
| 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.
| hhh wrote:
| what's wrong with ios/safari? i don't really ever have
| issues
| flessner wrote:
| 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.
| SassyBird wrote:
| 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).
| jraph wrote:
| 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).
| dizhn wrote:
| Didn't they allow alternative engines recently?
|
| They even have emulators now. Undoubtedly a change forced
| on them by the EU.
| jraph wrote:
| 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...
| tjoff wrote:
| Neat, question is if any of the browsers actually have
| had time to make use of it though?
| galad87 wrote:
| No.
| input_sh wrote:
| 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.
| YmiYugy wrote:
| 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.
| tjoff wrote:
| 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.
| Y_Y wrote:
| The EU is pretty big. For a population of about 450
| million people with decent spending power maybe it is
| worthwhile.
| fallingknife wrote:
| 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.
| revscat wrote:
| 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.
| dspillett wrote:
| MS went through anti-trust investigation for more than
| just bundling IE, and at the time commanded a much larger
| market share1 of desktop computing than Apple do of the
| mobile market now.
|
| But while your comparison is flawed, I agree with the
| assertion2 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!
| fallingknife wrote:
| 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.
| kalleboo wrote:
| 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.
| qingcharles wrote:
| 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.
| lapcat wrote:
| 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.
| easyThrowaway wrote:
| I wonder if any of those rules could be (mis)used to workaround
| or defeat iOs/macOs security features?
| orphea wrote:
| I guess a similar thing is happening with GPU drivers and
| games.
| CapsAdmin wrote:
| 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
| wruza wrote:
| In cases like benchmarking software, I guess.
| mort96 wrote:
| 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.
| rnicholus wrote:
| >CORS works differently in every browser and every website.
|
| Do you have some examples of this?
| mort96 wrote:
| 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;
| rnicholus wrote:
| 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
| formerly_proven wrote:
| Is this triggered by HN being a table-based layout? Shouldn't
| this then affect way more sites?
| graemep wrote:
| NO, the URL is hardcoded:
| https://github.com/WebKit/WebKit/commit/84ae355619354ee1bfa7...
| jraph wrote:
| 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.
| paulgb wrote:
| 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.
| jorlow wrote:
| 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).
| lililililililll wrote:
| Because bigtech considers their users morons and doesn't want
| to give them any control whatsoever, because they're
| terrified of potentially maybe confusing someone.
| saagarjha wrote:
| 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 :(
| lapcat wrote:
| The least they could do, which they don't, is log a console
| warning when a quirk is activated.
| qingcharles wrote:
| 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."
| nottorp wrote:
| > 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.
| its-summertime wrote:
| 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.
| Aardwolf wrote:
| 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...
| Narretz wrote:
| All this has nothing to do with outputting standard
| conformant CSS+HTML.
| sitharus wrote:
| I don't understand how that's at odds with having spec-valid
| HTML and CSS
| Aardwolf wrote:
| Because updating to become conformant might come with the
| risk of making it a "modern" overhaul :/
| noobermin wrote:
| 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.
| jraph wrote:
| 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.
| rwalle wrote:
| 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.
| nick__m wrote:
| I use the addon stylus on Firefox and apply a custom css.
| HN is really easy to customize and it never change.
| plorkyeran wrote:
| 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.
| gbalduzzi wrote:
| Those two things are not related at all though
| nightpool wrote:
| 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.
| sharpshadow wrote:
| And no JS needed for most of the functionality.
| _heimdall wrote:
| 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.
| arp242 wrote:
| 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.
| debugnik wrote:
| 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-*).
| arp242 wrote:
| None of which are serious errors. Certainly not the type
| that introduce rendering errors.
| bastawhiz wrote:
| 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.
| its-summertime wrote:
| https://html.spec.whatwg.org/multipage/parsing.html I really
| love the length of this page.
| qingcharles wrote:
| Lives up to its category of "multi page"!
| runarberg wrote:
| 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.
| fallingknife wrote:
| 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.
| its-summertime wrote:
| 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.
| bob1029 wrote:
| I am confused. What part of the hacker news web source was more
| difficult to change than the source code for my web browser?
| lapcat wrote:
| 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
| jraph wrote:
| 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.
| onion2k wrote:
| This is an example of somewhere a comment would actually have
| been useful.
| nightpool wrote:
| 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)
| alex3305 wrote:
| 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.
| refulgentis wrote:
| 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
| layer8 wrote:
| I have experienced the same on other sites as well, with
| large text size. It sounds like this bug could fit.
| Kiro wrote:
| OT but what's up with the spam comments? What's the purpose?
| maybevain wrote:
| Interestingly there seems to be a few quirks for twitter.com, but
| none for x.com. I assume that'll lead to some regressions?
| saagarjha wrote:
| Probably. But I doubt the engineers care about X as they did
| for Twitter.
| influx wrote:
| Why is that?
| manuelmoreale wrote:
| 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.
| tomduncalf wrote:
| 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.
| rob wrote:
| 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.
| account42 wrote:
| > 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.
| rwalle wrote:
| 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.
| louis-lau wrote:
| The font site is 9pt. It's just small. Not sure where
| someone got 12px from. The measurement is resolution
| independent, yes.
| SassyBird wrote:
| 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_...
| rob wrote:
| 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.
| account42 wrote:
| Then your setup is not compliant with web standards. Most
| likely you need to enable DPI scaling somewhere.
| SassyBird wrote:
| 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.
| wruza wrote:
| 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.
| wruza wrote:
| This breaks my workflow.
| zachrip wrote:
| 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.
| coldpie wrote:
| 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.
| emursebrian wrote:
| 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+
| phrz wrote:
| 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".
| kalleboo wrote:
| And beyond web engines, operating systems have them too -
| both Windows and macOS have workarounds for popular apps.
| kmlx wrote:
| gpu drivers with patches for individual games.
| nightpool wrote:
| Do you have a link to the Chrome site-specific patches
| directory? As you can imagine, it's pretty hard to search for
| :P
| syngrog66 wrote:
| 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.
| glonq wrote:
| 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!
| Thorrez wrote:
| 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
| glonq wrote:
| TIL that IT IS JUST ME then!
___________________________________________________________________
(page generated 2024-06-10 23:01 UTC)