Re: {Spam?} Re: [xhr]

On Wed, Sep 3, 2014 at 11:11 PM, Jonas Sicking wrote: > Agreed. Making it a conformance requirement not to use sync XHR seems > like a good idea. It is a conformance requirement. "Developers must not pass false for the async argument when the JavaScript global environment is a document environmen

Re: {Spam?} Re: [xhr]

On Wed, Sep 3, 2014 at 2:01 PM, Tab Atkins Jr. wrote: > On Wed, Sep 3, 2014 at 12:45 PM, Glenn Maynard wrote: >> My only issue is the wording: it doesn't make sense to have normative >> language saying "you must not use this feature". This should be a >> non-normative note warning that this shou

Re: {Spam?} Re: [xhr]

On Wed, Sep 3, 2014 at 10:49 AM, Anne van Kesteren wrote: > On Wed, Sep 3, 2014 at 7:07 PM, Ian Hickson wrote: >> Hear hear. Indeed, a large part of moving to a "living standard" model is >> all about maintaining the agility to respond to changes to avoid having to >> make this very kind of asser

Re: {Spam?} Re: [xhr]

On Wed, Sep 3, 2014 at 12:45 PM, Glenn Maynard wrote: > My only issue is the wording: it doesn't make sense to have normative > language saying "you must not use this feature". This should be a > non-normative note warning that this shouldn't be used, not a normative > requirement telling people

Re: {Spam?} Re: [xhr]

(Branden, your mails keep getting "{Spam?}" put in the header, which means every time you post, you create a new thread for Gmail users. I guess it's the list software to blame for changing subject lines, but it's making a mess of this thread...) On Wed, Sep 3, 2014 at 12:49 PM, Anne van Kesteren

Re: {Spam?} Re: [xhr]

On Wed, 3 Sep 2014, Anne van Kesteren wrote: > On Wed, Sep 3, 2014 at 7:07 PM, Ian Hickson wrote: > > Hear hear. Indeed, a large part of moving to a "living standard" model is > > all about maintaining the agility to respond to changes to avoid having to > > make this very kind of assertion. > >

Re: {Spam?} Re: [xhr]

On 9/3/14 8:25 AM, Robert Hanson wrote: That I think what is unclear from the writing of the warning are two things: Per the specs' "Participate" boilerplate, perhaps you should file a bug (^1). -Thanks, AB ^1

Re: {Spam?} Re: [xhr]

On Wed, Sep 3, 2014 at 7:07 PM, Ian Hickson wrote: > Hear hear. Indeed, a large part of moving to a "living standard" model is > all about maintaining the agility to respond to changes to avoid having to > make this very kind of assertion. See http://lists.w3.org/Archives/Public/public-webapps/2

Re: {Spam?} Re: [xhr]

On Tue, 2 Sep 2014, Brendan Eich wrote: > > Also (I am a WHATWG cofounder) it is overreach to promise obsolescence on any > timeline on the Web. Robert should not worry about real browser implementors > breaking content by removing sync XHR -- to do so would be to lose market > share. > > In this

Re: {Spam?} Re: {Spam?} Re: [xhr]

Brendan Eich wrote: In this light, WHATWG should avoid making indefinite-timescale, over-ambitious assertions. The W3C was rightly faulted when we founded the WHATWG for doing so. My apologies for a minor error: Anne informs me off-list that "W3C" (who?) added the warning. Not that it should

Re: {Spam?} Re: [xhr]

That I think what is unclear from the writing of the warning are two things: 1) It *appears *to be part of the spec. (The parts before say they are non-normative, but this section does not.) And it uses the word "must" -- implying that it is a requirement, not a recommendation. 2) Perhaps it is j

Re: {Spam?} Re: [xhr]

On 9/2/14 9:10 PM, Brendan Eich wrote: cha...@yandex-team.ru wrote: Sorry. As with showModalDialog() we would really like to make this > feature disappear. I realize this makes some forms of code generation > harder, but hopefully you can find a way around that in time. Perhaps we should s

Re: {Spam?} Re: [xhr]

cha...@yandex-team.ru wrote: Sorry. As with showModalDialog() we would really like to make this > feature disappear. I realize this makes some forms of code generation > harder, but hopefully you can find a way around that in time. Perhaps we should set some sense of expectation about*when*