There are dozens of these "browser shells" that just change the UI and nothing about the core rendering engine itself.
So called "lightweight" browsers based on webkit appear every now and then (uzbl, vimprobable, xombrero, etc), and all of them are useless. They us WebKit, which means around the same amount of bloat as Chome and Safari, except with a different interface. And even those that attempt at being small, like Dillo or NetSurf, are far from it.

That's why we need a new browser, one that isn't controlled by some large organisation, one which is compatible enough to view most information-oriented sites, maybe even some app-sites like YouTube or Fecesbook. Then figure out how to market it so that it appeals to the masses, making it spread widely. Encourage forks and customisations (it should be public-domain), so we might have several dozen different versions all based around the same core, but with subtly different UIs, extra features, etc.
This will be what can start the revolution - when the "web developers" realise that almost everyone's browser is slightly different, and that everyone likes their version because of their differences and is unwilling to change, hopefully this will make them more focused on content instead of styling, reduce unnecessary use of features for the sake of using them, and lead to a more accessible Internet for all.
Chrome gained marketshare because it was faster, easier to use in some ways, and still displayed existing pages well. What will be the "killer feature(s)" of The Next Browser? Being smaller and faster, completely pubic-domain and open-source, and easy-to-use but also powerful UI is what I'm thinking of.

A browser that doesn't handle at least most of HTML5 and JS won't be so interesting even if it's much less bloated, because most people will just see it as something like a theoretical exercise. A browser that can work with most websites out there now, including the JS-heavy stuff, on par with other major browsers like FF and Chrome, but also much smaller and more flexible, will get noticed. This is not about finding better protocols and web standards but about better implementations of them. I'm more interested in redefining attitudes towards software complexity and engineering than reinventing the Internet, by taking a relatively complex standard and making a simple implementation of it. HTML/CSS/JS is complex but my main argument is that complexity is far less than what contemporary implementations lead one to believe. Or perhaps that complexity is just from attempting to handle edge-cases that are not at all important in reality. What I'm aiming at is 1MB for HTML5 + CSS2.1 (maybe some of 3, we'll see) + ECMAScript 5.1.
This isn't like NetSurf or Dillo or any of the other original browsers out there - it's going to be far smaller than anything else, but at the same time more featured and compatible with more websites. It's designed to be the simplest thing that can possibly work.
This is also going to be the web browser that puts YOU in control. Per-site/per-domain/per-path settings for security and privacy; a UI that doesn't treat users like idiots by hiding everything; total control over JS execution environment and rendered page contents (although I don't really want to turn it into a full interactive HTML editor); choose what plugins you want to run on which pages, and what they can do.

The core of the complexity is the HTML/CSS rendering engine. HTTP and everything else is auxiliary, so you can use what's existing. Most OSs will have a network and graphics stack.
JS actually takes up the bulk of the bloat. It is automatic memory management which means it MUST use some sort of garbage collection. You can still keep memory usage sane by implementing exponential collection strategy: start off with a small limit like 1MB. Once memory usage hits 1MB, run GC. You should have free space left over. If you don't, then double the limit to 2MB and allocate. Keep going until 4MB gets filled up, then run GC. If memory usage drops below 1/4 the current limit after any GC run then shrink (release memory back to OS).
I was thinking of mark-compact:
http://en.wikipedia.org/wiki/Mark-compact_algorithm
This allows constant-time allocations and doesn't waste half the memory doing so. Essentially the heap becomes a huge dynamic array that gets resized in amortized constant time.
Rendering a document is overall a complex task, but if you can consider all that complexity in large pieces, and condense them into a simple algorithm, then the code does not need to be complex. In contrast with the traditional notion of breaking problems into simpler pieces and then combining them together to create a more complex whole, I'm taking complex pieces of the problem and combining them together to create a simple whole. It's somewhat like procedural generation in the demoscene.

