- From: Anne van Kesteren <annevk@opera.com>
- Date: Thu, 20 Oct 2011 11:15:10 +0900
- To: "public-web-perf@w3.org" <public-web-perf@w3.org>, "Jatinder Mann" <jmann@microsoft.com>
On Thu, 20 Oct 2011 02:19:31 +0900, Jatinder Mann <jmann@microsoft.com> wrote: > We had a similar discussion in the Page Visibility review, and came to > the same conclusion that having constants has the advantage of allowing > web developers to inspect for capability via developer tools and IDEs > rather than read the specification. Yes, and I disagreed with that outcome because it is flat out different from the other APIs we are designing for the web platform. We want consistency for developers. If you think APIs that use strings need constants, you should start by convincing APIs that already use this string-pattern to adopt constants before unilaterally adding it to your own APIs. It's fine that you think you this is better API design, but you should first convince the rest of the people working on the web platform before making incompatible designs. Otherwise developers end up with a confusing mess. > I don't believe WebIDL currently supports enums; based on this thread, > http://lists.w3.org/Archives/Public/public-script-coord/2011AprJun/0111.html, > appears like integer enums may be considered in a future version of the > spec. When we actually support string enums, we can update the > specification. By that time you might already have a test suite that tests for constants and claim compatibility will be broken if we remove them. That is not at all an acceptable resolution. If the Working Group refuses to address this problem I would like to raise a Formal Objection with my reasoning as per above. Knowingly introducing inconsistent APIs is bad. -- Anne van Kesteren http://annevankesteren.nl/
Received on Thursday, 20 October 2011 02:15:49 UTC