Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Web Browser Engineering (2021)

browser.engineering

Post reply on HN
Print view View original

121–130 of 138 posts

Re: Web Browser Engineering (2021)

#121

Post by mike_hearn »

berkes wrote: post #78
mike_hearn wrote: post #35

Earlier quoted context omitted.

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…

> 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. 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 in…

Sure, if you're willing to write a renderer for something that looks like HTML but isn't then that's a lot more tractable. But at that point why not just do something better than HTML? Most of the effort is in the engine anyway.

Re: Web Browser Engineering (2021)

#122

Post by zahlman »

SomeWan wrote: post #101
pavpanchekha wrote: post #25

One of the authors here—thank you all for the nice words. Happy to answer questions!

Thank you for this amazing book! I always wanted to learn more about the technological foundations that I rely on as web developer (or engineer, as you put it). I am just curious, what was the process that lead you to decide to use Python to implement the browser? I feel like JavaScript via node would have offered a more related programming experience.

This was answered elsewhere; see https://news.ycombinator.com/item?id=41847363.

Re: Web Browser Engineering (2021)

#123

Post by vbezhenar »

echoangle wrote: post #118
msie wrote: post #96

Earlier quoted context omitted.

Pixel positioning is so nice! I remember how easy it was to layout UIs with VB.

How does that work when someone resizes a window? I'm genuinely asking because pixel positioning to me sounds like hardcoding positions. Do you have to manually code the reflow when the window becomes narrow for example?

Pixel positioning usually anchors to a specific side. Like you can anchor label to the right side and it'll move as expected. And you also need to specify minimum width/height to keep thing sane.

Although it works poorly with translations, so it's probably not the best approach, but certainly one of the simplest. If you don't need translations, it works surprisingly well. Basically all Delphi applications used it and there were used a lot in private companies.

Re: Web Browser Engineering (2021)

#124

Post by berkes »

mike_hearn wrote: post #121
berkes wrote: post #78

Earlier quoted context omitted.

> 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. 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 in…

Sure, if you're willing to write a renderer for something that looks like HTML but isn't then that's a lot more tractable. But at that point why not just do something better than HTML? Most of the effort is in the engine anyway.

> something that looks like HTML

This is surprisingly easy. Because the "this is HTML" is both vague and limited. HTML5 is remarkably vague and permissive.

Also, HTML has nothing to do with CSS nor with JS, nor with any DOM apis and not even with how stuff has to be rendered or if it has to be rendered at all.

There are numerous libraries and projects that can parse the WHATWG version of HTML. I'm not saying these are trivial or simple. But far simpler than a full rendering engine will ever be.

Re: Web Browser Engineering (2021)

#125

Post by wmanley »

wmanley wrote: post #14
_benj wrote: post #9

It is so exciting to see material like this being made! Browsers seem like mysterious, undecipherable black boxes, which is very likely how G wants them to be perceived, but that is cracking by seeing the efforts/results of such projects like ladybird and others! I hope to one day be able to jump in and contribute to break that moat! And this books looks like an amazing start!

> I hope to one day be able to jump in and contribute to break that moat! The moat isn't caused by a lack of non-chrome browser engines, it's because so few people use a non-chrome browser engine. Firefox already exists - it's just that ~no-one uses it and for websites that don't work with it those users have learnt to just open up chrome. I'd love for the moat to be broken, and contributing to a browser engine like…

To clarify: My point is not that Firefox sucks, my point is that Firefox is great - better at handling the web than these new other web-browser engines will be for a long time, and yet it still hasn't broken the moat. It's not enough to make a great non-chrome web-browser - we already have one. It wouldn't make any difference toward that goal if we had 4 of them.

What is needed to break the moat are users - and enough for website operators to care. This is what Apple/Safari has. This is what Firefox increasingly lacks.

For and for that someone will have to do something other than make a great browser.

Re: Web Browser Engineering (2021)

#126

Post by RodgerTheGreat »

amjoshuamichael wrote: post #97
pmarreck wrote: post #42

Earlier quoted context omitted.

Or perhaps an entirely new platform/protocol, since this one is completely saturated with complexity at this point.

