search

WICG / interventions

A place for browsers and web developers to collaborate on user agent interventions.
Other
177 stars 28 forks source link

Deprecate and remove WebSQL #46

Closed nolanlawson closed 2 years ago

nolanlawson commented 7 years ago

The WebSQL spec has been deprecated with a big scary warning since 2011. We had a fairly long discussion with Google folks recently about WebSQL usage on the web (@drufball / @rbyers feel free to share that usage data if you'd like :smiley:). In any case, usage still remains nonzero in 2017, although Chrome has dropped support inside of web workers in Chrome 39 and Safari dropped it in Safari 9.

I believe that adding a console warning to openDatabase() will help hasten the end of WebSQL. Currently many developers are unaware of WebSQL's deprecation, because they write (for instance) Ionic/Cordova apps where the SQLite Plugin is very much alive and well, and then when they develop locally in Chrome they use openDatabase() because it's largely API-compatible.

This is bad for the web. Folks continue to write web applications that are effectively WebKit/Blink-only. They may start by writing a hybrid iOS+Android app, and then discover when they want to take it to the web (e.g. as a PWA) that they have to rewrite it for compatibility with Firefox/Edge. Some major websites (e.g. GMail) are still using WebSQL.

My proposal: if the site calls openDatabase(), show a warning similar to the one for non-passive event listeners:

2017-02-17 15_12_59-about_blank

I wouldn't recommend adding a warning for any openDatabase usage, because IDB wrappers like PouchDB and LocalForage use typeof openDatabase as part of their feature detection. But if the site calls openDatabase(), it would be great to show a warning and eventually remove support entirely.

In terms of webcompat, it may be good to align with market penetration of Safari 10.1, since both PouchDB and LocalForage are considering 10.1 as the cutoff for IDB support.

/cc @aliams

nolanlawson commented 7 years ago

@RByers Per discussion on Twitter: I realize this isn't much like the other interventions in that it's not user-focused. In fact there is no upside for users, and only downsides for Chrome/Safari (i.e. some websites stop working). The only upsides are for Edge, Firefox, and the web at large. :wink:

That's why my proposal is that we just start off with a warning. Let people know it's deprecated! Let's make sure that the flow of new WebSQL users stops, and at that point we're only left with legacy costs. Then we can approach the legacy costs with IDB extensions or RDB or whatever we need to make those existing WebSQL users happy.

RByers commented 7 years ago

We've got a (relatively new) policy on Chrome of not adding "hopeful" deprecation warnings - those that claim an API is deprecated without any concrete plan for removal. However we have a new tool for such things - off-by-default messages ("verbose" log level) which developers can explicitly enable in devtools or surface via other audit tools like Lighthouse. I'd support using that to warn about WebSQL with an appropriately worded message like "Non-standard and may be removed in the future". @inexorabletash WDYT?

inexorabletash commented 7 years ago

@RByers - Sounds cool - I was unaware of that new tool. Audits (like Lighthouse) make sense especially when we can point out compat issues. There are several other storage-related APIs we could tag that way, such as FileSystem.

File a crbug? (I'm OOO at the moment)

nolanlawson commented 5 years ago

Apple is removing WebSQL from iOS Safari. :slightly_smiling_face:

ChrisNZL commented 5 years ago

Not just iOS Safari - macOS Safari too, according to that page.

Safari 13 ships with iOS 13 and macOS 10.15.

  • Removed support for WebSQL.
ststeiger commented 3 years ago

Why not remove IndexedDb instead.

johannhof commented 2 years ago

(As noted in https://github.com/WICG/interventions/pull/72, we intend to archive this repository and are thus triaging and resolving all open issues)

Aside from the question to what extent this is an intervention, it looks like there's largely cross-browser consensus that this should happen, with Chrome being the one that still needs to remove, which is tracked in https://crbug.com/695592. It seems safe to close this issue and follow-up with anything else on individual browser bugs.