[widgets] Widgets Requirements LC

[Marcos Caceres]

In preparation for LC, I've updated the widgets requirements document:

http://dev.w3.org/2006/waf/widgets-reqs/

I did a small editorial cleanup and, to reflect the work Arve and I
did on the API spec, I've added the following requirements:

R28. Network State Change Events
A conforming specification must specify a means that allows authors to
check if the widget resource is connected to Web. A conforming
specification must also specify a mans by which connection and
disconnection events can be captured by an author through script.

Motivation:
Current development practice or industry best-practices, ease of use.

Rational:
To allow authors to programmatically capture when a the widget user
agent has got or lost a connection to the Web.

R30. Device Specific APIs and Services
A conforming specification should specify a mechanism, either through
an API or through the configuration document, that allows instantiated
widgets to bind to third-party APIs that allow access to
device-specific resources and services. A conforming specification is
not required to specify any APIs to device specific resources or
services, but shouldprovide some means of binding to those APIs if
they are available.

Motivation:
Current development practice or industry best-practices, ease of use.

Rational:
To endow widgets with functionality beyond what is currently available
to HTML documents, allowing widgets to be used as means to bridge
special device capabilities and operating system services with data on
the Web. Examples of device-specific services and resources that could
be made available through script include cameras, SMS, and the address
book. There are other WGs working on this requirements such as the
Ubiquitous Web Applications Working Group (UWA-WG), and the Open
Mobile Alliance (OMA) Device Capabilities Working Group.

R34. Icon API
A conforming specification SHOULD specify a means that allows authors
to control the iconic representation of a widget resource at runtime.

Motivation:
Current development practice or industry best-practices.

Rational:
To allow widget to communicate events and state changes to the user in
contexts outside the running widget. For instance, for a weather
widget, an icon could change to reflect the current weather
conditions.

R35. Configuration Document Data
A conforming specification SHOULD specify a means that allows authors
to access any relevant data they declared in the configuration
document for the widget resource.

Motivation:
Current development practice or industry best-practices.

Rational:
To allow authors to easily access metadata they declared in the
configuration document at runtime.

R36. Open Default System Web Browser
A conforming specification SHOULD specify a means that allows authors
to open URLs in a browsing contexts outside the widget engine.

Motivation:
Current development practice or industry best-practices.

Rational:
To allow author to open a URL in the default system web browser. For
example, in an news aggregator widget, to allow the end user to
navigate to the source of a particular news item.

-- 
Marcos Caceres
http://datadriven.com.au
http://standardssuck.org

[Widgets] Requirements LC

[Marcos Caceres]

In preparation for LC, I've updated the widgets requirements document.

I did a small editorial cleanup, and, to reflect the work Arve and I
did on the API spec, I've added the following requirements:

R28. Network State Change Events

A conforming specification must specify a means that allows authors to
check if the widget resource is connected to Web. A conforming
specification must also specify a mans by which connection and
disconnection events can be captured by an author through script.

Motivation:
Current development practice or industry best-practices, ease of use.

Rational:
To allow authors to programmatically capture when a the widget user
agent has got or lost a connection to the Web.

R30. Device Specific APIs and Services
A conforming specification should specify a mechanism, either through
an API or through the configuration document, that allows instantiated
widgets to bind to third-party APIs that allow access to
device-specific resources and services. A conforming specification is
not required to specify any APIs to device specific resources or
services, but shouldprovide some means of binding to those APIs if
they are available.

Motivation:
Current development practice or industry best-practices, ease of use.

Rational:
To endow widgets with functionality beyond what is currently available
to HTML documents, allowing widgets to be used as means to bridge
special device capabilities and operating system services with data on
the Web. Examples of device-specific services and resources that could
be made available through script include cameras, SMS, and the address
book. There are other WGs working on this requirements such as the
Ubiquitous Web Applications Working Group (UWA-WG), and the Open
Mobile Alliance (OMA) Device Capabilities Working Group.

R34. Icon API
A conforming specification SHOULD specify a means that allows authors
to control the iconic representation of a widget resource at runtime.

Motivation:
Current development practice or industry best-practices.

Rational:
To allow widget to communicate events and state changes to the user in
contexts outside the running widget. For instance, for a weather
widget, an icon could change to reflect the current weather
conditions.

R35. Configuration Document Data
A conforming specification SHOULD specify a means that allows authors
to access any relevant data they declared in the configuration
document for the widget resource.

Motivation:
Current development practice or industry best-practices.

Rational:
To allow authors to easily access metadata they declared in the
configuration document at runtime.

R36. Open Default System Web Browser
A conforming specification SHOULD specify a means that allows authors
to open URLs in a browsing contexts outside the widget engine.

Motivation:
Current development practice or industry best-practices.

Rational:
To allow author to open a URL in the default system web browser. For
example, in an news aggregator widget, to allow the end user to
navigate to the source of a particular news item.

-- 
Marcos Caceres
http://datadriven.com.au
http://standardssuck.org

ISSUE-8 (mouseenter/leave): Adding mouseenter and mouseleave Events [DOM3 Events]

[Web Applications Working Group Issue Tracker]

ISSUE-8 (mouseenter/leave): Adding mouseenter and mouseleave Events [DOM3 
Events]

http://www.w3.org/2008/webapps/track/issues/

Raised by: Doug Schepers
On product: DOM3 Events

'mouseenter' and 'mouseleave' events are similar to 'mouseover' and 'mouseout' 
events, but do not bubble.  Should we add these to DOM3 Events (or a later 
related spec)?


 

Re: Improving Communication and Expectations

[Marcos Caceres]

On Wed, Jun 18, 2008 at 9:20 AM, Chris Wilson
<[EMAIL PROTECTED]> wrote:
> You know, there is an idea that perhaps we're not IGNORING the work on Access 
> Control, and perhaps we simply disagree with some of it.
>

Oh, I see. Well, it has been good to get feedback on which aspects you
guys disagree with now (better late than never, right?). It came as a
bit of a shock when you guys just put in a counter proposal when you'd
had every opportunity to participate in the development of this work
from early on. It was sad to see Marc Silbey drop off the radar in
regards to Access-Control over a year ago. If Microsoft would have
found the time to collaborate, all this stuff could have been resolved
progressively and the spec would probably be done by now (as has been
shown, the MS proposal has just as many issues, if not more, than the
Access-control spec; so trying to do it in-house did not yield a more
adequate solution). Anyway, that's all water under the bridge now.
Glad you guys are back at the table and hopefully we can get this out
soon. Hopefully you guys won't vanish again to do your own thing when
you don't agree with certain aspects of a spec.

-- 
Marcos Caceres
http://datadriven.com.au
http://standardssuck.org

[widgets] icon text

[Marcos Caceres]

This is a proposal to add alternative text to  element. As with
the alt attribute in HTML, the alternative text could be used as
fallback content, or for context where an image icon does not fit or
is unsuitable, and for use by assistive technologies.

Proposal 1:


Proposal 2:


Proposal 3:
http://.../xhtml/";>Sunny with
a chance of showers. High: 22, Low: 23

Adding one of the above would also require a change to the Widgets API
spec. In the case of 1 and 2, the Widget API spec could be enhanced
with an appropriate property or method (eg. icon.alt = "something" or
setText() ).  In the case of proposal 3, icon could support the
innerHTML() method.

Kind regards,
Marcos


-- 
Marcos Caceres
http://datadriven.com.au
http://standardssuck.org

Re: ISSUE-3 (eventType): [Progress] [D3E]

[Charles McCathieNevile]

On Tue, 17 Jun 2008 20:19:16 +0900, Anne van Kesteren <[EMAIL PROTECTED]>  
wrote:


On Tue, 17 Jun 2008 07:25:42 +0200, Charles McCathieNevile  
<[EMAIL PROTECTED]> wrote:
The usecase makes sense to me. But I wonder if it should be defined in  
DOM 3 events instead?


DOM Events should define a way for other specifications to introduce  
their own event interfaces in a convenient way. The other specifications  
can then use that to easily describe FooEvent, FooEvent.init..., and  
"FooEvent" (for constructing). It would be quite a burden if DOM Events  
would actually needed to be updated each time we introduce a new event  
interface.


Indeed. Although that drives us to the question of how to make sure that  
events are not conflicting, when different specs can be written, I figure  
all that is an issue for DOM 3 events.


