• d3Xt3r@lemmy.world
      link
      fedilink
      English
      arrow-up
      34
      arrow-down
      1
      ·
      edit-2
      1 year ago

      Because Firefox is like a democracy, they prioritize work based on number of votes on issues/feature requests. The AudioEncoder API has literally just one vote, and the overall WebCodecs API that it’s a part of only has five votes. This shows that there’s very little demand for it, meaning very few sites actually use this (that or the vast majority of Firefox users don’t use/need this feature). Why bother focusing your efforts on implementing something that most users don’t care about? The higher priority things that most Firefox users care about is stuff like performance, and Mozilla have been making some good progress too on that front.

      • lud@lemm.ee
        link
        fedilink
        English
        arrow-up
        2
        ·
        1 year ago

        The thing isn’t only about votes. Both APIs are top priority but there are blocked and depends on other stuff that also needs to be fixed or implemented.

        • d3Xt3r@lemmy.world
          link
          fedilink
          English
          arrow-up
          1
          ·
          edit-2
          1 year ago

          AudioEncoder (bug 1749046) doesn’t really have any dependencies or blockers, as far as I can tell. If there are, then you (or whoever has access) should update Bugzilla and add the dependency there.

          • lud@lemm.ee
            link
            fedilink
            English
            arrow-up
            1
            ·
            1 year ago

            Honestly, I found bugzilla hard to read, so I am not sure but it looks like the WebCodecs API needs to be implemented first. And that one has a bunch of other stuff, I think.

    • redcalcium@lemmy.institute
      link
      fedilink
      English
      arrow-up
      20
      arrow-down
      1
      ·
      edit-2
      1 year ago

      This is an experimental API that hasn’t been finalized yet. Firefox devs has limited engineering resource and simply can’t keep up with Chrome’s push to implement experimental/proposal API. Safari also hasn’t implemented this yet because they also usually wait until the API finalized, which can take quite a while.