3 ms·

I wrote an HTML parser while waiting for Firefox to build once, it didn't take a ton to turn it into a minimal browser. Web browsers are hard when they have to

by swiley 5y ago

I wrote an HTML parser while waiting for Firefox to build once, it didn't take a ton to turn it into a minimal browser. Web browsers are hard when they have to be an application runtime instead of a document viewer, HTML grammar is easy.

pfalcon 5y ago
HTML parser is trivial. There's a huge difference between HTML parser and HTML rendering engine. "A minimal browser" which you allegedly wrote isn't something you or anyone else does, or would, use.
- swiley 5y ago
  I didn't "allegedly" write it, it's on my github. Yeah it doesn't do box model layout but (and this was my point) that's not as big a deal without js because the pages are still perfectly usable.
  - arp242 5y ago
    I wrote a toy browser in a weekend too; I just used an existing HTML and CSS parser. The hard part isn't the HTML parsing, that's pretty easy and mostly just basic lexing/parsing stuff. It's applying the CSS to the HTML and rendering a document that vaguely looks right. There are loads of different interactions, and even Firefox and Chrome actually get it wrong in many edge cases (and also frequently in not-so-edge cases). I wrote a list some time ago of all the interactions "position: sticky" breaks in Firefox, and there's loads of them (I can't find that list now though, it was a HN comment from last year). It was pretty basic stuff like z-index, tables, flexbox, etc. Nothing too obscure. If a lot of the cruft would be removed then actually, it probably wouldn't be so bad. But you know, compatibility and such. Still, a <link rel="newstylesheet" href="style.newcss"> probably wouldn't be such a bad idea. The base CSS specification can probably be reduced by half if not more, both by removing cruft and by learning from mistakes.
  - leephillips 5y ago
    Point taken, but you probably know that some pages will not be usable in a browser that does not implement CSS. As in, completely unreadable.
    - yborg 5y ago
      There are a great many pages that are not usable on a browser that does not implement JS. None of these things are "hypertext" anymore, the original idea was that all web locations would fall back to simple text rendering of the content, the fact that much of the modern web can't be read on a base HTML renderer is more of a statement of what a website is now - an application server.
minitech 5y ago
I don’t agree that HTML grammar is easy, but either way it’s objectively more complicated than Gemini markup. I also don’t agree that web layout is easy. Dillo, for example, is not the best document-viewing experience (even when I’ve designed for it specifically) despite putting in much more effort than I’d be willing to. Also, if this[1] is your HTML parser, it doesn’t look like an actual HTML parser with implicit tags and error correction, just a parser for some easy subset of HTML. If we’re not going to be web-compatible anyway, why not spec a language that’s actually good? [1] https://github.com/s2607/webthing/blob/d6dd43aa5a3cc6dee15f8046ef7dd0d67eaa3c1e/html.c https://github.com/s2607/webthing/blob/d6dd43aa5a3cc6dee15f8...

by swiley 5y ago

pfalcon 5y ago

HTML parser is trivial. There's a huge difference between HTML parser and HTML rendering engine. "A minimal browser" which you allegedly wrote isn't something you or anyone else does, or would, use.

swiley 5y ago
I didn't "allegedly" write it, it's on my github. Yeah it doesn't do box model layout but (and this was my point) that's not as big a deal without js because the pages are still perfectly usable.
- arp242 5y ago
  I wrote a toy browser in a weekend too; I just used an existing HTML and CSS parser. The hard part isn't the HTML parsing, that's pretty easy and mostly just basic lexing/parsing stuff. It's applying the CSS to the HTML and rendering a document that vaguely looks right. There are loads of different interactions, and even Firefox and Chrome actually get it wrong in many edge cases (and also frequently in not-so-edge cases). I wrote a list some time ago of all the interactions "position: sticky" breaks in Firefox, and there's loads of them (I can't find that list now though, it was a HN comment from last year). It was pretty basic stuff like z-index, tables, flexbox, etc. Nothing too obscure. If a lot of the cruft would be removed then actually, it probably wouldn't be so bad. But you know, compatibility and such. Still, a <link rel="newstylesheet" href="style.newcss"> probably wouldn't be such a bad idea. The base CSS specification can probably be reduced by half if not more, both by removing cruft and by learning from mistakes.
- leephillips 5y ago
  Point taken, but you probably know that some pages will not be usable in a browser that does not implement CSS. As in, completely unreadable.
  - yborg 5y ago
    There are a great many pages that are not usable on a browser that does not implement JS. None of these things are "hypertext" anymore, the original idea was that all web locations would fall back to simple text rendering of the content, the fact that much of the modern web can't be read on a base HTML renderer is more of a statement of what a website is now - an application server.

minitech 5y ago

I don’t agree that HTML grammar is easy, but either way it’s objectively more complicated than Gemini markup. I also don’t agree that web layout is easy. Dillo, for example, is not the best document-viewing experience (even when I’ve designed for it specifically) despite putting in much more effort than I’d be willing to. Also, if this[1] is your HTML parser, it doesn’t look like an actual HTML parser with implicit tags and error correction, just a parser for some easy subset of HTML. If we’re not going to be web-compatible anyway, why not spec a language that’s actually good? [1] https://github.com/s2607/webthing/blob/d6dd43aa5a3cc6dee15f8046ef7dd0d67eaa3c1e/html.c https://github.com/s2607/webthing/blob/d6dd43aa5a3cc6dee15f8...