Random idea time... configurable relayout/repaint intervals.
Those pages full of blingy animated shit are horrible for power consumption because the browser is forced to constantly relayout/repaint stuff. There's even whole JS libraries to batch DOM updates to avoid this for the stupid apps that can't do it right themselves...
How about the browser itself throttling things - you don't need to compute and repaint as fast as the scripts are trying to make the browser do, and since up to ~100ms is not so noticeable, by default script-driven repaint intervals could be limited to one every 100ms. Those wanking "web designers" aren't going to like this since it makes animations look jerky, but who gives a shit... that's why this should be configurable - if you really, really want to play some inane JS game or something else that needs ultra-fast repaints, then you can turn it up (and see that your power consumption goes up, and battery life goes down as a result.)
Ditto for "smooth scrolling" (one of the worst ideas ever conceived) - unless I'm grabbing a scrollbar and dragging it, I'm not scrolling one pixel at a time, so why the fuck do they think I want to see the window repainted every time it scrolls 1 goddamn pixel!? If I'm scrolling by 10 pixels then just move the existing content by 10 pixels and repaint that 10-pixel gap. What a ridiculous waste of (GPU mostly) power.
(I could rant on and on about the idiotic trend of making UI elements behave like physical objects - with the exception of "inertial scrolling" which is genuinely useful on a touchscreen but only without that annoying "bounce-back" or "friction" - but that's not so browser-related....)

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.

For anyone here, please ignore W3C. They are asshats. WHATWG is doing proper standardizations since '04.

Leave this for the professionals.

Do you know any professional FASM programmer working on this?
I'm not sure I understand what you are trying to say.

It's too big a task to keep the browser safe. It takes an incredible amount of effort to find and eliminate security holes. To code a browser in assembly would probably make it even more unsecure than other browsers. By the time the browser is in beta phase, you probably have to run it sandboxed anyway, and that eliminated all the benefits of it.

I don't know any FASM programmers working on it. But if you're interested in becoming part of a game project, I could need some help. Are you interested in game programming? I need a graphics artist, primarily for creating seamless tiles. I will be the master of the game engine, because I'm a technical guy and understand things that other people don't have a clue about.

What kind of game do you want to create?

We could do an open source variant of Warcraft II? Or perhaps a good lemmings game for windows.

Hey, PeExecutable!

I see you have problems in creating graphics for your game... But what about sounds? That is another problem I have. All games I made so far was all mute and this is a bit strange.

I have difficulties for creating graphics and sound. Those were the main reasons I stopped learning how to make games.

If you have solutions to the problems I described above, please let me know.

P.S. Do not suggest to steal graphics and sounds from other games... This is illegal in most cases and not fun at all.

Thank you!

The Mozilla company gets/need more than 100 million US$ from sponsors every year. I think the sponsors wouldn't pay so much if the company wouldn't need so much money.
I guess more than 1000 employees are working on the browser.

Companies never have enough money. The more they get, the more they will spend/invest and that is how they grow.

And I bet Mozilla has grown a lot these past years... It seems at least.

Just my opinion. I am not sure.

Best associative data structure for element attributes and CSS properties? There's only a few hundred of the standard ones in total, but they'll be retrieved very often, especially the CSS ones.

Hash tables and fixed arrays are the fastest but most memory-bloating, trees are sort of in the middle, and resizeable arrays and linked lists are O(n) (probably n < 10 for elements and < 100 for CSS most of the time) but smallest.

More disturbingly: Why doesn't there seem to be any information on the time complexities of various operations like attribute lookup in existing browsers!? Nobody cares to take the time to measure it?

That explains why web apps are so fucking slow... and I hate reading source code because it looks like the shit in >>1. But here, for probably the first time on the public Web, is the complexities of attribute storage in the most common browser engines.

WebKit:
https://github.com/WebKit/webkit/blob/master/Source/WebCore/dom/Element.cpp

A resizable array of unsorted(!) structures. Funny that elements themselves don't have attributes, but a secondary element->attribute hash table is used. Code is disturbingly verbose; just count how many function calls you have to go through from setAttribute to when the thing actually gets written to the array. The resizeable array itself is a bloody verbose mess too:

https://github.com/WebKit/webkit/blob/master/Source/WTF/wtf/Vector.h

Gecko:
https://hg.mozilla.org/mozilla-central/file/eab21ec484bb/dom/base/FragmentOrElement.h

One resizeable, unsorted array in each element that holds both children and attributes, with a bit of weird hashtable-like hybrid thing:

https://hg.mozilla.org/mozilla-central/file/eab21ec484bb/dom/base/nsAttrAndChildArray.cpp

Code feels a bit less verbose and is more readable than WebKit.

Trident (version used in IE4, no public link to source available):

Resizeable unsorted array allocated off end of element structure.

NetSurf:

Doubly-linked, doubly-indirect(!) unsorted list.

Dillo:

No attributes stored in element structure itself! Reparses the markup for every attribute retrieval operation. :facepalm:

tl;dr: O(n) except for Gecko which may be O(1) for some cases ("mapped attributes".)

I'm thinking about an unsorted parallel array for our FASM browser; it's probably not going to be worse than what's out there already (especially those "lightweight" browsers at the end) and likely slightly better cache-wise to use parallel arrays than arrays of structures.

The calculator is your friend here. You have to have a clear picture of how much graphics and sound you need, and then make a calculation how long it will take to create that artwork. If the time required is too long, you have to steal it from someone else.

If you need to steal sound, you can "mutate" the sound if you have a sound editing program. It basically creates a new variation of the old sound clip, so that it can't be recognized anymore, so nobody can sue you over their work.

If you need simple game sounds you can also use bfxr, it's a game sound creation software out there, it creates sounds automatically for you.

I also recommend Audacity to edit and convert sounds.

But I highly recommend creating the game engine first and put temporary "holders" where the real graphics is to be placed. For example, if you need tiles for your game, create temporary tiles in a paint program that temporary "fills in" the place where the real graphics will be placed. If you create temporary graphics, you can complete the engine without any real graphics, and when the game is done you have a lot less to worry about.

If you need an animated sea tile, create 4 temporary tiles in paint with a straight blue background and some text, text on first tile "Sea 1", text on tile 2 "Sea 2", when it animates you'll see a blue tile with sea 1-2-3-4 animating in the game. Use it as a temporary holder for the real graphics that comes at a later point. Not only is this easy to do but it also helps you identify that the engine is working correctly, when tiles have some text and numbers, you can identify that they animate in correct order and that everything is working properly.

Nothing is more disturbing than doing 3 hours of coding, 3 hours of photoshop, 3 hours of sound editing. Finish the engine first, and when that part is done, and when you can focus 100% on the graphical part, you'll find that part fun and straight forward.

So you like to steal people's code? Ahahaha

Doesn't M$ and Google do the same ?

How can one even conceptually "steal" code. At the most it must be copying or using code.

In older days when people played games on older computers, all the kids copied other games with a cassette recorder, they were all young and very kind people, they knew instinctively that copying a game wasn't really morally wrong. They had a clue that someone said it was wrong, but they couldn't feel remorse, as young and as kind these kids were, they just couldn't find the remorse or the understanding of the wrongdoings.

When they were not using their computers, they were helping the elders with shopping lists and doing other kind stuff.

The lack of remorse in those kids may be a sign of "sharing is a good trait in humanity", eventually they were taught not to share anymore and the inhumane were born.

"You'll go to hell if you share this with anyone" was what the commercial guy said. Commerce above humanity.

"Not even if you pay me, can you share this with anyone" - said the commercial guy.

One thing I love about commercial software, is that they offer, what you probably know as "Gift certificate". You can buy a certificate and give it to someone else and they can buy a game based on that ticket.

But the same companies are totally against giving or sharing the software as a gift to your friend. The concept of "gifts" have also been turned upside down, into something inhumane.

They are for gifts but also against gifts.

It doesn't stop until all the good traits in humanity has been turned upside down, in favor of their own bank account. The most immorale people of all time, is trying to convince good people that they have none.

If there are anyone in the world who is a complete thief and a robber, it must be the top chief of a software company. No idea is original, the ideas are mutations based on the early pioneers, the code is done by anyone but themselves, all the pseudo c code is based on what the underlying assembler can produce and on the knowledge of those who designed the assembler. Everything is a really a theft, nothing is original.

The commercial guys may respond "Well, we paid for the compiler, so we have earned what the underlying assembler outputs for us". And he forgets that those who designed the compiler also had stolen the knowledge about assembly from someone else.

The only trait that keeps humanity together, is that we copy one anothers behaviors so that we become "one" organism. But there are viruses inside that organism that now says that copying is bad, little do they know that everything is a copy and must be a copy.

The value of a product is measured in the simplicity that it can be duplicated. If it can be duplicated very easily, it has little value. But some people artificially implement a value into it by restrictions based on immorale principles.

I am new to the forum, but what's up with you discussing a game on this thread?
That's completely off-topic.

ncdr, tell us your thoughts on the new browser, articulated in a more general way than all the technical details. Sum up its features in a table or in a numeric list.

First and foremost, what's needed is the basics.
- HTML parser/DOM generation
- CSS parser
- CSS box generation and attribute computation
- Renderer
- Network/UI/Misc

Only then we can talk about other stuff.

Have you begun with any of those things yet? It would be wise to at least create a functioning basic library for those things you mentioned and make sure they are rock solid and robust.

Can you make another list where you sum up the points where this browser will differ from other browsers? Primarily the major differences. Will everything be assembly?

Can you list up some countermeasures that will be taken to prevent malicious remote execution, will flash be banned from the browser?

If you don't mind creating a list of security proposals.

Will it be a browser for mobile devices too? I suppose there is no name for the browser yet? Will there be a possibility to add extensions and will it support skinning? Is it a pure browser or will it have an integrated e-mail client? Tell more about your thoughts.

Also, will it support command line?

What is the main thing, the center point of the browser that will make it "shine better" or stand out from other browsers?

Will it be open source? Who will be in charge of the servers that provides updates, are there plans to create a fund for the browser?

Will there be a response group who are ready to quickly solve security issues when they are discovered, who will be in charge of everything.

There is a lot of questions that needs to be answered before you begin with the browser, it's the minimum requirement that you have the answers.

Problem begins if the questions that needs to be answered is unknown. If you don't know the questions, everything just collapses. You have to make a plan, a very solid plan and present the plan. If there is no plan there is no browser.

PeExecutable
It appears to me you like to talk the talk.

Some people just want to inspire others but they don't want to do anything about it. I could visit the ferrari forum and tell them all about what could make a beautiful "next" ferrari, but it adds approximately nothing to the overall plan how to achieve that, and that is what many people don't seem to get. It's not enough to be inspirational, it takes incredible effort to only come up with the plan. It matters not how many ideas and how inspirational one is, you HAVE to come up with the plan, no plan - no browser. I'm trying to get people to come down to a realistic level. People have too high confidence. Too high.

Let's be realistic here. There is a guy who have ideas for a new browser, I don't know who he think is going to code it, but if he hopes to recruit someone from this forum, I think they would at least want to have a full working plan before they do the dirty work. And it better be a very good plan, because the dirty workers don't want to spend time thinking about the fallacies in that plan, they just want to code.

And I do have to say, it was inspiring to read the ideas that showed up, tell us more.

It should be, this is an assembler forum. But it rarely happens anyway.

If I am mistaken please let me know.

Thank you!