- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Mon, 19 May 2008 17:30:34 -0500
- To: Sunava Dutta <sunavad@windows.microsoft.com>
- CC: "Web API WG (public)" <public-webapi@w3.org>, IE8 Core AJAX SWAT Team <ieajax@microsoft.com>
Sunava Dutta wrote: > I think you mean compatible with browsers who enable > the technologies when you mean compatible with the web? "Compatible with the web" means that when a UA implements the specification as written it will encounter either no reports of pages broken due to that implementation or a very very small number of them. One possible way to do that is to implement exactly what the market leader implements, although even that is no guarantee if sites work around some behavior of the market leader based on UA sniffing. In reality, what's needed here is that all "commonly used" functionality (and yes, this is an imprecise term; so is "compatible with the web" in the end) is specified the way websites expect it to work. Whether they expect it because of some other implementation, because of a popular book, because of documentation somewhere, or for some other reason is not relevant. What's relevant is what they expect when they write their code. > I'm amenable to what Maciej > said when he mentioned that in the case (I'm assuming this is a rarity) where > the implementations are doing whacky things or doing nothing at all, it makes > sense to work together to identify a way/solution that will allow for > convergence. Right. Any time implementations disagree, the most likely conclusion is that the point on which they don't agree is not used much, if at all, by websites. Therefore the exact behavior the spec requires on that point doesn't affect the "compatible with the web" criterion. -Boris
Received on Monday, 19 May 2008 22:31:31 UTC