- From: Tobie Langel <tobie@fb.com>
- Date: Tue, 19 Jun 2012 22:15:34 +0000
- To: Sylvain Galineau <sylvaing@microsoft.com>, 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>
On 6/20/12 12:05 AM, "Sylvain Galineau" <sylvaing@microsoft.com> wrote: > >[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....) Can't agree more. Unpublished / hard to find use cases makes everyone's life harder and worsens the perception authors have of spec writers and implementors. Calling them authors doesn't help, either. :-/ --tobie
Received on Tuesday, 19 June 2012 22:16:14 UTC