Isn’t that the point of the RFC approach to standardization? “Here’s what we think should be done, with the PoC being what we’re already doing ourselves in production; feel free to try our impl out, in order to better notice the design flaws in practice, so that we can talk out what changes could be made before it becomes a de-facto standard we’re all stuck with”? SPDY → HTTP2 was a great example of Google doing exactly this.
The opposite of the RFC approach is the “airy design document written by standards body in reference to nothing, never implemented by anyone” approach; and I know which of the two I prefer.
> Here’s what we think should be done, with the PoC being what we’re already doing ourselves in production
The problem with having anything in "production" on the web is that you can neither update it or change it because people will rely on it.
The idea behind web standards is that there should be at least two independent implementations, tested behind a flag, with iterations on design, before it becomes a full standard.
Chrome's approach for the past several years has been: spit out a half-completed spec, "ask" other browser for input.... and ship it in prod a month later.
The "text-wrap: balance" proposal is not new, though? I see it in the 2019-11-13 draft spec: https://www.w3.org/TR/2019/WD-css-text-4-20191113/#valdef-te...