[XHR] Dependencies in XHR

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

[XHR] Dependencies in XHR

Doug Schepers-3

Hi, WebAPI WG-

It seems that there are multiple dependencies upon HTML 5.0 in the XHR
specification.  As Team Contact, I would like to caution against this
approach, as the HTML 5.0 specification is a long time from being
stable, and this hinders implementation (particularly for vendors who
sell their browsers, and must therefore market them).

If possible, I would like to identify all dependencies and see if we can
remove them, or move them to a smaller, more manageable deliverable.
Anne (the editor) has helpfully marked these in the spec, which I
applaud as excellent speccing best practice.

"The terms origin and event handler DOM attribute are defined by the
HTML 5 specification."

I believe that "origin" can be defined in the Window Object
specification, one of this WG's explicit deliverables.

We have discussed adding consideration for "event handler DOM attribute"
in the DOM3 Events spec, such that a host language can define what that
means in its context


"Objects implementing the Window interface must provide an
XMLHttpRequest()  constructor."

Again, see Window Object spec.

"If there is a Content-Type header which contains a text/html MIME type
follow the rules set forth in the HTML 5 specification to determine the
character encoding. Let charset be the determined character encoding."

This is not, strictly speaking, a dependency.  It is a matter of each
host language defining its own value for charset.  Am I missing
something here?


I know that everything in the spec is normative unless marked otherwise,
but I just wanted to make sure that none of the references are informative?

Regards-
-Doug Schepers
W3C Team Contact, SVG, CDF, and WebAPI

Reply | Threaded
Open this post in threaded view
|

Re: [XHR] Dependencies in XHR

Anne van Kesteren-2

On Tue, 27 May 2008 18:59:38 +0200, Doug Schepers <[hidden email]> wrote:
> It seems that there are multiple dependencies upon HTML 5.0 in the XHR  
> specification.  As Team Contact, I would like to caution against this  
> approach, as the HTML 5.0 specification is a long time from being  
> stable, and this hinders implementation (particularly for vendors who  
> sell their browsers, and must therefore market them).

Vendors have actually requested this. The problem is summarized here:

   http://lists.w3.org/Archives/Public/public-webapi/2008May/0249.html


> If possible, I would like to identify all dependencies and see if we can  
> remove them, or move them to a smaller, more manageable deliverable.  
> Anne (the editor) has helpfully marked these in the spec, which I  
> applaud as excellent speccing best practice.
>
> "The terms origin and event handler DOM attribute are defined by the  
> HTML 5 specification."
>
> I believe that "origin" can be defined in the Window Object  
> specification, one of this WG's explicit deliverables.

In theory it could, yes. Until someone has done that it seems better for  
implementations to reference HTML5 as that has a better definition at the  
moment.


> We have discussed adding consideration for "event handler DOM attribute"  
> in the DOM3 Events spec, such that a host language can define what that  
> means in its context

Again, HTML5 currently has a better definition.


> "Objects implementing the Window interface must provide an  
> XMLHttpRequest()  constructor."
>
> Again, see Window Object spec.

The Window Object specification is not being maintained.


> "If there is a Content-Type header which contains a text/html MIME type  
> follow the rules set forth in the HTML 5 specification to determine the  
> character encoding. Let charset be the determined character encoding."
>
> This is not, strictly speaking, a dependency.  It is a matter of each  
> host language defining its own value for charset.  Am I missing  
> something here?

It's about determining the character encoding out of a stream of bytes.


> I know that everything in the spec is normative unless marked otherwise,  
> but I just wanted to make sure that none of the references are  
> informative?

There is one non-normative reference to HttpOnly cookies in the editor's  
draft, see:

   http://dev.w3.org/2006/webapi/XMLHttpRequest/#bibref


--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Reply | Threaded
Open this post in threaded view
|

Re: [XHR] Dependencies in XHR

Doug Schepers-3

Hi, Anne-

Anne van Kesteren wrote (on 5/27/08 6:24 PM):

> On Tue, 27 May 2008 18:59:38 +0200, Doug Schepers <[hidden email]> wrote:
>> It seems that there are multiple dependencies upon HTML 5.0 in the XHR
>> specification.  As Team Contact, I would like to caution against this
>> approach, as the HTML 5.0 specification is a long time from being
>> stable, and this hinders implementation (particularly for vendors who
>> sell their browsers, and must therefore market them).
>
> Vendors have actually requested this. The problem is summarized here:
>
>   http://lists.w3.org/Archives/Public/public-webapi/2008May/0249.html

