Hacker Newsnew | past | comments | ask | show | jobs | submit | HughParry's commentslogin

I wonder why the firefox CSS rendering engine prefers to smooth out. Looks like a dramatically different implementation, but maybe that's just because it's an edge case of rendering

Stroke expansion is a complex topic, with more than one reasonable result (subjective preferences), and a whole lot of corner cases and incorrect answers.

Firefox has chosen to expand based on distance at all points, which is one of the reasonable answers and probably the most general one; a cusp then expands to a curve.

The others have chosen to retain cusps, which can be a reasonable answer and I believe is a lot cheaper to compute; but degenerate cases abound as you expand past the feature size (distances between nodes), so that by the fourth red ring it’s obviously incorrect.

Box shadows are another case where expansion occurs: the fourth length parameter, spread distance. If the corner is a cusp, the shadow corner will be a cusp. If it’s rounded, the shadow corner will be rounded. See https://drafts.csswg.org/css-backgrounds/#shadow-shape for some helpful diagrams. A sneaky trick: .1px border-radius means the box still looks square, but the expanded shadow will curve. Sometimes useful. But back on the original content of the article—if you use a font with microscopic curves instead of cusp nodes, Chromium/Safari will look more like Firefox.


There aren't many "corner" cases in Firefox :D

(Yes, it could technically be infinite corner cases)


While I don't entirely love the rounding effect of firefox, I feel Chrome interpretation is just wrong in creating spurious spikes. Intuitively for the asterisk shape I'd expect the outline to go towards a plain hexagon, something that neither browser accomplishes.

Miter join (Safari) VS round join (Chrome)

firefox looks like an SDF (shortest distance to the object), I'm not sure what the chrome one is...

I would assume they are just drawing the outline, not performing any distance calculations, and the differences are just a result of different linejoin choices. [1]

[1] https://www.w3.org/TR/fill-stroke-3/#stroke-linejoin


I'd imagine that at some point during the text rendering process, they have to generate an SDF of the text they want to render (it's what I did when I wanted to manually render text anyway). If they do, then they can generate the extra text-width lines basically for free, just fill everything with distance less than the property.

I may be entirely wrong though, I don't know in detail how browsers render stuff


The Firefox one looks like exactly what you’d expect from stepping the result of a SDF for that character. The rounded corners of the first layer would all be equidistant from the nearest corner of the original character.

I think Firefox applies more aggressive subpixel rendering and path smoothing before stroking. It resamples the glyph outline path at a higher precision level before handing it to the stroke algorithm.

Ran into this discrepancy myself. On top that, what seemed also odd to me were the "dots" (tittle, period, semicolon) where oversized becomes hollow in the middle, like it cancels out itself. No other shape I've tried did that. And browsers surprisingly agreed on this.

Made few shots and playground for that back then: https://x.com/myfonj/status/1870178380831732160


Look at V in Love. It looks like bug in Chrome.

I’ve never seen people on the likes of blackhatworld selling hacker news accounts or services. The glass half full take on this is that hn is surprisingly robust in its ability to deal with vote manipulation.


Somebody spent a small fortune trying this a while ago with disliked results https://nypost.com/2025/04/13/entertainment/ailing-doctor-wh...


They seem to have been pleased with the results:

> “It has to be worth it for the pleasure it’s brought me to see them,” Levine said. “Doctor Who runs all night in my bedroom, complete, nothing missing.”


Ah I mean others disliked the results.

Make up your own mind I suppose, I doubt you will find them rewarding: https://youtu.be/rQabMPpdQnk?si=Fm9Yqj7EwAjYp5np


Well heck - many don't even like the originals at all :p. On the contrary I found these much more enjoyable than the audio and stills! Of course I'd prefer more of the original copies be found... but for now the AI ones fill the gaps in my collection instead of the audio reconstructions.


They animated a lot of the missing pieces of the missing episode Shada with excellent results. If AI could do something of similar quality that would be wonderful.


Please don't capture my cursor on your homepage, and if you have to, please don't apply smoothing to is so that it doesn't go where I want it to! I appreciate that it's pretty, but making your site annoying to use can only increase churn


RIP Danya <3


The outage did make me realise I’d be happier watching episodes of House instead


Most services appear to work, aside from actual video streaming for me


YouTube music is 95% broken for me too. UK.


Posted on the other thread as I thought it was pretty interesting:

>Roughly 0.5% odds on him on polymarket before he was announced


EDIT: I was wrong, he was quite down the list! He only appears in the chart because he ultimately won, so higher contenders dropped off.

--

He seemed to hover around 1%, which was the second highest behind Tagle (~20%)

https://polymarket.com/event/who-will-be-the-next-pope?tid=1...


That link isn't showing most of the options. I believe there were at least 10 above him. Just individually look at the lines for Zuppi, Pizzaballa, Sarah, etc.


I don't understand what people were basing that on; the conclave is a completely secret process?


The winning lottery numbers are a secret too before they're drawn; people just like to gamble.


Roughly 0.5% odds on him on polymarket before he was announced


Just had a look - looks like pretty regular/reasonable cloudflare default stuff as far as I can tell. The headers relating to error reporting are the only thing that stand out a little, though it doesn't look unreasonable.

---

Headers

---

HTTP/2 301

date: Fri, 24 Jan 2025 13:59:51 GMT

content-type: text/html

content-length: 167

location: <the website in question>

cache-control: max-age=3600

expires: Fri, 24 Jan 2025 14:59:51 GMT

report-to: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v4?s=JZu4FOa%2ByynaFOXWYlxaePF9KdRQ0qGUJkfm1F1aK2m3VEx6idlvWlb5go%2B08hgSog1zm1zuMobXcVK2BkR4mQD0SEGU%2Bzp2oC6mXPgQs%2FUzvOH7LbqAG96jtf9KNqemV8Q%3D"}],"group":"cf-nel","max_age":604800}

nel: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}

server: cloudflare

cf-ray: 90708be24810e8fe-LHR

alt-svc: h3=":443"; ma=86400

server-timing: cfL4;desc="?proto=TCP&rtt=59748&min_rtt=41108&rtt_var=43898&sent=7&recv=8&lost=0&retrans=1&sent_bytes=3535&recv_bytes=789&delivery_rate=33797&cwnd=225&unsent_bytes=0&cid=e5052200af7e27a5&ts=145&x=0"


If you are seeing 301s logged on your end that is your site redirecting to another one.

There isn’t a way to see what a referring site did to do the redirect (301 or 302 or even a js redirect) in your logs. All you’ll see is (potentially) the Referer http header.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: