Historical engineering note. This is a point-in-time planning document from the project archive, written before browser work began, and may not reflect the current system; MayteraOS has since shipped a working browser with HTTP/2 and TLS 1.3 support.

MayteraOS Web Browser Implementation Plan

Version: 1.0 Date: January 2026 Status: Planning Phase

Executive Summary

This document outlines a comprehensive plan for implementing a web browser on MayteraOS. After analyzing the existing kernel capabilities and evaluating multiple browser options, this plan recommends a phased approach starting with NetSurf's framebuffer frontend as the primary strategy, with a fallback to a custom minimal HTML renderer for educational value and tight integration.

Options Analysis
Recommendation
Current MayteraOS Capabilities
Requirements Analysis
Implementation Phases
Dependencies and Prerequisites
Technical Architecture
Realistic Scope Assessment
Risk Analysis
Timeline Estimates
References

1. Options Analysis

Option A: Port NetSurf (Recommended)

Overview: NetSurf is a free, open-source web browser written in ANSI C with its own custom layout and rendering engine. It was specifically designed for portability and resource-constrained environments.

Advantages:

Written in portable ANSI C with minimal external dependencies
Framebuffer frontend available that bypasses all GUI toolkit requirements
Memory footprint as low as 32MB RAM
HTML5-compliant parser (Hubbub)
Full CSS 2.1 support with CSS3 partial support
Successfully ported to Plan 9, Nintendo 3DS, RISC OS, AmigaOS, Haiku, Atari
Active development community
MIT/GPL dual licensed
Renders its own widgets, scrollbars, and mouse pointer
Well-documented porting guide

Disadvantages:

Still requires implementing platform abstraction layer (libnsfb backend)
No JavaScript support (would need to add later)
Requires porting ~8 internal libraries
HTTPS requires TLS library port
Font rendering requires either internal bitmap fonts or FreeType

Porting Complexity: Medium-High Web Standards Compliance: Good (HTML5, CSS 2.1+)

Required Libraries (in build order):

BuildSystem - Shared build infrastructure
LibParserUtils - Parser building utilities
LibWapcaplet - String internment
Hubbub - HTML5 parser
LibCSS - CSS parser and selection engine
LibNSGIF - GIF decoder
LibNSBMP - BMP/ICO decoder
LibNSFB - Framebuffer abstraction (needs MayteraOS backend)

Option B: Port Links/Lynx (Text-Based)

Overview: Lynx and Links are text-based web browsers. Links has a graphics mode with limited HTML rendering.

Advantages:

Extremely lightweight
Lynx has been ported to DOS, VMS, BeOS, MINIX, QNX, AmigaOS
Links supports basic graphics mode
Minimal dependencies
Good for testing HTTP/network stack

Disadvantages:

Limited or no graphical rendering (Lynx is text-only)
Links graphics mode still requires curses/terminal abstraction
Poor modern web compatibility
No CSS support in Lynx
Not suitable as a primary browser for a graphical OS
Would need terminal emulation layer

Porting Complexity: Medium Web Standards Compliance: Poor (HTML 4.0 basic)

Verdict: Suitable as a debugging/fallback browser but not as primary

Option C: Port Dillo

Overview: Dillo is a lightweight graphical browser written in C/C++ using the FLTK GUI toolkit.

Advantages:

Very lightweight (~10MB with Dillo+)
Has run on Intel 486
Simple codebase
Active development resumed in 2024
HTTPS support with mbedTLS

Disadvantages:

Requires FLTK library port - significant undertaking
FLTK depends on X11 or equivalent windowing system
C++ increases complexity vs pure C
Would need to implement FLTK backend for MayteraOS window manager
Less documented porting process than NetSurf

Porting Complexity: High (due to FLTK dependency) Web Standards Compliance: Moderate (HTML 4, basic CSS)

Verdict: Not recommended due to FLTK dependency

Option D: Custom Minimal HTML Renderer

