Re: [csswg-drafts] [css-values] Radians considered useless without π

As I've explained here and elsewhere, it's not "one man-hour or so" of time.  It's that, plus testing, plus more things to support in other spots (like Houdini), plus more things for authors to learn (and spend time encountering for the first time and having trouble googling because it's just a few letters), plus the speccing and testing work for us spec writers.

And it's not this one thing.  If the bar is "this might be convenient", then you can multiply this amount of time by a relatively large number, as we add lots more "might be convenient" things with the same level of justification.  Your own proposals show this immediately - with the same justification given here, we'd have to accept 20+ more units and page-size keywords. Each one individual isn't a large amount of work (but more than "an hour or so"), but combined they become quite significant.

Yes, the web ecosystem is path-dependent; things that already exist don't need to self-justify themselves nearly as hard as proposed new things do.  This is because new things are expensive, and the frontier of "new things we might want to add" is *much* larger than the existing territory of "things we've already added".  Browsers are already very large; we need to jealously guard it against gratuitous growth, and require things to self-justify more and more as time goes on, or else we'll drown in the weight.  Thus, for example, the strong push for better primitives that let authors develop their own "conveniences", so we can write *one* more complicated feature instead of a thousand simpler ones.

In this case, the existing units cover pretty much everything you might want to do with reasonably good efficiency. If you're writing JS, you just have plain numbers already (the pi is already baked in), so you can just use the existing `rad` unit.  If you're writing by hand, you can use degrees or turns, and if you for some reason really like doing angle math by hand in radians, we have tau-radians for you, a mere factor of two off of the requested pi-radians.  (Factors of two are well-established as being the easiest possible non-trivial factor to deal with in mental math.)

We do follow the PoC, but that doesn't mean slavishly going "oh, this helps authors, that means we have to do it". It's still about balancing interests, just with particular weightings given such that users are valued over authors, etc.  In this case, the value to authors seems to be extremely minimal; we're not seeing much demand for pi-radians in the first place, and even if there is, tau-radians (turns) are almost as good and already exist, so the "user" side of the equation is almost nil. Compare that with the cost of implementing/testing/etc, which is also small but not nil, and put another thumb on the scale to accommodate the larger ecosystem concerns (that I outlined earlier in this message, which go beyond just the cost of any one individual feature), and our conclusion - to not add this unit - becomes more obvious.

We deeply appreciate your love of the language and the time you've spent trying to improve it. As someone who was also once just a web author trying to interact with a standards body, I also totally understand that this is the sort of thing that looks like easy, low-hanging fruit - it's so easy to define! It's quite a surprise to learn of the significant costs that underlie *every* feature, no matter how trivial, and to deal with the balancing act that the WGs have to make between convenience and maintaining a reasonably small feature set.

I hope you'll continue to donate your passion to helping CSS grow, and that we can find something together that will make it thru the gauntlet. ^_^

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/309#issuecomment-329299730 using your GitHub account

Received on Wednesday, 13 September 2017 21:17:53 UTC