Re: [whatwg] Removing mediagroup/MediaController from HTML

[David Singer]

> On Oct 1, 2015, at 6:49 , Anne van Kesteren  wrote:
> 
> In https://github.com/whatwg/html/issues/192 we're planning on
> removing mediagroup/MediaController from HTML since other than WebKit
> no implementations appear interested in implementing these features.

Hi

is removal really the right thing to do, given that we have an implementation?  
I can understand a note saying that this interface is not currently broadly 
implemented, as a warning to authors.  If there are technical problems, and we 
have or can imagine a better replacement, I can imagine deprecation as a 
warning to both implementors and authors. But making an implementation become 
undocumented seems strange — and 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.



David Singer
Manager, Software Standards, Apple Inc.

Re: [whatwg] Removing mediagroup/MediaController from HTML

[Domenic Denicola]

From: whatwg [mailto:whatwg-boun...@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  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.

[whatwg] XML/HTML Entities draft

[David Carlisle]

Ian,
Not sure if you still use a "live" copy of unicode.xml
and hopefully there will never be a need to change the
HTML character entity definitions but anyway



The editor's draft of the entities spec has been moved to github

https://w3c.github.io/xml-entities/

(The old URL at http://www.w3.org/2003/entities/2007doc/ redirects to the same 
thing)

In particular this now means that unicode.xml and other source files
are more easily tracked by other projects. (I know several browser
and latex-to-xxx projects are using that in one way or another.)

The sources are at

https://github.com/w3c/xml-entities



David





The Numerical Algorithms Group Ltd is a company registered in England and Wales 
with company number 1249803. The registered office is:

Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.



This e-mail has been scanned for all viruses by Microsoft Office 365.

Re: [whatwg] XML/HTML Entities draft

[Ian Hickson]

On Fri, 2 Oct 2015, David Carlisle wrote:
> 
> Ian,
> Not sure if you still use a "live" copy of unicode.xml
> and hopefully there will never be a need to change the
> HTML character entity definitions but anyway
> 
> > The editor's draft of the entities spec has been moved to github
> > 
> > https://w3c.github.io/xml-entities/
> > 
> > (The old URL at http://www.w3.org/2003/entities/2007doc/ redirects to the
> > same thing)
> > 
> > In particular this now means that unicode.xml and other source files
> > are more easily tracked by other projects. (I know several browser
> > and latex-to-xxx projects are using that in one way or another.)
> > 
> > The sources are at
> > 
> > https://github.com/w3c/xml-entities

Thanks for the heads-up, David!

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'