Oh wonderful. Thank you! I was looking for something like this for my project https://htwins.net/scale2 and others which use svg or canvas
Woah, I'd love a writeup on how you made this
Show HN: Dropflow, a CSS layout engine for node or
111–120 of 146 posts
Re: Show HN: Dropflow, a CSS layout engine for node or <canvas>
#112I worry that this sort of technology is going to lead to webapps that aren't really what we've grown to think of as "the web" but which will instead be closer to a VNC window where you just see pixels and can't interact with anything or see how stuff works in devtools.
That’s what a GUI app is, though. You could say it’s the default way we interact with graphical apps. Web browsers, along with web-enabled platforms, add a bunch of extra stuff to that. 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.
This discussion reminds me a bit of the description of Fujitsu trying to implement Habitat in Japan:
“…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...
Re: Show HN: Dropflow, a CSS layout engine for node or <canvas>
#113Its too bad browsers don't support this. // 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(...);
The security implications would be interesting, unless you tainted the canvas (which makes it instantly less useful).
What security vulnerability becomes possible with native CSS-in-canvas support that's not already possible today? Or becomes easier?
Re: Show HN: Dropflow, a CSS layout engine for node or <canvas>
#114Earlier quoted context omitted.
> Opera switched from Presto to Blink, too True. But I wonder if there are more special-purpose engines similar to Prince that have been abandoned. > Did you ever consider integrating with web-platform-tests? I've run some of the WPT tests manually, but I don't yet have support, and some of them use I think? That's a path I'm wary of (eval()?) but I could have a special mode just for tests. I did discover lots of wei…
Yes, a _lot_ of WPT tests depend on . But there's also a bunch of ref-tests, where you just check that A and B match pixel for pixel (where B is typically written in the most obvious, dumb way possible). It lets you test advanced features in terms of simple ones. But yes, you'd need selector support in particular.
I maintain a standalone web layout engine[0] (currently implementing Flexbox and CSS Grid) which has no scripting support. WPT layout tests using is a major blocker to us running WPT tests against our library. Yoga (used by React Native) is in a similar position.
Do you think the WPT would accept pull requests replacing such tests with equivalent tests that don't use (perhaps using a build script to generate multiple tests instead - or simply writing out the tests longhand)?
I could run against only the ref-tests, but if I can't get full coverage then the WPT seems to provide little value over our own test suite.
Re: Show HN: Dropflow, a CSS layout engine for node or <canvas>
#115Great achievement, congratulations!
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.
Re: Show HN: Dropflow, a CSS layout engine for node or <canvas>
#116For anyone struggling with flexbox, you can use this tool to streamline the process of creating responsive layouts, removing the need to focus on multiple properties: https://flexboxcss.com
This is the first site I've run in to that uses neumorphic design. Love the aesthetic -- just never seen in it the wild before.
CRED had it in their app for a while, their library is open source
Re: Show HN: Dropflow, a CSS layout engine for node or <canvas>
#117Earlier quoted context omitted.
Yes, a _lot_ of WPT tests depend on . But there's also a bunch of ref-tests, where you just check that A and B match pixel for pixel (where B is typically written in the most obvious, dumb way possible). It lets you test advanced features in terms of simple ones. But yes, you'd need selector support in particular.
I maintain a standalone web layout engine[0] (currently implementing Flexbox and CSS Grid) which has no scripting support. WPT layout tests using is a major blocker to us running WPT tests against our library. Yoga (used by React Native) is in a similar position. Do you think the WPT would accept pull requests replacing such tests with equivalent tests that don't use (perhaps using a build script to generate multiple…
I don't decide WPT policies (and I honestly don't know who does), but I'm pretty sure using a build script would be right out, as WPT is deeply embedded in a lot of other projects. E.g., if you made a build script, you would need to add support for running that script in Blink and in Gecko and in WebKit, and their multiple different runners, and probably also various CI systems.
As for the second option, I don't actually know. If it becomes 10x as long, I would assume you get a no for maintainability and readability reasons. If it's 20% longer and becomes no less clear, I'd say give it a try with a couple tests first? It's possible that the WPT would be interested in expanding its scope to a wider web platform than just browsers. You would probably never get people to stop writing JS-dependent tests, though, so you would need to effectively maintain this yourself.
Of course, for a bunch of tests you really can't do without , given that a lot of functionality is either _about_ scripting support (e.g. CSSOM), intimately tied to it (e.g. invalidation) or will be tested only rather indirectly by other forms of tests (e.g. computed values, as opposed to used values or specified values or actual values or …).
Re: Show HN: Dropflow, a CSS layout engine for node or <canvas>
#118Earlier quoted context omitted.
The security implications would be interesting, unless you tainted the canvas (which makes it instantly less useful).
What security vulnerability becomes possible with native CSS-in-canvas support that's not already possible today? Or becomes easier?
As I understand the proposal, everything about visited link colors, for instance. Lots of cross-origin leaks. New forms of image leaks.
Re: Show HN: Dropflow, a CSS layout engine for node or <canvas>
#119This is an amazing piece of work. Thanks for making this open-source. 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/…
We did use this approach years back when I worked for on a feature that generated PDF invoices.
But I wondered whether using instead something like LaTeX wouldn't be faster and easier to scale.