Re:The Rise of Worse Is Better (1991)
by jancsika on Sunday April 01, 2018 @05:47PM
(#16730645)
Here's some rank speculation after reading the first few weeks of the w3c svg group archive:
A well designed api typically arrives at the dev cycle from somewhere else. This causes longer iterations in the dev cycle because new devs have to contend with two sources of truth-- the dev cycle itself and whatever unreachable realm used unreachable arguments to bring the well designed api into existence.
So you get these weird situations where certain topics are in scope, but others are out of scope because they were decided in the unreachable realm. For example, a discussion about using CSS for SVG shape attributes (fill, stroke, etc.) gets cut short because the unreachable realm already decided that they don't want to have to "parse twice" in order to get at the CSS data.
Oops, now modern browsers have CSS props, SVG presentation attributes with corresponding CSS props with the same name that override them, and other SVG attributes which don't have corresponding CSS props. Except they do in the SVG 2.0 spec.
And now you're stuck because you've got this wonderful new(ish) (actually well-designed) API for web animation but it's unclear how to treat SVGs because of the ambiguity among the above categories. Chromium seems to already be doing things the SVG2 way while last I checked Mozilla still uses SVG1.1 and had prefixes for the svg presentation attys (perhaps behind a feature flag, can't remember).
Slowwww...
Compare that to just deciding early on to put all attys that could conceivably be related to "presentation" in CSS.
But that's hard to argue when the counter-argument is that the issue was already considered in an unreachable realm in a process that isn't available for inspection.
I also read threads where both SVG path syntax and the awful path arc command parameters could have been improved if the unreachable realm hadn't existed.
On the other hand, devs who write self-described "crappy apis" (or some such self-deprecating business) don't typically have an unreachable realm. Or if they do, their self-deprecation makes it clear that it rarely if ever trumps the open realm.
So my idea is that a single iteration through crappy api-land is faster because there's only one source of truth leading to greater clarity and a greater incentive to participation at any level.
A well designed api typically arrives at the dev cycle from somewhere else. This causes longer iterations in the dev cycle because new devs have to contend with two sources of truth-- the dev cycle itself and whatever unreachable realm used unreachable arguments to bring the well designed api into existence.
So you get these weird situations where certain topics are in scope, but others are out of scope because they were decided in the unreachable realm. For example, a discussion about using CSS for SVG shape attributes (fill, stroke, etc.) gets cut short because the unreachable realm already decided that they don't want to have to "parse twice" in order to get at the CSS data.
Oops, now modern browsers have CSS props, SVG presentation attributes with corresponding CSS props with the same name that override them, and other SVG attributes which don't have corresponding CSS props. Except they do in the SVG 2.0 spec.
And now you're stuck because you've got this wonderful new(ish) (actually well-designed) API for web animation but it's unclear how to treat SVGs because of the ambiguity among the above categories. Chromium seems to already be doing things the SVG2 way while last I checked Mozilla still uses SVG1.1 and had prefixes for the svg presentation attys (perhaps behind a feature flag, can't remember).
Slowwww...
Compare that to just deciding early on to put all attys that could conceivably be related to "presentation" in CSS.
But that's hard to argue when the counter-argument is that the issue was already considered in an unreachable realm in a process that isn't available for inspection.
I also read threads where both SVG path syntax and the awful path arc command parameters could have been improved if the unreachable realm hadn't existed.
On the other hand, devs who write self-described "crappy apis" (or some such self-deprecating business) don't typically have an unreachable realm. Or if they do, their self-deprecation makes it clear that it rarely if ever trumps the open realm.
So my idea is that a single iteration through crappy api-land is faster because there's only one source of truth leading to greater clarity and a greater incentive to participation at any level.