In part the question arises for progress events in particular because it  
is actually being defined by the same WG that is defining DOM 3 events, so  
it could reasonably expect to work with the developers for that spec in a  
way that is not available to most people who might try to create some kind  
of eventType...


cheers

Chaals

--
Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera 9.5: http://snapshot.opera.com

Re: ISSUE-6 (Element Traversal Nodelist): Should the ElementTraversal Interface Have a Nodelist? [Element Traversal]

[Jonas Sicking]

Web Applications Working Group Issue Tracker wrote:

ISSUE-6 (Element Traversal Nodelist): Should the ElementTraversal Interface 
Have a Nodelist? [Element Traversal]

http://www.w3.org/2008/webapps/track/issues/

Raised by: Doug Schepers
On product: Element Traversal

Daniel Glazman requested that a nodelist or item accessor be added to
the ET spec, in
,
spawning a long thread.

Doug discussed the history of similar proposals, from himself,
Mozilla, and others in
.

On the plus side, it would allow for discrete access to elements in
some use cases, and would be easy to implement for UAs that already
have a nodelist implementation.  On the downside, it is heavier to
implement if the UA doesn't already have nodelist (such as some mobile
uses), and ET is already referenced by other specifications.


One thing that I recently realized. Any UA that implements the HTML DOM 
must already have the code to implement a live nodelist of child 
elements with a given name. This is needed to implement the 
HTMLTableElement.rows, HTMLTableElement.tBodies and 
HTMLTableRowElement.cells properties.


So it seems like it should be easy to reuse that code to implement a 
.childElements list. That is exactly what the implementation in mozilla 
would do.


/ Jonas

RE: Improving Communication and Expectations

[Chris Wilson]

You know, there is an idea that perhaps we're not IGNORING the work on Access 
Control, and perhaps we simply disagree with some of it.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marcos Caceres
Sent: Monday, June 16, 2008 3:02 PM
To: Doug Schepers
Cc: Anne van Kesteren; [EMAIL PROTECTED]; public-webapps@w3.org
Subject: Re: Improving Communication and Expectations


On Tue, Jun 17, 2008 at 2:32 AM, Doug Schepers <[EMAIL PROTECTED]> wrote:
> Yes, that does sound like an opportunity to get closer alignment. Microsoft
> should attend the telcons, if they have an investment (in some sense) in the
> technology and want to contribute.
>

...Or they could just ignore over two years of work, as was the case
with Access Control, create their own proposal and implementation in
secret and then attempt to fast track it through standardization
ignoring due process.

--
Marcos Caceres
http://datadriven.com.au
http://standardssuck.org

Re: ISSUE-7 (Transfer Old Issues): Transferring old WebAPI and WAF [All Products]

[Charles McCathieNevile]

On Wed, 18 Jun 2008 05:45:04 +0900, Web Applications Working Group Issue  
Tracker <[EMAIL PROTECTED]> wrote:


ISSUE-7 (Transfer Old Issues): Transferring old WebAPI and WAF [All  
Products]


http://www.w3.org/2008/webapps/track/issues/

Raised by: Doug Schepers
On product: All Products

Should We transfer old issues from WebAPI and WAF to this Tracker?


Hmmm. It's a bit of a pain either way. Probably any open issues should be  
reopened in this tracker, with a pointer placed in the old one...


cheers

Chaals

--
Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera 9.5: http://snapshot.opera.com

Re: ISSUE-4 (SpecContent): Should specifications decide what counts as content for transfer? [Progress Events]

[Jonas Sicking]

Web Applications Working Group Issue Tracker wrote:

ISSUE-4 (SpecContent): Should specifications decide what counts as content for 
transfer? [Progress Events]

http://www.w3.org/2008/webapps/track/issues/

Raised by: Charles McCathieNevile
On product: Progress Events

Currently the spec says that the bytes counted for total/loaded are
exclusive of headers and other such traffic overheads. Does it make
more sense to require that specifications decide this question? This
is reopening Issue 108 from the webapi tracker:
http://www.w3.org/2006/webapi/track/issues/108 - because I think it
makes more sense to clarify a common practice, and then tell specs
that they have to define this in order to conform.


It makes no sense to me to for HTTP say that the total number of bytes 
should include HTTP headers. It would be similar to including the TCP 
headers in the IP packets IMHO.


However, ideally the spec should be protocol agnostic. But it might be a 
good idea to mention how HTTP (and possibly FTP) should be handled since 
that's likely the vastly most common case.


/ Jonas

Re: Tracker RSS and API (was Re: ISSUE-7 (Transfer Old Issues): Transferring old WebAPI and WAF [All Products])

[Michael(tm) Smith]

Marcos Caceres <[EMAIL PROTECTED]>, 2008-06-18 08:33 +1000:

> If not supported already, what would make the tracker really useful would be:
> 
> 1. RSS support (per product, person, etc)

I believe that work on that may already be in progress.

> 2. a web API (JSON in particular)

That would certainly be really useful, but I don't know whether
it's already being considered or not. I'll ask and find out.

  --Mike

-- 
Michael(tm) Smith
http://people.w3.org/mike/
http://sideshowbarker.net/


smime.p7s
Description: S/MIME cryptographic signature

Re: [XHR] LC comments from the XForms Working Group

[Jonas Sicking]

Boris Zbarsky wrote:


Anne van Kesteren wrote:
I suppose. Though it would create some path in the XMLHttpRequest 
specification we can't really test and it's not clear to me why we 
should do that.


Because if it's low-cost, and lets people reuse the specification, it's 
a win. Whoever comes up with another embedding of XHR would write the 
tests for it, of course.  Otherwise their specification wouldn't have 
that whole test suite thing needed to exit CR.


Also, I forgot to mention that the definition of origin in HTML5 
depends on Window and we really want to use the HTML5 definition of 
origin.


Again, it seems like this could be handled by requiring that anyone 
using XHR not in a Window specify how one gets an origin from the object 
that the XHR constructor is on (or from the current scope object, 
whichever XHR is using).


Or would that not work for some reason?


I fully agree with Boris. Also, remember that we'll have to remove any 
normative references to the Window spec by the time we go to rec one way 
or another no matter what, since the Window spec is unlikely to be in 
Rec before XHR.


/ Jonas

Re: responseXML/responseText exceptions and parseError

[Jonas Sicking]

Anne van Kesteren wrote:


On Tue, 17 Jun 2008 10:29:12 +0200, Zhenbin Xu 
<[EMAIL PROTECTED]> wrote:

Technically because all other XHR methods/properties throw exceptions
in case of state violation, exception for responseXML/responseText is 
better.


The reason these don't throw an exception anymore is actually documented 
on the public-webapi mailing list. Nobody else provided additional 
information at the time:


http://lists.w3.org/Archives/Public/public-webapi/2008Feb/thread.html#msg94

Regarding parseError, since the parseError object is not part of DOM 
Core and nobody but Internet Explorer supported it, it's not part of 
XMLHttpRequest.


Agreed.

If we change DOM Core to say that documents with a 
namespace well-formedness violation are represented by an empty Document 
object with an associated parseError object I suppose we could update 
XMLHttpRequest to that effect.


If we return null now people will use that to check for well-formedness 
checks. If we in the next version of the spec then said that an empty 
document with .parseError set should be returned those pages would break.


So if we are planning on doing the parse error thing then I think we 
should define that an empty document is returned.


Though I think it's more friendly to JS developers to return null. 
Otherwise they have to nullcheck both .responseXML as well as 
.responseXML.documentElement in order to check that they have a valid 
document.


And if I understand it right IE would have to be changed to be complient 
with the spec no matter what since they currently return a non-empty 
document.


/ Jonas

Tracker RSS and API (was Re: ISSUE-7 (Transfer Old Issues): Transferring old WebAPI and WAF [All Products])

[Marcos Caceres]

If not supported already, what would make the tracker really useful would be:

1. RSS support (per product, person, etc)
2. a web API (JSON in particular)

With an API, editor's could mash up issues into specs (eg. as a table,
or inline where needed). Personally, the problem I find with the
tracker is that it is "out-of-sight-out-of-mind". As an editor, if I
could track issues and actions directly in the spec, that would be
really useful and I would be much more inclined to use it.

Could these features be added?

Kind regards,
Marcos

On Wed, Jun 18, 2008 at 6:45 AM, Web Applications Working Group Issue
Tracker <[EMAIL PROTECTED]> wrote:
>
> ISSUE-7 (Transfer Old Issues): Transferring old WebAPI and WAF [All Products]
>
> http://www.w3.org/2008/webapps/track/issues/
>
> Raised by: Doug Schepers
> On product: All Products
>
> Should We transfer old issues from WebAPI and WAF to this Tracker?
>
>
>
>
>



-- 
Marcos Caceres
http://datadriven.com.au
http://standardssuck.org

Possible test for DOM Events

[Carmelo Montanez]

Hi:

Given that I am still unable to use the wiki to upload a file, I am 
attaching  possible

test for the DOM API Test Suite as per my Action Item last week.  I am off from
the office for the next two weeks.

Thanks,
Carmelohttp://www.w3.org/TR/html4/loose.dtd";>  
 



  
  DOM Events API Test Suite - mouseover-002
  
  

// function to get the expect results

   function getExecutionResults()
   {
 var t2 = document.getElementById("tb1");
 return t2.getAttribute("class");
   }

 // function to get expected results.
  
   function getExpectedResults()
   {
   return "tb2";
   }
   
  
// Function to be executed in reaction to mouseover.
   
   function reacttomouseover() {  
 var t2 = document.getElementById("tb1");
 t2.setAttribute("class","tb2"); 
   }
 
// Function to add a listener to the element.

   function addListener() {
  var e1 = document.getElementById("tb1");
  
  if (document.addEventListener) {  
   e1.addEventListener("mouseover", reacttomouseover, false);
 }
 else { 
e1.attachEvent("on"+"mouseover", reacttomouseover());   
 }
   } 
  
  
 
  
   Row 1, Cell 1Row 1, Cell 2 
   Row 2, Cell 1Row 2, Cell 2 
   Row 3, Cell 1Row 3, Cell 2
   Row 4, Cell 1Row 4, Cell 2
   Row 5, Cell 1Row 5, Cell 2   
 
  
   
 drag the mouse over the element 
above (Background color will change)
   
  
  

ISSUE-7 (Transfer Old Issues): Transferring old WebAPI and WAF [All Products]

[Web Applications Working Group Issue Tracker]

ISSUE-7 (Transfer Old Issues): Transferring old WebAPI and WAF [All Products]

http://www.w3.org/2008/webapps/track/issues/

Raised by: Doug Schepers
On product: All Products

Should We transfer old issues from WebAPI and WAF to this Tracker?

Re: Registration now open for the Combined Technical Plenary and Advisory Committee Meeting

[Arthur Barstow]

Hi All,

Just to clarify the confidentiality of the WebApps meetings during  
the October TPAC week ...


The registration page says the WebApps meeting confidentiality is  
"Member Confidential".


However, please note:

1. As required by the WG's Charter, the minutes of the technical  
discussions will be *Public*.


2. The agenda may include some Member-confidential part and the  
minutes from that specific part of the agenda will be Member- 
confidential.


-Regards, Art Barstow


On Jun 17, 2008, at 12:55 AM, ext Charles McCathieNevile wrote:



Sumary: PLease register - http://www.w3.org/2002/09/wbs/35125/ 
TPAC2008/


We have two rooms reserved, so that we can work on stuff in parallel.

The full schedule is at http://www.w3.org/2008/10/TPAC/Schedule and  
they ask you to stay at the hotel at 195€/night (single - double  
room is 225€/night for those who share).


cheers

Chaals

--- Forwarded message ---
From: "Alexandra Lavirotte" <[EMAIL PROTECTED]>

Dear all,

Registration for the October TPAC2008: Combined Technical Plenary
and Advisory Committee Meeting is now open at
http://www.w3.org/2002/09/wbs/35125/TPAC2008/. Registration will close
on 28 September.

Participation in the All Group Meetings and Technical Plenary is open
to participants in good standing in a W3C Working or Interest Group,
Incubator group, Advisory Committee Representatives, the TAG and
Advisory Board.
Participation in the W3C Advisory Committee Meeting is open to one
Advisory Committee Representative per Member Organization, Chairs, the
TAG and Advisory Board.

The schedule of the All Group Meetings, Advisory Committee Meeting and
Technical Plenary is at: http://www.w3.org/2008/10/TPAC/Schedule.html

The TPAC2008 will be held at the Pullman Cannes Mandelieu Royal Casino
(Formerly Sofitel Cannes Mandelieu Royal Casino), in Mandelieu,  
France.

More information can be found on the Overview page at:
http://www.w3.org/2008/10/TPAC/Overview.html

A block of rooms has been reserved at the Pullman Cannes Mandelieu  
Royal

Casino.
The discounted room rates of 195€ for single room and 225€ for double
romm are available from Saturday 18 October to Saturday 25 October  
2008:

http://www.w3.org/2008/10/TPAC/Overview.html#Hotel

Re: [XMLHttpRequest]HttpOnly cookies visibility in XMLHttpRequest

[eric bing]

>I very much agree, but given that nobody has defined cookies yet in 
sufficient detail making this a hard requirement is not really feasible 
at the moment. Once someone has defined cookies in sufficient detail >we 
can revisit this.


Thanks for the reply and for getting this to the correct mail list Anne!

I understand the issues around the lack of a cookie definition, and we 
suspected that this was the reason this hadn't been addressed more 
forcefully.  But, just to reinforce what Jim said below, we're very 
worried that vague language and inconsistent implementation now will 
lead to backward compatibility issues once the community is able to 
address this.  And that in the mean time, web application developers 
will not have the tools to create secure web applications.


In my mind, you've already started down the slippery slope by mentioning 
HTTPOnly cookies at all (not that I think that's a bad thing).  If we 
use the language that Jim mentions below (/recommend/) we can avoid 
making this a hard requirement but give real guidance to folks 
implementing the spec.


Thanks,
Eric Bing,
Senior Director, Application Product Security
Oracle USA

Jim Manico wrote:

Anne,

Thanks kindly for all of the information. Hope you do not mind if I 
chime in. Here is a little backstory/status on HttpOnly.


Both the browser and web application security community stand behind 
HttpOnly.


HttpOnly is supported by IE 6/7, FireFox 2/3, Opera 9.5 and Safari is 
currently adding it.


The Web Security community supports HttpOnly strongly, more details 
here: 
https://www.owasp.org/index.php/HTTPOnly#Browsers_Supporting_HTTPOnly


IE 6/7 and FireFox 2/3 both support HttpOnly in both READING a 
HttpOnly cookie via the JavaScript document.cookie call, as well as 
writing to HttpOnly cookies via JavaScript.


However, there is a workaround in JavaScript that involves making a 
request via XMLHTTPRequest and reading cookies out of the headers. 
That makes the HttpOnly flag almost useless. FireFox has recognized 
this as a bug https://bugzilla.mozilla.org/show_bug.cgi?id=380418 and 
plans to patch. There is also a Opera bug on this topic posted at 
[EMAIL PROTECTED] IE recognizes this as a bug, too.


For the sake of security, the browser and web security community would 
be greatful if the text at


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

Is stronger when talking about HttpOnly protection in JavaScript. We 
need only 3 vectors locked down:


1) Reading of HttpOnly cookies via JavaScript
2) Writing to HttpOnly cookies via JavaScript
3) Reading of HttpOnly cookies from the headers of a XMLHttpRequest 
via JavaScript


If we wait until someone decides to finally define cookies (the 
current standard is the netscape standard from 10 years ago?) then we 
are encouraging the next generation of browsers to expose HttpOnly 
cookies in the XMLHTTPRequest JavaScript object - which is a security 
flaw.


Thank you or considering,
With respect,
Jim

PS: Might I suggest we change

*Apart from requirements affecting security made throughout this 
specification implementations /may/, at their discretion, not expose 
certain headers, such as headers containing HttpOnly cookies.*


to

*Apart from requirements affecting security made throughout this 
specification implementations /may/, at their discretion, not expose 
certain headers. For security purposes it is recommended that HttpOnly 
cookies should never be exposed via XMLHTTPRequest.*



Note: due to the wonders of W3C process we now have a new mailing 
list, public-webapps. I cc'ed it on this e-mail.


On Sat, 07 Jun 2008 00:18:32 +0200, eric bing <[EMAIL PROTECTED]> 
wrote:

Apologies for the late comments - I belatedly realized the close of
comments on this was June 3.


