[chearon]

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

[rikroots]

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

[chearon]

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

[jsunderland323]

I’m curious if you’ve implemented a rich text editor with this. I think Google Docs uses canvas. I hate the browser APIs for rich text and wonder if this could be more a viable candidate than using contenteditable for future projects

[chearon]

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!

[c-smile]

> Every time someone releases a new rich text editor ... uses contentEdtiable

Sciter is using its own implementation (obviously).

contentEdtiable thing is indeed quite limited for general purpose WYSIWYG editor.

For example Web platform is missing transactional update [1] mechanism that allows to put custom DOM mutation groups into unified undo/redo stack.

Sciter's <htmlarea> element ( implement behavior:richtext - WYSIWYG ) allows to build specialized editors. For example it is used in Sciter.Notes [2].

[1] https://docs.sciter.com/docs/behaviors/behavior-richtext#ric... [2] https://notes.sciter.com/

[Traubenfuchs]

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

[c-smile]

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

The spec area is so huge and indeed obscure that even Microsoft could not handle it.

[niutech]

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.