I keep coming back to this idea as the (albeit ideal) future of the web. HTML keeps morphing and changing to fit the increasingly complex requirements of modern web apps. I mean the W3C spec is 114 million words (1). I think that web apps as a concept are a good idea, but I just can't believe that HTML/CSS/JS are the best technologies to fill that out. I'd love to see someone tackle a new, "micro-sized app format", w…

For the record, Decker uses a 4-bit palette configured from a 24-bit gamut: http://beyondloom.com/decker/color.html

Reflowing UIs to suit varying aspect ratios is a challenging puzzle that Decker presently doesn't touch, though I do have some ideas for the future. If decks were embedded as inline "applets" of interactive content within a fluid document container (markdown, gemtext, etc) I think reflow would be considerably less important.

Re: Web Browser Engineering (2021)

#127

Post by peoplefromibiza »

PaulDavisThe1st wrote: post #67
vbezhenar wrote: post #45

Earlier quoted context omitted.

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.

Actually, almost every GUI toolkit's scheme for layout has issues, and none of them are perfect. The ones that use absolute pixel positioning fail when using different resolution displays. The ones that use box packing fail when you need to deal with different sized displays. The ones that use constraint programming fail when you need to layout hundreds or thousands of widgets. CSS-style layout has its own pros and c…

possibly, but videogames have been doing layout for ages without CSS and they can vary a lot from game to game while most desktop applications have basically the same 2-3 layouts: input and edit some text, fill in some form, display some data in a table, a tree or a chart

Re: Web Browser Engineering (2021)

#128

Post by afavour »

pstrateman wrote: post #99
afavour wrote: post #50

Earlier quoted context omitted.

> not usefully true with most videos on the web today > The only time video is fully hardware decoded is when it's a simple video element to a static video file. These seem in disagreement to me. The vast majority of videos on the web are simple video elements going to static video files. It is not usual for each frame to pass through JavaScript before being displayed.

Most of the things you think of as static video files (say youtube) are actually video segments operating more or less exactly the way live streams work.

Yes, I know. But the frames still aren't passed through JavaScript.

Re: Web Browser Engineering (2021)

#129

Post by RodgerTheGreat »

pmarreck wrote: post #42
currygen wrote: post #24

It'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.

Or perhaps an entirely new platform/protocol, since this one is completely saturated with complexity at this point.

I think multiple smaller formats and protocols would be a better approach than one big new standard, and we already have lots of simple, broadly-supported options to choose from.

There's nothing to say that a Gemini browser (for example) can't choose to display gemtext links to other resources inline; images are a natural choice, but imagine a browser displaying CSV files as nice inline tables with standard affordances like sorting and line highlighting. No special browser support? No problem; lots of tools can work with CSV, and it's not completely unusable when displayed as raw text.

Some things don't currently have great options. We desperately need a standardized vector image format that doesn't have the cancerous complexity of SVG or EPS. A rich, declarative format for describing forms and their validation could be handy. Perhaps a simple self-contained format for interactive visualizations and games, like a stripped-down equivalent of Flash? (I have some ideas there.) As long as new formats are designed to degrade as gracefully as possible without special support and the means of composing formats is flexible enough, an ecosystem as a whole can grow and evolve while each component remains simple enough for one person to understand.

The present web and our universe of broadly supported technologies is very close to this ideal, if developers had a bit more restraint.

Re: Web Browser Engineering (2021)

#130

Post by userbinator »

pavpanchekha wrote: post #64
tannhaeuser wrote: post #63

Earlier 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.

Since you're still working on it, have you considered this edge-case with floats: if a float is added long after the last breakpoint, and the current line grows long enough that it (with the float) reaches the right edge, do you take that breakpoint (and thus the float that came after moves to the next line due to the rule that a float cannot be put higher than its occurrence in the flow), or "defer" the float to the next line, freeing more space on the current line? All the browsers I've tested recently seem to do the former, but if you read the CSS rules for floats carefully, the rule that says floats are to be placed as high as possible suggests that deferring the current float, and thus possibly allowing more content on the current line, may result in future floats being higher than if the current float was not deferred, despite the current float ending up at the same height.
Post reply on HN