Why are standards so slow? Find out in this intricate discussion of subgrid BPMs (border/padding/margin) & the TSA (track sizing algorithm) of its parent grid in a subgridded axis.
What’s that all about? I have no idea. I suspect very few people have. But if the CSS Working Group get it wrong, it’ll be on the web —and pissing off web developers— for ever.
Also, have we defined what happens when an RTL Flexbox is inside a CSS Grid, that an ancient CMS has put in a float that’s in a
display: table-header container? No-one will ever be mad enough to do that, you say? But, yes, they will, so behaviours need to be defined so browsers are interoperable.
And all of this conversation has to be done asynchronously over GitHub or mailing lists so that all interested parties can contribute, across timezones, to fit the schedules of people across the world, some of whom do Standards full-time, some of whom do it as a part of their jobs, and some of whom do it afterhours.
And that’s why web standards are so slow, and so powerful — they’re made in the open, for everybody.
Addendum, 27 July 2018:
I didn’t want this to suggest that because standards are necessarily slower than company X magicking up some Proprietary FlimFlam™, therefore progress on the web platform must be slow. Many standards are retrospective: an encouraging example is
Standards such as Houdini are explicitly designed to open up the black box of browsers’ super-optimised CSS flux capacitors so developers can polyfill upcoming/ putative CSS features without having to replicate the whole system in order to tweak part of it. If you haven’t read up on Houdini, a good starting point is Houdini: Maybe The Most Exciting Development In CSS You’ve Never Heard Of. For the philosophical background, read The Extensible Web Manifesto.
With the excellent browser interoperability that HTML5 ushered in, the unlamented death of vendor prefixes and plugins, and the near-ubiquity of evergreen browsers, the future of web development is so bright I gotta wear shades.