- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 19 Jun 2008 15:10:37 -0700
- To: Zhenbin Xu <Zhenbin.Xu@microsoft.com>
- CC: Ian Hickson <ian@hixie.ch>, Sunava Dutta <sunavad@windows.microsoft.com>, Web API public <public-webapi@w3.org>, IE8 Core AJAX SWAT Team <ieajax@microsoft.com>, "public-webapps@w3.org" <public-webapps@w3.org>
Zhenbin Xu wrote: > I think we are now off track. > > Nonetheless we should realize that customer cannot > write an interoperable page with my fictional home grown browser if it doesn't exist > or doesn't have the needed feature when the page was written. I doubt customers > would write against particular browser if equal efforts can results in interoperable > solutions run on top multiple browsers. Now that the solutions are in place, they > deserve our consideration. > > I would argue it is important to think about customer's migration path when we design > new feature or standardizing existing ones. Otherwise we would be painting customers > into corner and blaming them for their dilemma. So I think the sticking point here is if there really are site interoperability issues or not. In the cases where all UAs behave the same way I certainly agree that that is a good indication that sites depend on that behavior, and so we should specify that behavior. However when existing UAs with significant marketshare do different things, then that is a good indication that sites don't really depend on any particular behavior. Especially if the UA vendors haven't received any input about this being a problem, despite having a large user base. In these cases I think we should choose the API that is most friendly towards JS developers. Of course it is debatable what is the best API from that point of view, but I would like to at least frame the discussion from that viewpoint in those cases. / Jonas
Received on Thursday, 19 June 2008 22:10:47 UTC