RE: XHR HTTP method support, Re: XHR LC comments

[Sunava Dutta]

Hey Julian!
Thanks for your mail. I'm adding my x-teammates from IE who should be able to 
help you here. FYI I've transitioned over to our Online Services Group here at 
MS!
All the best!

-Original Message-
From: Julian Reschke [mailto:julian.resc...@gmx.de]
Sent: Monday, February 09, 2009 2:50 AM
To: Sunava Dutta; public-webapps@w3.org
Cc: Anne van Kesteren; Web API WG (public)
Subject: XHR HTTP method support, Re: XHR LC comments

Following up to a mail from May 2008:

Julian Reschke wrote:
> Sunava Dutta wrote:
>> ...
>>> At this point, I'm not sure why we're bothering with XHR1 at all. It is
>>> *not* what the current implementations do anyway.
>> [Sunava Dutta] I'm sorry, this statement is concerning and I'd like to
>> understand it better. We haven’t had a chance to run the latest test
>> suite yet but expect the test suite to be compliant with at least two
>> existing implementations. Do you mean the XHR 1 draft is not
>> interoperable with existing implementations?
>> ...
>
> Absolutely. Everytime I check something that is of interest to me it
> turns out that there is no interop, and that only some or even none of
> the browsers works as specified.
>
> Examples:
>
> - Support for HTTP extension methods: IE violates the SHOULD level
> requirement to support extenstion methods. Opera silently (!!!) changes
> extension method names to "POST".
> ...

Just rechecked...

IE8beta: no improvement -- only the methods in RFC2518 are are
supported, the remaining methods
(),
not to mention future methods, are unsupported.

Opera 10: only a small improvement; unknown method names are now changed
to "GET" (still silently!!!).

Best regards, Julian

Re: Seeking implementation status of XBL2

[Sean Hogan]

There are a few active JS implementation projects:

xbl.googlecode.com, see http://code.google.com/p/xbl/wiki/Features

dojo.E has some support, see: 
http://blog.nexaweb.com/post/xbl-support-for-all-browsers-via-dojoe/


XBLUI, see: http://meekostuff.net/projects/XBLUI/status.html

XBLUI (my project) doesn't implement templates / shadow-trees yet.

cheers,
Sean


Arthur Barstow wrote:

Hi All,

The W3C's XBL2 Candidate spec [1] was published almost two years ago. 
Since then, there has been some implementation activity reported (e.g. 
[2],[3]) but nothing recently.


Does anyone have XBL2 implementation status they can share with us?

-Regards, Art Barstow

[1] 
[2] 

[3] 



 
___

dev-tech-xbl mailing list
dev-tech-...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-xbl

Re: Seeking implementation status of XBL2

[Jonas Sicking]

Arthur Barstow wrote:


Hi All,

The W3C's XBL2 Candidate spec [1] was published almost two years ago. 
Since then, there has been some implementation activity reported (e.g. 
[2],[3]) but nothing recently.


Does anyone have XBL2 implementation status they can share with us?


I don't yet have any status, however I expect to start working on an 
implementation of XBL2 for firefox in a matter of weeks. It's my main 
project once we have Firefox 3.1 out the door. However it will take a 
while to implement of course, so not sure how rapidly feedback will come in.


/ Jonas

Re: [webidl] [Implements] extended attribute

[Ian Hickson]

On Mon, 9 Feb 2009, Anne van Kesteren wrote:
> 
> To complement [ImplementedOn] I think we need [Implements]. For 
> instance, objects implementing the XMLHttpRequest interface must 
> implement the EventTarget interface can be neatly described in the IDL:
> 
>   [Constructor,
>Implements=EventTarget]
>   interface XMLHttpRequest ...
> 
> It would be nice if it could be used multiple times as well, e.g.
> 
>   [Implements=EventTarget,
>Implements=XMLHttpRequestEventTarget]
>   interface XMLHttpRequestUpload ...
> 
> I am assuming something like this ends up in the Web IDL specification 
> for now as per IRC discussion.

Heycam and I discussed this on IRC a few weeks ago.

The problem with Implements= and ImplementedOn= is that which you would 
use would depend on which spec came first, which is a pretty silly way for 
us to write the IDL. I would instead recommend a way to annotate such 
relationships that is independent of interface {} blocks. For example:

   [Constructor]
   interface XMLHttpRequest { ... };

   interface EventTarget { ... };

   XMLHttpRequest implements EventTarget;

This would also allow us to spec the relationships completely 
independently of the interfaces, e.g. the spec that defines Navigator and 
the spec that implements EventTarget need not be the same as the spec that 
fires 'online' events at Navigator (and thus requires Navigator to be an 
EventTarget).

Is there a list of outstanding WebIDL requests anywhere?

(Incidentally, since XMLHttpRequestEventTarget inherits from EventTarget, 
XMLHttpRequestUpload should implement the former only.)

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

Seeking implementation status of XBL2

[Arthur Barstow]

Hi All,

The W3C's XBL2 Candidate spec [1] was published almost two years ago.  
Since then, there has been some implementation activity reported  
(e.g. [2],[3]) but nothing recently.


Does anyone have XBL2 implementation status they can share with us?

-Regards, Art Barstow

[1] 
[2] 
[3] 


 

[webidl] [Implements] extended attribute

[Anne van Kesteren]

To complement [ImplementedOn] I think we need [Implements]. For instance,  
objects implementing the XMLHttpRequest interface must implement the  
EventTarget interface can be neatly described in the IDL:


  [Constructor,
   Implements=EventTarget]
  interface XMLHttpRequest ...

It would be nice if it could be used multiple times as well, e.g.

  [Implements=EventTarget,
   Implements=XMLHttpRequestEventTarget]
  interface XMLHttpRequestUpload ...

I am assuming something like this ends up in the Web IDL specification for  
now as per IRC discussion.



--
Anne van Kesteren

Re: [cors] Updates

[Thomas Roessler]

On Mon, 09 Feb 2009 14:25:37 +0100, Thomas Roessler   
wrote:

On 9 Feb 2009, at 13:57, Anne van Kesteren wrote:


* There was a logic error in the cache processing model.


I wonder whether that part of the spec is actually being  
implemented (or found useful by implementors).


If not, I'm all for dropping it.


https://bugs.webkit.org/show_bug.cgi?id=22950
http://groups.google.com/group/mozilla.dev.super-review/browse_thread/thread/80568859350375ae

... suggests it is implemented in at least two browsers.


... in which case I'm not suggesting to drop it.

Re: [cors] Updates

[Anne van Kesteren]

On Mon, 09 Feb 2009 14:25:37 +0100, Thomas Roessler  wrote:

On 9 Feb 2009, at 13:57, Anne van Kesteren wrote:


* There was a logic error in the cache processing model.


I wonder whether that part of the spec is actually being implemented (or  
found useful by implementors).


If not, I'm all for dropping it.


https://bugs.webkit.org/show_bug.cgi?id=22950
http://groups.google.com/group/mozilla.dev.super-review/browse_thread/thread/80568859350375ae

... suggests it is implemented in at least two browsers. This is the first  
time I hear a request for removal to be honest. Why do you want to drop it?



--
Anne van Kesteren

Re: [cors] Updates

[Thomas Roessler]

On 9 Feb 2009, at 13:57, Anne van Kesteren wrote:


* There was a logic error in the cache processing model.


I wonder whether that part of the spec is actually being implemented  
(or found useful by implementors).


If not, I'm all for dropping it.

--
Thomas Roessler, W3C  

[cors] Updates

[Anne van Kesteren]

After renaming the specification I decided to go through the normative  
parts of the specification again to clean various things up and resolve  
some outstanding issues. Since the October 6 editor's draft (last  
relatively stable draft) the following things have changed starting  
January 14:


 * The specification was renamed.

 * Terminology was made more consistent throughout. Cross-site,  
cross-domain, cross-origin is now all cross-origin, as it should be.


 * Fixed various examples that still used the old model.

 * User agents are to lowercase Access-Control-Request-Headers values and  
sort them. This makes it less likely for authors to depend on behavior of  
a particular user agent.


 * A change in HTML 5 resulted in origin being able to serialize to the  
string "null" again.


 * The syntax section now has requirements on servers.

 * The expiry time cache field is now called max age. Cache fields are  
linked through the document as well.


 * Parsing of headers by user agents and what to do if parsing failed is  
now more properly defined.


 * Non-normative sections and appendices are now clearly marked as such.

 * I updated the JSONRequest FAQ entry based on comments from DanC in a  
W3C QA blog post.


 * The Content-Type header is now always limited for simple requests, not  
just if the method is POST.


 * There was a logic error in the cache processing model.

 * The specification is now more clear on how preflight requests are  
supposed to work. I.e. when to include Access-Control-Request-Headers and  
Access-Control-Request-Method.


As indicated in the status e-mail more changes are underway based on  
feedback, but those should not affect implementors. I would appreciated  
feedback from implementors on the changes and in particular on the wording  
in the latest draft:


  http://dev.w3.org/2006/waf/access-control/


--
Anne van Kesteren

[cors] Status

[Anne van Kesteren]

Last week I have been cleaning up CORS with respect to the normative  
definitions and various algorithms. I will summarize those changes in a  
separate e-mail. I'm now trying to figure out how to deal with the  
remaining bits of work.


I would very much appreciate it if people involved in CORS (and other  
interested parties of course) can read through this e-mail and share their  
thoughts. The sooner the better.



  http://www.w3.org/2008/webapps/track/products/7

ISSUE-13 "Opting into cookies" it seems this is part of the specification  
now in the form of the Access-Control-Allow-Credentials header and  
credentials flag.


ISSUE-25 "Revocation of cached access grants" as I stated in July 2008  
(e-mail is referenced from the issue) you can revoke cache entries by  
simply not allowing the actual request to pass. (Part of this issue became  
ISSUE-30.)


ISSUE-30 "Should spec have wording to recognise that User Agents may  
implement further security beyond the spec?"  
http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0048.html  
has suggested additional restrictions user agents may impose. I'm thinking  
that should be a normative subsection of the processing model. Makes sense?


ACTION-11 "Draft scenarios for AC + various host specs" the use cases  
section in the specification has some scenarios. Given @font-face and  
media elements I could add some more there I suppose if that is desired.


ACTION-148 "Try to find an Editor for the Access Control Primer document"  
I do not think this is worth the time of the WG to be honest. Tutorials  
for using CORS are already appearing on the Web. E.g.  
https://developer.mozilla.org/En/HTTP_access_control Having one that is  
vetted by the WG seems like something that demands more resources than we  
have.


ACTION-192 "Submit an input that will result in closing Issue #21" that is  
a Widgets issue.



The Origin header needs to become something that can be referenced. Should  
I keep the definition in the draft meanwhile? Currently it is commented  
out.



The security section currently mostly makes redundant requirements  
(incorrect, it should be non-normative) and requirements that are better  
moved to the processing model. I thought of maybe introducing a processing  
model for servers so that the requirements on them become a bit more  
clear. And the the user agent and server processing model share the syntax  
section for header definitions on writing and parsing. Does that make  
sense?


Not sure what happens to the security section after that. Ideas?


The terms case-sensitive, ASCII case-insensitive, and converting a string  
to lowercase would ideally be defined in a separate document all kinds of  
specifications can reference. Although it should be pretty clear from the  
definitions already, that would strengthen they are indeed identical and  
can be implemented with the same function. This is just a minor thing  
though and does not really affect CORS in any way.



--
Anne van Kesteren

Re: Call for Consensus - Selectors API to Candidate Rec

[Lachlan Hunt]

timeless wrote:

This specification introduces two methods that take a group of selectors
 it requires a script like the following that iterates


that => which ?


No, "that" is correct in this case.


With these methods, it is easier to match a set of Element nodes
based on specific criteria.


easier than what? (yes, i know the next sentence would explain, but I
don't think English allows for that.)


I rephrased it to the following:

  "With these methods, it is easier to match a set of Element nodes
   based on specific criteria, than having to subsequently filter the
   result of calling other methods like getElementsByTagName()."

The implementation must first trim any leading or trailing 
whitespace from the value of the selectors parameter.


or => and ?


I think "or" is actually correct in this case, but to remove any 
confusion, I've changed it to "and/or".


If the user agent also supports some level of CSS, the 
implementation should support the same set of selectors in both 
these APIs and CSS.


This is poorly written, at first parse I concluded that selectors
weren't CSS (there is no CSS level 0), and CSS3 comes in modules.


I do not understand what you mean, nor what is wrong with the sentence. 
 What is it about the sentence that implies there is a CSS level 0? 
Selectors was part of CSS levels 1 and 2, but as of level 3, it's an 
independent specification.



The goal is presumably to indicate that if some other entrypoint to
CSS supports something, then this API should support the same thing
with the same syntax. But it didn't manage to read that way.


I do not understand this either.  The point of the sentence is to say if 
if the UA supports, or at least partially supports, CSS level 1, 2, 3 or 
any subsequent level, then it should support the same set of Selectors.


The NodeList object returned by the querySelectorAll() method must 
be static, not live. ([DOM-LEVEL-3-CORE], section 1.1.1) Subsequent 
changes the structure of the underlying document must  not be

reflected in the NodeList object.

...
DOM3 Core defines several methods for checking for interface 
support, or for obtaining implementations of interfaces, using

feature strings. ([DOM-LEVEL-3-CORE], section 1.3.6) A DOM
application can use these methods, each of which accept feature and
version parameters, using the values "Selectors-API" and "1.0"
(respectively).


I believe that the parenthetical should be part of the first sentence
instead of after the period.


Fixed both.


var x = document.querySelector("#foo, #bar");
x would contain the first element in the document with an ID of either foo or 
bar (or both).


1. could you change 'contain' - i read contain to mean list, which of
course is wrong for querySelector()


I'm not convinced there is a problem with the word "contain" in this case.

2. it might be null - or whatever the return is for the case where 
there's no match

3. i think the '(or both)' bit doesn't add value, even understanding
the case where there's a node matching #foo#bar, if it's the first
that matches #foo or #bar, it's still the first that matches #foo or
#bar and the fact that it matches #foo#bar is absolutely irrelevant


I removed "(or both)" and appended "or null if there is no such element".


The methods can also be invoked on elements.


The methods _defined in this specification_ ...


I don't think that extra qualification is necessary in this case.

In ECMAScript, the language binding also allows NodeLists to be 
addressed using the array notation, so that loop could be rewritten 
like this:


using array notation


I'm fairly sure "using the array notation" is grammatically correct in 
this case.


This would cause each selected element to be removed from the DOM, 
but each element will remain in the NodeList. If the list were a 
live NodeList, removing an item from the DOM would also remove the 
element from the list and adjust the indexes of subsequent 
elements. That would have adverse effects upon the loop because not

all selected elements would be processed.


I know that explanatory text is valuable, but i don't particularly
like this explanatory text in a normative section. Could you make this
a non-normative note?


The entire example section is already non-normative.


excluding all others, requires an additional processing to filter the result.


requires additional processing, or an additional step


Fixed.

--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

If not Multiple-Contents, how do we have Widgets with multiple modes?

[ivan.demarino]

Hello.

I'm following the specs evolving for Window Modes 
(http://dev.w3.org/2006/waf/widgets/#window-modes).
Given the fact that the "content tag" has an occurrence of "0 or 1", and the 
fact that the "mode" is one, my question is:
- Would it be possible to have widgets that have "multiple views"?

I dug into the "widgets-api", and what it looks like is the fact that the only 
place where the widget should handle "mode change" is the call-back named 
"onmodechange()".
That's fine.

But we are assuming that there is an "initial mode" chosen by the Developer and 
that the widget "change it's shape" based on the event "onmodechange".
- What if the Developer can't know in which mode the Widget will start?
- What if the "User-Agent" running the Widget does not pass a "onmodechange", 
because NO MODE WAS CHANGED: it was simply initialized with a mode different 
from the one chosen in the "config.xml"?

It's a bit "tricky" to explain, but I can give more details if needed.

One of the great thing of having "widgets with multiple modes", is the fact 
that the same widget can run in different scenarios, based on the hosting 
platform screen resolution AND other requirements. The widget has to adapt 
itself at "load time".
A widget that, for example, run in "window mode" and just after load has to 
change to "docked", because that's the mode supported by the current 
User-Agent, will look "clunky" and "not seamlessly integrated".

What do you think?


 <> 
Ivan De Marino
Orange Labs
Mobile and Web Software Engineer, R&D UK
tel. +44 20 8849 5806
mob. +44 7515 955 861
mob. +44 7974 156 216
ivan.demar...@orange-ftgroup.com  
 <> 

This e-mail, and any files transmitted with it, is intended only for the use of 
the person/s or entity to whom it is addressed. If you are not the intended 
recipient (or authorised to receive information for the intended recipient) you 
must not use, disclose, copy, print or rely on this e-mail. If an addressing or 
transmission error has misdirected this e-mail, please notify the author by 
replying to this e-mail and delete all copies of this e-mail.  Thank you.

France Telecom R&D UK Ltd is a company registered in England and Wales with 
company number 4193379. Our registered office is Minerva House, Montague Close, 
London, SE1 9BB.

<><>

XHR HTTP method support, Re: XHR LC comments

[Julian Reschke]

Following up to a mail from May 2008:

Julian Reschke wrote:

Sunava Dutta wrote:

...

At this point, I'm not sure why we're bothering with XHR1 at all. It is
*not* what the current implementations do anyway.
[Sunava Dutta] I'm sorry, this statement is concerning and I'd like to 
understand it better. We haven’t had a chance to run the latest test 
suite yet but expect the test suite to be compliant with at least two 
existing implementations. Do you mean the XHR 1 draft is not 
interoperable with existing implementations?

...


Absolutely. Everytime I check something that is of interest to me it 
turns out that there is no interop, and that only some or even none of 
the browsers works as specified.


Examples:

- Support for HTTP extension methods: IE violates the SHOULD level 
requirement to support extenstion methods. Opera silently (!!!) changes 
extension method names to "POST".

...


Just rechecked...

IE8beta: no improvement -- only the methods in RFC2518 are are 
supported, the remaining methods 
(), 
not to mention future methods, are unsupported.


Opera 10: only a small improvement; unknown method names are now changed 
to "GET" (still silently!!!).


Best regards, Julian

Re: Call for Consensus - Selectors API to Candidate Rec

[timeless]

On Thu, Feb 5, 2009 at 2:21 AM, Charles McCathieNevile  wrote:
> [1] http://dev.w3.org/2006/webapi/selectors-api/

I've been meaning to read this for months. sorry for the delay, i
expect none of my comments are significant, but i enjoy reading and
writing

> This specification introduces two methods that take a group of selectors
>  it requires a script like the following that iterates

that => which ?

> With these methods, it is easier to match a set of Element nodes based on 
> specific criteria.

easier than what? (yes, i know the next sentence would explain, but I
don't think English allows for that.)

> The implementation must first trim any leading or trailing whitespace from 
> the value of the selectors parameter.

or => and ?

> If the user agent also supports some level of CSS, the implementation should 
> support the same set of selectors in both these APIs and CSS.

This is poorly written, at first parse I concluded that selectors
weren't CSS (there is no CSS level 0), and CSS3 comes in modules.

The goal is presumably to indicate that if some other entrypoint to
CSS supports something, then this API should support the same thing
with the same syntax. But it didn't manage to read that way.

> The NodeList object returned by the querySelectorAll() method must be static, 
> not live.
> ([DOM-LEVEL-3-CORE], section 1.1.1) Subsequent changes to the structure of 
> the underlying document must not be reflected in the NodeList object.

I believe that the parenthetical should be part of the first sentence
instead of after the period.

> DOM3 Core defines several methods for checking for interface support, or for 
> obtaining implementations of interfaces, using feature strings.
> ([DOM-LEVEL-3-CORE], section 1.3.6) A DOM application can use these methods, 
> each of which accept feature and version parameters, using the values 
> "Selectors-API" and "1.0" (respectively).

I believe that the parenthetical should be part of the first sentence
instead of after the period.

note that you do sometimes put the period after, as in:
> If the group of selectors include namespace prefixes that need to be 
> resolved, the implementation must raise a NAMESPACE_ERR exception 
> ([DOM-LEVEL-3-CORE], section 1.4).

> var x = document.querySelector("#foo, #bar");
> x would contain the first element in the document with an ID of either foo or 
> bar (or both).

1. could you change 'contain' - i read contain to mean list, which of
course is wrong for querySelector()

anne suggests "be"

2. it might be null - or whatever the return is for the case where
there's no match
3. i think the '(or both)' bit doesn't add value, even understanding
the case where there's a node matching #foo#bar, if it's the first
that matches #foo or #bar, it's still the first that matches #foo or
#bar and the fact that it matches #foo#bar is absolutely irrelevant

> The methods can also be invoked on elements.

The methods _defined in this specification_ ...

> In ECMAScript, the language binding also allows NodeLists to be addressed 
> using the array notation, so that loop could be rewritten like this:

using array notation

> This would cause each selected element to be removed from the DOM, but each 
> element will remain in the NodeList.
> If the list were a live NodeList, removing an item from the DOM would also 
> remove the element from the list and adjust
> the indexes of subsequent elements. That would have adverse effects upon the 
> loop because not all selected elements
> would be processed.

I know that explanatory text is valuable, but i don't particularly
like this explanatory text in a normative section. Could you make this
a non-normative note?

> excluding all others, requires an additional processing to filter the result.

requires additional processing, or an additional step