No‑code tools either constrain what they can do with the Box Model too much to equal the design leverage you get with written code, or they're too complex to output good results for those who do not know how to code in the first place.

At its core, Web design relies on using the box model. The Box Model is a very flexible specification allowing you to make anything that can be displayed using 2D elements on a 2D digital space, and is the standard that is used to display HTML ; no‑code tools are all thusly rendering those same boxes at the end of the day. But the Box Model specification, or HTML, or CSS, or ES by themselves do not compel you into displaying those boxes in specific ways, whilst the vast majority of no‑code tools work by funelling your design elements into generic templates, within generic templates, within generic templates.

The Box Model didn't tell you what was reasonable to do with it: it's just a bunch of infinitely nesting boxes that you can rearrange in completely unexpected ways if you want to, even up to the point where you can legitimately question if you can call these elements "boxes" anymore. But simpler, more accessible no‑code tools compel you into normative and prescriptive use cases of the box model. People can now center a <div> using a mouse or ask Claude to do it for them without even knowing what a <div> is, but their <div> is dull, and full of the dullest shit you'll ever not want to stare at as a result.

Sure, even using no‑code, you can retrieve idiosyncrasy by being more manual in your workflows, more involved in the inner workings of each element you generate and use in your interface... But then that defeats the point of no‑code as a more accessible way to develop interfaces in the first place; and that defeat is easy to feel when it is necessary to use code‑based inputs to do something the no‑code UI does not give you the ability to tweak.

If said no‑code UI eventually gives you visually the tweaking abilities that coding "by hand" provides, then its interface is undoubtedly going to be very complex, subtle, and will require a steep learning curve to master. It is very, very likely if not mandatory as well that you would need to understand coding beforehand to anticipate what such a sophisticated no‑code tool will output properly... Unless you want to make a real mess. Thusly, even that fidelity defeats the point of accessibility again.

So, in a way, no‑code has been running into this little accessibility/idiosyncrasy dilemma for a while, and continues to do so. I have no answer to it either, but I felt like sharing my two cents about the nature of the problem.