Yes, @Baste explained it better than me, thanks!
@uMathieu 95% of the time we have to do a domain load anyway because you dont edit a stylesheet without also editing code. If you sit next to someone developing Editor UI this is immediately apparent. Even when developing game UI its not rare (depends on your game, team, etc - and how much you use practices like TDD - but its pretty normal). So, in reality, There is often no particular time advantage from using assets, and theres considerable time loss (because multiple files = more cognitive load = slower human programmers + more bugs + bugs take longer to fix). For the cases where USS is the right answer - great! Its there as an option! Its another tool in our toolbox - but reaction here and lot of the responses Iâve had recently point to Unity considering USS as the only option, even though on its own its obviously not as powerful, not as effective, (its good but not perfect) as a code-based solution, or a code+USS solution, a lot of the time.
It seems like the things we need from Unity, for code solutions to work âgreatâ, as fully supported usecases ⌠are usually mostly a subset of what youve already had to write to implement USS, so the foundations for the code already exist (with some additional effort needed - obviously: making public versions of that code with stable APIs is not free)
I 100% agree with the sentiment that a public API needs careful planning - eg look at the places in UIToolkit where insufficiently developed API designs already caused large amounts of wasted time because of API designs that seemed a good idea at the time but didnt really work well (and ugly code in our codebases to workaround the API) - the âcompletely ignores the existing API pattern used for all other callbacksâ solution for mouseclick handlers for Buttons Iâm looking at you! Designing good APIs is a skill and requires work and time.
âŚhence my opening question: I wasnt sure if there was a reason for this missing API feature (because it seems to be core for people doing serious UI work in games!), or if it was an oversight, or if the feature does exost but Im looking in the wrong place, etc etc.
NB: Iâm not saying its impossible to write good, complex, rich, UI without API features like this, but Iâm saying that any experienced team of game engineers (people working on live games) is likely (not all - but most should already know how to build procedural UI extremely fast in CSS (ie mixing code + styles) and/or in native ui libs; this stuff is standard practice, and in many cases works much better than using USS files alone) to do it faster and more effectively this way ⌠so I would expect that such features exist in the API and work out of the box.
But weâre getting very close to the previously anniunced official launch date for UIT, and it seems theres quite a lot of these holes still unplugged, with only USS properly supported as a use case. I would really like to see them plugged (happy to give feedback, test API ideas, etc if it helps) before it goes gold. Or to get official answers on which features have been left out of UIT and why, so we can decide how much to use it on future projects, versuseg building/maintaining more proprietary solutions on top of UnityUI where these limitations dont exist.