4 ms·

I understand where you're coming from, but at the same time it's a feature defined as a finalized spec in the Web incubator. Even if it's currently implemented

I understand where you're coming from, but at the same time it's a feature defined as a finalized spec in the Web incubator. Even if it's currently implemented by one engine, 1) that engine is used in browsers from many different vendors - Google, Microsoft, Samsung, etc. which represent a huge chunk of the Web and 2) there's still hope that other browsers will implement it in the future. For example, File System Access API was also part of WICG and similarly deemed by commenters as Chrome-only API because it implemented it first, but is now at least partially implemented in Safari 15.2. Who knows what we'll see adopted next? As long as there's a Web spec and apps using an API, browser vendors can prioritise.

dblohm7 5y ago
> Even if it's currently implemented by one engine, 1) that engine is used in browsers from many different vendors - Google, Microsoft, Samsung, etc. which represent a huge chunk of the Web That's a really terrible argument, tbh.
- RReverser 5y ago
  Is it? It's worth keeping in mind that it's users and apps that comprise the web, not the implementation details of any given browser.
  - dmitriid 5y ago
    > It's worth keeping in mind that it's users and apps that comprise the web, not the implementation details of any given browser. Ah yes. As we all know, Chrome is very well known for how well it listens to users. Remember the alert fiasco? And many other fiascos? Or remember "standards" like WebHID which are so bad that Mozilla engineers couldn't even understand them, but you still shipped them? Or other "standards" which have multiple issues pointed out and still shipped by default in Chrome? Please don't insult our intelligence by pretending that you, or Chrome team care at all about users or standards.
    - RReverser 5y ago
      Funny how you use words like "insult" yet don't see the irony in the tone you use when talking to other people :) Good day to you too.
      - dmitriid 5y ago
        Well, you don't care about that, either. Because the entire behaviour of every single public person from Chrome team has been: - deflect - pretend Chrome-only APIs are standards - gaslight other browser vendors You are not different, and there's literally nothing in this world will stop you, and nothing I say or do can ever even begin to approach the behaviour of the Chrome team. So, do hold up the mirror to your actions first.
        afavour 5y ago
        Just from a third party perspective here: your tone in this post and all over the thread is not even remotely constructive. You have one point that you’ve made rudely in about five different places. We get it.
        dmitriid 5y ago
        > all over the thread is not even remotely constructive Constructive tone has been tried with Chrome team again, and again, and again, and again. It's gotten so bad that in various "Request for position on standards" Safari team simply ends up saying "no" without stating reasons. Because it literally doesn't matter anymore. All is left is directly pointing out the outright lies (see e.g. https://news.ycombinator.com/item?id=30019370 https://news.ycombinator.com/item?id=30019370) that Chrome's various talking heads will tell you. And yes. I will keep saying this in many places. And there's a good reason for that, as someone else noted in the discussion: https://news.ycombinator.com/item?id=30014807 https://news.ycombinator.com/item?id=30014807 Do you by any chance go and admonish people for "not being constructive" about Safari or Firefox?
        GeorgeWBasic 5y ago
malepoon 5y ago
It's too bad these Chromium "specs" tend to be pretty low quality and rushed. They're then never changed because "too bad, we shipped it already, can't break the web!" See the garbage they tried to push in the form of NaCl, WebSQL, etc.
- baxuz 5y ago
  Don't forget Web components v1
ciupicri 5y ago
Regarding File System Access I notice that [1]: > This specification was published by the Web Platform Incubator Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. [1]: https://wicg.github.io/file-system-access/ https://wicg.github.io/file-system-access/
- deleted 5y ago
  [deleted]
dmitriid 5y ago
> but at the same time it's a feature defined as a finalized spec in the Web incubator. At the dame time both Firefox and Safari consider this feature harmful and will not implement it. Just because you rammed it through standards bodies doesn't make it standard, or good. And, unfortunately, you've co-opted web.dev to be a full-on Chrome propaganda machine. Additionally, the status of this "finalized spec" is, quote, "Draft Community Group Report". It's nowhere near to being a) finalized and b) standardized. The "finalized spec" literally has this in its description: "It is not a W3C Standard nor is it on the W3C Standards Track." > For example, File System Access API 1. Is anyone talking about this API here? No. Only you, trying to pull conversation away from WebUSB 2. Filesystem API suffers from the same thing: it's a "standard", and now your team is busy pushing three more file standards
chrismorgan 5y ago
WebUSB is not finalised in any way. It’s a WICG draft (draft means not finalised, and WICG means explicitly unofficial), with only one shipping implementation in browsers. (There’s also an implementation for Node.js, but I think that’s considered irrelevant.) My recollection of the rough processes is that to become a Candidate Recommendation (which is the first stage you could reasonably argue “finalised spec” corresponds to) it would need at least a second shipping implementation, and to be adopted by a working group. As it stands, there’s no short-term prospect of a second implementation: Mozilla’s current position is that WebUSB is harmful because it’s super dangerous and the risks can’t be adequately explained, and is a tracking hazard <https://mozilla.github.io/standards-positions/#webusb https://mozilla.github.io/standards-positions/#webusb>, and WebKit have likewise consciously decided not to implement WebUSB for similar reasons (“due to fingerprinting, security, and other concerns, and where we do not yet see a path to resolving those concerns”) <https://webkit.org/tracking-prevention/#anti-fingerprinting https://webkit.org/tracking-prevention/#anti-fingerprinting>. That multiple browsers use the same engine and implementation is irrelevant for standardisation—otherwise Chromium would be the very definition of the standards. To show this even more clearly, WebSQL was scuttled because everyone used SQLite and there was no satisfactory way of specifying what would be permitted. Speaking frankly here: as the post author and a “WebAssembly Advocadoer @Google”, you’re speaking from a position where authority will be assumed, but in this comment you expressed some very significant errors and presented a badly biased view. This is not good.
- mehdix 5y ago
  Thank you for clarification. As an ill-informed reader, by reading the parent comment I was under the impression that it was already a standard. Considering the hazards, the last thing I want is random js in random website start messing with my operating system file system and USB connected devices.
