RE: XHR LC comments

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