- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 19 May 2008 15:14:26 -0700
- To: Sunava Dutta <sunavad@windows.microsoft.com>
- CC: Anne van Kesteren <annevk@opera.com>, Julian Reschke <julian.reschke@gmx.de>, Maciej Stachowiak <mjs@apple.com>, "Web API WG (public)" <public-webapi@w3.org>, IE8 Core AJAX SWAT Team <ieajax@microsoft.com>
Sunava Dutta wrote: >>> setRequestHeader() currently simply is broken. We should deprecate it, >>> and add new methods with well-defined semantics: >>> >>> - removeHeader(...) (or specify set with null to mean remove) >>> - addHeader... >>> - getHeader... >> "Deprecating" a method does not help implementations converge. Besides, >> for typical usage there's no issue in using this header at all. >> > [Sunava Dutta] I agree with Anne here. Deprecating an existing > implementations and re-engineering XHR is something we just cannot > accept. This spec should be designed to reflect reality and seek > interoperability for each and every single section/method/event with > at least one (I think the W3C mandates two?) existing implementations. > That does not mean the entire spec is aligned with FF or IE, but it > should be harmonious at any instance with one existing implementation. There is absolutely no W3C mandate that a spec is compatible with any existing implementations in order to reach the earlier milestones in the standardization track. Not sure where you got that idea. It would be very strange if there was a requirement to have implementations in order to reach LC, when W3C is discouraging implementations at that stage. Also, I personally don't care at all which UAs the various features of spec is compatible with. Or if it's not compatible with any UA. What I care about is that the spec is compatible with the web, and in the cases where the web doesn't care, that it's as useful and simple as possible. / Jonas
Received on Monday, 19 May 2008 22:16:58 UTC