That's ok. Technical comments are _always_ welcome. (Though they may 
not always impact the transition to CR or some other level, of course.)




I've been discussing some of this internally within Oracle USA and
within the OWASP mail lists, and would like to make a suggestion.

We're very happy with the mention in the April 15th spec:
/Apart from requirements affecting security made throughout this
specification implementations /may/, at their discretion, not expose
certain headers, such as HttpOnly cookies.//
/http://dev.w3.org/2006/webapi/XMLHttpRequest/#security

However, we'd like to see even stronger language here.  We think it
should be *recommended *or even better yet *required *that
XMLHttpRequest not see these headers of HttpOnly cookies.   The fact
that XMLHTTPRequest can currently see these cookies greatly undermines
the security value of this flag.


I very much agree, but given that nobody has defined cookies yet in 
sufficient detail making this a hard requirement is not really 
feasible at the moment. Once someone has defined cookies in 
sufficient detail we can revisit this.






--
Jim Manico, Senior Application Security Engineer
[EMAIL PROTECTED] | [EMAIL PROTECTED]
(301) 

Re: RE: Potential bugs identified in XHR LC Test Suite

[Jonas Sicking]

Ian Hickson wrote:

On Tue, 17 Jun 2008, Zhenbin Xu wrote:
I am not sure if I understand your question. responseXML.parseError 
has the error information 
http://msdn.microsoft.com/en-us/library/aa926483.aspx
Oh, I assumed Sunava meant a conforming Document object was returned. 
A parseError-type object would be what I had in mind, yes. However, if 
we do this, then we should specify it. If we don't specify it, I'd 
rather have an exception.
The spec can simply state that a conforming document object is returned, 
which includes out-of-band error information. This is what IE does today 
and is a very reasonable approach that allows rich error information for 
debugging.


I don't believe it is conforming for Document objects to have parseError 
attributes, but I could be mistaken -- is there a spec for parseError? 
Even if there isn't, though, I agree that it is a generally good solution 
to the problem, I'm just saying that we should specify it, so that UAs 
can be standards-compliant and support it interoperably.


I think we have two choices for how to handle parse errors here:

1. Mandate that a Document object containing a .parseError property
   is returned for .responseXML
2. Mandate that null is returned

I think some hodgepodge solution of the two is likely just going to be 
harder to code against for developers.


Are we comfortable adding the .parseError object to the XHR spec? Feels 
like spec creep to me unfortunately.


/ Jonas

Re: [access-control] header black list

[Jonas Sicking]

Anne van Kesteren wrote:


On Tue, 17 Jun 2008 06:59:50 +0200, Jonas Sicking <[EMAIL PROTECTED]> wrote:

Block lists are unacceptable we all agree. The block list currently in
the spec really should be moved to the XMLHttpRequest Level 1 spec as
that is where the issue lies, not with the Access-Control spec.


Other host language implementations of Access Control that allow setting 
of headers need the same kind of protection. That's why the header list 
is there. Alternatively we could make it a requirement on the host 
language implementation, e.g. XMLHttpRequest, to do this filtering, but 
that would still require listing the headers in some way in the Access 
Control specification.


These aren't headers that are dangerous in a cross-site environment, 
these are headers that are dangerous period. So any other spec that 
supports a sufficently large part of the HTTP spec would need to worry 
about them, whether it uses Access-Control or not.


This applies to the CONNECT, TRACE, and TRACK verbs as well, but I've 
not yet addressed that in the specification.


Same thing here.

Listing these headers and methods in the AC spec just results in a 
situation where specs can get out of sync. It seems much better to put 
the headers in the XHR spec for now, and if any other spec ends up with 
the same issues it can refer to the XHR spec.


Having it in the AC spec is only a source of confusion so far.

/ Jonas

Re: [XHR] LC comments from the XForms Working Group

[Boris Zbarsky]

Anne van Kesteren wrote:
I suppose. Though it would create some path in the XMLHttpRequest 
specification we can't really test and it's not clear to me why we 
should do that.


Because if it's low-cost, and lets people reuse the specification, it's a win. 
Whoever comes up with another embedding of XHR would write the tests for it, of 
course.  Otherwise their specification wouldn't have that whole test suite thing 
needed to exit CR.


Also, I forgot to mention that the definition of origin in HTML5 depends 
on Window and we really want to use the HTML5 definition of origin.


Again, it seems like this could be handled by requiring that anyone using XHR 
not in a Window specify how one gets an origin from the object that the XHR 
constructor is on (or from the current scope object, whichever XHR is using).


Or would that not work for some reason?

-Boris

Re: Issues and Actions

[Jonas Sicking]

Arthur Barstow wrote:


Doug, All,

On Jun 17, 2008, at 12:21 AM, ext Doug Schepers wrote:

In general, I think using the tracker can be more effective at dealing 
with issues than merely using email or notations in the spec, for a 
number of reasons:


Yes, I agree there are some benefits for more fine-grained Issues.

One concern I have is the meta issues with Issues i.e. the overhead of 
managing the Issues. For example, it would be unfortunate if we ended-up 
spending more time discussing things like "is this an issue or not" 
instead of discussing/debating the technical specifics.


Yes, that is something i'd be concerned about too. Microsofts feedback 
contained much more than technical issues regarding the Access-Control 
spec so in order to create issues based on that someone would need to go 
through and actually try to understand the issues and pick out the meaty 
parts.


Having issues like "AC needs to be secure by design" wouldn't be useful. 
(not saying anyone would create issues like that)


/ Jonas

Re: [XHR] LC comments from the XForms Working Group

[Anne van Kesteren]

On Tue, 17 Jun 2008 17:47:24 +0200, Boris Zbarsky <[EMAIL PROTECTED]> wrote:

Anne van Kesteren wrote:
The constructor and providing a pointer to the document from the object  
on which the constructor was invoked.


So correct me if I'm wrong, but wouldn't it work to say that if the  
object the constructor is on is a Window things work as now and  
otherwise whatever specification placed the constructor on some other  
object is responsible for describing how one gets a document from that  
object?


I suppose. Though it would create some path in the XMLHttpRequest  
specification we can't really test and it's not clear to me why we should  
do that.


Also, I forgot to mention that the definition of origin in HTML5 depends  
on Window and we really want to use the HTML5 definition of origin.



Note that a lot of the text can still be shared (in terms of whether the  
calling scope or callee object determines the "right" document to use);  
all that depends on Window is how one actually gets the document, right?


Actually, no, origin depends on it too. I forgot about that because  
XMLHttpRequest just references origin directly.



Having basic Window support is also good for the test suite so we can  
actually test the cross-frame scenarios you raised a long time ago (for  
which I added this dependency when I addressed the issue).


I don't see a problem with saying that the test suite requires a Window,  
to be honest.  If we really wanted we could somehow flag the tests in  
the test suite that really have that as a hard requirement, of course,  
but realistically the tests are HTML files, aren't they?  So they would  
always have a Window...


That's fair enough.


--
Anne van Kesteren

Re: [XHR] LC comments from the XForms Working Group

[Boris Zbarsky]

Anne van Kesteren wrote:
The constructor and providing a pointer to the document from the object 
on which the constructor was invoked.


So correct me if I'm wrong, but wouldn't it work to say that if the object the 
constructor is on is a Window things work as now and otherwise whatever 
specification placed the constructor on some other object is responsible for 
describing how one gets a document from that object?


Note that a lot of the text can still be shared (in terms of whether the calling 
scope or callee object determines the "right" document to use); all that depends 
on Window is how one actually gets the document, right?


Having basic Window support is also good for the test suite so we can 
actually test the cross-frame scenarios you raised a long time ago (for 
which I added this dependency when I addressed the issue).


I don't see a problem with saying that the test suite requires a Window, to be 
honest.  If we really wanted we could somehow flag the tests in the test suite 
that really have that as a hard requirement, of course, but realistically the 
tests are HTML files, aren't they?  So they would always have a Window...


-Boris

Re: New Progress Events editor's draft

[Michael(tm) Smith]

Sam Weinig <[EMAIL PROTECTED]>, 2008-06-17 07:34 -0700:

> On Jun 17, 2008, at 3:45 AM, Michael(tm) Smith wrote:
>> Note that all of the Web API WG drafts are in this tree:
>>
>>  http://dev.w3.org/2006/webapi/
>>
>> And the WAF WG drafts (including Access-Control spec) are here:
>>
>>  http://dev.w3.org/2006/webapi/
>
> By which I am sure Mike meant
>
>  http://dev.w3.org/2006/waf/