Well... that's not quite a normative reference. :)

Could you please point to a specific request from a vendor requesting
that, rather than to your own email stating the claim?


>> If possible, I would like to identify all dependencies and see if we
>> can remove them, or move them to a smaller, more manageable
>> deliverable. Anne (the editor) has helpfully marked these in the spec,
>> which I applaud as excellent speccing best practice.
>>
>> "The terms origin and event handler DOM attribute are defined by the
>> HTML 5 specification."
>>
>> I believe that "origin" can be defined in the Window Object
>> specification, one of this WG's explicit deliverables.
>
> In theory it could, yes. Until someone has done that it seems better for
> implementations to reference HTML5 as that has a better definition at
> the moment.

I'm not convinced that it's better, since this is an LC draft.  That
means the WG thinks it's done, and thus that dependency will persist.


>> We have discussed adding consideration for "event handler DOM
>> attribute" in the DOM3 Events spec, such that a host language can
>> define what that means in its context
>
> Again, HTML5 currently has a better definition.

Okay, I'll work on that.


>> "Objects implementing the Window interface must provide an
>> XMLHttpRequest()  constructor."
>>
>> Again, see Window Object spec.
>
> The Window Object specification is not being maintained.

True.  Maybe we need to reprioritize, then.

Hey, Browser Implementors!  Anyone got an editor to spare?


>> "If there is a Content-Type header which contains a text/html MIME
>> type follow the rules set forth in the HTML 5 specification to
>> determine the character encoding. Let charset be the determined
>> character encoding."
>>
>> This is not, strictly speaking, a dependency.  It is a matter of each
>> host language defining its own value for charset.  Am I missing
>> something here?
>
> It's about determining the character encoding out of a stream of bytes.

Sure.  Is there some reason this can't be made generic and left to the
host language to define?


>> I know that everything in the spec is normative unless marked
>> otherwise, but I just wanted to make sure that none of the references
>> are informative?
>
> There is one non-normative reference to HttpOnly cookies in the editor's
> draft, see:
>
>   http://dev.w3.org/2006/webapi/XMLHttpRequest/#bibref

Okay, thanks.


--
Regards-
-Doug Schepers
W3C Team Contact, SVG, CDF, and WebAPI

Reply | Threaded
Open this post in threaded view
|

Re: [XHR] Dependencies in XHR

Anne van Kesteren-2

On Wed, 28 May 2008 00:58:45 +0200, Doug Schepers <[hidden email]> wrote:
>>  Vendors have actually requested this. The problem is summarized here:
>>    http://lists.w3.org/Archives/Public/public-webapi/2008May/0249.html
>
> Well... that's not quite a normative reference. :)

It was not a reference for that claim, it was a reference for the issue we  
have. It seems you're suggesting you rather leave it underdefined?


> Could you please point to a specific request from a vendor requesting  
> that, rather than to your own email stating the claim?

   http://lists.w3.org/Archives/Public/public-webapi/2008May/0245.html


>>> I believe that "origin" can be defined in the Window Object  
>>> specification, one of this WG's explicit deliverables.
>>  In theory it could, yes. Until someone has done that it seems better  
>> for implementations to reference HTML5 as that has a better definition  
>> at the moment.
>
> I'm not convinced that it's better, since this is an LC draft.  That  
> means the WG thinks it's done, and thus that dependency will persist.

It means the WG agrees that the concept referenced is important to the  
draft. If the concept moves to another draft the WG would surely agree  
that referencing the new draft where the concept is defined is acceptable.

More concrete, if Window moves out of HTML5 into its own separate  
specification updating the XMLHttpRequest CR to point to this new  
specification is a trivial matter. However, so far we have not seen any  
evidence of that happening so it seems better to reference HTML5 as it is  
still being updated in response to comments, etc.


>>> We have discussed adding consideration for "event handler DOM  
>>> attribute" in the DOM3 Events spec, such that a host language can  
>>> define what that means in its context
>>
>>  Again, HTML5 currently has a better definition.
>
> Okay, I'll work on that.

Great, though note that we reference DOM Level 2 Events currently as that  
is more stable and does everything XMLHttpRequest requires. Referencing  
DOM Level 3 Events instead would actually increase the number of instable  
dependencies.


>>> "If there is a Content-Type header which contains a text/html MIME  
>>> type follow the rules set forth in the HTML 5 specification to  
>>> determine the character encoding. Let charset be the determined  
>>> character encoding."
>>>
>>> This is not, strictly speaking, a dependency.  It is a matter of each  
>>> host language defining its own value for charset.  Am I missing  
>>> something here?
>>  It's about determining the character encoding out of a stream of bytes.
>
> Sure.  Is there some reason this can't be made generic and left to the  
> host language to define?

