- From: Sylvain Galineau <sylvaing@microsoft.com>
- Date: Tue, 19 Jun 2012 22:05:36 +0000
- To: Daniel Glazman <daniel.glazman@disruptive-innovations.com>, fantasai <fantasai.lists@inkedblade.net>
- CC: Anne van Kesteren <annevk@annevk.nl>, Arthur Barstow <art.barstow@nokia.com>, Peter Linss <peter.linss@hp.com>, Chris Lilley <chris@w3.org>, public-webapps <public-webapps@w3.org>, "www-style@w3.org" <www-style@w3.org>
[Daniel Glazman:] > > > That's also the reason why I asked to explain requestFullscreen(). It can > sound obvious, but it's not. And in fact, we should _never_ introduce a new > syntax, API, whatever w/o saying _what it does_ from a functional point of > view before explaining how it works. > To the extent possible I think specs should document some of the core use-cases and scenarios they are derived from e.g. as an informative intro or appendix. Extra points for covering scenarios that are explicitly out of scope for the current version. This would be especially valuable for new specifications. I don't think people who don't live in WHATWG/W3C mailing lists and/or make browsers for a living can read a document like this one - or, say, CORS - and hope to figure out what problems they are/aren't trying to solve. (I'm not sure they're even that obvious for people who do....)
Received on Tuesday, 19 June 2012 22:06:30 UTC