Hacker News Reader

Hacker News

Comment by jeroenhd | Hacker News Reader

Full thread

jeroenhd

A lot of these don't work in any browser other than Chrome. Demos that work in Firefox:

- Fullscreen

- Image capture

- Resize observer

- Broadcast Channel

Demos that don't:

- Clipboard API (not supported)

- Battery API (not supported)

- Performance information (says it's supported, but shows an empty page)

- Vibration API (supported by the browser, but doesn't actually vibrate because malvertisers abuse the API in their antivirus scams)

- Bluetooth API (not supported)

The fullscreen, image capture and broadcast channel APIs are nice I suppose, but the rest should probably be considered "Chrome APIs" rather than "web APIs".

Edit: even in Chrome on Android, the battery API is reporting fake information and the vibration demo doesn't work. That's the problem with experimental web APIs, you can't rely on them at all.

View on HN

...the rest should probably be considered "Chrome APIs" rather than "web APIs".

That's just plain wrong. They're web APIs that are maintained by the W3C (in various states) that Firefox doesn't support yet. That doesn't make them "Chrome APIs" just as a W3C spec that only Firefox supports isn't a "Firefox API".

Clipboard API: https://w3c.github.io/clipboard-apis/

Battery API: https://w3c.github.io/battery/

Performance: https://www.w3.org/TR/resource-timing/

Bluetooth API: https://webbluetoothcg.github.io/web-bluetooth/

The fact there isn't good cross-browser support is a reason to check whether or not a user's browser has support and use progressive enhancement to only show the feature to users who can benefit from it. It isn't a reason to avoid using the API unless you want to stick to the lowest common denominator for your users. In my case that would mean serving Chrome and Firefox users content that's developed for IE10. That would suck for people who are able to update their browser, so I prefer to put the effort in to adding features progressively.

> That's just plain wrong.

In theory yes, in practice no.

If code doesn't run in 1 of 2 the browser-engines we currently have, I would consider that a major short-coming preventing me from using it in production.

How many of your production end users are using firefox? Low single digits?

I am using Firefox, and I find that attitude among developers infuriating.

If not enough users are using a platform, let's actively sabotage for that platform by making it less viable, further justifying your own laziness? Is that it?

As someone who has gone from Amiga, to Mac, to Windows PCs, to FreeBSD and now Linux (not to mention the smart-phone story!), I take pride in my work being portable and cross-platform friendly. I have absolutely no desire to go back to the mono-culture days of MSIE.

If you put it on the web, it should work everywhere, otherwise you're just being lazy and/or incompetent.

Being portable and cross-platform doesn't mean you can't take advantage of things unique to a subset of platforms to provide a better user experience on those platforms. You just need to check for support and provide fallback on those platforms without support. One could easily argue that just using the lowest common denominator across platforms is in fact the lazy and/or incompetent option.

Also you mentioned in another comment there being 2 browser-engines. There are in fact 3 major browser-engines.

> Also you mentioned in another comment there being 2 browser-engines. There are in fact 3 major browser-engines.

Fair enough. I was thinking in terms of browser-engine families (WebKit-based, Gecko-based) and tried to keep things simple, because I didn't want to overcomplicate my comment.

You're right though that there's Google WebKit (Blink) and straight WebKit and that does make a difference which matters in this context.

> If you put it on the web, it should work everywhere, otherwise you're just being lazy and/or incompetent.

Everywhere? Do you support IE6 users too?

Most of what I put on the public internet supports IE6 just fine.

It might not look as pretty but if nothing else (TLS etc) stands in the way it should Just Work (TM) thanks to the magic of generating the content on the server side and also careful use of CSS.

Very dangerous position and self-defeating.

I am my own favorite production end user and I use firefox.

Do you think those numbers have anything to do with the fact that there's an encroaching browser monoculture right now, hearkening back to the IE6 days?

"Chrome isn't becoming IE6, Chrome is actually good" ~ A person who didn't use IE6 when it was new.

If memory serves, IE5.5 was actually a belter of a release and came at a point that Netscape Navigator (*spit!) was beginning to really cause trouble.

Still didn't mean I'd've been happy with a monoculture, no matter how swear-inducing things got.

Strange for me to think al these years later that my beloved Firefox came from the ashes of Netscape!

I have memories of a Microsoft evangelist in the 90s. He told us "IE4 is good but everybody uses Netscape." IE4 wasn't that good IMHO, IE5 was probably better than Netscape (the company was starting to collapse) and IE6 was the better browser by far, until it stagnated and Firefox appeared.

I can understand the down votes but it's an interesting question nonetheless. I'm a Firefox user, but my customers? 5%. I'm still surprised by this.

> I'm still surprised by this.

What you are observing is the same thing that got Microsoft in anti-trust trouble back in the days, but which is now being done web-scale instead of desktop-scale by Google.

Also, Google is/was bundling Chrome as a drive-by installation with lots of other popular downloads, so less competent users got their (other) browsers replaced by Chrome, possibly without knowing.

...and what if it is in the low single digits? 1% of 10000 is still a 100 (potentially paying) users. Should we abandon accessibility efforts as well because of the low single digits users?

What kind of thought lead to such questions even being asked in this community or presumably intelligent people ?

If your attitude had been prevalent in 200x we had still been stuck with IE6.

The reason we aren't is because we "old" devs fought against it and got lucky that Microsoft forgot IE at the same time as Firefox became really good.

Today Firefox is getting good again (edit: see added footnote [0]) and Google only needs to do a couple of mistakes, and that includes the one which they already seems pretty committed to - or maybe get some IMO really well deserved punishment for anti competitive behavior - before things become more competitive.

But that still depends on us fighting to keep the web cross browser compatible until then.

[0]: for my and many others purposes it was always better, I actually tried toblike Chrome back when it was the underdog and it just never cut it for me

HN users are probably offended by this comment but the truth is outside of devs very few people use FF. What I see around me is that people use either Chrome or Safari, but mostly Chrome.

Personally, I tried to use FF a couple of months ago but it didn't work for me.

> 1 of 2 the browser-engines we currently have

Not only does WebKit exist, there are more WebKit users than Gecko users.

You're right, it doesn't run in 2 out of the 3 browser-engines we currently have. Which actually makes the GPs point even more important.

Or do you also want to include the fringe engines like kHTML, Trident, links, etc too...all of which also wouldn't run the APIs in question?

The Clipboard API is in Webkit - https://webkit.org/blog/10855/async-clipboard-api/

I haven't checked the others because I don't use them, but that one is.

> Or do you also want to include the fringe engines like kHTML, Trident, links, etc too...all of which also wouldn't run the APIs in question?

Don't try to get me to defend a point that I never made in an argument that I never weighed in on. The only point I was making was to correct the more-than-implied false claim that we have "2 browser engines". And I think I made it clear by pointing out that WebKit is bigger than Gecko that if Gecko is a valid consideration that WebKit cannot be considered "fringe".

[deleted]

The authors aren't listed in the spec. You're looking at the editors. Anyone can contribute to the spec, and lots of people from Mozilla do. Taking the first one as an example, https://github.com/w3c/clipboard-apis/graphs/contributors, marcoscaceres, janiceshiu, and Johanna-hub are current or former Mozilla staff, and plenty more who don't say one way or the other on their profile.

Mozilla and Apple have publicly announced that they will not implement the Bluetooth and Battery APIs [1][2], which makes them definitely Chrome proprietary APIs.

These kind of proprietary APIs are exactly what Microsoft did 10-20 years ago as part of their "embrace, extend and exterminate" process. They extended IE with their proprietary APIs (such as HTML+TIME), which other browsers never implemented.

Bluetooth, Battery and many other Chrome APIs are just Google's and Microsoft's new attempt to "embrace, extend and exterminate" other browsers.

[1] https://www.zdnet.com/article/apple-declined-to-implement-16... [2] https://mozilla.github.io/standards-positions/

Mozilla and Apple have publicly announced that they will not implement the Bluetooth and Battery APIs [1][2], which makes them definitely Chrome proprietary APIs.

I realise this is a bit pedantic, but this is wrong. They're W3C specs that Mozilla and Apple have chosen not to support. Calling them "Chrome proprietary APIs" is loaded with unnecessary and unhelpful subtext.

If we really want to be pedantic, then I must point out that they're not W3C standards and likely never will be.

- Battery Status API was on a standards track but the last published version is a Candidate Recommendation from 2016

- Web Bluetooth is just a Community Group Draft. It's not even formally adopted by a Working Group.

Neither is likely to progress to Recommendation status as the W3C - IMHO, wisely - requires to independent implementations before a specification is adopted as a web standard.

If we really want to be pedantic the post your comment refers to never said they were W3C standards. It referred to them as W3C specs which since they are api specifications and published by the W3C is accurate even if they are not standards.

It seems like we're really far down the "arguing semantics" curve at this point.

The practical consideration is: These APIs are only supported by one browser. Other major browsers have announced that they have no intention of supporting them. Therefore, use them with caution. If it's an Electron app and nothing but an Electron app, you're probably good to go. If, OTOH, it's a web page or site, and you don't want to alienate non-Chrome users (which would include all iOS users), then you should make sure you aren't doing anything janky when these APIs aren't available or don't work as advertised.

If we really want to be pedantic these APIs are only supported by one browser engine but are supported by multiple browsers.

Fair point. I do tend to forget about Edge and Opera.

I think the general thrust of what I'm trying to say stands, though: The grotty procedural details surrounding W3C standards are something that can be left to the W3C to worry about. For those of us who think C-SPAN is boring, the presence of a particular webpage at a particular location on the W3C's website serves as a really bad proxy for browser support statistics.

It goes well beyond Opera and Edge.

Looking at the netmarketshare stats for August there are 14 browsers which use the blink engine and have a reported market share. Brave is not on the list since it currently reports itself as Chrome. 2 of those browsers have a market share higher than Firefox, Microsoft Edge and Samsung Internet Browser. Samsung Internet Browser is a mobile only browser which ships on Samsung phones and tablets. Removing those and Chrome the remaining 9 blink based browsers combined still have a higher market share than Firefox.

If we are going to assume that the term 'Web APIs' doesn't presuppose W3C standard-track documents at a minimum, rather than just "the W3C has a document on this", then I think it's safe to say that we are more interested in being argumentative than in communicating.

Just to be clear, "Battery Status" is not a "W3C spec". The latest published version at https://www.w3.org/TR/battery-status/ is "Candidate Recommendation", and has been stuck there for over four years, precisely because it's failing to meet the bar to progress to "Recommendation".

And the reason it's failing to meet that bar is because of fundamental and unaddressed privacy problems with the proposal.

Calling it a "Chrome proprietary API" is exactly correct at this point.

I remember Microsoft was generally pretty good about submitting their stuff to the W3C as part of the embrace, extend, extinguish policy - example the Note on VML https://www.w3.org/TR/NOTE-VML

Bluetooth API would be very nice. Now you are forced to make an iOS app.

Google essentially controls the W3C now.

They also develop the browser that has the sheer majority of users and fund almost exclusively the only real technical competitor. This is really worrying.

Safari? And just because MS is rebasing on Chromium doesn’t mean they still don’t have a lot of technical might to throw at Edgeium.

> that Firefox doesn't support yet.

> This specification was published by the Web Bluetooth Community Group. It is not a W3C Standard nor is it on the W3C Standards Track.

It's not a Chrome API because nobody else supports it yet, it's a Chrome API because nobody other than Chrome is going to support it. Ideally, Chrome itself should remove their implementation.

The Web Bluetooth debacle is a good example of why new browser APIs shouldn't be turned on for end users by default until after they get far enough in the standards process that they we know they're not going to be rejected.

That "(in various states)" is very important. They're all drafts except for the performance API which is an RC.

The four also seem really fit for fingerprinting. We don't need the web to have all the capabilities of a regular application.

Firefox supports at least some of the clipboard APIs. They'll likely support a few more in future (like the async variants). But they tend to implement them a little slower and leave out a few bits due to privacy concerns.

Could it be that you've got antitracking mechanisms enabled? Noscript, enhanced tracking protection or something else? They could very well prevent Firefox from accessing said APIs

Edit: never mind, I just checked some, and they're all not supported according to caniuse. Interesting to see Firefox used to support battery api, but was removed for public consumption as of 52 due to privacy concerns.

Yeah, I'm not sure Firefox would choose to implement some of the APIs in the not implemented list. The chance they can be used for fingerprinting is pretty high.

The battery API has been in the news before:

https://www.theguardian.com/technology/2016/nov/01/firefox-d...

Firefox supports the performance API for timing, but not for memory.

Also, full screen doesn't work in iOS Safari. It was supported but that support was removed several years ago (I want to say 2014, but may be a little off).

Off the top of my head, i believe it only works on iPad Safari?

The Clipboard API demo works fine in Safari.

Reply on news.ycombinator.com