I'm not sure what you're talking about here.


Note that we also rely on HTML5 for document.innerHTML to define proper  
serialization of a Document object.


--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Reply | Threaded
Open this post in threaded view
|

Re: [XHR] Dependencies in XHR

Doug Schepers-3

Hi, Anne-

Anne van Kesteren wrote (on 5/27/08 7:17 PM):
>
> On Wed, 28 May 2008 00:58:45 +0200, Doug Schepers <[hidden email]> wrote:
>>>  Vendors have actually requested this. The problem is summarized here:
>>>    http://lists.w3.org/Archives/Public/public-webapi/2008May/0249.html
>>
>> Well... that's not quite a normative reference. :)
>
> It was not a reference for that claim, it was a reference for the issue
> we have. It seems you're suggesting you rather leave it underdefined?

No, I want it defined somewhere that there isn't a long wait on a
dependency chain.  I assume you're not claiming that vendors have asked
for the opposite... but I'd be entertained by a link to that reference. :)

Seriously, I'm not sure what your point was here... I explained that
commercial browser vendors prefer stable, mature specs, without
unresolved dependencies... could you clarify why that isn't a concern?



>>>> We have discussed adding consideration for "event handler DOM
>>>> attribute" in the DOM3 Events spec, such that a host language can
>>>> define what that means in its context
>>>
>>>  Again, HTML5 currently has a better definition.
>>
>> Okay, I'll work on that.
>
> Great, though note that we reference DOM Level 2 Events currently as
> that is more stable and does everything XMLHttpRequest requires.
> Referencing DOM Level 3 Events instead would actually increase the
> number of instable dependencies.

Yes, let's reevaluate that in light of progress on DOM3 Events shortly.


>> Sure.  Is there some reason this can't be made generic and left to the
>> host language to define?
>
> I'm not sure what you're talking about here.

I'm asking for an explanation about the nature of the dependency, vis a
vis the necessary level of details in XHR.


> Note that we also rely on HTML5 for document.innerHTML to define proper
> serialization of a Document object.

Noted.  Any proposal on how that can be resolved?

Regards-
-Doug Schepers
W3C Team Contact, SVG, CDF, and WebAPI

Reply | Threaded
Open this post in threaded view
|

Re: [XHR] Dependencies in XHR

Ian Hickson
In reply to this post by Doug Schepers-3

On Tue, 27 May 2008, Doug Schepers wrote:

>
> It seems that there are multiple dependencies upon HTML 5.0 in the XHR
> specification.  As Team Contact, I would like to caution against this
> approach, as the HTML 5.0 specification is a long time from being
> stable, and this hinders implementation (particularly for vendors who
> sell their browsers, and must therefore market them). [...]
>
> I believe that "origin" can be defined in the Window Object
> specification, one of this WG's explicit deliverables.
>
> "Objects implementing the Window interface must provide an
> XMLHttpRequest() constructor."
>
> Again, see Window Object spec.

Um, if we're going to be moving the references away from HTML5, could we
at least move them to specs that have a chance of actually getting
maintained sometime this decade?


> We have discussed adding consideration for "event handler DOM attribute"
> in the DOM3 Events spec, such that a host language can define what that
> means in its context

That would be great, I'd love to offload this part of HTML5. Do you have a
plan for how to resolve the dependency between event handler DOM
attribute processing and the designMode DOM attribute? Also, please
remember to deal with the mouseover event's quirk when doing this.

Cheers,
--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Reply | Threaded
Open this post in threaded view
|

Re: [XHR] Dependencies in XHR

Doug Schepers-3

Hi, Ian-

Ian Hickson wrote (on 5/27/08 8:44 PM):

> On Tue, 27 May 2008, Doug Schepers wrote:
>>
>> I believe that "origin" can be defined in the Window Object
>> specification, one of this WG's explicit deliverables.
>>
>> "Objects implementing the Window interface must provide an
>> XMLHttpRequest() constructor."
>>
>> Again, see Window Object spec.
>
> Um, if we're going to be moving the references away from HTML5, could we
> at least move them to specs that have a chance of actually getting
> maintained sometime this decade?

Obviously, we would only move references if there were a spec that
adequately covers the necessary material.  If the Window Object spec is
not taken up, then clearly it would be inappropriate.


>> We have discussed adding consideration for "event handler DOM attribute"
>> in the DOM3 Events spec, such that a host language can define what that
>> means in its context
>
> That would be great, I'd love to offload this part of HTML5. Do you have a
> plan for how to resolve the dependency between event handler DOM
> attribute processing and the designMode DOM attribute? Also, please
> remember to deal with the mouseover event's quirk when doing this.

(This seems like a sarcastic and combative reply, for no good reason.)

Perhaps I misunderstood the issue.  My impression was that Anne was
referring to the definition for the "onfoo" event handlers, as stated in
the HTML 5.0 spec:

"Event handler DOM attributes, on setting, must set the corresponding
event handler attribute to their new value, and on getting, must return
whatever the current value of the corresponding event handler attribute
is (possibly null)." [1]

We had discussed, in the DOM3 Events telcons, that we might define the
general mechanism for "onfoo" attributes, and their relationship to
named events, addEventListener, et al.  A host language, such as HTML or
SVG, would define the specific event handler attributes appropriate to
that language, and provide details about the event.  The host language
would also cover the particulars of the quirks you mention (so, sorry,
but you're stuck with that task).

Are you saying that this is not a useful addition to DOM3 Events?  Or
that you don't think that this adequately covers what is needed for XHR
(which seems only to require a definition, from my reading)?

I'm interested to hear your feedback on what would be useful for the
DOM3 Events spec to say on the matter, beyond (on in contradiction to)
what I have already described as the intent.


[1] http://www.w3.org/html/wg/html5/#event4

Regards-
-Doug Schepers
W3C Team Contact, SVG, CDF, and WebAPI

Reply | Threaded
Open this post in threaded view
|

Event handler attributes (Was: Dependencies in XHR)

Ian Hickson

On Tue, 27 May 2008, Doug Schepers wrote:

> > >
> > > We have discussed adding consideration for "event handler DOM
> > > attribute" in the DOM3 Events spec, such that a host language can
> > > define what that means in its context
> >
> > That would be great, I'd love to offload this part of HTML5. Do you
> > have a plan for how to resolve the dependency between event handler
> > DOM attribute processing and the designMode DOM attribute? Also,
> > please remember to deal with the mouseover event's quirk when doing
> > this.
>
> (This seems like a sarcastic and combative reply, for no good reason.)

Sorry, that was not the intent.


> Perhaps I misunderstood the issue.  My impression was that Anne was
> referring to the definition for the "onfoo" event handlers, as stated in
> the HTML 5.0 spec:
>
> "Event handler DOM attributes, on setting, must set the corresponding
> event handler attribute to their new value, and on getting, must return
> whatever the current value of the corresponding event handler attribute
> is (possibly null)."

Right, that is indeed what I'm talking about (that and the event handler
content attributes).

I really would like this to be taken out of HTML5 and turned into a
generic mechanism.


