But that's because you care about the output vs what might bring value to the company.

If things never bubble up, does that not mean that this is really a non-issue?

You may be surprised, but most useful software is crappy by too many metrics, except for the main one: it gets the job done.

And to be honest, on the original story, as a software engineer, I would rather consider if this is a better behavior for "gap" that most people would expect? Perhaps an addendum to W3C CSS flexbox spec is a more useful avenue? Fix it once and for everyone.

> If things never bubble up, does that not mean that this is really a non-issue?

It's a small issue, not a non-issue. Or some might even be big issues but for a minority of users. They're worth addressing from time to time because they add up.

And yes, the app is probably getting the job done, which is all the more reason to start polishing the app and stop bloating it into something it was never meant to be. Focus on what does make the app good and useful. And heck, you can stop hiring thousands of engineers to build useless stuff and start enjoying all the money rolling it. (Of course that doesn't happen because every company needs 'growth' to appease the shareholders, but I digress)

> And to be honest, on the original story, as a software engineer, I would rather consider if this is a better behavior for "gap" that most people would expect? Perhaps an addendum to W3C CSS flexbox spec is a more useful avenue? Fix it once and for everyone.

I certainly wouldn't. There's 2 elements, a radio and a label, and there's a gap between them, exactly as specified in the CSS. Why would you make the gap clickable? How would you even define that? What if it was radio-image-label. The radio is clickable by virtue of being an input, the label is specified as being for that radio. Should we make the image clickable because it's in a line? Or just the gaps adjacent to the radio and label? What if the are other clickable elements next to them, which ones get priority over the gap? There's a lot of issues here, and this isn't a scenario we want to just randomly do what we think is best. That's how we ended up with HTML4 and IE.

You obviously have something against contemporary growth-obsession, but I don't see a relation to agile. Do I need to point out that there are cases where you would have enough profit only to cover running the business (if that) and can't afford to stress over smaller issues?

> Why would you make the gap clickable?

I already said why: if everyone expects that behaviour (OP obviously did).

Just like "sanding your UI" removes rough edges for customers, fixing things in computer languages removes papercuts for developers (customers of the language).

Regarding technical challenges, didn't OP switch to padding? How is that different?

I do have an issue with growth obsession, but I concede it's unrelated. If you only have enough resources to do some subset of tasks, you should of course prioritize what's best for your business. I happen to work for a company that's not running on fumes, so I think they can afford to do some more sanding.

How is padding different? It's kind of in the definition of padding. Background colors and click regions are expected to fill the padding but not margins. It's the standard CSS box model.

> How is padding different? It's kind of in the definition of padding.

I was responding to you raising technical questions about how could gap work in some edge cases by saying: "same as padding".

If "gap" is always used like padding, why wouldn't it behave the same?

FTR, I am not sure it's used like that commonly (I've stopped doing CSS UIs before the flexbox came to be): I am not putting that out as a conditional by accident.

> If "gap" is always used like padding, why wouldn't it behave the same?

Ah.. yeah, that's a big loaded "if". I would say it's not. It's usually used as a gap, like the name implies. Gap and padding play nicely together too, so, if you want both, use both.