hey, this book looks cool! well done :)
Web Browser Engineering (2021)
71–80 of 138 posts
Re: Web Browser Engineering (2021)
#72Re: Web Browser Engineering (2021)
#73One great thing about this book is the 'stuff I didn't do' part. Layout is really hard. Just tables by themselves are hard, even without any css around them. CSS makes layout impossibly difficult. I challenge anyone to keep the whole CSS spec and its associated behaviors in their head. At this point css + html + javascript have become a dynamic PDL, and probably is one of the most complex pieces of software today. As…
Layout is so difficult that it made me quit using Common Lisp and ncurses to build my passion project and become the very thing I swore to destroy (a React developer). I can't be the only one who wants a simpler layout language than CSS that's designed with two decades of hindsight to provide the maximum simplicity-expressiveness product. Are there any serious projects to engineer something like this, or has everyone…
Re: Web Browser Engineering (2021)
#74One great thing about this book is the 'stuff I didn't do' part. Layout is really hard. Just tables by themselves are hard, even without any css around them. CSS makes layout impossibly difficult. I challenge anyone to keep the whole CSS spec and its associated behaviors in their head. At this point css + html + javascript have become a dynamic PDL, and probably is one of the most complex pieces of software today. As…
This Babylonian tower will crumble one day. Layout does not have to be so complex. There are dozens of GUI frameworks with simpler layout system. Those are enough for applications everyone uses.
Re: Web Browser Engineering (2021)
#75Is there a promotional code for HN? I was a happy user of HTMLUnit [1] with Jython [2] in the past and am very interested in a future where we can automatically generate portions of browser code using code generation and verification techniques. I've never felt as comfortable with tools like Playwright/Cypress/Selenium as I did with HTMLUnit (with all due respect to both). [1] https://htmlunit.sourceforge.io/ [2] htt…
The book isn’t out yet, so no promo code, but the whole thing is free online.
Re: Web Browser Engineering (2021)
#76Earlier quoted context omitted.
FWIW, Pavel, one of the authors, has devoted considerable time into what is one of the very, very few attempts at a formal specification for CSS (the static/float layout fragment cf [1]). It's a Racket program generating Z3 SMT solver code for verifying an instance layout (which also looks like Scheme) so it's not for the faint-hearted ;) but maybe just what an FP fan on HN is looking for as a challenge. [1]: https:/…
Wow, thanks, you always suspect no one has actually read the papers :) That was a crazy project... I eventually got it passing almost all of the WPT css2 fragment. I'm still working on CSS layout, with hopefully another paper coming soon.
Re: Web Browser Engineering (2021)
#77Earlier quoted context omitted.
FWIW, Pavel, one of the authors, has devoted considerable time into what is one of the very, very few attempts at a formal specification for CSS (the static/float layout fragment cf [1]). It's a Racket program generating Z3 SMT solver code for verifying an instance layout (which also looks like Scheme) so it's not for the faint-hearted ;) but maybe just what an FP fan on HN is looking for as a challenge. [1]: https:/…
Wow, thanks, you always suspect no one has actually read the papers :) That was a crazy project... I eventually got it passing almost all of the WPT css2 fragment. I'm still working on CSS layout, with hopefully another paper coming soon.
Re: Web Browser Engineering (2021)
#78It's refreshing that browser engineering seems to become a "trend" now. The ecosystem is quite sparse with basically only Google, Apple and Mozilla defining it. I'd like to see forward into a future with more independent browser engines.
I don't think it's worth trying to write a rendering engine for HTML. You will never finish - HTML is a spec fully owned by Google and Apple at this point and it's just too complex to implement from scratch. The interesting space is really post-HTML UI/document tech. There's another thread running about Typst which is a sort of better LaTeX. Markdown was highly impactful. There's a lot of scope for people to do inter…
This keeps being repeated. But it leans on three false assumptions.
- That is has to be "finished" at all. For many use-cases, a subset (of a subset) might just be fine. The screen in my refrigerator, or the information display in a train, might want to render some HTML, but when the HTML is controlled and constrained, there's no need for "everything".
- That is has to adhere to "the spec". See above, but also if the HTML+CSS+JS is less controlled, quite a few use-cases it's fine to ignore lots of the quirks or even large parts of the specs. Even Chrome and FF don't implement "all", whatever "the spec" might be in the first place. But a browser in a TV set-top box, my e-reader, some dedicated wikipedia-device, or the "help section of an app" are fine if they break on complex sites.
- That is must be implemented from scratch. Even if you forego the big rendering engines, JS VMs and so forth, there's a lot of libs that do DOM handling, CSS parsing, JS runtime etc. There's a lot of shoulders to stand on, aside from "just run chrome headless".
By repeating this mantra that its not worth "building a new browser" or "rendering engine", we only cement the status quo further. And promote the idea that your car, refrigerator, test-runner, help-section, dashboard, e-reader and whatnot must run either a full chrome or firefox. We stiffle innovation.
Re: Web Browser Engineering (2021)
#79Earlier quoted context omitted.
Something that uses less RAM would be nice. Other than that and the spyware from Capital-G Google Chrome and Capital-M Mozilla Firefox, I don't have a problem with it being sparse. It's millions of hours of de-duplicated work. I'd like an alternative to HTML though. If I was to make a browser maybe I'd focus on replacing HTML because I can't stand it, and replacing js just because the runtime is heavy. Like, a browse…
> Like, a browser that only runs wasm That's not a browser. More or less by definition, a browser is an application that can use HTTP (and potentially other protocols) to make requests to other systems and retrieve stuff described using HTML (and possibly other formats). Sure, a tool that just loads wasm and executes it would be fun (and probably exists, at least for the local case). But it's not a web browser.
Yes there would be a DOM in addition
Re: Web Browser Engineering (2021)
#80One great thing about this book is the 'stuff I didn't do' part. Layout is really hard. Just tables by themselves are hard, even without any css around them. CSS makes layout impossibly difficult. I challenge anyone to keep the whole CSS spec and its associated behaviors in their head. At this point css + html + javascript have become a dynamic PDL, and probably is one of the most complex pieces of software today. As…
Layout is so difficult that it made me quit using Common Lisp and ncurses to build my passion project and become the very thing I swore to destroy (a React developer). I can't be the only one who wants a simpler layout language than CSS that's designed with two decades of hindsight to provide the maximum simplicity-expressiveness product. Are there any serious projects to engineer something like this, or has everyone…