Yep, thanks Sam.. copy/paste laziness on my part.

FWIW, also note that all the HTML WG drafts are here:

  http://dev.w3.org/html5/

And Geolocation is here:

  http://dev.w3.org/geo/api/

I think the covers most of the browser API-related spec work for
which we are maintaining drafts on dev.w3.org

  --Mike

-- 
Michael(tm) Smith
http://people.w3.org/mike/
http://sideshowbarker.net/


smime.p7s
Description: S/MIME cryptographic signature

Re: [XHR] LC comments from the XForms Working Group

[Anne van Kesteren]

On Tue, 17 Jun 2008 05:24:48 +0200, Boris Zbarsky <[EMAIL PROTECTED]> wrote:

Anne van Kesteren wrote:
It would change the conformance criteria. I'm not sure that's a good  
idea. Especially since the use case put forward is mostly theoretical.

 Overall, I'm still not convinced this is a good idea.


It doesn't seem necessarily that theoretical to me, for what it's  
worth.  Anne, do you happen to have a more or less complete list of the  
current dependencies of XHR on Window, buy chance?  I think that  
information would be very helpful in seeing where things stand.


The constructor and providing a pointer to the document from the object on  
which the constructor was invoked.


Having basic Window support is also good for the test suite so we can  
actually test the cross-frame scenarios you raised a long time ago (for  
which I added this dependency when I addressed the issue).



--
Anne van Kesteren

Re: New Progress Events editor's draft

[Sam Weinig]

On Jun 17, 2008, at 3:45 AM, Michael(tm) Smith wrote:


Hi Mark,

You can find the editor's draft of the progress-events doc here:

 http://dev.w3.org/2006/webapi/progress/Progress.html

That's actually a direct link to the latest CVS source, so if/when
it gets updated, it'll be immediately available there.

Note that all of the Web API WG drafts are in this tree:

 http://dev.w3.org/2006/webapi/

And the WAF WG drafts (including Access-Control spec) are here:

 http://dev.w3.org/2006/webapi/


By which I am sure Mike meant

 http://dev.w3.org/2006/waf/




Regards,

 --Mike


-Sam

Re: Issues and Actions

[Anne van Kesteren]

On Tue, 17 Jun 2008 16:17:22 +0200, Arthur Barstow <[EMAIL PROTECTED]>  
wrote:
Anyhow, comments from others are welcom, particularly the WebApps  
Editors.


I think I'd be fine with having the technical issues in the tracker.  
However, if it's just going to contain a link to Microsofts' e-mail I  
don't think it's worth it. Also, Jonas already replied in detail to that  
e-mail suggesting there are not as many issues as one might think. (In his  
reply I found one concrete thing he thought Access Control should do  
different (aside from the other things he raised in separate threads, that  
is, for which I raised some issues in the old tracker), to which I  
replied.)


(I hope my afterthought parentheticals are not too confusing.)


Also, I'd like it not to be required to have issues in the tracker. The  
way it worked in the Web API WG and WAF WG was good.



--
Anne van Kesteren

Re: Issues and Actions (was: XHR2 Feedback As Tracker Issues)

[Arthur Barstow]

Doug, All,

On Jun 17, 2008, at 12:21 AM, ext Doug Schepers wrote:

In general, I think using the tracker can be more effective at  
dealing with issues than merely using email or notations in the  
spec, for a number of reasons:


Yes, I agree there are some benefits for more fine-grained Issues.

One concern I have is the meta issues with Issues i.e. the overhead  
of managing the Issues. For example, it would be unfortunate if we  
ended-up spending more time discussing things like "is this an issue  
or not" instead of discussing/debating the technical specifics.


Another concern I have is the potential burden for the Editors i.e.  
the folks actually doing a large part of the group's work. I am most  
familiar with the Editors from the WAF WG (Marcos/Widgets, Hixie/XBL2  
and Anne/AC4CSR) and I think they are generally already doing a good  
job of managing Issues for their specs.


If an Editor wants to manage fine-grained Issues then I'd be open to  
supporting that model. However, if Editors are generally satisfied  
with their current Issue management model, then I'd tend to continue  
to support that too.


Anyhow, comments from others are welcom, particularly the WebApps  
Editors.


-Regards, Art

[access-control] header black list

[Anne van Kesteren]

On Tue, 17 Jun 2008 06:59:50 +0200, Jonas Sicking <[EMAIL PROTECTED]> wrote:

Block lists are unacceptable we all agree. The block list currently in
the spec really should be moved to the XMLHttpRequest Level 1 spec as
that is where the issue lies, not with the Access-Control spec.


Other host language implementations of Access Control that allow setting  
of headers need the same kind of protection. That's why the header list is  
there. Alternatively we could make it a requirement on the host language  
implementation, e.g. XMLHttpRequest, to do this filtering, but that would  
still require listing the headers in some way in the Access Control  
specification.


This applies to the CONNECT, TRACE, and TRACK verbs as well, but I've not  
yet addressed that in the specification.



--
Anne van Kesteren

Re: New Progress Events editor's draft

[Mark Birbeck]

Many thanks, Mike.

2008/6/17 Michael(tm) Smith <[EMAIL PROTECTED]>:
> Hi Mark,
>
> You can find the editor's draft of the progress-events doc here:
>
>  http://dev.w3.org/2006/webapi/progress/Progress.html
>
> That's actually a direct link to the latest CVS source, so if/when
> it gets updated, it'll be immediately available there.
>
> Note that all of the Web API WG drafts are in this tree:
>
>  http://dev.w3.org/2006/webapi/
>
> And the WAF WG drafts (including Access-Control spec) are here:
>
>  http://dev.w3.org/2006/webapi/
>
> Regards,
>
>  --Mike
>
> Mark Birbeck <[EMAIL PROTECTED]>, 2008-06-17 11:08 +0100:
>
>> Hi Chaals,
>>
>> Would you mind providing the link? I'm sure it's in an easy to find
>> place, but I'm not yet familiar with the spec locations yet.
>>
>> Thanks.
>>
>> Mark
>>
>> On Tue, Jun 17, 2008 at 10:45 AM, Charles McCathieNevile
>> <[EMAIL PROTECTED]> wrote:
>> >
>> > Hi folks,
>> >
>> > I have produced a new editor's draft [1] that incorporates a bunch of the
>> > feedback I have on the Public Working Draft. It notes, rather than provides
>> > a resolution for, the new (or recycled) issues I raised on defining an
>> > eventType for document.createEvent and on where to define what parts of the
>> > message are counted towards counting content. There are some known things 
>> > to
>> > clean up still.
>> >
>> > Feedback welcome as always and should be sent to this list.
>> >
>> > cheers
>> >
>> > Chaals
>> >
>> > --
>> > Charles McCathieNevile  Opera Software, Standards Group
>> >je parle français -- hablo español -- jeg lærer norsk
>> > http://my.opera.com/chaals   Try Opera 9.5: http://snapshot.opera.com
>> >
>> >
>>
>>
>>
>> --
>> Mark Birbeck, webBackplane
>>
>> [EMAIL PROTECTED]
>>
>> http://webBackplane.com/mark-birbeck
>>
>> webBackplane is a trading name of Backplane Ltd. (company number
>> 05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
>> London, EC2A 4RR)
>>
>
> --
> Michael(tm) Smith
> http://people.w3.org/mike/
> http://sideshowbarker.net/
>



-- 
Mark Birbeck, webBackplane

[EMAIL PROTECTED]

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)

Re: ISSUE-5 (Unexpanded Entities): Wording for the Treatment of Unexpanded Entity References and Entity Replacement Markup [Element Traversal]

[Anne van Kesteren]

On Tue, 17 Jun 2008 08:01:08 +0200, Web Applications Working Group Issue  
Tracker <[EMAIL PROTECTED]> wrote:
Note that this is an issue for any interface specification, so a uniform  
solution should be decided.


I think the solution that makes most sense is to not let entities enter  
the DOM, ever. This should probably have been the case for DOCTYPEs and  
CDATA sections as well, but it's probably too late for those.



--
Anne van Kesteren

responseXML/responseText exceptions and parseError

[Anne van Kesteren]

