41–50 of 76 posts
This should be standard functionality offered by browsers. How do you make feature requests to W3C, and do they allow the community to vote on feature ideas?
Right now Chrome is much more focused on AI related APIs (sigh) and not stuff like FontMetrics.
Love this. I especially liked shape based reflow example. This is something I've been thinking for ages and would love to add to Ensō (enso.sonnet.io), purely because it would allow me to apply better caret transitions between the lines of text. (I'm not gonna do that because I'm trying to keep it simple, but it's a strong temptation) Now a CSS tangent: regarding the accordion example from the site ( https://chenglou…
Earlier quoted context omitted.
it is not clear from the API/docs how i would use prepare() once on one text and then use layout() for completely different text. i think the intended purpose is that your text is maybe large but static and your layout just changes quickly. this is not the case for figuring out the height of 100k rows of different texts in a table, for example.
I think for that to use pretext is to join each row with hard line break and then do prepare once, then walk each line. At least that will put the single layout performance into the best light. I am skeptical getting row height of many items only once is the intended behavior though. It is probably the intended behavior to get row height of many items and enables you to resizing width many time later (which is pretty…
Earlier quoted context omitted.
Looks like uWrap only handles latin characters and doesn't deal with things like soft hyphens or emoji correction, plus uWrap only handles white-space: pre-line while Pretext doesn't handle pre-line but does handle both normal and pre-wrap.
correct, it was meant for estimating row height for virtualizing a 100k row table with a latin-ish LTR charset (no emoji handling, etc). its scope is much narrower. still, the difference in perf is significant, which i have found to be true in general of AI-generated geenfield code.
That is to say, I wouldn't be so quick to call a library that only handles latin characters comparable to one that handles all this breath of things, and I also wouldn't be so quick to blame the performance delta on the assumption of greenfield AI-generated code.
I said it elsewhere but will repeat it here: This is incredibly impressive, many of this things have been missing for forever! I remember the first time I couldn't figure out how do a proper responsive accordion, it was with bootstrap 1, released in 2011 !! Today it's still not properly solved (until now?). Many of thing things belong in css no in js, but this has been the pattern with so many things in the web 1) we…
Responsive accordions are actually solved using CSS nowadays, but plenty of other things aren't, and the web has definitely needed an API or library like this for a long, long time. So it's great that we now have it. Building something like this was certainly possible before, but it was a lot of effort. What's changed is simple: AI. It seems clear this library was mostly built in Cursor using an agent. That's not a c…
This thing is very impressive. The problem it solves is efficiently calculating the height of some wrapped text on a web page, without actually rendering that text to the page first (very expensive). It does that by pre-calculating the width/height of individual segments - think words - and caching those. Then it implements the full algorithm for how browsers construct text strings by line-wrapping those segments usi…
i wrote something similar for this purpose, but much simpler and in 2kb, without AI, about a year ago. uWrap.js: https://news.ycombinator.com/item?id=43583478 . it did not reach 11k stars overnight, tho :D for ASCII text, mine finishes in 80ms, while pretext takes 2200ms. i haven't yet checked pretext for accuracy (how closely it matches the browser), but will test tonight - i expect it will do well. let's see how cl…
This thing is very impressive. The problem it solves is efficiently calculating the height of some wrapped text on a web page, without actually rendering that text to the page first (very expensive). It does that by pre-calculating the width/height of individual segments - think words - and caching those. Then it implements the full algorithm for how browsers construct text strings by line-wrapping those segments usi…
> This thing is very impressive. Agreed! Text layout engines are stupidly hard. You start out thinking "It's a hard task, but I can do it" and then 3 months later you find yourself in a corner screaming "Why, Chinese? Why do you need to rotate your punctuation differently when you render in columns??" This effort feeds back to the DOM, making it far more useful than my efforts which are confined to rendering multilin…
(by the way, in your cool demo the wheel template can have some letter parts like the top of L or d extend beyond the wheel)
Has someone ever found a good solution for long / infinite lists / grids virtualization not breaking browsers native text search? Maybe for this we need a new web "Search" API instead of JS. Not sure it can be done otherwise without browser's help.
As far as I can tell, this went basically nowhere. Except this:
https://github.com/WICG/display-locking
https://developer.mozilla.org/en-US/docs/Web/API/Element/bef...