Overview: Build a custom browser from scratch using existing libraries for parsing.

Approach 1: Use litehtml library

C++ library for HTML/CSS rendering
Requires implementing document_container interface
Platform-agnostic (only needs STL)
Uses gumbo-parser for HTML parsing
BSD licensed

Approach 2: Build from scratch

Complete control over implementation
Educational value
Can target exactly MayteraOS capabilities
Start with HTML 1.0/2.0, iterate

Advantages:

Perfect integration with MayteraOS window manager
No external toolkit dependencies
Full control over memory and rendering
Educational and satisfying
Can evolve with OS capabilities

Disadvantages:

Enormous development effort
Web standards are complex (HTML5 spec is 1000+ pages)
CSS layout is notoriously difficult
Would take years to achieve reasonable compatibility
Risk of creating another incompatible browser

Porting Complexity: Extreme (if building from scratch) Web Standards Compliance: Depends on effort

Verdict: Consider litehtml integration as Phase 2 fallback

Option E: Chromium/WebKit (Not Realistic)

Note: Full Chromium or WebKit are explicitly not considered due to:

Multi-gigabyte codebase
Requires full POSIX environment
Needs pthreads, advanced memory management
GPU acceleration expectations
Thousands of dependencies
Would take 5+ years to port
Exceeds hobby OS scope by orders of magnitude

2. Recommendation

Primary Strategy: NetSurf Framebuffer Port

Justification:

Designed for this use case: NetSurf's framebuffer frontend was specifically created for embedded systems and custom OS ports. It has no GUI toolkit requirements and renders everything through its own plotter interface.
Proven portability: Successfully running on Plan 9, Nintendo 3DS (64-128MB RAM), RISC OS, and other unusual platforms demonstrates real-world portability.
Matches MayteraOS architecture: MayteraOS already has:

Framebuffer graphics (kernel/video/framebuffer.c)
TCP/IP networking with HTTP client (kernel/net/wget.c)
Window manager (kernel/gui/window.c)
BMP image decoding (kernel/gui/image.c)
Memory allocator (kernel/mm/heap.c)

Modern web support: HTML5 parser, CSS 2.1 support, and reasonable rendering make it usable for many websites.
Modular architecture: Can start with basic rendering and add features (images, CSS, later JavaScript) incrementally.

Secondary Strategy: litehtml Integration

If NetSurf porting proves too complex, litehtml provides a lighter alternative:

Smaller codebase focused only on layout/rendering
Clear interface (document_container) to implement
Can leverage existing MayteraOS graphics primitives
Better for tight OS integration

3. Current MayteraOS Capabilities

Existing Infrastructure (Assets)

Component	Status	Location	Notes
TCP Stack	Implemented	`kernel/net/tcp.c`	Full state machine, socket API
HTTP Client	Implemented	`kernel/net/wget.c`	HTTP/1.0, no HTTPS
Framebuffer	Implemented	`kernel/video/framebuffer.c`	32-bit BGRA, drawing primitives
Window Manager	Implemented	`kernel/gui/window.c`	Windows, events, z-ordering
Bitmap Font	Implemented	`kernel/video/font.c`	8x16 fixed-width
BMP Decoder	Implemented	`kernel/gui/image.c`	24/32-bit uncompressed
Heap Allocator	Implemented	`kernel/mm/heap.c`	kmalloc/kfree
Mouse Input	Implemented	`kernel/drivers/mouse.c`	PS/2 mouse
Keyboard Input	Implemented	Standard PS/2 driver	ASCII input
FAT Filesystem	Implemented	`kernel/fs/fat.c`	Read support
IRC Client	Implemented	`kernel/gui/irc.c`	Proof of TCP GUI app

Missing Infrastructure (Gaps)

