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?

>>559

Does anyone find it funny that the CSS parser may end up being larger than the HTML one...?

No, I find it said.

>>560,561
No detailed syntax spec for CSS2.1 at all; it's just a lex/yacc (more like yucck) grammar and some descriptive prose:

http://www.w3.org/TR/CSS21/grammar.html

I might end up combining/simplifying what I can from the two specs and end up with something CSS2.5-ish.

>>559
No it's not. HTML is a matter of document markup. CSS is about the visual elements of the HTML document. It makes sense to me that your CSS parser is larger because it will need to deal with a larger set of possible inputs.

>>563

it will need to deal with a larger set of possible inputs.

Both are countably infinite. What's you're point?

>>564
That's not what I meant by possible inputs. This is what I meant. http://www.w3.org/TR/CSS/

lol man stop stroking cudder's fucking ego we all know "why browsers are bloated" is like a fucking fairy tale on tihs shitty board, no1 gives a fuck

>>566
Fairy tales can be very real when you have 2Gb of ram

>>566
Fairy tales can be very real when you have 2Gb of ram

Why in god's name does anyone write sepples,just WHY

>>569
It's much easier to write generic code and do heavy code composition in C++ than in C.

>>570
Well C is useless shit, so what? Why choose a pain-in-the-ass BDSM shit then?

>>570

generic code

Shitty version of macros. Use a Lisp (or roll your own, you dumb nigger) if you want to do wizard like things with your code.

heavy code composition

wat? googled that and got some bullshit about OOP. fuckin normalfag

>>570
I wouldn't argue that the latter is of actual benefit to anyone. Deep composition isn't abstraction, it's obfuscation, and any language that actively encourages it is creating more problems than it sets out to solve.

“newnewnewcss”, the port of Servo to the recently refactored rust-cssparser, has landed: https://github.com/servo/servo/pull/4689

Please let me know if you find any regression.

If you’re writing or modifying CSS parsing code in Servo (e.g. adding a new CSS property), you should be aware of and follow the conventions documented here:

http://servo.github.io/rust-cssparser/cssparser/index.html

Previously, parsing was based on "component values" that were either tokens, or blocks/function that contained a vector of more component values, forming a tree. Parsing functions would take a `&ComponentValue` or `&[ComponentValue]` parameter as their input.

Now the input is represented by a `&mut Parser` that tracks its own position within the input and yields tokens. When encountering a function token on block-opening token, you can get another `Parser` object for the arguments/contents. Otherwise the block is just skipped. Alternatives can be expressed by saving and restoring the internal state of the parser. (This is cheap, just copying 16 bytes. However some tokenization work may be duplicated.) Everything relies heavily on `Result<_, ()>` types and the `try!` macro (which returns early on `Err`) to make the code easier to read and maintain. (For what it’s worth, the diff stat is +1,949/-2,319 lines.)

Finally, string components of tokens now use the `CowString` type to borrow from the input when possible and avoid many allocations and lots of copying.

>>574
Wow that is an impressive design change. Ok, it sounds like the old design was pretty crap. But the new design is good.

>>576
Terrible!

What about links' engine, Cudder?
http://links.twibright.com/download/links-2.9.tar.gz

>>573
Code composition and generic programming (in C++ and Java) have benefited me over the years. In the industries that I've worked in (I've been working for 18 years now), I've noted various patterns in data structures and algorithms for the class of business operations that I've experienced. One of the reasons that I'm effective at delivering my work is because I reuse and repurpose the same old generic modules I've already written in the past (for the code that's copyrighted to me). I don't know why you consider abstraction as obfuscation because I always deliver a comprehensive set of software system models that model the different parts of the system. Everybody with half a brain can look at my models and comprehend how my system works.

>>578
Spare us the elevator speech about your
SCALABLE TURNKEY ENTERPRISE SOLUTIONS
please.

Design attributes that are unique to C++ are not good, and good design attributes are not unique to C++. You can compose abstract data structures in C too, if you really need it. The fact that you don't usually need it is not an indictment.

>>579
I would just gently remind you that any language without generics is useless.
C is a language without generics.

>>580
I wonder how we coped before Bjarne came along and saved the world.

>>580
It is with generics now, if your compiler supports _Generic
thats how how i implemented type-agnostic,variadic fprintf in a single macro(p(...))

>>581
Generic programming was pioneered by Ada, not by this retard.

>>583
Yes, exactly. I was mocking >>578 who was dick-waving about

generic programming (in C++ and Java)

>>581
Stepanov added templates and STL to Sepples, not Bjarne. Americans are not smart enough for those kinds of things. Even Ada was created by the French.

>>582
Wow, there's even a library based on it. Probably a pain to use, but it's still a commendable effort to make C at least a little useful.
http://sglib.sourceforge.net/

>>574
I don't know Rust so I can't examine this in detail, but...

When encountering a function token on block-opening token, you can get another `Parser` object for the arguments/contents.

I'm pretty sure you don't need to create another bloody object for that.

This is cheap, just copying 16 bytes. However some tokenization work may be duplicated.)

Tokenisation is almost certainly going to take far more time than "just copying 16 bytes" so duplicating work is definitely a BAD idea here.

Finally, string components of tokens now use the `CowString` type to borrow from the input when possible and avoid many allocations and lots of copying.

This is a good thing.

>>586
Looks like what OpenSSL does.

>>580-581
You can fake templating in the preprocessor if you really need it. It's ugly and I won't defend it except where it's absolutely necessary, but it is possible. The need to write generic code arises comparatively rarely in C (struct composition and private void pointers go a long way) so the situation isn't as dire as people coming from languages with generics in their standard libraries might think.

>>585

Stepanov added templates and STL to Sepples, not Bjarne. Americans are not smart enough for those kinds of things.

Are you insinuating that Bjarne is American?

IT'S BEEN A LONG TIME SINCE WE TALKED ABOUT THIS

*puts on bampu pantsu*

https://bugzilla.mozilla.org/show_bug.cgi?id=77790

>>591

2001-04-26 14:57:30 PDT

How nice

>>591

IMHO, no aspect of the page should be left out of the developer's control.

There's only one sane response to that: FUCK YOU.

>>589
What, he isn't? He's definitely retarded enough to be an American.

1990: Named one of "America's twelve top young scientists" by Fortune Magazine.

>>591
Oh wow. The entitlement of some people astounds me.

I feel worse for having read all that. Imagine how Moz devs must feel.

Time to look at CSS parsing/tokenising again in more detail...

http://dev.w3.org/csswg/css-syntax/#tokenization

What a mess... no reason I can see for "colon-token", "semicolon-token", and "comma-token", amongst others, to be separated out, when they could've just put them in with "delim-token". Ditto for "whitespace" since it get skipped over anyway - no sense in pushing that up to the parser. This needs to be transformed into a more usable set of states first.

>>596
Just admit you're never finishing your browser, so we can continue with the Cudder is all talk and no action epic meme instead of complaining about the W3C.

ｄｅｌ

>>596
Nice job on polishing a turd, Cudder.

You fuckers should stop wasting so much energy on ``improving'' the HTML/CSS shit and create something half-reasonable instead.

>>599
We should at least have a reasonable implementation of the shitty standard so we can access services that use it with secure software.