It probably looks very wrong to people who still think lots of "modularity" and small packages is a good thing.
I'm all for it, and lots of Bun APIs are purely practical. Bun.stringWidth, for example, exposes code Bun already has internally. Nodejs probably has the same thing, but instead of us being able to use it, it gets reimplemented in 10 different versions in node_modules. How is that better?
I doubt the Bun team will have to change the S3 code very much over the years. The test runner, bundler, Postgres client, sure, I can see those being harder to maintain. But I'm also tired of everyone assuming everything needs to change all of the time. DX aside, my team is still on Webpack and we've only needed one new feature from it in the last ~5 years. Why can't Bun's bundler reach maturity and only receive a few updates?
Node does have the same thing, and you can access it with `--expose-internals` from `const { getStringWidth } = require("internal/util/inspect");`. They don't expose it for some reason.
I'm also still using webpack. Not sure why the community abandoned it. Haven't had any issues. Everything seems to use babel under the hood anyway and they all have their little wrappers over top.
Automattic acquired LearnBoost who employed TJ Holowaychuk, the original creator of node-canvas (and also Express and tons else). Automattic has not been involved in any way since at least 2017 when I joined node-canvas.
That uses harfbuzzjs to do shaping and, for the segments that it has to, it paints paths instead of using fillText. There is an even better method which Mozilla's pdfjs uses: for all the glyphs that you want to draw, build a font (easy with HarfBuzz) that maps sequential characters to those glyphs. Then use fillText with that font and the character that corresponds to the glyph that you want for each glyph. That's nearly as fast as fillText on the whole string.
The points you make are really important. I rant about how even Google Sheets doesn't do rich text correctly because of fillText's simplicity here: [1]. But I think many of your points could be solved by using HarfBuzz. I dream of having shapeText and fillGlyphs methods on the canvas as an alternate to HarfBuzz because it would be less wasteful. Leave the high-level APIs up to client-side libraries like dropflow and scrawl.
Google has proposed a placeElement method [2] that allows you to render HTML and CSS into a canvas, but that destroys what's so great about canvas, which is that it's crazy fast. DOM is very heavy-weight.
Now sometimes you can colour parts differently: if you stick with the inherent vowel on a conjunct, here making it LETTER KA, SIGN VIRAMA, LETTER RA, ditching the VOWEL SIGN I, then essentially the K from KA and the A from RA will be coloured LETTER KA, and the R from LETTER RA will be coloured SIGN VIRAMA. I haven’t decided yet if that’s an improvement! But this split colouring I only see in Dropflow—I’m not experiencing it in Firefox or Chromium, both of which do split Arabic colouring.
That's because Noto Sans Telugu (the font dropflow automatically downloaded based on the text; doesn't seem like a great pick but not wrong?) is returning ligatures. Not all fonts will be able to support styling individual characters. I get the same results in the dropflow playground as I get in Firefox and Chrome [1]. Maybe you were using different fonts in those browsers?
You might be able to turn OpenType features off in those browsers to make it look like your manual coloring, I'm not sure.
> if you stick with the inherent vowel on a conjunct, here making it LETTER KA, SIGN VIRAMA, LETTER RA, ditching the VOWEL SIGN I, then essentially the K from KA and the A from RA will be coloured LETTER KA, and the R from LETTER RA will be coloured SIGN VIRAMA. I haven’t decided yet if that’s an improvement!
Maybe because it changes the shaping results? I don't know enough about the writing system to understand this yet :)
> There’s a strong need for better text support on Canvas. [...] This includes not only visual features but also the possibility of supporting the same level of user interaction as the rest of the web
Agreed, but ... adding HTML/CSS to a raster (or WebGL etc) image is not the way to do it. I much prefer your idea of incorporating HarfBuzz-like functionality into the canvas/text APIs - especially given that HarfBuzz is included as part of most browsers' code base.
I've played with mixing HTML/CSS with canvas in my canvas library. The results are ... interesting[1][4], but (probably) not the ideal solution. Making it easy for developers to build canvas interactions with HTML/events anywhere on the page is much more productive and useful[2].
> There is currently no guarantee that the canvas fallback content currently used for accessibility always matches the rendered content, and such fallback content can be hard to generate.
My thinking is that directly reflecting the canvas text back into the DOM is often not useful for people using screen readers. They don't need to hear every number on the chart axis when instead they could be presented with just the measure and range of the axis. If the HTML element rapidly/repeatedly updates its content, it's going to be a very unpleasant experience for the user. I've experimented with this sort of thing in [2], but need feedback from real screenreader users to understand if the solution meets their needs.
> Access to live interactive forms, links, editable content with the same quality as the web. This will help to close the app gap with Flash.
Flash is dead. Please leave its bones in the crypt.
> A limited set of CSS shaders, such as filter effects, are already available, but there is a desire to use general WebGL shaders with HTML
I only work with 2D canvas, but I can understand the desire here. A different approach might be to convince browser devs to work on improving SVG (and CSS) filters to support WebGL shaders, which can then be used by the canvas? Though Safari still doesn't support using SVG filters in the canvas so maybe convince them first?
Playing with filter effects is one of the joys I get from working on my canvas library[3] - but that's got nothing to do with text layout ... except when applying the filter to text, of course![4]
Interesting take on representing charts in an accessible way. I feel like, as web developers, we were fed a myth that lots of markup and attributes automatically makes your content accessible. But it takes more thinking than that.
I've taken a similar approach to layering canvases with normal HTML (typically the HTML is on top). I don't have a problem logically representing what's painted on the canvas and doing my own hit detection either. Shaders and text shaping in canvas sound a lot more attractive to me than placeElement, but I guess we'll see. I should get around to campaigning for ctx.shapeText and ctx.fillGlyphs but I don't know how much folks care about it.
The title made me think this could actually layout and paint HTML, but I couldn't find anything remotely layout-related in the source tree. Then I found this comment saying even block sizing isn't done: https://github.com/lexbor/lexbor/issues/219#issuecomment-207.... Looks like a nice groundwork, though. It's nice to see things like parsing and Unicode being part of the same source tree.
We have a decent chunk of layout and paint implemented in an HTML renderer I'm working on (https://github.com/DioxusLabs/blitz), which is targeting the "electron" use case (but with a rust scripting interface rather than a JS one).
The implementation is currently very immature and there are a lot of bugs and missing features (I only got a first cut of inline layout working yesterday (but we already have flexbox and grid implemented)), but we're already seeing pretty decent results on a bunch of real-world web pages and hope to be at the point where we can render most of the web (excl. JS) in the next 6 - 12 months.
I interpreted your comment as this being unfinished but then I heard that PHP has already switched from libxml2 to Lexbor so I guess it's production-ready.
I do think complexity could be part of why we don't have many options here, but I don't agree that a layout engine is too difficult to maintain. More of the issue is that CSS layout (and maybe layout in general) is not widely well-understood. I've almost _never_ come across people interested in layout because generally it's a few properties to get something working and then you move on.
> few organizations have the resources to maintain a rendering engine long-term
I'm curious are there other instances of this happening than Edge switching to Blink? That event was one of my main motivators; it felt like further consolidation of obscure knowledge.
Very fun project! Did you ever consider integrating with web-platform-tests? It's shared between all the common browser vendors, and we're always interested in more contributors :-)
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 <style> support, and some of them use <script> 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 weird corners that would be great to make some WPT tests for. Definitely something I want to do!
Yes, a _lot_ of WPT tests depend on <script>. 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 <script> 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 <script> (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.
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 <script>, 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 …).
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).
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!).
With this and node-canvas, you have everything you need to generate PDFs. I'll add an example to the examples/ directory for that. The spreadsheet library and PDFs I talked about in OP were examples of how we use this in our application, but are closed-source.
Yes, definitely. In the meantime, you can still use this to get the intrinsic sizes of cells to create rows and columns, and you can use an empty inline-block and paint the image where it's laid out. I'll put something in the examples/ directory soon.
