Live demo: https://chearon.github.io/dropflow/
It matches browsers in all cases I can find where they agree, and it's fast. It supports `position`, `inline-block`, `z-index`, and complex properties like `float` and `vertical-align`. It doesn't support high-level layout like flexbox or grid yet, but you can get intrinsics to easily divide space yourself and paint multiple layout trees. It has a great text layout implementation, and supporting non-Latin scripts is a top priority.
I've wanted this to exist as far back as 2013, and the desire kept coming up: for a way to get detailed intrinsics, for high quality rich text layout to canvas and SVG, and for server-side rich text. We currently use it in CellEngine for our new canvas-based spreadsheet library to layout text in hundreds of thousands of cells, and will be using it soon to render PDFs with thousands of pages in a few seconds.
The default way of generating beautiful PDFs in the backend these days is, running a headless browser and using browser APIs to turn HTML/CSS into PDFs. And apparently, it's a bit costly running instances of browser in the server and scale it properly for huge workloads.
This is literally a game changer. Now it's possible to design PDFs using HTML/css and generate them without the browser overhead!
We are now using a commercial alternative that seems be be using a custom engine that implements the HTML and CSS specs. The result is reduced memory usage (below 512MB during my tests) and the resulting PDF is much smaller, 3.3MB vs 42MB.
(Admittedly, the PDFs I generate are most certainly not beautiful, so maybe that's the difference)
But I wondered whether using instead something like LaTeX wouldn't be faster and easier to scale.
In a past role, my job was to develop an immersive, online learning platform. We used Oculus Quest 2s to do foreign language training for DoD personnel. WebXR, Three.js, etc, because I had had enough Unity3D for one lifetime and we didn't want to submit to app store reviews. We had a fleet of our own devices, so it was fine.
One of the biggest challenges with the project was creating a workflow for didactic content. By myself. I had an employee who I supervised working for me, but most of the work was of such high technical level that it was way over their head and we couldn't afford to hire anyone else. I eventually landed on having our actual language instructors use PowerPoint to create PDFs, use a bespoke editor I created to upload the PDF into a content database and position them in the training environments, and then used PDFJS to render them to canvas elements to then texture on a 3D quad.
Something like this would have made it possible for me to avoid having people go out of band into PowerPoint to make those materials. The PowerPoint route did dramatically improve our workflow speed over a previous attempt to get people to author images in Photoshop. But if I could have built the "sign" editor into the app, it would have improved it even more by eliminating the "guess what will look good in the environment, export to PDF, upload to the database (oh, BTW, not a lot of people know how to keep files well organized), then find out how it really looks" cycle.
Oh well. We didn't have a business development team or market department that knew anything about selling products instead of services, so I guess the point is moot anyway.
responsive layouts, removing the need to focus on multiple properties: https://flexboxcss.com
It would be great if we could create a full machine readable spec for html and CSS rendering, so that renderers can be generated. Browser quirks could then be extensions to that. Like https://github.com/tawesoft/html5spec but used for real engines.
I wonder how hard it was to implement css. I've heard it can be pretty complex.
There's another project called Sciter that uses CSS to target native graphics libraries: https://sciter.com
> I wonder how hard it was to implement css. I've heard it can be pretty complex.
It was hard, but the biggest barrier is the obscurity of the knowledge.
Text layout is the hardest, because working with glyphs and iterating them in reverse for RTL is brain-breaking. And line wrapping gets really complicated. It's also the most obscure because nobody has written down everything you need to know in one place. After I finished block layout early on, I had to stop for a couple of years (only working a few hours a week though) and learn all of the ins, outs, dos, and don'ts around shaping and itemizing text. A lot of that I learned by reading Pango's [1] source code, and a lot I pieced together from Google searches.
But other than that, the W3C specifications cover almost everything. The CSS2 standard [2] is one of the most beautiful things I've ever read. It's internally consistent, concise, and obviously the result of years of deliberation, trial and error. (CSS3 is great, but CSS2 is the bedrock for everything).
I can confirm this. I've been working on a (much simpler!) text layout engine for my canvas library over the past couple of months and the amount of complexity associated with just stamping some glyphs onto a canvas has left me screaming at my laptop on an almost daily basis. Getting a decent underline was a proud moment!
Question: did you ever find out what algorithm the various browsers are using to calculate how many words can fit on a given line? I'm almost there, except words will occasionally jump between lines when I scale the text. Really annoying!
The PR's still a work in progress, but I've got all the functionality I want in there (shaping lines to fit in non-rectangular containers, styling text, text along a non-straight line, dynamic updates, etc). Just need to test and document it all now ... https://github.com/KaliedaRik/Scrawl-canvas/pull/75
Your work might have been, or maybe still is, the worlds biggest chance for this to change!
As someone who loves working with CSS for layout, I am mostly relying on Flexbox and Grids these days — it is totally understandable that these are not supported yet — but do you plan to do so at some point? If so, how can others help?
I think most folks probably don't realize how difficult it is to go from HTML -> PNG programmatically. You get hit with a thousand papercuts related to either Node<>Browser differences or HTML<>Canvas differences.
This reminds me of flying saucer, a CSS render written in pure Java. Successfully used it in multiple projects for rendering PDFs in the past. It has some great features to handle paged media. For example, it can repeat table headers on a new page, if there is a page-break within the table.
Unfortunately, it seems that it doesn't get much active development anymore.
What in the world?
Text is about the most complex UI element that a UI framework offers, and if you’ve got Flow Layout working, that’s very encouraging! Will be interested how far along things like gestures (particularly text highlighting) and IME integration are. In any case, kudos for opensourcing this!
But the idea of using html for text styling has stuck, Swing UI do text styling with html (and rudimentary css!) to this day. Html would not be a lingua franca if its use was limited to the equivalent of native speakers (browsers).
The upstream layout engine handles flexbox layout, and it's unclear if Facebook needs inline layout or if Vercel would pick it up and close the gap: https://github.com/facebook/yoga
Then again, for the main purpose Satori is advertised for - generating URL unfurl previews - Dropflow looks like it might be the answer.
It's trivial to create svg in the server. It's like rendering html.
i can understand the abuse for server side rendering, but at this poit you pretty much have a bad browser engine. running inside a 2d hack in a browser engine. sigh.
you can still follow css spec if you want. just get a better environment than a canvas.
I was looking at Glide Grid the other day, and it renders so fast, even with 1 million rows; it's somehow responsive. There should be an easier way to render HTML to canvas without resorting to low-level primitives. Why is canvas faster than the "regular" DOM renderer?
I'm only speculating, but it doesn't seem surprising that regular DOM rendering logic - which has to handle approximately a bazillion different rules and special cases - is slower than a custom renderer written for a specific subset of HTML.
You can actually insert your HTML into a SVG foreignObject, and then drawImage() that onto your canvas. But your HTML-in-SVG document will need to load all its own resources, fonts, CSS etc.. which makes this process rather tedious.
You can have a fast DOM without canvas, but it requires creative thinking. DataGridXL also renders millions of cells, but it does not use canvas as its main renderer (https://www.datagridxl.com/demos/one-million-cells).
The way it works: only columns are their own DOM nodes. For browsers it's just too much to ask to re-render let's say (20rows*10cols) 200 DOM nodes while keeping scrolling at 60fps.
I don't think this is true with modern browsers and CSS. For a table, every cell and parents of the cells as much as possible, should be styled `contain: strict` and if possible, absolutely positioned.
Satori is meant for rendering Open Graph images (e.g. the little images that come up when you post a link on Twitter/Slack/Facebook), but I found that it works well for rendering arbitrary images. Satori has no native dependencies, so it kinda "just works" on the backend. It supports a subset of modern CSS, including flexbox.
My use case is posting match reports for League of Legends into a Discord text channel, e.g. person X just played a match, here are their stats.
It's quite nice because there are almost zero server-side native dependencies (the one exception is the library to convert svg -> png requires some native libraries).
Here's what a match report looks like: [1]
Here's an example of what the JSX looks like: [2]
I also built a small project [3] that renders the JSX in a browser to make developing the images just as easy as developing a normal website.
If others are interested in this, I would by happy to write a blog post about the process.
[0]: https://github.com/vercel/satori
[1]: https://github.com/shepherdjerred/glitter/blob/main/assets/p...
[2]: https://github.com/shepherdjerred/glitter/blob/main/packages...
[3]: https://github.com/shepherdjerred/glitter/tree/main/packages...
What I'm thinking is: there's been soo much discussion around "we have corrupted the Web", "Web standards were never made to build apps on", etc. with sometimes good and sometimes really bad arguments.
If we can build viewports in canvas that behave more like just a desktop environment where apps can be built, maybe that could be good? It could mean a split between the informational web and the "apps on the browser" paradigm, and in a ideal scenario this could make things simpler and more organized for everyone? Or it could just mean more work, more standards, more rupture and more siloing. Honestly don't know.
(It's also terrible for accessibility, for both disabled people or just regular users who expect to be able to navigate with the keyboard for instance, unless the framework re-implement everything itself, which I doubt)
To get an idea of what you'd have to emulate, here are some (not even all) issues related to rendering text: https://faultlore.com/blah/text-hates-you/
Many of us just want good, GUI apps for many things. They were often faster and lighter. VS Code is the exception to the rule which I use regularly.
“…instead of sending a command message to the object on the server, the client would send the X-Y coordinates of your mouse click. The server would then render its own copy of the scene into an internal buffer to figure out what object you had clicked on. Not only was this extremely inefficient, but the race conditions inherent a multi-user environment meant that it also sometimes just got the wrong answer. It was amazing…”
http://habitatchronicles.com/2004/04/you-cant-tell-people-an...
Seems like less of a risk than the flash days because browsers are faster and more capable, and stuff like this is currently a subset of what the browser can do, instead of a superset like flash was (or the strong vendor push like microsoft silverlight).
Not old enough to have been a dev when flash was in it's prime though so might not have the most accurate view.
// Do CSS layout in the regular document
const doc = new CssLayout(document);
doc.layout(...);
// Do CSS layout on your own canvas
const mycanvas = new CssLayout(document.getElementById('mycanvas'));
mycanvas.layout(...);But congrats on the work! I can definitely see this being useful for text formatting and layouting PDFs. Neat!
A web search shows something that's written in Rust: https://github.com/DioxusLabs/taffy?tab=readme-ov-file#taffy