Live data from Hacker News

Show HN: Dropflow, a CSS layout engine for node or

github.com

131–140 of 146 posts

Re: Show HN: Dropflow, a CSS layout engine for node or <canvas>

#131

Earlier quoted context omitted.

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 actu…

To reply mostly with my WPT Core Team hat off, mostly summarising the history of how we've ended up here:

A build script used by significant swaths of the test suite is almost certainly out; it turns out people like being able to edit the tests they're actually running. (We _do_ have some build scripts — but they're mostly just mechanically generating lots of similar tests.

A lot of the goal of WPT (and the HTML Test Suite, which it effectively grew out of) has been to have a test suite that browsers are actually running in CI: historically, most standards test suites haven't been particularly amenable to automation (often a lot of, or exclusively, manual tests, little concern for flakiness, etc.), and with a lot of policy choices that effectively made browser vendors choose to write tests for themselves and not add new tests to the shared test suite: if you make it notably harder to write tests for the shared test suite, most engineers at a given vendor are simply going to not bother.

As such, there's a lot of hesitancy towards anything that regresses the developer experience for browser engineers (and realistically, browser engineers, by virtue of sheer number, are the ones who are writing the most tests for web technologies).

That said, there are probably ways we could make things better: a decent number of tests for things like Grid use check-layout-th.js (e.g., https://github.com/web-platform-tests/wpt/blob/f763dd7d7b7ed...).

One could definitely imagine a world in which these are a test type of their own, and the test logic (in check-layout-th.js) can be rewritten in a custom test harness to do the same comparisons in an implementation without any JS support.

The other challenge for things like Taffy only targeting flexbox and grid is we're unlikely to add any easy way to distinguish tests which are testing interactions with other layout features (`position: absolute` comes to mind!).

My suggestion would probably be to start with an issue at https://github.com/web-platform-tests/rfcs/issues, describing the rough constraints, and potentially with one or two possible solutions.

Re: Show HN: Dropflow, a CSS layout engine for node or <canvas>

#132
post #129
post #73

Earlier quoted context omitted.

I needed to transform a 12MB HTML file into a PDF document and headless Chrome quickly ran out of memory (4GB+). 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.

We use docraptor based on princexml engine but haven’t tried a huge pdf. We generate 20-30 page pdfs sometime and it works great.

We are also using DocRaptor. It takes around 20 seconds to generate the PDF, and we only need to generate it every night. So the costs are also not an issue at the moment.

Re: Show HN: Dropflow, a CSS layout engine for node or <canvas>

#133
post #10

Earlier quoted context omitted.

> wondering if css and svg could be used as abstraction over graphics and UI libraries 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 t…

> 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 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 gly…

> 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

This made me laugh because I can relate so much. Inline backgrounds can start in LTR text and end in RTL text, and when I was implementing that I got so frustrated that I had to stop and seriously consider I might have an anger problem.

> Question: did you ever find out what algorithm the various browsers are using to calculate how many words can fit on a given line?

Not sure if I understood the question correctly, but they use a greedy algorithm where the break points in the string are the choices. If your glyphs are scaling and so is the available width, you might have a float precision problem? Browsers use integers for that reason. I'm still using floats.

Scrawl/that PR look extremely cool! I would love to some day support CSS `shape-outside`, which achieves a similar thing to what you have in your PR.

Re: Show HN: Dropflow, a CSS layout engine for node or <canvas>

#135

This 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/…

I don't think rasterized output makes a good pdf.

Re: Show HN: Dropflow, a CSS layout engine for node or <canvas>

#136

This 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/…

You can make PDF client-side by html2canvas or webkit.js (https://github.com/trevorlinton/webkit.js)

Re: Show HN: Dropflow, a CSS layout engine for node or <canvas>

#138
post #121

Truly a service to the world. I think this is a classic example of "somebody ought to do $X" and nobody ever having done it. Thanks. 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?

For flexbox check out Facebook Yoga (https://github.com/facebook/yoga) or Webkit.js (https://github.com/trevorlinton/webkit.js).

Re: Show HN: Dropflow, a CSS layout engine for node or <canvas>

#139

Earlier quoted context omitted.

> It's also the most obscure because nobody has written down everything you need to know in one place Your work might have been, or maybe still is, the worlds biggest chance for this to change!

There was a whole team behind Microsoft Trident (IE engine) that was dissolved in favour of third-party (for them) Blink engine. That team was surely knowledgeable, but they had gone. Blink source is de facto current spec. Each function, if not single line, there is a paragraph in spec. I remember at WHATWG / HTML5 WG times when Ian Hickson (Google) was pushing whole SQLite (and its SQL flavour) to be included in HTM…

Blink source is not the spec, there are W3C specs implemented by Webkit/Blink/Gecko, see the Interop project.

It's not that MS couldn't handle its own engine, it was just not worth it for them in the long term.

Ladybird, NetSurf or Servo engines are prime examples that it is possible to create an independent web engine from scratch even not being a big corp. If they can do it, MS definitely could do it as well if they wanted.

Re: Show HN: Dropflow, a CSS layout engine for node or <canvas>

#140
post #34

This is incredible --- @chearon thank you for open sourcing this! 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.

Have you tried dom-to-image (https://github.com/tsayen/dom-to-image) or html2canvas?
Post reply on HN