- RReverser 5y ago
  It sounds like you're talking about the W3C standards track (correct me if I'm wrong, just guessing from the context) whereas I'm talking about the spec itself as the document and the API. Those are two different things after all. All browser engines have been following living specs even for core stuff like HTML/CSS instead of the W3C "officially finalised" standards for a while now, so I didn't bring the latter up as they weren't relevant to the conversation about the spec itself or its stability. However, I admit that I missed myself and should've called out that the spec, while stable, is still a draft - that's a mistake on my part.

dblohm7 5y ago

> Even if it's currently implemented by one engine, 1) that engine is used in browsers from many different vendors - Google, Microsoft, Samsung, etc. which represent a huge chunk of the Web That's a really terrible argument, tbh.

RReverser 5y ago
Is it? It's worth keeping in mind that it's users and apps that comprise the web, not the implementation details of any given browser.
- dmitriid 5y ago
  > It's worth keeping in mind that it's users and apps that comprise the web, not the implementation details of any given browser. Ah yes. As we all know, Chrome is very well known for how well it listens to users. Remember the alert fiasco? And many other fiascos? Or remember "standards" like WebHID which are so bad that Mozilla engineers couldn't even understand them, but you still shipped them? Or other "standards" which have multiple issues pointed out and still shipped by default in Chrome? Please don't insult our intelligence by pretending that you, or Chrome team care at all about users or standards.
  - RReverser 5y ago
    Funny how you use words like "insult" yet don't see the irony in the tone you use when talking to other people :) Good day to you too.
    - dmitriid 5y ago
      Well, you don't care about that, either. Because the entire behaviour of every single public person from Chrome team has been: - deflect - pretend Chrome-only APIs are standards - gaslight other browser vendors You are not different, and there's literally nothing in this world will stop you, and nothing I say or do can ever even begin to approach the behaviour of the Chrome team. So, do hold up the mirror to your actions first.
      - afavour 5y ago
        Just from a third party perspective here: your tone in this post and all over the thread is not even remotely constructive. You have one point that you’ve made rudely in about five different places. We get it.
        dmitriid 5y ago
        > all over the thread is not even remotely constructive Constructive tone has been tried with Chrome team again, and again, and again, and again. It's gotten so bad that in various "Request for position on standards" Safari team simply ends up saying "no" without stating reasons. Because it literally doesn't matter anymore. All is left is directly pointing out the outright lies (see e.g. https://news.ycombinator.com/item?id=30019370 https://news.ycombinator.com/item?id=30019370) that Chrome's various talking heads will tell you. And yes. I will keep saying this in many places. And there's a good reason for that, as someone else noted in the discussion: https://news.ycombinator.com/item?id=30014807 https://news.ycombinator.com/item?id=30014807 Do you by any chance go and admonish people for "not being constructive" about Safari or Firefox?
      - GeorgeWBasic 5y ago

malepoon 5y ago

It's too bad these Chromium "specs" tend to be pretty low quality and rushed. They're then never changed because "too bad, we shipped it already, can't break the web!" See the garbage they tried to push in the form of NaCl, WebSQL, etc.

baxuz 5y ago
Don't forget Web components v1

ciupicri 5y ago

Regarding File System Access I notice that [1]: > This specification was published by the Web Platform Incubator Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. [1]: https://wicg.github.io/file-system-access/ https://wicg.github.io/file-system-access/

deleted 5y ago
[deleted]

dmitriid 5y ago

> but at the same time it's a feature defined as a finalized spec in the Web incubator. At the dame time both Firefox and Safari consider this feature harmful and will not implement it. Just because you rammed it through standards bodies doesn't make it standard, or good. And, unfortunately, you've co-opted web.dev to be a full-on Chrome propaganda machine. Additionally, the status of this "finalized spec" is, quote, "Draft Community Group Report". It's nowhere near to being a) finalized and b) standardized. The "finalized spec" literally has this in its description: "It is not a W3C Standard nor is it on the W3C Standards Track." > For example, File System Access API 1. Is anyone talking about this API here? No. Only you, trying to pull conversation away from WebUSB 2. Filesystem API suffers from the same thing: it's a "standard", and now your team is busy pushing three more file standards

