W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2015

Re: [whatwg] Removing mediagroup/MediaController from HTML

From: Domenic Denicola <d@domenic.me>
Date: Fri, 2 Oct 2015 17:27:48 +0000
To: David Singer <singer@apple.com>, Anne van Kesteren <annevk@annevk.nl>
Message-ID: <CY1PR0501MB136932929D886FD33B20C0D1DF4B0@CY1PR0501MB1369.namprd05.prod.outlook.com>
Cc: WHATWG <whatwg@whatwg.org>
From: whatwg [mailto:whatwg-bounces@lists.whatwg.org] On Behalf Of

> is removal really the right thing to do, given that we have an
> implementation?

I agree this is a problematic question. I opened https://github.com/whatwg/html/issues/209 for the more general issue but am happy to have the discussion here since that hasn't gotten much replies. Do check out the examples listed there though. E.g. Blink is in similar situations with <dialog> and HTML imports.

The web seems to end up with a lot of APIs like this, where the spec ends up just being documentation for a single-vendor implementation. I don't really know what to do in these cases. If our goal in writing these specs is to produce an interoperable web platform, then such features seem like they shouldn't be part of the platform.

> as a point of practice, would seem to deter implementors from being first-to- implement of something, or they might get caught like this. That’s not a good incentive.

I'm not too worried about this. Implementers *should* be wary of implementing something alone, with no other vendors interested. Getting stuck with the only implementation of something is not good no matter what; having such features specced doesn't really make things better if you get caught in that situation.

Going forward we can be more vigilant about this, and not add things without at least interest from two vendors, and preferably commitment to implement.

The harder case is not about new features and who ships first, but about old features which only ever have one interested implementer, with no sign of that changing.
Received on Friday, 2 October 2015 17:28:20 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:35 UTC