danisss9.Lite 0.3.0

Lite

Lite is an experimental HTML, CSS, and JavaScript rendering engine for Windows and Linux, written in C#. It turns a URL into a native window (Win32 on Windows, X11 on Linux) without embedding WebView2 or another browser engine.

HTML and CSS are parsed with AngleSharp, layout is calculated by Lite's own layout engine, pixels are drawn with SkiaSharp, and JavaScript runs in QuickJS through Lite's native bridge. The project is intended for developers exploring browser internals, building constrained HTML-driven interfaces, or experimenting with a small managed rendering stack.

Lite implements a practical subset of the web platform. It is not a replacement for a production browser, and arbitrary websites should not be expected to render exactly as they do in Chromium, Firefox, or Safari.

<img width="975" height="728" alt="image" src="https://github.com/user-attachments/assets/23aa9646-d119-4647-9e05-36ad7f16f8fb" />

<img width="970" height="730" alt="image" src="https://github.com/user-attachments/assets/79f4f03b-2ae8-4483-96d8-ba1608c6fd91" />

Highlights

• Native Win32 (Windows) and X11 (Linux) hosts with mouse, keyboard, scrolling, navigation, and page transitions
• Custom block, inline, flex, table, float, absolute, and fixed-position layout
• CSS cascade, selectors, media queries, custom properties, generated content, transforms, transitions, and keyframe animations
• DOM APIs, events, timers, promises, fetch, XMLHttpRequest, Web Storage, history, and ES modules
• Forms and common controls, including validation and submission
• Inline SVG, Canvas 2D, images, iframes, audio, and video
• Optional LibVLC media backend through Lite.Media
• Unit, Web Platform Test, CSS 2.1, Test262, and Acid test harnesses

Requirements

• Windows x64, or Linux x64 with an X11 display (Wayland desktops work through XWayland)
• .NET 8 SDK
• To build the repository's QuickJS native library: MinGW-w64 GCC on Windows; gcc, git, curl, and xz on Linux
• An HTTP or HTTPS URL to render

On Linux, Lite talks to libX11.so.6 directly (install libx11-6 on minimal systems). <input type=file> and alert() use zenity or kdialog when one is installed; without them the file picker is unavailable and alerts go to stderr. Local pages should be served over HTTP; the example project includes a small static-file server for that purpose.

Install

Add the package from NuGet:

dotnet add package danisss9.Lite

During repository development, reference the project directly instead:

<ItemGroup>
  <ProjectReference Include="..\Lite\Lite.csproj" />
</ItemGroup>

Create a window

using Lite;

var window = new BrowserWindow(
    url: "https://example.com",
    title: "My Lite App",
    width: 1024,
    height: 768);

window.Run();

BrowserWindow.Run() loads the document, creates the native window, and enters the platform's message loop (Win32 on Windows, X11 on Linux). It blocks the calling thread until the window closes, so call it from the application's main UI thread.

The constructor is:

BrowserWindow(
    string url,
    string title = "Lite",
    int width = 800,
    int height = 600)

Run the example

The example hosts the files in Lite.Example/resources at http://localhost:4444 and opens the gallery in Lite. Run it with Lite.Example as the working directory so its relative resources path resolves correctly:

cd Lite.Example
dotnet run

The gallery contains focused pages for typography, layout, colors and effects, lists and tables, forms, transforms and animations, SVG and Canvas, JavaScript and DOM APIs, iframes, and media.

Pass a URL to open a remote page in the example window instead of starting the gallery server:

dotnet run --project Lite.Example -- https://lite.duckduckgo.com/lite/

Real audio and video playback use LibVLC when its native libraries are available: the bundled VideoLAN.LibVLC.Windows package on Windows, or the system libvlc on Linux (for example sudo apt install libvlc-dev vlc-plugin-base). If initialization fails, the example falls back to Lite's simulated media timeline.

How it works

The main rendering path is:

URL -> resource loading -> HTML/CSS parsing -> style resolution
    -> layout tree -> box layout -> SkiaSharp painting -> Win32 / X11 window

JavaScript -> DOM mutation/event -> style and layout invalidation -> repaint

Repository layout

Development

Build the complete solution:

dotnet build Lite.sln

The QuickJS bridge is built as part of Lite.QuickJs: build-quickjs.ps1 produces runtimes/win-x64/native/litequickjs.dll on Windows and build-quickjs.sh produces runtimes/linux-<arch>/native/liblitequickjs.so on Linux, both from the same pinned QuickJS archive and patches.

Run the regression suite:

dotnet run --project Lite.Tests/Lite.Tests.csproj -c Release

The upstream conformance suites are downloaded separately and pinned by Lite.Conformance/test-suites.lock.json (on Linux, run the scripts with PowerShell 7 pwsh):

# -IncludeCss21Official verifies the official CSS 2.1 snapshot, which is committed to the
# repo and hash-pinned; a matching tree needs no network. The suite was originally vendored
# from Internet Archive captures of test.csswg.org (offline), and the script can re-crawl
# those if the tree is ever missing or fails its pin check.
./scripts/fetch-tests.ps1 -IncludeCss21Official

dotnet run --project Lite.Conformance -c Release -- --suite profile
dotnet run --project Lite.Conformance -c Release -- --suite css21
dotnet run --project Lite.Conformance -c Release -- --suite wpt
dotnet run --project Lite.Conformance -c Release -- --suite html5
dotnet run --project Lite.Conformance -c Release -- --suite test262
dotnet run --project Lite.Conformance -c Release -- --suite acid

The WPT/HTML/CSS suites execute through one persistent worker process per run (recycled every 200 tests), so wall time tracks engine work rather than per-test process startup. Set LITE_WPT_ISOLATED=1 to fall back to the per-test fresh process (used for crash attribution comparisons). --shard i/N splits a suite across concurrent processes; scripts/run-css21-baseline.ps1 sizes its shard count to the machine by default, and python scripts/run-es2020.py already runs the JS suite in eight shards. Known-slow pages whose outcome is timeout under any budget get reviewed reduced kill budgets in Lite.Conformance/Wpt/test-timeouts.txt.

Lite targets the HTML 5.0 Recommendation of 28 October 2014, alongside the separate CSS 2.1 and ES2020 workstreams. The active profile publishes its exclusions and incomplete coverage. Historical HTML 5.2 contracts remain in Lite.Conformance/Profile/history/.

Curated green tests protect existing behavior; they do not establish complete standards conformance. --suite html5 runs the small set of reviewed assertions. html5ProfileReady remains false until all applicable requirements and required dependencies have current passing evidence. See HTML 5.0 implementation and evidence for the remaining work, upstream WPT serving, and report commands.

For JavaScript, see ES2020 conformance: full ECMA-262 11th edition support is established, with es2020ProfileReady true — 67,117 required Test262 executions pass, the browser host suite passes, all host obligations and all 2,115 specification clauses are reviewed, and the verdict is enforced by compatibility CI and NuGet release validation. --suite test262 runs the complete classified corpus; --test262-set smoke selects the small regression set; --test262-set staging executes the upstream staging tests as a review diagnostic. python scripts/run-es2020.py --require-ready runs eight shards, the host checks, and gates on the readiness verdict.

Contributing

Bug reports and focused pull requests are welcome. For rendering fixes, include a minimal HTML/CSS/JS reproduction and add the smallest relevant regression test. Run the unit suite and the affected conformance suite before opening a pull request.

When changing rendering behavior, keep parsing, style resolution, layout, painting, hit testing, and DOM-driven invalidation in mind: a visual fix in one stage can expose a mismatch in another.

License

Lite is available under the MIT License.