To me it would make more sense to just have one language that can do both things well instead of using two completely different languages – custom versions, as if that wasn’t enough.
Simplified answers:
- We wanted something that works well within Unity with full control over the format and implementation. This includes being able to run on all the 25+ platforms that Unity runs on.
- One of the main goals was to separate the hierarchy from the styles (and from the code logic). Combining them into one format would defeat part of our goal.
Of course, choices like this are rarely simple.
That said, you can embed USS inside UXML if you want to. Same applies if you want to implement everything in C#.
The way I see it, a subset has less features than the parent language to keep the implementation simple. That’s it. That being the case, you’re still constrained by the specifications of the parent languages. Also, XAML is effectively XML for application development, so if for some mysterious reason there’s no XAML parsers or whatever that can run on those 25+ platforms, you can always write your own. You didn’t have any problems doing that with the indentation-based YAML. Let’s be honest: generally speaking, if you can write a parser that has to guess statement terminations (indentation), you can write a parser that works with explicit statement termination (<>).
In XAML you have Style tags, which can be stored in separate files. And even if it didn’t, it’s effectively XML. You could theoretically just do some linking.
CSS is convenient and easy to replace. Same applies in web designing. No need for replacing whole file. Just styles. Also easy to test on web.
Either way, whatever Unity choose their solution, I don’t think proposed approach is any deal braking, to satisfy one customer. It would only introduce much cost and amount of work, to redesign and test Interfaces.
Personally I would prefer HTML5 tech as UI. But that wasn’t a thing much, back decade ago. And now they a bit stuck, with what they got. So I don’t expect it HTML5 either.
XAML is also an custom XML.
I have experimented with WPF in the past, and the XML-based styles… i don’t like it.
To define styles, css / uss is much easier for humans to write / read.
I come from web, so it’s also easier for me. And it’s not only me, there are many other people with more experience in HTML/CSS than in XAML.
I think, HTML5 it’s to heavy for just a Game UI. Sometimes it’s easier to write an new system specialized for a specific “Problem” than brute force a existing solution for a different “problem” to your “problem”.
You can make it as light weight, as heavy weight. Depends which approach you take.
But I can agree, that not all game would benefit from it. However many games uses it.
Is just what I prefer.
And don’t think editors as Unity would suffer from it either. It just would add so much flexibility, specially when so many tools and utilities now are available for HTML5.
Light weight HTML5 not exits, that would no longer be HTML5 
(by specification)
XML has more freedom. Normally you can’t nested (valid) HTML5 Files, and if you strip part of the specification, or only save part of a html-code in a file, you are completely out of any specification.
However, I would have preferred if unity would put some things closer to HTML5. As example the #selector for “id” and not “name”.
1 Like
Perhaps I phrased wrongly. What I mean is, you can use it to make simple form, or fancy shiny game 
Either way, Unity apparently did major revamp recently of their UI, so any fancy changes are out of scope. Even saying that, they still struggle with UI design.
Using ready to use plugins and utilities of HTML5, or relevant, they would probably be able do much more and streamline things. At least my thought.
Much more important than HTML5 is CSS/USS. That’s the part where you are create fancy stuff. And i hope unity extends USS.
1 Like