It’s not so much the lack of the CSS, but moreover the frustration at UXP’s CSS support being so opaque.
At the risk of sounding facetious, one hand we’re told that we shouldn’t use anything but supported Spectrum components and that workarounds should be avoided, but on the other hand we’re often left with no choice but to use workarounds to achieve quite basic design/functionality.
Sure, this has been the way of Adobe scripting since time immemorial, but everything else about UXP has been a great step forward and has hugely improved developer experience so this feels like a bit of retrograde step.
From the quotes provided by @Maher I interpret that at least to mean that the ability to use HTML tags will disappear, but not extant CSS, which I hope is the case. The loss of HTML tags matter not to me, Spectrum generally does the job fine in that respect; I’d just like more control over the laying out and display of those SWC.
Ultimately, I think that Adobe’s choices and our frustrations both stem from the same place - we want to build robust, beautiful plugins that are intuitive, enjoyable to use, and perhaps more importantly, that people want to purchase, but I think that we’re being a little bit stymied at the expense of what I’m not quite sure.
I have no idea of the complexity and technical challenges presented by adding CSS to UXP, but I don’t presume that it’s by any means a triviality for Adobe, and nor do I wish to come across as angry and resentful (far from it, I love UXP!) - I just struggle with the “not knowing”.
It’s one thing to have to revisit old work when the API changes (e.g. the switch to API 2/Manifest 5), it’s another thing to be worried that a hack for a flex gap is going to fall over.