> browser things the HTML Element object with custom HTML and CSS may never be portable.
>
I think this is quite an (additional) important point against requiring us to use HTML/CSS for UI systems. Most popular C3 commercial games are ported to console thanks to those 3rd party companies but soon it might be impossible to ever port a C3 game to console if the whole UI of the game was done using HTML/CSS.
And this is only one of the less annoying drawbacks with going with a HTML/CSS-based UI solution for C3 as we talked about recently
https://twitter.com/OverboyYT/status/1638952637315047424
(which is also why i think we need built-in UI features and they could be Hierarchy-based construct23.ideas.aha.io/ideas/C23-I-78 )
if you targeting consoles, best practice to do your entire game in Javascript, visual and all... that way you can have one streamlined code...JS in this case 100% if possible. and when u go to a 3rd party they just replicate what u did in JS in C++ or C# which is usually used in consoles.
there could be a work around, a built in function that converts Js into C# or C++ however we talking about years of development (considerable ammount of investment time and money to build a "native" C3 exporter to consoles) and the maintanance for the code is just insane... especially if u using libraries etc.
And let's say Ashley and the team manages to do it... it will be another feature... that the product has which requires coding skills. which defeats the purpose of C3... being a visual "scripter" drag and drop events and plugins. It's just unfeasibble atm. Unless Consoles start to adapt Html5 or JS, is just a early mismatch. Soon in a few years they might change stuff in consoles. but till then... 3rd party solutions.
This is a issue since Construct 2 or classic days, a known feature that has potential is just the technology in consoles is moving slower than Construct itself.