Lightweight HTML/CSS rendering engine written in pure Free Pascal

[Wallaby]

I've been building an HTML/CSS rendering engine in Free Pascal called Pixie. It has its own HTML5 parser, CSS3 tokeniser/parser, and a layout engine that handles block, inline, float, table, flexbox, and CSS grid.

I'm considering open-sourcing it and wanted to see if there's interest in the community first.

What it does

Pixie takes an HTML string and renders it into a Lazarus control (TPixieHtmlView) with full mouse interaction, scrolling, links, hover/active states, and form controls. Think of it as a way to use HTML/CSS for rich content display in native desktop apps — without embedding a browser.

Features

• HTML5 parser (68 tokeniser states, 23 insertion modes) — handles malformed HTML the same way browsers do
• CSS3 parser following the W3C CSS Syntax Level 3 spec
• Layout: block, inline, float, table (colspan/rowspan), flexbox, CSS grid
• Selectors: type, class, ID, attribute, combinators, :nth-child(), :not(), :is(), :hover, :active, ::before/::after
• Gradients: linear-gradient(), radial-gradient(), conic-gradient() with repeating variants
• Media queries (Level 4), custom properties (var()), border-radius, opacity, positioned elements
• Owner-drawn form controls: text inputs, textareas, checkboxes, radio buttons, buttons — with caret, selection, and clipboard

Architecture — no dependencies

Pixie is pure Pascal with zero third-party dependencies. The rendering backend is abstracted behind a canvas interface with three implementations:

• Direct2D / DirectWrite (Windows) — hardware-accelerated, native SVG via ID2D1DeviceContext5
• Cairo (Linux / cross-platform)
• Core Graphics (macOS)

~49,000 lines of Pascal across 58 units. A full demo app compiles to a 4.2 MB stripped executable (Win64, smart-linked). No DLLs, no runtime, no WebView2 redistributable.

Use cases for Lazarus apps

• Rich "about" dialogs, changelogs, and release notes
• In-app help systems and documentation viewers
• HTML-formatted reports and print previews
• Email or message display
• Dashboard panels with styled content and tables
• Any UI where you want the flexibility of HTML/CSS without the weight of an embedded browser

Current state

The engine is used in production in our commercial products. It handles real-world HTML well, though it's not trying to be a full browser — no JavaScript, no <video>, no CSS animations. The focus is on correct layout and rendering of static/interactive content.

Compiles with Lazarus/FPC targeting Windows (32/64), Linux (x64, ARM64), and macOS (x64, ARM64).

Would there be interest in seeing this released as open source? Curious to hear thoughts, questions, or what features would matter most to you.

[440bx]

@Wallaby,

At first sight, it looks really, really good.

Compiles with Lazarus/FPC targeting Windows (32/64), Linux (x64, ARM64), and macOS (x64, ARM64).

Would there be interest in seeing this released as open source? Curious to hear thoughts, questions, or what features would matter most to you.

I think it would be _great_ for it to be open source.  That would give other people the chance to improve upon what looks like an already very capable and useful foundation.  It might also ensure that its continued existence and improvements is not in turn dependent on the existence of a single entity.

[dsiders]

I've been building an HTML/CSS rendering engine in Free Pascal called Pixie. It has its own HTML5 parser, CSS3 tokeniser/parser, and a layout engine that handles block, inline, float, table, flexbox, and CSS grid.
I'm considering open-sourcing it and wanted to see if there's interest in the community first.

Your work to-date looks pretty impressive. I would absolutely love to see an open source version.

Pixie is pure Pascal with zero third-party dependencies. The rendering backend is abstracted behind a canvas interface with three implementations:

• Direct2D / DirectWrite (Windows) — hardware-accelerated, native SVG via ID2D1DeviceContext5
• Cairo (Linux / cross-platform)
• Core Graphics (macOS)

~49,000 lines of Pascal across 58 units. A full demo app compiles to a 4.2 MB stripped executable (Win64, smart-linked). No DLLs, no runtime, no WebView2 redistributable.

Isn't Cairo GTK-specific? Asking for a QPainter/QPaintDevice friend...

[Wallaby]

Isn't Cairo GTK-specific? Asking for a QPainter/QPaintDevice friend...

I haven't researched the Qt backend yet, but architecturally shouldn't be hard at all - the canvas interface is already abstracted.

It would just need TPixieCanvasQt with the same ~15 drawing methods as the D2D/Cairo/CG backends, I'll have a look at that.

[ALLIGATOR]

Wow! This is mind-blowing!

[egsuh]

Great! Frankly speaking, Lazarus's UI is not excellent --- of course I know it's my problem. But if importing forms / designs of HTML/CSS into Lazarus then it would imporve the look of Lazarus apps by large. Am I understanding accurate?

[DonAlfredo]

Would there be interest in seeing this released as open source?

+1 !

[zeljko]

Looks great, open source it !

[zeljko]

Isn't Cairo GTK-specific? Asking for a QPainter/QPaintDevice friend...

I haven't researched the Qt backend yet, but architecturally shouldn't be hard at all - the canvas interface is already abstracted.

It would just need TPixieCanvasQt with the same ~15 drawing methods as the D2D/Cairo/CG backends, I'll have a look at that.

Open source it and you'll get Qt5/Qt6 backend for free on all platforms where Qt lcl works: linux, mac, win, amiga ...

[paweld]

Looks great

[Wallaby]

Open source it and you'll get Qt5/Qt6 backend for free on all platforms where Qt lcl works: linux, mac, win, amiga ...

I'll get to that, the only issue is neither Qt5Pas or Qt6Pas6 have QSvgRenderer, which will be required for SVG rendering.

I might just submit a patch for Lazarus with that, otherwise maybe fallback to librsvg, which should be present in most distros.

[zeljko]

In that case, qt6 only, I'm not willing to change bindings for Qt5 since it is EOL, but anyway, QSvgRenderer can be added into it's own unit, so won't kill current lazarus users so they must rebuild C bindings. In a few years when distros update bindings then such unit can be merged to the qt62.pas

[domasz]

Looks interesting. When you open source you might get:
- bug reports
- fixes
- new features
- fame
It seems it beats THtmlViewer so billions of programmers who use THtmlViewer might want to switch to your Pixie.

[theo]

Looks great, open source it !

+1

[JuhaManninen]

It seems it beats THtmlViewer so billions of programmers who use THtmlViewer might want to switch to your Pixie.

Maybe not billions! 
Anyway, how does it compare speed-wise to THtmlViewer and TurboPowerIPro?
At least TurboPowerIPro is slow because it creates and frees a huge amount of objects.