I feel like we all know that HTML/CSS is the greatest way to represent a GUI. With how many existing libraries there are with almost any type of controls you could ask for, how could it not be (in my view). So given that I'm shocked as the lack of good HTML/CSS game libraries that exist. It makes no sense. Can someone talk about why HTML/CSS has been so slow to migrate to the game GUI space? It seems like a perfect fit and some have tried (librocket) but are just poorly implemented (interfacing is a nightmare).

? This is the Lunge right? Just expressing views to see if I get reactions/ideas/thoughts about the topic.

It's interesting to get other views on this.

HTML/CSS is very flexible and allows the ability to do a ton of things. Millions of people also know it so finding resources to work with it is very easy and cheap. There are also thousands of libraries already available ready to use where you can see the source for all of them.

I don't want to have a crappy HTML renderer bloating my game code.

I think this is debatable on it bloating your code itself. When making a game you'll have a lot of libraries "bloating" your code so not sure why you would see this as any different. If anything the separation has many benefits.

What exactly is the advantage of using HTML over other options? What does it gain me over, say, an xml driven windowing/button system?

Some of the things I've stated above show some advantages but for me the biggest one is that HTML/CSS is well established. It's not going anywhere anytime soon and will evolve for decades to come. It has a huge backing and following where as any custom xml driven windowing system just doesn't have that. Even xaml which was created by MS is much more likely to die out over HTML/CSS in the future. On top of that all rendering is done for you. Maybe some people enjoy making GUI's, but the bottom line is if you are trying to make a game and the gameplay is what matters to you the most, you just need a GUI that is reliable, flexible, has longevity, and has a ton of backing. To me HTML/CSS rules in all of those spaces. That's my view on it.

http://www.awesomium.com/ looks interesting. I'll have to dig deeper to see if it's as bad as librocket though.

Modern HTML/CSS is quite resource intensive which makes it unsuitable for game GUIs

What seems interesting with awesomium is that it seems to run on it's own process so should have no impact on our games process. That would for sure be required. Also, I think we'd have to look at what is really in a game gui. They aren't exactly all that complicated the majority of the time. I know some games try to get cute with them but most games are pretty easy going with the gui itself. I wonder how taxing an average game gui would really be.

I think this is debatable on it bloating your code itself. When making a game you'll have a lot of libraries "bloating" your code so not sure why you would see this as any different. If anything the separation has many benefits.

We were forced to use it (via webkit) on a title for corporate reasons, against the will of everyone on the team including team leads. This was on a game console.

Corporate heads demanded that everyone use the same web-based interface to log in to the system, displaying all the HTML and graphics and scripts and style sheets, because they wanted a uniform player experience across all platforms. Once we were fully authenticated and had our security tokens we could use different systems, but the initial login, password recovery, legal screens, and support items needed to use the web interface. (After a few years they backed off on the stupid requirement.)

The initial setup for webkit, both to run all the parts and display the pages, took about half our RAM on the console.

We were able to trim it down and unloaded it at all times except for when the person needed the browser for the corporate login and account management screens. Obviously we couldn't do anything game-related while the web UI was showing, they could either use the web interface or play the game, never both.

Most people underestimate what a web browser does, and the requirements for it.

It provides a complete graphical OS driven by memory-hungry text -- an uncompiled, uncompressed, low-density blob of data that uses a highly redundant markup language. Images are not in a device-friendly format so they need to be read completely, processed, and expanded into card-friendly formats. The text resources are loaded a first time as text, compiled and interpreted on the fly, then converted into programs and visual resources, then run though a layout engine. Finally all the parts are rendered.

And it isn't just text. There are multiple versions of CSS, multiple editions of HTML and XHTML, several historic DOM configurations, JavaScript virtual machines and JIT compilers, support for a long list of graphics formats both bitmap and vector, security components, networking components, and even local storage.

All the time this is going on, the massive web browser is competing for resources. Not only does it consume a large percentage of RAM, it dilutes the usable space of your caches, in turn causing performance to plummet. It fights for CPU time to run the virtual machine. Repeat for most of the regular bottlenecks, reducing what is available for your core product.

The enormous amount of resources required for a full web interface is a big reason why it normally should not be used. Yes, it can potentially offer some convenient features. If those are useful to your app then feel free to use them. But for most of us, the overhead a browser demands are at cross purposes with the rest of the game.

If you really want to use HTML+CSS for your 3D game gui you can do so, but for most games, it is a really bad idea.

There are commercial games that uses HTML/CSS to render the GUI, but as frob said, it's mostly limited to the menu screens, and it seems even that decision was driven by legal/corporate reasons rather than technical.

...run on it's own process so should have no impact on our games process.