Component	Importance	Effort	Notes
DNS Resolution	High	Medium	wget.c only supports IP addresses
HTTPS/TLS	High	High	Required for modern web
PNG Decoder	High	Medium	Most web images
JPEG Decoder	High	High	Very common format
GIF Decoder	Medium	Medium	Animations less critical
TrueType Fonts	Medium	High	FreeType or equivalent
Unicode Support	Medium	Medium	UTF-8 handling
FAT Write	Low	Medium	Cache/downloads
Scrollbar Widget	Low	Low	Already in window.c

4. Requirements Analysis

4.1 HTML/CSS Parsing

HTML Requirements:

Minimum: HTML 4.01 parsing
Target: HTML5 parsing (for modern sites)
Hubbub (NetSurf's HTML5 parser) handles error recovery per spec

CSS Requirements:

Minimum: CSS 1.0 (basic text styling, colors)
Target: CSS 2.1 (layout, positioning, box model)
LibCSS provides CSS parsing and cascade resolution

Implementation Strategy:

Phase 1: Use NetSurf's Hubbub + LibCSS
Alternative: Use litehtml with gumbo-parser

4.2 JavaScript (Optional for v1)

Assessment: JavaScript is explicitly optional for the first version. Many useful websites (documentation, Wikipedia, simple pages) work without JavaScript.

Future Options:

Duktape: Lightweight embeddable JavaScript engine (C)
QuickJS: Small, fast JS engine by Fabrice Bellard
MuJS: Minimal JS interpreter

Recommendation: Defer JavaScript to Phase 4. Focus on rendering first.

4.3 Networking (HTTP/HTTPS)

Current State:

HTTP/1.0 implemented in wget.c
TCP stack functional
No DNS (IP addresses only)
No TLS/HTTPS

Required Improvements:

DNS Client:

Simple UDP-based DNS resolver
Query A records for hostname resolution
Cache responses
Estimated effort: 2-3 days

HTTPS/TLS:

Options:
BearSSL (MIT license, designed for bare metal, no malloc required)
mbedTLS (Apache 2.0, more features, needs malloc)
BearSSL recommended for minimal footprint
State machine API fits single-threaded model
Estimated effort: 2-3 weeks

HTTP/1.1:

Keep-alive connections
Chunked transfer encoding
Content-Encoding (gzip optional)
Estimated effort: 1 week

4.4 Graphics Rendering

Current Capabilities:

Pixel plotting
Line drawing
Rectangle fill/outline
Circle drawing
8x16 bitmap font
BMP image loading

Additional Requirements:

Plotter Interface (for NetSurf):

   struct plotter_table {
       bool (*rectangle)(int x0, int y0, int x1, int y1, ...);
       bool (*line)(int x0, int y0, int x1, int y1, ...);
       bool (*polygon)(const int *p, unsigned int n, ...);
       bool (*clip)(const struct rect *clip);
       bool (*text)(int x, int y, const char *text, ...);
       bool (*disc)(int x, int y, int radius, ...);
       bool (*arc)(int x, int y, int radius, ...);
       bool (*bitmap)(int x, int y, int width, int height, ...);
       bool (*path)(const float *p, unsigned int n, ...);
   };

Anti-aliased line drawing (optional, improves appearance)
Alpha blending (already partial in gfx_blend)
Clipping regions (essential for window content)

4.5 Font Rendering

Options:

Internal Bitmap Fonts (NetSurf built-in):

Monospaced, limited sizes
Fast and simple
No anti-aliasing
Suitable for initial version

FreeType Library:

Industry standard
TrueType, OpenType support
Anti-aliased rendering
~500KB code size
Complex to port but well-documented

stb_truetype.h:

Single-header library
TrueType parsing
No dependencies
Lighter than FreeType
Good middle ground

Recommendation: Start with NetSurf internal fonts, add stb_truetype in Phase 3.

5. Implementation Phases

Phase 1: HTTP Client Enhancement (4-6 weeks)

Goals:

Robust HTTP/1.1 client
DNS resolution
Foundation for browser networking

Tasks:

DNS Resolver (1 week)

UDP DNS query implementation
A record parsing
Simple cache (256 entries)
Timeout and retry logic

HTTP/1.1 Upgrade (2 weeks)

Keep-alive connection support
Chunked transfer encoding
Content-Length handling
Redirect following (301, 302, 307)
Cookie storage (basic)

URL Parser (3 days)

Scheme, host, port, path parsing
Query string handling
Relative URL resolution

Testing Framework (3 days)

Simple HTTP server for testing
Test pages for various features

Deliverable: HTTP client that can fetch web pages by hostname

Phase 2: Basic HTML Parser and Renderer (8-10 weeks)

Goals:

Parse HTML documents
Render basic text and structure
Display in MayteraOS window

Tasks:

NetSurf Library Ports (4 weeks)

Port LibParserUtils
Port LibWapcaplet
Port Hubbub (HTML5 parser)
Basic test harness

libnsfb MayteraOS Backend (2 weeks)

Implement surface operations
Connect to MayteraOS framebuffer
Input event translation

Basic Rendering (3 weeks)

Text layout (single font)
Headings (H1-H6)
Paragraphs
Line breaks
Lists (ul, ol)
Links (clickable)
Scrolling

Browser Chrome (1 week)

Address bar
Back/Forward buttons
Reload button
Status bar

Deliverable: Browser that renders simple HTML pages

Phase 3: CSS Layout Engine (10-12 weeks)

Goals:

CSS parsing and cascade
Box model layout
Common CSS properties

Tasks:

Port LibCSS (3 weeks)

CSS parser
Selector matching
Cascade and inheritance

Layout Engine Integration (4 weeks)

Box model (margin, padding, border)
Block layout
Inline layout
Float (basic)
Position (static, relative, absolute)

Font System Upgrade (2 weeks)

Integrate stb_truetype
Font family selection
Font size scaling
Font style (bold, italic)

Image Loading (2 weeks)

PNG decoder (stb_image or libpng)
JPEG decoder (stb_image or libjpeg)
Image caching
Image scaling

Polish (1 week)

Background colors/images
Text colors
Border styles

Deliverable: Browser that handles CSS-styled pages

Phase 4: TLS/HTTPS Support (6-8 weeks)

Goals:

Secure connections
Modern web access

Tasks:

BearSSL Port (3 weeks)

Core crypto functions
TLS 1.2 handshake
Certificate validation
CA certificate bundle

HTTPS Integration (2 weeks)

Wrap TCP sockets with TLS
Certificate error handling
Mixed content warnings

Security UI (1 week)

Padlock icon
Certificate viewer
Security warnings

Deliverable: Browser with HTTPS support

Phase 5: JavaScript Engine (Optional, 12+ weeks)

Goals:

Basic JavaScript execution
DOM manipulation

Tasks:

Duktape/QuickJS Port (4 weeks)

Core engine port
Memory integration
Event loop integration

DOM Bindings (6 weeks)

Document object
Element manipulation
Event handlers
XMLHttpRequest

Testing and Debugging (2+ weeks)

Compatibility testing
Performance optimization

Deliverable: Browser with basic JavaScript support

6. Dependencies and Prerequisites

6.1 SSL/TLS Support

Recommended: BearSSL

Rationale:

Designed for bare metal (no malloc required)
State machine API (no threads needed)
MIT licensed
Smallest footprint among secure options
Constant-time crypto implementations

Alternative: mbedTLS

More features
Better documentation
Requires malloc (MayteraOS has kmalloc)
Larger code size

Implementation Notes:

Need to provide random number generator (use hardware RNG if available, or entropy collection)
Certificate bundle storage (~200KB for common CAs)
Consider certificate date validation (needs RTC)

6.2 Font Rendering System

Phase 1-2: Bitmap Fonts

Use existing 8x16 font
Add 6x8 small font for UI elements
No anti-aliasing

Phase 3+: stb_truetype

Single header file
Parse TTF/OTF files
Rasterize glyphs
Font caching required

Files Needed:

System fonts (DejaVu Sans, DejaVu Serif, DejaVu Mono)
Store on FAT filesystem

6.3 Image Decoding

PNG (Required):

Options: stb_image.h (easy), libpng (full-featured)
stb_image is single-header, easy integration
Needed for most web graphics

JPEG (Required):

Options: stb_image.h, libjpeg-turbo
Very common photo format
stb_image handles basic JPEG

GIF (Lower Priority):

LibNSGIF from NetSurf project
Already part of NetSurf port
Animations can be deferred

Recommendation: Use stb_image.h for PNG and JPEG initially (single file, no dependencies)

6.4 Memory Requirements

Estimated Memory Usage:

Component	RAM Requirement
HTTP buffers	64 KB
HTML DOM tree	256 KB - 2 MB (page dependent)
CSS structures	128 KB - 512 KB
Rendered page	1-4 MB (depends on viewport)
Image cache	2-8 MB (configurable)
Font cache	256 KB - 1 MB
TLS buffers	32 KB per connection
JavaScript heap	2-8 MB (if enabled)

Total Minimum: 8 MB Recommended: 32 MB Comfortable: 64 MB+

MayteraOS should have sufficient heap available (verify with heap_print_stats()).

7. Technical Architecture

7.1 NetSurf Integration Architecture

+------------------+
|  Browser UI      |  <- MayteraOS Window (window.c)
|  (address bar,   |
|   buttons)       |
+--------+---------+
         |
+--------v---------+
|  NetSurf Core    |  <- HTML parser, CSS engine, layout
|  - Hubbub        |
|  - LibCSS        |
|  - Layout Engine |
+--------+---------+
         |
+--------v---------+
|  libnsfb         |  <- Framebuffer abstraction
|  MayteraOS       |
|  Backend         |
+--------+---------+
         |
    +----+----+
    |         |
+---v---+ +---v---+
|Frame- | |Input  |  <- MayteraOS drivers
|buffer | |Events |
+-------+ +-------+

7.2 libnsfb MayteraOS Backend

Required Functions:

// Surface creation
nsfb_t *nsfb_new(enum nsfb_type_e type);
int nsfb_init(nsfb_t *nsfb);

// Geometry
int nsfb_set_geometry(nsfb_t *nsfb, int width, int height,
                      enum nsfb_format_e format);
int nsfb_get_geometry(nsfb_t *nsfb, int *width, int *height,
                      enum nsfb_format_e *format);

// Framebuffer access
int nsfb_get_buffer(nsfb_t *nsfb, uint8_t **ptr, int *linelen);
int nsfb_update(nsfb_t *nsfb, nsfb_bbox_t *box);

// Input events
bool nsfb_event(nsfb_t *nsfb, nsfb_event_t *event, int timeout);

// Plotting (can use default implementations)
bool nsfb_plot_set_clip(nsfb_t *nsfb, nsfb_bbox_t *clip);
bool nsfb_plot_rectangle_fill(nsfb_t *nsfb, nsfb_bbox_t *rect,
                               nsfb_colour_t c);
// ... more plotting functions

MayteraOS Mapping:

libnsfb Function	MayteraOS Function
get_buffer	Pointer to framebuffer memory
update	fb_swap_buffers (or direct)
plot_rectangle_fill	fb_fill_rect
plot_line	fb_draw_line
event (mouse)	mouse_get_state
event (keyboard)	keyboard_get_key

7.3 Browser Window Structure

typedef struct browser_window {
    window_t *window;        // MayteraOS window

    // Navigation
    char url[2048];          // Current URL
    char *history[64];       // Back/forward history
    int history_pos;

    // Page state
    void *netsurf_context;   // NetSurf browser window handle

    // UI elements
    widget_t *url_bar;
    widget_t *back_btn;
    widget_t *forward_btn;
    widget_t *reload_btn;
    widget_t *stop_btn;

    // Rendering
    int scroll_x, scroll_y;
    int content_width;
    int content_height;

    // Status
    bool loading;
    char status_text[256];
} browser_window_t;

8. Realistic Scope Assessment

8.1 What IS Achievable for a Hobby OS

Definitely Achievable (6-12 months):

Basic HTML rendering (text, headings, paragraphs, lists, links)
Simple CSS (colors, fonts, basic layout)
HTTP/1.1 with DNS
Image display (PNG, JPEG, BMP)
Navigation (back, forward, reload)
Bookmarks (simple list)
Local file viewing (file:// URLs)

Achievable with Significant Effort (12-24 months):

Full CSS 2.1 layout
Tables
Forms (input, textarea, select, button)
HTTPS with TLS 1.2
Cookie handling
Download manager
Multiple tabs

Challenging but Possible (24+ months):

Basic JavaScript
CSS3 partial support
Web fonts
Audio/video elements (with codec support)

Not Realistic:

Full JavaScript engine comparable to V8
WebGL/Canvas hardware acceleration
CSS Grid/Flexbox full implementation
WebAssembly
Service workers
Web Components
Browser extensions

8.2 Website Compatibility Expectations

Will Work Well:

Wikipedia (mostly text-based)
Documentation sites
Static HTML sites
Simple blogs
Classic web forums

Partial Functionality:

News sites (text content visible)
Some e-commerce (browsing, not checkout)
GitHub file viewing (not interactive features)

Will Not Work:

Single-page applications (React, Vue, Angular)
Google Docs, Office Online
YouTube, Netflix
Social media (Twitter, Facebook, Instagram)
Modern web apps requiring JavaScript

8.3 Honest Assessment

A NetSurf port to MayteraOS would result in a browser roughly equivalent to browsers from 2005-2008. This is still useful for:

Reading documentation
Browsing Wikipedia
Viewing many informational websites
Personal satisfaction of having a working browser It will not provide a "modern web experience" but that's acceptable for a hobby OS.

9. Risk Analysis

9.1 Technical Risks

Risk	Probability	Impact	Mitigation
NetSurf libraries don't compile	Medium	High	Use libc shim, stub unavailable functions
Memory exhaustion	Medium	High	Implement hard limits, page-at-a-time rendering
Rendering bugs	High	Medium	Start simple, test incrementally
TLS implementation issues	Medium	High	Use well-tested BearSSL
Performance too slow	Medium	Medium	Optimize hot paths, reduce features
Scope creep	High	Medium	Strict phase gates

9.2 Schedule Risks

Risk	Probability	Impact	Mitigation
Underestimated effort	High	High	Add 50% buffer to estimates
Dependency issues	Medium	Medium	Test dependencies early
Maintainer burnout	Medium	High	Set realistic milestones, celebrate progress
Other priorities	High	Medium	Accept that hobby projects flex

9.3 Fallback Strategies

If NetSurf port stalls: Switch to litehtml (smaller scope)
If CSS too complex: Ship with CSS disabled initially
If TLS too hard: HTTP-only mode with warning
If memory issues: Reduce cache sizes, simpler rendering

10. Timeline Estimates

Aggressive Timeline (Full-time effort)

Phase	Duration	Cumulative
Phase 1: HTTP Enhancement	6 weeks	6 weeks
Phase 2: Basic HTML	10 weeks	16 weeks
Phase 3: CSS Engine	12 weeks	28 weeks
Phase 4: HTTPS	8 weeks	36 weeks

Total: ~9 months to usable browser

Realistic Timeline (Hobby project, part-time)

Phase	Duration	Cumulative
Phase 1: HTTP Enhancement	3 months	3 months
Phase 2: Basic HTML	5 months	8 months
Phase 3: CSS Engine	6 months	14 months
Phase 4: HTTPS	4 months	18 months

Total: ~18 months to usable browser

Milestone Checkpoints

Month 3: DNS resolution and HTTP/1.1 working
Month 6: Display plain HTML pages in window
Month 9: Styled text with basic CSS
Month 12: Images loading, links clickable
Month 15: Most simple websites render acceptably
Month 18: HTTPS support, browser is daily-usable

11. References

NetSurf Resources

Alternative Browsers

TLS Libraries

Browser Engine Development

Single-Header Libraries

stb_image.h - Image loading
stb_truetype.h - Font rendering
These are part of stb

Appendix A: Quick Start Commands

Verify Current Network Capabilities

Before starting, confirm that the kernel's existing HTTP client can fetch a test page from a web server on the local network. This exercises DHCP, ARP, TCP, and the HTTP/1.0 path that the browser will build on.

NetSurf Build Environment (on Linux host)

# Install build dependencies
sudo apt install build-essential git libcurl4-openssl-dev libpng-dev

# Clone NetSurf workspace
mkdir ~/netsurf && cd ~/netsurf

# Get build system
git clone git://git.netsurf-browser.org/buildsystem.git

# Get libraries (in order)
for lib in libparserutils libwapcaplet libhubbub libcss libnsgif libnsbmp libnsfb netsurf; do
    git clone git://git.netsurf-browser.org/${lib}.git
done

# Build for framebuffer
cd netsurf
make TARGET=framebuffer

Appendix B: MayteraOS Integration Checklist

[ ] Verify heap has 32+ MB available
[ ] Test TCP with large transfers (1MB+)
[ ] Implement DNS resolver
[ ] Add scrollbar widget to window.c
[ ] Implement text input widget for URL bar
[ ] Add keyboard focus management
[ ] Test framebuffer performance with full-screen updates
[ ] Measure font rendering speed
[ ] Create test HTML files on FAT filesystem
[ ] Set up cross-compilation environment for NetSurf

Document prepared for MayteraOS browser implementation planning. Last updated: January 2026

MayteraOS Web Browser Implementation Plan

Executive Summary

Table of Contents

1. Options Analysis

Option A: Port NetSurf (Recommended)

Option B: Port Links/Lynx (Text-Based)

Option C: Port Dillo

Option D: Custom Minimal HTML Renderer

Option E: Chromium/WebKit (Not Realistic)

2. Recommendation

Primary Strategy: NetSurf Framebuffer Port

Secondary Strategy: litehtml Integration

3. Current MayteraOS Capabilities

Existing Infrastructure (Assets)

Missing Infrastructure (Gaps)

4. Requirements Analysis

4.1 HTML/CSS Parsing

4.2 JavaScript (Optional for v1)

4.3 Networking (HTTP/HTTPS)

4.4 Graphics Rendering

4.5 Font Rendering

5. Implementation Phases

Phase 1: HTTP Client Enhancement (4-6 weeks)

Phase 2: Basic HTML Parser and Renderer (8-10 weeks)

Phase 3: CSS Layout Engine (10-12 weeks)

Phase 4: TLS/HTTPS Support (6-8 weeks)

Phase 5: JavaScript Engine (Optional, 12+ weeks)

6. Dependencies and Prerequisites

6.1 SSL/TLS Support

6.2 Font Rendering System

6.3 Image Decoding

6.4 Memory Requirements

7. Technical Architecture

7.1 NetSurf Integration Architecture

7.2 libnsfb MayteraOS Backend

7.3 Browser Window Structure

8. Realistic Scope Assessment

8.1 What IS Achievable for a Hobby OS

8.2 Website Compatibility Expectations

8.3 Honest Assessment

9. Risk Analysis

9.1 Technical Risks

9.2 Schedule Risks

9.3 Fallback Strategies

10. Timeline Estimates

Aggressive Timeline (Full-time effort)

Realistic Timeline (Hobby project, part-time)

Milestone Checkpoints

11. References

NetSurf Resources

Alternative Browsers

TLS Libraries

Browser Engine Development

Single-Header Libraries

Appendix A: Quick Start Commands

Verify Current Network Capabilities

NetSurf Build Environment (on Linux host)

Appendix B: MayteraOS Integration Checklist