On Tue, 17 Jun 2008 10:29:12 +0200, Zhenbin Xu <[EMAIL PROTECTED]>  
wrote:

Technically because all other XHR methods/properties throw exceptions
in case of state violation, exception for responseXML/responseText is  
better.


The reason these don't throw an exception anymore is actually documented  
on the public-webapi mailing list. Nobody else provided additional  
information at the time:


  http://lists.w3.org/Archives/Public/public-webapi/2008Feb/thread.html#msg94


Regarding parseError, since the parseError object is not part of DOM Core  
and nobody but Internet Explorer supported it, it's not part of  
XMLHttpRequest. If we change DOM Core to say that documents with a  
namespace well-formedness violation are represented by an empty Document  
object with an associated parseError object I suppose we could update  
XMLHttpRequest to that effect.


I don't really feel strongly either way though it's a bit unfortunate that  
Microsoft comes with this feedback now given that it's been stable this  
way since the first W3C XMLHttpRequest draft published over two years ago.  
(Returning null for documents that have a namespace well-formedness  
violation.)



--
Anne van Kesteren

Re: ISSUE-3 (eventType): [Progress] [D3E]

[Anne van Kesteren]

On Tue, 17 Jun 2008 07:25:42 +0200, Charles McCathieNevile  
<[EMAIL PROTECTED]> wrote:
The usecase makes sense to me. But I wonder if it should be defined in  
DOM 3 events instead?


DOM Events should define a way for other specifications to introduce their  
own event interfaces in a convenient way. The other specifications can  
then use that to easily describe FooEvent, FooEvent.init..., and  
"FooEvent" (for constructing). It would be quite a burden if DOM Events  
would actually needed to be updated each time we introduce a new event  
interface.



--
Anne van Kesteren

Re: New Progress Events editor's draft

[Michael(tm) Smith]

Hi Mark,

You can find the editor's draft of the progress-events doc here:

  http://dev.w3.org/2006/webapi/progress/Progress.html

That's actually a direct link to the latest CVS source, so if/when
it gets updated, it'll be immediately available there.

Note that all of the Web API WG drafts are in this tree:

  http://dev.w3.org/2006/webapi/

And the WAF WG drafts (including Access-Control spec) are here:

  http://dev.w3.org/2006/webapi/

Regards,

  --Mike

Mark Birbeck <[EMAIL PROTECTED]>, 2008-06-17 11:08 +0100:

> Hi Chaals,
> 
> Would you mind providing the link? I'm sure it's in an easy to find
> place, but I'm not yet familiar with the spec locations yet.
> 
> Thanks.
> 
> Mark
> 
> On Tue, Jun 17, 2008 at 10:45 AM, Charles McCathieNevile
> <[EMAIL PROTECTED]> wrote:
> >
> > Hi folks,
> >
> > I have produced a new editor's draft [1] that incorporates a bunch of the
> > feedback I have on the Public Working Draft. It notes, rather than provides
> > a resolution for, the new (or recycled) issues I raised on defining an
> > eventType for document.createEvent and on where to define what parts of the
> > message are counted towards counting content. There are some known things to
> > clean up still.
> >
> > Feedback welcome as always and should be sent to this list.
> >
> > cheers
> >
> > Chaals
> >
> > --
> > Charles McCathieNevile  Opera Software, Standards Group
> >je parle français -- hablo español -- jeg lærer norsk
> > http://my.opera.com/chaals   Try Opera 9.5: http://snapshot.opera.com
> >
> >
> 
> 
> 
> -- 
> Mark Birbeck, webBackplane
> 
> [EMAIL PROTECTED]
> 
> http://webBackplane.com/mark-birbeck
> 
> webBackplane is a trading name of Backplane Ltd. (company number
> 05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
> London, EC2A 4RR)
> 

-- 
Michael(tm) Smith
http://people.w3.org/mike/
http://sideshowbarker.net/


smime.p7s
Description: S/MIME cryptographic signature

Re: FW: [Adding mouseenter and mouseleave events]

[Michael(tm) Smith]

Magnus Kristiansen <[EMAIL PROTECTED]>, 2008-06-17 12:19 +0200:

> Bjoern Hoehrmann did write a reply[1].

OK, thanks -- I seemed to have have missed that somehow.

> My recap: It clarified some technical misconceptions on my part. Also  
> confirmed that there is demand for the events and that the existing  
> solutions are exceedingly complicated.
>
> [1] http://lists.w3.org/Archives/Public/public-webapi/2008May/0111.html

OK, so I guess we ought to decide where we go with this next. Take
it up as an issue for the group? Assign somebody an action?
Something else?

  --Mike

-- 
Michael(tm) Smith
http://people.w3.org/mike/
http://sideshowbarker.net/


smime.p7s
Description: S/MIME cryptographic signature

Re: Plans for after F2F?

[Anne van Kesteren]

On Tue, 17 Jun 2008 12:19:36 +0200, Anne van Kesteren <[EMAIL PROTECTED]>  
wrote:
On Tue, 17 Jun 2008 11:47:15 +0200, Anne van Kesteren <[EMAIL PROTECTED]>  
wrote:
Is everyone leaving Thursday evening or Friday or some people staying  
until Saturday/Sunday? I'm trying to book flights and I'm not sure what  
return ticket to take.


Seems I'm going back Friday myself.


Make that Sunday. (Guess I still need to wake up...)


--
Anne van Kesteren

Re: FW: [Adding mouseenter and mouseleave events]

[Magnus Kristiansen]

Michael(tm) Smith wrote:

I wanted to note the following was posted to the public-webapi
list last month but as far as I can see, nobody ever replied to
it. So I'm wondering what the status is on the request. Has there
been further discussion about this on telcons or IRC? Is it
something that's being considered or incorporation in the DOM3
Events spec?

  --Mike


Bjoern Hoehrmann did write a reply[1].

My recap: It clarified some technical misconceptions on my part. Also 
confirmed that there is demand for the events and that the existing 
solutions are exceedingly complicated.


[1] http://lists.w3.org/Archives/Public/public-webapi/2008May/0111.html

--
Magnus Kristiansen
"Don't worry; the Universe IS out to get you."

Re: Plans for after F2F?

[Anne van Kesteren]

On Tue, 17 Jun 2008 11:47:15 +0200, Anne van Kesteren <[EMAIL PROTECTED]>  
wrote:
Is everyone leaving Thursday evening or Friday or some people staying  
until Saturday/Sunday? I'm trying to book flights and I'm not sure what  
return ticket to take.


Seems I'm going back Friday myself.


--
Anne van Kesteren

Re: New Progress Events editor's draft

[Mark Birbeck]

Hi Chaals,

Would you mind providing the link? I'm sure it's in an easy to find
place, but I'm not yet familiar with the spec locations yet.

Thanks.

Mark

On Tue, Jun 17, 2008 at 10:45 AM, Charles McCathieNevile
<[EMAIL PROTECTED]> wrote:
>
> Hi folks,
>
> I have produced a new editor's draft [1] that incorporates a bunch of the
> feedback I have on the Public Working Draft. It notes, rather than provides
> a resolution for, the new (or recycled) issues I raised on defining an
> eventType for document.createEvent and on where to define what parts of the
> message are counted towards counting content. There are some known things to
> clean up still.
>
> Feedback welcome as always and should be sent to this list.
>
> cheers
>
> Chaals
>
> --
> Charles McCathieNevile  Opera Software, Standards Group
>je parle français -- hablo español -- jeg lærer norsk
> http://my.opera.com/chaals   Try Opera 9.5: http://snapshot.opera.com
>
>



-- 
Mark Birbeck, webBackplane

[EMAIL PROTECTED]

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)

FW: [Adding mouseenter and mouseleave events]

[Michael(tm) Smith]

I wanted to note the following was posted to the public-webapi
list last month but as far as I can see, nobody ever replied to
it. So I'm wondering what the status is on the request. Has there
been further discussion about this on telcons or IRC? Is it
something that's being considered or incorporation in the DOM3
Events spec?

  --Mike

- Forwarded message from Ian Hickson <[EMAIL PROTECTED]> -

Date: Thu, 8 May 2008 00:58:04 + (UTC)
From: Ian Hickson <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Archived-At: 
Subject: Adding mouseenter and mouseleave events


The WHATWG received the attached feedback. It's not clear to me which 
specification should be defining the normative requirements on events like 
mouseover, mousemove, mouseout, and so forth, let alone who would specify 
new events as requested in this feedback.

