1. 26
  1.  

  2. 2

    Quick glance tells me Chrome is the browser of choice, given all is green (to a point where I thought the author is a Google employee). But no, that doesn’t seem to be the case when I drill down what the “harmful” means.

    IMO, the page isn’t very useful without a TL;DR context at the top… if I have to click on 3rd party articles or drill down to the details, then the purpose of the landing page is questionable. My recommendation would be clarify what “Harmful”, “Shipped” and “Community Draft” means at the top, and then it will make much sense. :-)

    1. 1

      Thanks, good suggestions, really appreciate it

    2. 2

      Hi, creator here, thanks for submitting and please share any feedback or thoughts you might have!

      1. 21

        Without more context it’s difficult at a glance to know how to interpret “Harmful”.

        It looks like it’s saying “Mozilla’s implementation of the Serial API is harmful” but it sounds like what it’s actually saying is “Mozilla considers the Serial API to be harmful” which is very different!

        1. 1

          Hmm, yeah, good point. The wording is taken from their own site which is linked to when one clicks on the status.

          Suggestion on how it could be improved?

          1. 8

            Personally I have no idea what this website is about. Perhaps add a few lines on top that explain what it is?

            1. 1

              Further down I’ve written:

              observations of APIs with controversy around them and where hard facts has often been hard to find

              Maybe replacing/extending the current “Background” in the top with something similar? Maybe like this:

              Gathering of Web API specifications that has caused controversy among browser vendors, giving them relevant context

              1. 3

                I think you need even more context than that. What is Web API? Why is it controversial? The nice thing about the FAQ format is that you can spend the first 1–3 items answering questions like these and anyone who already has this context can just skip over them.

                A design note—the text in the FAQ expands to fill the full width of the screen (or at least the 1,280 pixels of my browser window), and there is also no margin between the text and the edge of the screen. Both of these things make the text harder to read. You might consider limiting the width of the text to 800 px or 40 em (very approximate numbers) and, on smaller screens, adding at least 10 px of whitespace on either side.

                1. 1

                  Suggestion on wording and such is much appreciated, this is just something I threw together quickly in an afternoon to try and gather references in these topics :)

            2. 3

              Perhaps you’d consider changing the colour scheme? To me, green = GOOD and red = BAD, which makes it hard to understand what’s actually going on at first glance.

              1. 1

                In what way? Green = positive about the state of the spec, Red = negative about the state of the spec, isn’t that the correct way?

                1. 4

                  I think the problem is that it’s not immediately obvious that this ‘judgement’ of good vs bad is about the spec. At first glance this just looks like chrome has everything green and is thus good, while firefox/safari have everything red and are thus bad.

                  1. 1

                    Yeah, good feedback, will try to find time to improve it asap

              2. 2

                “Harmful to Users” or “Deemed Harmful to Users” perhaps? The key point that needs communicating is that Mozilla has determined that implementing the spec would be harmful to its own users, e.g. someone might use the serial api to modify their insulin delivery device.

                1. 1

                  Intentionally omitted.

                  1. 1

                    Well, Mozilla’s own description of their “Harmful” label is “Mozilla considers this specification to be harmful in its current state.”

                    That the focus is on the spec, not the implementation should get clarified

                    1. 5

                      “Harmful” doesn’t mean anything on its own, you have to tell a person what is being harmed.

                      1. 1

                        Totally, but that’s better explained by the ones considering it to be harmful than for me to try and summarize and maybe misinterpret

                        1. 1

                          By using the single word “Harmful” I’d argue that you have summarized. It’s just that that summary is ambiguous and prone to misinterpretation, as others in this thread have pointed out.

                          1. 1

                            How would you summarize it better? I would love to do it better

                            1. 1

                              Maybe “Mozilla considers it harmful” or “No plans to implement”? I know these are more wordy than what you’ve got now, but I can’t think of a shorter bit of text that still conveys the right meaning.

                  2. 2

                    Added an issue for it to ensure it doesn’t get lost: https://github.com/voxpelli/webapicontroversy.com/issues/1

                    1. 1

                      Perhaps “Rejected” instead of “Harmful”?

                      Though Mozilla themselves refer to it as “harmful”.

                      1. 1

                        They often haven’t rejected the specs though, rather they have found that they in their current state would be harmful to the web.

                        Remember: All of these specs are drafts and still under discussion, even though Chrome has decided to ship them

                        1. 1

                          Yea, I get that, I just don’t feel that “HARMFUL” is representative of what’s going on.

                          For example, the Safari side of things talks about anti-fingerprinting challenges, which is fair.

                          I don’t get the sense that the Chrome side is actively trying to enact more ways to fingerprint, but rather they’re trying to build a browser environment that competes with OS functionality, which I think is also fair (ideology aside). I’m not sure how Safari feels about this, given that they’re a purveyor of iOS and macOS and probably don’t love the idea of browsers competing.

                          Meanwhile I’m not sure what Mozilla’s agenda is. They’re no longer providing Firefox OS, but also it’s not clear that Firefox is interested in pushing browser functionality forward, while also experimenting with ads/sponsored content by default.

                          My personal bias, as someone who uses Linux and benefits greatly from cross-platform applications like browser apps, is that I like the idea of these additional WebAPIs and it doesn’t sound intractable to make them robust against fingerprinting. The cost of not advertising the functionality by default and even requiring the user to manually enable them seems more than worth it.

                          My wish for something like the Web API Controversy page (which I appreciate exists as it’s a handy dashboard to keep track of!) is that it didn’t make the premise of the proposals seem nefarious and intractable. :)

                  3. 2

                    I think it would be nice to link to discussions directly in the details, e.g. https://github.com/mozilla/standards-positions/issues/336

                    1. 2

                      I prefer to link to the most official kind of reference and have it refer to the discussions they feel are relevant, feels like that has a better chance of being up to date and staying as objective as possible

                  4. 1

                    It’s sooooooo weird to me that all these browsers implement camera/mic APIs (and with a totally fine security model of “ask the user to activate it”) and all these other APIs are rejected despite them potentially having exactly the same implementation strategy? Maybe I’m missing some details (and I think the Web NFC comment of “not being able to communicate to users what this does” is legit) but I’ve always thought that the browser security model is pretty much ideal and it (in theory) should have let people to build out stuff for it that would otherwise be unsafe.

                    Maybe people think even the camera/mic stuff was a mistake and this is the result, but as a user of the web being able to (for example) not have to install Teams to join some random vendor meeting is a very nice thing.