> A host language, such as HTML or SVG, would define the specific event
> handler attributes appropriate to that language, and provide details
> about the event.  The host language would also cover the particulars of
> the quirks you mention (so, sorry, but you're stuck with that task).

designMode's quirks aren't HTML-specific, they apply equally to SVG event
handlers. I expect (but haven't tested) that the same applies to
onmouseover's quirks. I certainly would rather all the behaviour was
defined in one place than requiring implementors to have to
cross-reference multiple specs to get this done right.

(In particular, I think we really need to get over the concept of "but
that's a host language issue" or "that doesn't belong in my spec" and so
on -- we're defining a single platform here, it isn't useful for us to be
declining responsibility over the more complicated parts. While the theory
of orthogonal technologies would have been nice, the Web is at a point
where all the technologies are embedded in each other to some extent, and
we should embrace that, not try to deny it. We will have a healthier
technology stack if we consider the HTML and SVG specs, say, to be
different chapters of the same language spec, rather than if we consider
them to be separate languages.)

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Reply | Threaded
Open this post in threaded view
|

Re: Event handler attributes (Was: Dependencies in XHR)

Maciej Stachowiak


On May 27, 2008, at 11:56 PM, Ian Hickson wrote:

>
> (In particular, I think we really need to get over the concept of "but
> that's a host language issue" or "that doesn't belong in my spec"  
> and so
> on -- we're defining a single platform here, it isn't useful for us  
> to be
> declining responsibility over the more complicated parts. While the  
> theory
> of orthogonal technologies would have been nice, the Web is at a point
> where all the technologies are embedded in each other to some  
> extent, and
> we should embrace that, not try to deny it. We will have a healthier
> technology stack if we consider the HTML and SVG specs, say, to be
> different chapters of the same language spec, rather than if we  
> consider
> them to be separate languages.)

I strongly agree with this sentiment. I strongly prefer if similar  
concepts shared between SVG and HTML can be defined in a consistent  
way in a single place. I would say many parts of HTML5 arguably fall  
in this category and I am ok with them being in HTML5 mainly as a  
matter of expediency, and I hope that in time these things can be  
factored out. Every little thing like this that is different is a  
point of pain for implementors of and authors in the emerging Web  
platform that includes both HTML and SVG.

If any such items can be factored sooner rather than later, then that  
will be welcome news. I apologize also for the item I volunteered to  
factor out but have not taken to completion (the Window object). It  
turned out to be a lot harder to do than I expected going in.

Regards,
Maciej


Reply | Threaded
Open this post in threaded view
|

Re: Event handler attributes (Was: Dependencies in XHR)

Jon Ferraiolo-2

FWIW - I generally agree with Maciej's perspective. In the early days of SVG when I was authoring many of the proposals that (after discussion and subsequent modification) ended up in the SVG spec, what I was thinking was that HTML and SVG shared all of the same infrastructure (e.g., scripting, styling, eventing, DOM, hyperlinking), and most definitely the same events and event attribute, but were separate languages. Truthfully, I had the HTML and PDF specs open on my desk, and I took the graphics model from PDF and pretty much everything else from HTML. In my mind, the key area of difference was that HTML was about flowable documents organized into paragraphs whereas SVG was about bottom-to-top painting onto a canvas. One key part of infrastructure that I was hoping would be shared would be the timing and animation features (and ultimately video and audio) features, such as what Microsoft did with XHTML+Time, but I don't see much momentum in that direction. For the most part, the places where SVG differs in the *infrastructure* versus HTML were not intentional, at least relative to what I was thinking way back when.

The SVG language design was such that it was expected that there was a distinct SVG module that processed the <svg:svg> subtree. One key reason in my mind for having SVG as its own separate thing was that it would allow for dedicated tools (e.g., Photoshop authors raster, Illustrator authors vectors). At this point it would be too hard to attempt to make HTML and SVG into the same unified language. Maybe it would have been better back in 1998-2001 if SVG were designed as new tags within HTML, but that's not what happened, and given current implementation status (Opera, WebKit, and Mozilla all support SVG now, plus all of the mobile implementations of SVG and the implementation of SVG in J2ME), it would be better to do evolutionary improvements to make the combination of HTML+SVG(+Canvas) better rather than attempt a revolutionary set of modifications.

Incidentally, I would support the inclusion of incremental SVG enhancements within the HTML5 effort, such as merging Canvas and SVG such that SVG was the declarative markup for Canvas, which would mean such things as adding to createImageData() and getImageData() to SVGImageElement. I haven't thought much about this, but it seems like a good general direction.

Jon

Inactive hide details for Maciej Stachowiak <mjs@apple.com>Maciej Stachowiak <[hidden email]>



To

Ian Hickson <[hidden email]>

cc

Doug Schepers <[hidden email]>, Web API public <[hidden email]>

Subject

Re: Event handler attributes (Was: Dependencies in XHR)



On May 27, 2008, at 11:56 PM, Ian Hickson wrote:

>
> (In particular, I think we really need to get over the concept of "but
> that's a host language issue" or "that doesn't belong in my spec"  
> and so
> on -- we're defining a single platform here, it isn't useful for us  
> to be
> declining responsibility over the more complicated parts. While the  
> theory
> of orthogonal technologies would have been nice, the Web is at a point
> where all the technologies are embedded in each other to some  
> extent, and
> we should embrace that, not try to deny it. We will have a healthier
> technology stack if we consider the HTML and SVG specs, say, to be
> different chapters of the same language spec, rather than if we  
> consider
> them to be separate languages.)

I strongly agree with this sentiment. I strongly prefer if similar  
concepts shared between SVG and HTML can be defined in a consistent  
way in a single place. I would say many parts of HTML5 arguably fall  
in this category and I am ok with them being in HTML5 mainly as a  
matter of expediency, and I hope that in time these things can be  
factored out. Every little thing like this that is different is a  
point of pain for implementors of and authors in the emerging Web  
platform that includes both HTML and SVG.

If any such items can be factored sooner rather than later, then that  
will be welcome news. I apologize also for the item I volunteered to  
factor out but have not taken to completion (the Window object). It  
turned out to be a lot harder to do than I expected going in.

Regards,
Maciej




pic24019.gif (1K) Download Attachment