Will the DOM3 Events specification include such requirements? (Right now 
it has nothing resembling normative requirements for these events.)

Please let me know if this is not something that DOM3 Events will handle, 
so that I can find a more suitable working group for this feedback.

Thanks,
-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Content-Description: [whatwg] Adding mouseenter and mouseleave events (fwd)
To: [EMAIL PROTECTED]
From: Magnus Kristiansen <[EMAIL PROTECTED]>
Date: Thu, 15 Mar 2007 01:30:13 +0100
User-Agent: Opera Mail/9.20 (Win32)
Subject: [whatwg] Adding mouseenter and mouseleave events


Mouseover/out events will trigger when elements contained inside the
EventTarget are hovered, and then bubble up. This is contrary to the most
obvious interpretation, as you are still inside (over) the targeted
element. IE supports two events, mouseenter[1] and mouseleave[2], which
solve this problem by not bubbling.

It is possible to work around the problem by using target/relatedTarget
and walking up the DOM tree. However, this requires extra code for every
event handler. Besides, these events were often not meant to be generated
in the first place, by the intent of the author.

I have no statistics for how often mouseover/out are used with and without
intent of bubbling, but the anecdotal evidence from my own experience has
never found me wanting it.

I suggest these two events be added to the web applications spec.

[1]
http://msdn.microsoft.com/workshop/author/dhtml/reference/events/onmouseenter.asp
[2]
http://msdn.microsoft.com/workshop/author/dhtml/reference/events/onmouseleave.asp

--
Magnus Kristiansen
"Don't worry; the Universe IS out to get you."

Content-Description: Re: [whatwg] Adding mouseenter and mouseleave events (fwd)
Date: Thu, 15 Mar 2007 12:25:52 +0100
To: Gareth Hay <[EMAIL PROTECTED]>
From: Magnus Kristiansen <[EMAIL PROTECTED]>
User-Agent: Opera Mail/9.20 (Win32)
Cc: [EMAIL PROTECTED]
Subject: Re: [whatwg] Adding mouseenter and mouseleave events


On Thu, 15 Mar 2007 02:02:46 +0100, Gareth Hay <[EMAIL PROTECTED]> wrote:

> On 15 Mar 2007, at 00:30, Magnus Kristiansen wrote:
>
>> Mouseover/out events will trigger when elements contained inside the
>> EventTarget are hovered, and then bubble up. This is contrary to the
>> most obvious interpretation, as you are still inside (over) the
>> targeted element. IE supports two events, mouseenter[1] and
>> mouseleave[2], which solve this problem by not bubbling.
>>
>> It is possible to work around the problem by using target/relatedTarget
>> and walking up the DOM tree. However, this requires extra code for
>> every event handler. Besides, these events were often not meant to be
>> generated in the first place, by the intent of the author.
>>
>> I have no statistics for how often mouseover/out are used with and
>> without intent of bubbling, but the anecdotal evidence from my own
>> experience has never found me wanting it.
>>
>> I suggest these two events be added to the web applications spec.
>>
>> [1] http://msdn.microsoft.com/workshop/author/dhtml/reference/
>> events/onmouseenter.asp
>> [2] http://msdn.microsoft.com/workshop/author/dhtml/reference/
>> events/onmouseleave.asp
>>

> Can't you just return false from an event handler to prevent further
> bubbling?
>

As mentioned there are workarounds, although I don't think attempting to
add anti-bubbling handlers on every descendant element is a reliable one.
This unwanted bubbling puts extra load on the user agent for processing
it, and the script author to work around it, when removing the root cause
is easily possible by making the event non-bubbling to begin with.

--
Magnus Kristiansen
"Don't worry; the Universe IS out to get you."

Content-Description: Re: [whatwg] Adding mouseenter and mouseleave events (fwd)
From: Gareth Hay <[EMAIL PROTECTED]>
Date: Thu, 15 Mar 2007 19:10:33 +
To: Magnus Kristiansen <[EMAIL PROTECTED]>
X-Mailer: 

Plans for after F2F?

[Anne van Kesteren]

Hi,

Is everyone leaving Thursday evening or Friday or some people staying  
until Saturday/Sunday? I'm trying to book flights and I'm not sure what  
return ticket to take.


Cheers,


--
Anne van Kesteren

New Progress Events editor's draft

[Charles McCathieNevile]

Hi folks,

I have produced a new editor's draft [1] that incorporates a bunch of the  
feedback I have on the Public Working Draft. It notes, rather than  
provides a resolution for, the new (or recycled) issues I raised on  
defining an eventType for document.createEvent and on where to define what  
parts of the message are counted towards counting content. There are some  
known things to clean up still.


Feedback welcome as always and should be sent to this list.

cheers

Chaals

--
Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera 9.5: http://snapshot.opera.com

RE: RE: Potential bugs identified in XHR LC Test Suite

[Ian Hickson]

On Tue, 17 Jun 2008, Zhenbin Xu wrote:
> > >
> > > I am not sure if I understand your question. responseXML.parseError 
> > > has the error information 
> > > http://msdn.microsoft.com/en-us/library/aa926483.aspx
> >
> > Oh, I assumed Sunava meant a conforming Document object was returned. 
> > A parseError-type object would be what I had in mind, yes. However, if 
> > we do this, then we should specify it. If we don't specify it, I'd 
> > rather have an exception.
> 
> The spec can simply state that a conforming document object is returned, 
> which includes out-of-band error information. This is what IE does today 
> and is a very reasonable approach that allows rich error information for 
> debugging.

I don't believe it is conforming for Document objects to have parseError 
attributes, but I could be mistaken -- is there a spec for parseError? 
Even if there isn't, though, I agree that it is a generally good solution 
to the problem, I'm just saying that we should specify it, so that UAs 
can be standards-compliant and support it interoperably.


> > Not really; if the script is expecting an exception, and receives null 
> > instead, then they'll just get an exception as soon as they 
> > dereference the object, which in almost all cases will be straight 
> > away.
> 
> [Zhenbin] I should explain the scenario I talked about. For instance, if 
> I am to write a wrapper object myXHR, it makes a difference for me when 
> I do the following
> 
> myXHR.responseXML
> if (!_innerResponseXML)
>   {
> try
> {
>_innerResponseXML = _innerXHR.responseXML;
> }
> catch (e)
> {
> _myexception = e;
> return _dummpyResponseXML;
> }
> }
> return _innerResponseXML;
> 
> My try catch would not catch null. And the exception would be passed on 
> to my callers, which is not what I wanted.

Indeed.


> > > If we are going to spec it to accommodate all existing browsers, we 
> > > would want to make it "return null or INVALID_STATE_ERR exception".
> >
> > We want interoperable behaviour, so defining it in this way would be a 
> > bad idea. (I don't really have an opinion either way about exception 
> > vs null, but it seems that we should just pick whatever is most 
> > commonly implemented, which I'm guessing is what Anne did here.)
> 
> Fair enough. So let's pick one.
> 
> What is "commonly implemented"? Is it largest browser market share?

Since the cost to implementations for fixing the problem is independent of 
the size of the user base, it would be based just on the number of 
independent implementations.


> Is it number of enterprise applications written on top of particular 
> browser?

All the browsers want to be compatible with the Web, so if there are mroe 
Web sites depending on the exception behaviour than the null behaviour, 
then we clearly should do the exception behaviour. And vice versa. Do we 
have any good numbers on this? (That there are widely deployed browsers 
that return null instead of throwing an exception tends to suggest that 
Web pages don't depend on either behaviour; we'd probably need evidence 
to the contrary to decide one way or the other based on compatibility.)


> Is it the number of browers, in which case I hope my fictional 
> home grown personal browser gets a vote :-)

Obviously fictional browsers aren't relevant, since the cost of fixing a 
fictional browser is zero.


> From a pure technical point of view, predictably throw exception on 
> state violations is easier to understand.  I hope you would agree there 
> is value to change spec for the sake of consistent programming model 
> (which happens to be the IE model).

Indeed.


> Did the spec call out that responseXML returned from XHR should have 
> equivalent DOM support as UA's object?  If it is, that would be a good 
> topic for us to debate about.

I believe the spec just says that you return a Document object; it is the 
lack of a distinction between different Document objects that requires the 
level of support to be the same. As you said, a consistent programming 
model has value.


