Why browsers are bloated

https://github.com/WebKit/webkit/blob/master/Source/WebCore/platform/Scrollbar.cpp
https://github.com/WebKit/webkit/blob/master/Source/WebCore/platform/win/ScrollbarThemeWin.cpp
Let's reinvent the fucking scrollbar, which every goddamn platform with a UI already has, and make it behave subtly different from the native one!

Right-click a native scrollbar in some other app:
- Scroll Here
- Top
- Bottom
- Page Up
- Page Down
- Scroll Up
- Scroll Down

Right-click a scrollbar in Chrome:
- Back
- Forward
- Reload
- Save As...
...

Right-click a scrollbar in Firefox and Opera:
Absolutely fucking nothing happens!

What the fuck!? How did these terminally retarded idiots get involved in creating one of the most important pieces of software to the average user?

>>107
Yes, removal of features from one place and insertion of them in another place where they make more sense. The tokeniser doesn't need to parse the fields within a DOCTYPE, it just needs to figure out where the end of the tag is, which is really easy (but you wouldn't know just by reading the spec) - scan to the next '>'. The fields within it can be parsed at some later point, perhaps even in a different thread. The DOCTYPE is only used for an edge-case quirks-mode parsing decision but the way that's detected in the spec is ridiculously bloated (see http://www.w3.org/TR/html5/syntax.html#the-initial-insertion-mode; all those string constants are bigger than the whole tokeniser I have), so I'll probably end up just defaulting to quirks-mode off and letting the user push a button to toggle it if she feels the page doesn't look right...

Character references (< &nbsp etc.) are another thing the spec tries to put into the tokeniser, but once again it's not necssary to parse them at this point to determine the boundaries between various pieces. Charref conversion can be done when strings get copied out of the input buffer and into the DOM.

>>108
2/3rds Rust and almost 1/3... Python!? The code I glanced at there doesn't look much simpler. Browsers are bloated because the whole thing is bloated. The HTML parser there contains a tokeniser...

https://github.com/servo/libhubbub/blob/master/src/tokeniser/tokeniser.c

...which is a pretty horrific 3kline+ piece of code, much of it duplicated, considering it came from one of the more "lightweight" browsers - NetSurf. On the other hand, Dillo's HTML parser (entire parser, tokeniser is integrated, around 4.1klines) is quite a bit nicer, although I don't know how HTML5-compliant it is:

http://hg.dillo.org/dillo/file/tip/src/html.cc