Very cool - writing a browser has been on my own project todo list for going on 10 years now; like you I also write everything myself with few exceptions.
Maybe you'd like to follow a book building a browser? :-)
One of the ideas is to allow readers to build along in their own programming language, or using AI. The main material is more about the building blocks and what needs to be done; the C coding can be skipped.
Text rendering, but really layout/shaping, especially for complex scripts like Arabic.
There are lots of problems involved: parsing TTF, rasterizing the glyph shapes, line layout in CSS, avoiding floats, multiple styles (line-height, vertical-align, decorations, etc), just to make something quite simple.
I'm not doing text shaping, so Arabic will look strange. Also no RTL like Arabic and Hebrew, and no support for CJK scripts yet (that should be easier, using the Google Noto font. Needs a huge builtin map from codepoints to which fonts have those glyphs; each TTF file has at most just 2^16 glyphs, which isn't enough.)
JavaScript, which unfortunately seems like a necessity for the modern age.
Indeed, it's a pity that React sites won't work at all without Javascript. Doing a Javascript interpreter is very doable; I strongly recommend Crafting Interpreters as an excellent book that builds an interpreter for a language that is very similar to Javacript.
But the bigger piece is doing all the DOM bindings and web APIs.
The HN <script> payload is very easy to handle though: https://news.ycombinator.com/hn.js?FmJw8tvF5GVURtPJ592v
The very relaxed parsing of HTML/CSS. It's surprising just what browsers will tolerate in terms of malformed syntax yet still get a functional website out of it.
You'd be surprised! The HTML5 spec is actually very comprehensive about how to handle errors cases as well. Take a look:
https://html.spec.whatwg.org/multipage/parsing.html#parsing-...
I'm not handling all of the edge cases, only the standard <!DOCTYPE html> stuff i.e. I don't handle quirks in any special way. I guess most of those quirks are meant to handle older web pages and the way they rendered in IE back then.
My goal was always going to be to get Wikipedia working also.
That's a great goal, and it helps a lot to scope down what needs to be built.
Here's a screenshot of Wikipedia so far: https://imgur.com/a/vG0U3in
(small hack in that screenshot: the flex and grid layouts are getting replaced with blocks instead)
I'm thinking of doing an Advent of Code series for next year, to build a very minimal browser just for Wikipedia but with lots of shortcuts :-) For example, using a local HTTP proxy to avoid having to handle TLS, which is quite a big of work to get working.
One of the ideas is to allow readers to build along in their own programming language, or using AI. The main material is more about the building blocks and what needs to be done; the C coding can be skipped.
There are lots of problems involved: parsing TTF, rasterizing the glyph shapes, line layout in CSS, avoiding floats, multiple styles (line-height, vertical-align, decorations, etc), just to make something quite simple.I'm not doing text shaping, so Arabic will look strange. Also no RTL like Arabic and Hebrew, and no support for CJK scripts yet (that should be easier, using the Google Noto font. Needs a huge builtin map from codepoints to which fonts have those glyphs; each TTF file has at most just 2^16 glyphs, which isn't enough.)
Indeed, it's a pity that React sites won't work at all without Javascript. Doing a Javascript interpreter is very doable; I strongly recommend Crafting Interpreters as an excellent book that builds an interpreter for a language that is very similar to Javacript.But the bigger piece is doing all the DOM bindings and web APIs.
The HN <script> payload is very easy to handle though: https://news.ycombinator.com/hn.js?FmJw8tvF5GVURtPJ592v
You'd be surprised! The HTML5 spec is actually very comprehensive about how to handle errors cases as well. Take a look:https://html.spec.whatwg.org/multipage/parsing.html#parsing-...
I'm not handling all of the edge cases, only the standard <!DOCTYPE html> stuff i.e. I don't handle quirks in any special way. I guess most of those quirks are meant to handle older web pages and the way they rendered in IE back then.
That's a great goal, and it helps a lot to scope down what needs to be built.Here's a screenshot of Wikipedia so far: https://imgur.com/a/vG0U3in
(small hack in that screenshot: the flex and grid layouts are getting replaced with blocks instead)
I'm thinking of doing an Advent of Code series for next year, to build a very minimal browser just for Wikipedia but with lots of shortcuts :-) For example, using a local HTTP proxy to avoid having to handle TLS, which is quite a big of work to get working.