> I disagree that because DOM Level 3 is 3+ yr old spec that every UA has 
> to support it in order to be XHR compliant, if that is what you implied. 

I didn't mean to imply that. I don't think XHR should require any 
particular level of support.

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

RE: RE: Potential bugs identified in XHR LC Test Suite

[Zhenbin Xu]

Exceptional situation in general doesn't hinder interoperability. It only
becomes an issue if it is clearly stated in W3C spec and used as
a way to measure if UA is compliant.

We have provided our feedback to write spec in a away all current browsers
are complaint. If the general sentiment is to pick one model, then lets pick
the exception model, which is the model original XHR inventors picked.

Technically because all other XHR methods/properties throw exceptions
in case of state violation, exception for responseXML/responseText is better.
If original XHR picked the null model, then we should go null model.
The important thing really is consistency, thus predictability.


Thanks!
Zhenbin


> -Original Message-
> From: Jonas Sicking [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 16, 2008 2:13 PM
> To: Zhenbin Xu
> Cc: Sunava Dutta; Web API public; IE8 Core AJAX SWAT Team; public-
> [EMAIL PROTECTED]
> Subject: Re:  RE: Potential bugs
> identified in XHR LC Test Suite
>
> Zhenbin Xu wrote:
> > The issue of return "null or an exception" is simply a compromise
> > here. IE would throw an exception for state violations. Accessing
> > responseXML before open() is a state violation so it would trigger
> > exception. Other browsers may return null in such situation.  In
> order
> > to accommodate all browsers, the spec would have to be rewritten in
> > some way.
>
> Please note that it is not a goal for the spec to be written in such a
> way that all existing browsers are conforming to the spec. It turned
> out
> that it was impossible to write a spec with that goal while still
> keeping the spec useful. So we no longer try to "accomodate all
> browsers", but instead write a spec that leads to interoperability
> between browsers.
>
> > We would certainly love to have the spec change to "MUST throw
> > INVALID_STATE_ERR exception", which is consistent with other
> > INVALID_STATE_ERR cases.  For instance, the spec says if send() is
> > called before OPENED, it should trigger  INVALID_STATE_ERR exception.
> > Another example is that user agent must raise INVALID_STATE_ERR if
> > "status" is not available. responseText and responseXML are the
> > outlier in the spec.
>
> Personally I think it makes more sense to return 'null' from
> .responseXML. We at mozilla have not had any interoperability problems
> with this behavior. Exceptions are better left for exceptional
> circumstances.
>
> However I can't say that I think the behavior is very important to me
> one way or another, as long as it's usefully defined.
>
> Best Regards,
> Jonas Sicking
>

RE: RE: Potential bugs identified in XHR LC Test Suite

[Zhenbin Xu]

Inline...

> -Original Message-
> From: Ian Hickson [mailto:[EMAIL PROTECTED]
> Sent: Sunday, June 15, 2008 11:46 PM
> To: Zhenbin Xu
> Cc: Sunava Dutta; Web API public; IE8 Core AJAX SWAT Team; public-
> [EMAIL PROTECTED]
> Subject: RE:  RE: Potential bugs
> identified in XHR LC Test Suite
>
> On Sun, 15 Jun 2008, Zhenbin Xu wrote:
> > Ian wrote:
> > > On Wed, 11 Jun 2008, Sunava Dutta wrote:
> > > >
> > > > When Parsing Error happens, IE would still retain responseXML and
> > > > put error information on the object.  Isnt this better than null
> as
> > > > there�s more relevant information for the web developer?
> > >
> > > How does one distinguish a document returned with parse error
> > > information from one that happens to look like a parse error but
> was
> > > well-formed?
> > >
> > > I wouldn't mind including more information but it seems like it
> should
> > > be out-of-band.
> >
> > I am not sure if I understand your question. responseXML.parseError
> has
> > the error information
> > http://msdn.microsoft.com/en-us/library/aa926483.aspx
>
> Oh, I assumed Sunava meant a conforming Document object was returned. A
> parseError-type object would be what I had in mind, yes. However, if we
> do
> this, then we should specify it. If we don't specify it, I'd rather
> have
> an exception.
>

[Zhenbin]  The spec can simply state that a conforming document object
is returned, which includes out-of-band error information. This is what
IE does today and is a very reasonable approach that allows rich error
information for debugging.


>
> > > > The test is expecting us to return NULL in case open() has not
> been
> > > > called.  We throw an exception in IE.  I�d pre fer if the spec
> > > > says �MUST return null OR an exception� otherwise I fear sites
> > > > today will be broken.
> > >
> > > If a site is expecting an exception and gets null, then they'll get
> an
> > > exception when they try to dereferene the null, so in most cases it
> > > seems like this would work anyway.
> >
> > Properly written sites would have no problem one way or the other.
> > However if someone is writing a wrapper on top of XMLHTTP, clearly it
> > would make a difference on how to expose wrapped properties.
>
> Not really; if the script is expecting an exception, and receives null
> instead, then they'll just get an exception as soon as they dereference
> the object, which in almost all cases will be straight away.
>
>

[Zhenbin] I should explain the scenario I talked about. For instance, if
I am to write a wrapper object myXHR, it makes a difference for me when I
do the following

myXHR.responseXML
if (!_innerResponseXML)
  {
try
{
   _innerResponseXML = _innerXHR.responseXML;
}
catch (e)
{
_myexception = e;
return _dummpyResponseXML;
}
}
return _innerResponseXML;

My try catch would not catch null. And the exception would be passed on
to my callers, which is not what I wanted.




> > If we are going to spec it to accommodate all existing browsers, we
> > would want to make it "return null or INVALID_STATE_ERR exception".
>
> We want interoperable behaviour, so defining it in this way would be a
> bad
> idea. (I don't really have an opinion either way about exception vs
> null,
> but it seems that we should just pick whatever is most commonly
> implemented, which I'm guessing is what Anne did here.)
>
>


[Zhenbin]  Fair enough. So let's pick one.

What is "commonly implemented"? Is it largest browser market share?
Is it number of enterprise applications written on top of particular browser?
Is it the number of browers, in which case I hope my fictional home grown
personal browser gets a vote :-)

From a pure technical point of view,  predictably throw exception on state
violations is easier to understand.  I hope you would agree there
is value to change spec for the sake of consistent programming model (which
happens to be the IE model).



>
> > > I think it's important that we test that the DOM returned from XHR
> is
> > > DOM Core conformant just like any other, so this seems like an
> > > important and relevant testing area for XHR.
> >
> > That is not necessarily a good idea because you would then have to
> > mandate which level of DOM Core support is required. And if the spec
> > requires DOM level 3, that is big barrier for new user agent that
> wants
> > to be compliant with XHR spec.
> >
> > getElementById requires DOM Level 2. At the least the testing case
> can
> > be changed to use getElementByTagName, which is DOM level 1.
>
> I think expecting DOM Level 3 is the least of our worries -- after all,
> that's a 3+ year old spec. So testing just DOM Level 2 is really not a
> problem as far as I can tell. However, I agree that it would make sense
> to
> make the test pass if the UA didn't support that level of DOM on
> "regular"
> DOM objects t

Re: [WebIDL] Assigning to constants

[Cameron McCormack]

Cameron McCormack:
> > Yes. The properties set for IDL consts on the interface object, the
> > interface prototype object (or corresponding exception ones) should
> > all be ReadOnly.  (And the prototype is where the constant comes
> > from in the document.documentElement.ELEMENT_NODE case.)

Magnus Kristiansen:
> The last case isn't covered at the moment, since s14 of [[Put]] goes to  
> s24, skipping [[CanPut]] (which is the step that checks prototype chain  
> for readonly). It should instead go to s19.

Over-zealous optimisation on my part (fixed).

> However, at that point it's just doing what would happen at s15, so
> s14 can actually be removed.

Not as of the latest revision, I think?

> And two more issues I noticed:
> - Using an IndexSetter results in a return value (s7), the other returns  
> are void. Copypaste from [[Get]] maybe?

Yeah it shouldn’t be there (fixed).

> - [[HasProperty]] = true (s9-10) should go to s15, since s14 is  
> trivially false. This solves itself if s14 is removed per above.

It’s not false if [[HasProperty]] returned true because the property was
in the prototype chain rather than directly on the object, though.

-- 
Cameron McCormack ≝ http://mcc.id.au/