chearon

That might actually be a bug in Firefox. The source text is correct and it works in Chrome. `text-overflow` shouldn't apply to text that fit on a line...

esbuild still doesn’t support top-level await. And live reloading is way, way slower than HMR.

It matters a lot more if you use vim at a huge resolution, or anything that sends a lot of control sequences. Terminal.app and iTerm get sluggish.

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?

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.

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.

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 :)

[1] https://jsfiddle.net/fz15xu20/

Paste the following into https://chearon.github.io/dropflow/ to see that it _is_ possible to style individual Arabic characters in canvas:

<div style="font-size: 10em;">ع<span style="color: blue;">ر</span>ب<span style="color: red;">ي</span></div>

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.

[1] https://github.com/chearon/dropflow#harfbuzz [2] https://github.com/WICG/canvas-place-element

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.

> 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.

> 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 <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!

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.

Yes, this is pretty high up on my list. I've already done a little bit of work on pagination/fragmentation, but it will take me some time.

Google Docs uses canvas, yeah, and last I looked it used an empty contentEditable just to receive [rich text] input. I do think you could use this to write a document editor like Docs and side-step many of the problems with contentEditable, but I haven't tried to.

Every time someone releases a new rich text editor I'm disappointed to find that it uses contentEdtiable. Would be very interesting!

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.

Wow thanks! Seeing Ladybird progress kept me motivated!

> 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 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).

[1] https://gitlab.gnome.org/GNOME/pango/

[2] https://www.w3.org/TR/CSS22/

I had the same experience. Very often, I couldn't fall asleep until 6-7am. I felt like I was losing my mind. I got professional help from sleep psychologists but it didn't do much. They told me all the same stuff that comes up when you google it, and it terrified me even more that even professionals didn't know why I couldn't sleep. I never had this much of a problem sleeping before I read the book.

After a year of this, a therapist pointed out that you can have bad days on good sleep and good days on bad sleep. That finally made it click that it wasn't logical to worry about bad sleep so much. I just stopped caring and that mostly got me over it, but I still have more bad nights than I ever used to.

If I see people reading the book, I warn them about it even though it feels a bit rude to tell someone not to read something.

Igalia is funding it by providing 4 employees:

https://people.igalia.com/mrego/servo/igalia-servo-tsc-2022/

The browser doesn't know what the auto size is any more than you do until it performs a layout (reflow). Layouts are expensive and must be minimized. And what if content is changed in the middle of the transition? Should it recalculate the new auto size? Maybe we will get it some day, but there are good reasons to be cautious.

I'd go as far as saying layout properties like `height` and `font-size` shouldn't even be animated. If you pay attention to animations on macOS or iOS, the animations are performed on post-layout pixels: scaling and translating. That gets you very smooth FPS and isn't thrashing the CPU.

You can still browse the source on GitHub though. I don't mind them trying to make more money so much. What I don't like is that we have 3 bugs open, one of them 3 years old, that aren't getting fixed. And paying for a license didn't give us any additional priority.

It's also not very performant. Rendering often forces multiple style/layout recalculations, which is nearly always solvable by having your rendering code better organized. Version 8, when they rewrote cell meta, caused certain cell meta APIs we were calling to take _seconds_ on large tables. Version 9 did not document that the "beforeManualColumnMove" changed the meaning of the indices from "before columns" to "after columns". Undo/redo is implemented incorrectly too, so we had to write that ourselves. These caused real problems that affected our users.

As soon as we get the capacity to switch to something like Datagridxl2 we will.

It does but only after a layout. Interpolating from `height: 0;` to `height: 10px` is easy, but interpolating to `height: auto` takes an additional layout. I always assumed that you can't do this either for performance reasons or because it would be really hard to implement.

I often have to set `min-width: 0` if it's a flexbox inside another flexbox. `min-width` defaults to `auto` which means the smaller of the `width` on it and its content width. The content width of a flexbox (being checked here as a flex item) is not defined as the smallest width it could be without overflowing, though. It's based on the content widths of _its_ flex items, regardless of whether or not you put `min-width: 0` on those [1]. So even if that inner flexbox can shrink below the items content width, its default minimum size will be larger than that. It feels wrong when you have to do it, but it also preserves the meaning of minimum _content_, and it might be what you want in other situations.

Width/height: auto require a layout to know the size, so I don't know if we'll ever get that either.

[1] https://www.w3.org/TR/css-flexbox-1/#intrinsic-main-sizes

I'm not seeing Safari 12 in the App Store (macOS 10.13.6). I wonder if they pulled the update because of this? I have Safari 11 still but my colleague got Safari 12 through the App Store.