4 ms·

At the time of the tweet not in Chrome: https://twitter.com/denschub/status/1582730988118867968?s=20 https://twitter.com/denschub/status/1582730988118867968?s=2

At the time of the tweet not in Chrome: https://twitter.com/denschub/status/1582730988118867968?s=20 https://twitter.com/denschub/status/1582730988118867968?s=20

jefftk 4y ago
And the tweet is correct, unfortunately: https://www.jefftk.com/test/webmidi https://www.jefftk.com/test/webmidi Looks like Chrome is trying to change this, and is slow as usual: https://groups.google.com/a/chromium.org/g/blink-api-owners-discuss/c/RWw9-bGrewU https://groups.google.com/a/chromium.org/g/blink-api-owners-...
- illiarian 4y ago
  > is slow as usual: It's funny because for anything Chrome deems beneficial to Google they are anything but slow, including shipping APIs that no other browser agreed on.
  - jefftk 4y ago
    Having been someone at Google working on new browser APIs, that's slow too. But maybe it doesn't look as slow from the outside?
    - illiarian 4y ago
      > But maybe it doesn't look as slow from the outside? Google ships 400 new APIs per year. It readily ships API within a month after it spits out a half-prepared spec and asks other browsers for input. Even benign changes like CSS headline balancing was sent to TAG three weeks ago, and will ship a month from now. From the outside this is neck-breaking speed with utter disregard for anything. But when user privacy is concerned? Nah, must spend sweet time to do anything.
      - jefftk 4y ago
        > Even benign changes like CSS headline balancing was sent to TAG three weeks ago 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-text-wrap-balance https://www.w3.org/TR/2019/WD-css-text-4-20191113/#valdef-te...
        illiarian 4y ago
        Perhaps, but it was sent for TAG review only three weeks ago, and already with an intent to ship in a month.
        jefftk 4y ago
        It looks like that was just because it was very uncontroversial, though? https://github.com/w3ctag/design-reviews/issues/822 https://github.com/w3ctag/design-reviews/issues/822
        derefr 4y ago
        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.
        illiarian 4y ago
        > 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.

At the time of the tweet not in Chrome: https://twitter.com/denschub/status/1582730988118867968?s=20 https://twitter.com/denschub/status/1582730988118867968?s=20

jefftk 4y ago

And the tweet is correct, unfortunately: https://www.jefftk.com/test/webmidi https://www.jefftk.com/test/webmidi Looks like Chrome is trying to change this, and is slow as usual: https://groups.google.com/a/chromium.org/g/blink-api-owners-discuss/c/RWw9-bGrewU https://groups.google.com/a/chromium.org/g/blink-api-owners-...

illiarian 4y ago
> is slow as usual: It's funny because for anything Chrome deems beneficial to Google they are anything but slow, including shipping APIs that no other browser agreed on.
- jefftk 4y ago
  Having been someone at Google working on new browser APIs, that's slow too. But maybe it doesn't look as slow from the outside?
  - illiarian 4y ago
    > But maybe it doesn't look as slow from the outside? Google ships 400 new APIs per year. It readily ships API within a month after it spits out a half-prepared spec and asks other browsers for input. Even benign changes like CSS headline balancing was sent to TAG three weeks ago, and will ship a month from now. From the outside this is neck-breaking speed with utter disregard for anything. But when user privacy is concerned? Nah, must spend sweet time to do anything.
    - jefftk 4y ago
      > Even benign changes like CSS headline balancing was sent to TAG three weeks ago 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-text-wrap-balance https://www.w3.org/TR/2019/WD-css-text-4-20191113/#valdef-te...
      - illiarian 4y ago
        Perhaps, but it was sent for TAG review only three weeks ago, and already with an intent to ship in a month.
        jefftk 4y ago
        It looks like that was just because it was very uncontroversial, though? https://github.com/w3ctag/design-reviews/issues/822 https://github.com/w3ctag/design-reviews/issues/822
        derefr 4y ago
        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.
        illiarian 4y ago
        > 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.