- From: Sunava Dutta <sunavad@windows.microsoft.com>
- Date: Mon, 19 May 2008 16:03:49 -0700
- To: Jonas Sicking <jonas@sicking.cc>
- 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>
Inline... > -----Original Message----- > From: Jonas Sicking [mailto:jonas@sicking.cc] > Sent: Monday, May 19, 2008 3:53 PM > To: Sunava Dutta > Cc: Anne van Kesteren; Julian Reschke; Maciej Stachowiak; Web API WG > (public); IE8 Core AJAX SWAT Team > Subject: Re: XHR LC comments > > Sunava Dutta wrote: > > Inline... > > > >> -----Original Message----- > >> From: Jonas Sicking [mailto:jonas@sicking.cc] > >> Sent: Monday, May 19, 2008 3:14 PM > >> To: Sunava Dutta > >> Cc: Anne van Kesteren; Julian Reschke; Maciej Stachowiak; Web API WG > >> (public); IE8 Core AJAX SWAT Team > >> Subject: Re: XHR LC comments > >> > >> 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 > > [Sunava Dutta] Compatible with the web sounds very nice and is > > something I think I share with you. I think you mean compatible with > > browsers who enable the technologies when you mean compatible with the > > web? > > No, I mean "able to run the javascript that exists on pages on the web". > So for example if there is an aspect to a feature that no, or very few, > web pages use, then I don't think we need to pay attention to what UAs > do today and instead make the best possible spec based on technical > considerations. [Sunava Dutta] Thanks for explaining. Yes, if features exist in XHR that web content does not rely on, we should absolutely drive to UA alignment with the reality. > > Figuring out what aspects webpages do or don't use is hard of course. > But often there are indications as well as implementation experience. > > > Getting back to more specifics, if we're talking about compatibility I > > absolutely believe the spec should be relevant to existing > > implementations. > > What do you mean by "relevant to existing implementations". And why do > you think that? [Sunava Dutta] Existing implementations means the web sites. I see the confusion, since I use the term implementation later on to mean browsers. > > > 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. > > It is in fact quite common when you start looking at the details of the > various features that implementations behave very differently. So in > those details we should in my opinion use the strategy I described above. > > / Jonas
Received on Monday, 19 May 2008 23:04:36 UTC