Yep, it is basically the new game menu/gui standard to use HTML/CSS, and libRocket is supposedly based directly upon it (lots of writing on it, lots of companies using it, Rockstar for example uses HTML/CSS and flash with some other stuff for rage's front end along with many other companies, but I can't speak to Rage's in-game hud and whether this is used there or not). You'd really have to take a look at libRocket to confirm this is as cut and dry as I make it, I might be getting too much hope from the front page! Not sure!
Take this from my userbase growing and marketing role in the grit engine team outside of any of my actual working inside of the engine, because my life is very hard otherwise, and your programming life is more easy, the more easy mine is in this regard
Consideration:
Implementing things may be fun, and I would love for the tech to be totally original some day (as we joked about even replacing ogre one day in the past), but the wisest thing in my eyes is to hit the internet and find every bit of modular or plugged-in tech that we can find that also agrees with our licensing choices, to very Quickly have that complete engine that people can start using.
This is the only sensible option in my eyes, because once you put in a straight up GUI library like libRocket, for example, you have many new possibilities that are not possibly now nor with a completely scratch made GUI that could take a long time considering all of the other aspects of the engine (networking, deeper work to sound, more graphics - there is a lot to do, implementing is fun, but let's get the tech put together, and THEN wipe out stuff with scratch-made things - get the engine put together, and then you'll even see what you want to do that much better):
1: People can complain about libRocket, and thus people can be encouraged to work on it, or its replacement. Something they cannot do without a complete gui.
2: People who already use libRocket are more attracted to Grit. When you implement and have fun making a better GUI, then they can see that as an improvement, while if we don't use techs that are already out there, we are robbing ourselves of sharing those users with those techs.
3: If we grabbed a networking (enet I guess) component, grabbed lib rocket, and plugged them in, I can go find eNet and libRocket users. You can not think about GUI or Networking again until you are ready to scratch-implement, or at least, it will clear your plate, and let you focus on making the game scriptable, and making the graphics nice and fast.
I understand, most likely, all the reasons, and there are probably more not listed, for not using middle/outer techs, but these can always be rewritten later, with the benefit the engine is usable 100x faster, and only can improve from there. I can't see any other option as crucial.
libRocket can likely be integrated in under a weekend. Then you can leisurely do as you wish with gui - when you wish - with the benefit again, that you can point people to libRocket docs and grit-specific ones when they ask GUI question a, b, or c.
This eliminates the "well, there is no gui, so i don't use grit..." and replaces it with "SWEET it uses libRocket! Awesome. I can do GUI in CSS!!!!!". There is never a "I haven't done that yet" and instead you can say "It's like this, with libRocket, but my replacement might improve the experience with a, b, c"
You see?
You can see where ignoring existing tech would be a somewhat naive move in regards to actually being feasible to use our engine here, and I feel this post is incomplete and have a lot more points, but it's getting long. Even if grit ends up scatch-made 100% one day, the smartest thing to do is treat that GUI like you have treated physics. Treat it like sound has been treated with openAL. Treat it like we will likely treat networking with eNet.
Not using existing tech is shooting ourselves in the foot, the face, and the clock. We need these existing techs - EVEN if it is just temporary - to gain users, to be usable, to be noticable.
How can I go tell people about grit on libRocket if I'm not having a valid reason (like using the tech)? How can I tell people about our multiplayer project on the eNet community if eNet isn't used? Again, even if temporary, right?
We can post showcases to bullet if we want. This is because we USE bullet. We can post to Ogre. We can post to 3ds max and Blender forums because we have exporters for those. Prior to your work on Blender Exporter, I couldn't think of going there and talking to blender users - our cousin as an OS project. I haven't yet gone over there to web-based outlets, only chats, but in time I will, and it is only possible because we didn't make our own map editor/model editor.
It would be unwise to make our own map editor/model editor, right? That's because one exists. We instead support the ones we're known to use. This applies to this argument for libRocket (or another, I don't care, just let it be a somewhat popular one who has users) GUI, as well. You can spend time away from more arguably more important things, or bounce back and forth, or you can have the potential for more users, and a more close to complete engine awaiting your libRocket replacement at your leisure.
Any of the third party stuff we use can be replaced, libRocket wouldn't be any different, using it has the advantages of, and not using it introduces or makes apparent major disadvantages in, both the growth and people's knowledge of Grit, but also just how long it is going to take to see a game project show up using it, small or large. Use existing tech. Replace it at your leisure, but use the existing tech. It's the smartest thing when you weigh it all out.