chrismorgan 5y ago

WebUSB is not finalised in any way. It’s a WICG draft (draft means not finalised, and WICG means explicitly unofficial), with only one shipping implementation in browsers. (There’s also an implementation for Node.js, but I think that’s considered irrelevant.) My recollection of the rough processes is that to become a Candidate Recommendation (which is the first stage you could reasonably argue “finalised spec” corresponds to) it would need at least a second shipping implementation, and to be adopted by a working group. As it stands, there’s no short-term prospect of a second implementation: Mozilla’s current position is that WebUSB is harmful because it’s super dangerous and the risks can’t be adequately explained, and is a tracking hazard <https://mozilla.github.io/standards-positions/#webusb https://mozilla.github.io/standards-positions/#webusb>, and WebKit have likewise consciously decided not to implement WebUSB for similar reasons (“due to fingerprinting, security, and other concerns, and where we do not yet see a path to resolving those concerns”) <https://webkit.org/tracking-prevention/#anti-fingerprinting https://webkit.org/tracking-prevention/#anti-fingerprinting>. That multiple browsers use the same engine and implementation is irrelevant for standardisation—otherwise Chromium would be the very definition of the standards. To show this even more clearly, WebSQL was scuttled because everyone used SQLite and there was no satisfactory way of specifying what would be permitted. Speaking frankly here: as the post author and a “WebAssembly Advocadoer @Google”, you’re speaking from a position where authority will be assumed, but in this comment you expressed some very significant errors and presented a badly biased view. This is not good.

mehdix 5y ago
Thank you for clarification. As an ill-informed reader, by reading the parent comment I was under the impression that it was already a standard. Considering the hazards, the last thing I want is random js in random website start messing with my operating system file system and USB connected devices.
RReverser 5y ago
It sounds like you're talking about the W3C standards track (correct me if I'm wrong, just guessing from the context) whereas I'm talking about the spec itself as the document and the API. Those are two different things after all. All browser engines have been following living specs even for core stuff like HTML/CSS instead of the W3C "officially finalised" standards for a while now, so I didn't bring the latter up as they weren't relevant to the conversation about the spec itself or its stability. However, I admit that I missed myself and should've called out that the spec, while stable, is still a draft - that's a mistake on my part.