RE: Microsoft Corp. has nominated Alec Berntson to Web API Working Group

[Travis Leithead]

(Except that this working group just closed down... :-)

Will you also be joining the web applications WG?

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sunava Dutta
Sent: Monday, June 09, 2008 2:31 PM
To: Alec Berntson; Charles McCathieNevile; Michael Champion
Cc: public-webapi@w3.org; Alec Berntson
Subject: RE: Microsoft Corp. has nominated Alec Berntson to Web API Working 
Group

Good to have you here Alec!

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> On Behalf Of Alec Berntson
> Sent: Friday, June 06, 2008 10:32 AM
> To: Charles McCathieNevile; Michael Champion
> Cc: public-webapi@w3.org; Alec Berntson
> Subject: RE: Microsoft Corp. has nominated Alec Berntson to Web API
> Working Group
>
> Thanks Chaals,
>My Name is Alec Berntson, and I work on a variety of location related
> projects at Microsoft. My interest in the group's work is primarily
> focused on the Geolocation API proposal, which I would very much like to
> see take off. My goal is to help define the specification and (hopefully)
> coordinate resources to test it.
>
> Cheers,
>   Alec
>
>
> -Original Message-
> From: Charles McCathieNevile [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 06, 2008 2:37 AM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Michael Champion
> Cc: [EMAIL PROTECTED]; Alec Berntson
> Subject: Re: Microsoft Corp. has nominated Alec Berntson to Web API
> Working Group
>
> Alec,
>
> welcome to WebAPI. Can you please send a brief intro to the group (either
> [EMAIL PROTECTED] or public-webapi@w3.org is fine) including your
> interests in the group's work.
>
> Thanks in advance...
>
> cheers
>
> Chaals
>
> On Fri, 06 Jun 2008 04:52:01 +0200, <[EMAIL PROTECTED]> wrote:
>
> >   Dear AC Rep, Chair, Team Contact, and Participant,
> >
> > On June 6, 2008, 2:50  UTC, Alec Berntson became a participant in the
> Web
> > API Working Group. This person was nominated by Michael Champion
> >
> > This also implies that the following commitments were made:
> > - to  have reviewed the Process Document on individual participant
> > qualifications ( section 3.1 [1]),  Member participation in a Working
> > Group (section 6.2.1.1 [2]) - in particular that (1) the Member will
> > provide the necessary financial support for participation (e.g., for
> > travel, telephone calls, and conferences), and (2) the AC representative
> > attests that the individual accepts the participation terms set forth in
> > the charter [3] -  and good standing (section 6.2.1.7 [4])
> > - to  agree to the participation conditions described in the Working
> > Group
> > charter [3]
> >
> > For more information on Web API Working Group participation, see:
> > http://www.w3.org/2004/01/pp-impl/38482/status
> >
> > 1.
> > http://www.w3.org/2005/10/Process-
> 20051014/policies.html#ParticipationCriteria
> > 2. http://www.w3.org/2005/10/Process-20051014/groups.html#member-rep-wg
> > 3. http://www.w3.org/2006/webapi/admin/charter.html
> > 4. http://www.w3.org/2005/10/Process-20051014/groups.html#good-standing
> >
> >
> > This message has been sent by the W3C Working Group Management System.
>
>
>
> --
> 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

Note for DOM L3 Core SE

[Travis Leithead]

While implementing some improvements to getAttribute in IE8, we actually 
checked in code that is conformant to what the spec says about the return value:

Return Value
DOMString
The Attr value as a string, or the empty string if that attribute does not have 
a specified or default value

Once this code was in, we immediately hit app and site compat problems because 
we always returned a string--an empty string--if the "attribute [did] not have 
a specified or default value".

As it turns out in practice, all browsers actually implement this a slightly 
different way: they return the value as a string, or null if the attribute does 
not have a specified or default value. In other words, if there is no entry for 
the requested attribute in the NamedNodeMap, then null is returned.

IE8 is being fixed to be conformant with what everyone else has implemented, I 
just thought I would pass this along to whomever is doing the DOM L3 Core 
Second Edition so that it might be recorded in that spec, an errata, or so that 
we can discuss.

Travis Leithead - OM Program Manager - Internet Explorer

ACTION-250 TRAVIS - provide a simple test for modifier key combinations (specifically the "alt" key)

[Travis Leithead]

Attached test shows that some combinations of alt modifier keys on 
Windows-based machines are handled in a strangely consistent inconsistent way.
Title: Alt S repro







Lossy key combinations using the ALT modifier key on Windows-based machines
There are several scenarios that will be used for comparison:

	Scenario 1: down ALT, down x, up ALT, up x
	Scenario 2: down ALT, down x, up x, up ALT
	Scenario 3: down ALT, up ALT, down ALT, up ALT
	Scenario 4: down ALT, up ALT, down ALT, down x, up ALT, up x
	Scenario 5: down ALT, up ALT, down ALT, down x, up x, up ALT

x was picked as it is a relatively neutral key in most browsers
Directions for repro
After this page loads, assuming no other clicks or focus within the webpage area, 
press the keys in the combinations shown in the scenarios
The difference column in the table below should be zero for both rows. If it 
is not then there is a mismatch between keydown/keyup pairs. The last column indicates 
the result of the number of keyUp events minus the number of keyDown events.
A positive number indicates more key ups and a negative number indicates 
more key downs, i.e, keyUps are being lost.


What is essential in this repro is that the ALT key is the first key processed 
upon loading this page. In some browsers, pushing F5 is also considered a key that precedes 
the alt key (despite the page having been reloaded). In order to do a reload where 
ALT is processed as the first key, one needs to click on the address bar and push 
enter (assuming the page address is already in there).
Testing results--two browsers
The following table shows which keys are lost on several browser platforms tested.

	
		 
		Scenario 1
		Scenario 2
		Scenario 3
		Scenario 4
		Scenario 5
	
	
		IE7
		x: up
		ALT: up
		x: 
		ALT: up
		x:
		ALT: 2nd down
		x: up
		ALT: 2nd up, 2nd down
		x: 
		ALT: 2nd up, 2nd down
	
	
		Firefox3RC1
		x:
		ALT: up
		x:
		ALT: up
		x:
		ALT: 2nd down
		x:
		ALT: 2nd up, 2nd down
		x:
		ALT: 2nd up, 2nd down
	

Press c to clear the results

DOML3: ACTION-266: TRAVIS - Test addEventListener vs onFoo attribute

[Travis Leithead]

Interesting findings (mostly related to IE):

This test tries to define if the HTML event handlers (onFoo) are linked to the 
add/removeEventListener APIs in any way (or to define what the relationship is).

Browsers tested: Opera 9.25, Firefox 3 RC1, IE8 Beta1, Safari 3.1.1.

(on IE, I substituted attach/detachEvent for add/removeEventListener)

The findings appear to indicate that:

1.  All tested browsers follow a basic model in that an HTML event handler is 
maintained separately (perhaps in a separate queue) from event handlers 
attached via programmatic means (e.g., addEventListener/attachEvent). This can 
be verified by adding an HTML event handler and then trying to delete the 
reference to its DOM attribute via removeEventListener.

In addition to this basic conclusion, there were a few discrepencies in event 
handling that should be noted:

* IE/Firefox/Opera all keep a reference alive to the HTML event handler via the 
element's 'onclick' DOM attribute even after the content attribute has been 
removed.
* Safari also keeps a reference to the element's 'onclick' handler, yet the 
"body" of the handler may be missing if the element's content attribute is 
removed (this prevents adding an event listener via the DOM attribute if the 
content attribute is missing).
* IE's attachEvent is cumulative, despite re-applying the same handler over and 
over. detachEvent works in reverse, removing references until none are left.
* IE has a bug that HTML event handlers are not actually removed via 
removeAttribute (though the attribute itself is removed). This is being fixed 
in IE8, but does impact this test page :(


Title: onFoo versus programmatic event handlers







onFoo versus add/removeEventListener(foo)
This test checks the relationship between HTML inline event handlers and 
programmatically-added event handlers for both the Microsoft and W3C event 
handling models.
The box below is the testing area for mouse events. It has no 
events attached by default when the page loads. The buttons below 
the box control the adding/removing of the following event handler
 to the box:

	onclick - cycle the color of the box from (0)red -> (1)orange -> (2)yellow -> (3)green -> (4)blue

The buttons below it control the dynamic addition/removal of the event via 
the various dynamic mechanisms supported by browsers.

 
 0
 
 Event handler manipulation via the Element
 
 
  
 
 
 Event handler manipulation via the EventTarget
 
 
 Handler Attached: no
 
 
 Event handler manipulation via the EventTarget with references to the Element's DOM property
 
 
 Handler Attached: no
 

RE: XHR LC comments

[Travis Leithead]

>The point is that Apple and Microsoft are both going to implement the
>thing as required by the Web in 2000, not as defined in HTML5. HTML5 is
>describing existing practice on these matters, not defining new material.

Well, a _few_ bits of new material ;-)

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson
Sent: Thursday, May 15, 2008 1:35 PM
To: Julian Reschke
Cc: Anne van Kesteren; public-webapi@w3.org
Subject: Re: XHR LC comments


On Thu, 15 May 2008, Julian Reschke wrote:
> >
> > But we don't have to limit ourselves to that definition. We could just
> > as easily say that XHR1's functionality is as defined in XHR1, and
> > that it uses terms and features that are currently underdefined. It
> > wouldn't, in
>
> ...in which case I'd say that (a) the references aren't normative after
> all, and (b) the spec itself can't be normative as it is written.

I don't mind calling the references "informative" if that's what it takes.
I'm not sure what practical difference it would make.

> > practice, take anything away from the ability to get interoperable
> > implemenations of the feature described in XHR1.
>
> Really?
>
> What if Apple implements the thing as defined by HTML5-as-of-2008, and
> Microsoft as defined in HTML5-as-of-2009?
>
> If it matters, then it's a problem. If it doesn't matter, leave it out
> of the XHR spec, as apparently, it's irrelevant for the goal it's trying
> to achieve.

The point is that Apple and Microsoft are both going to implement the
thing as required by the Web in 2000, not as defined in HTML5. HTML5 is
describing existing practice on these matters, not defining new material.

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

RE: DOM3 Events Telcon Agenda, 14 May 2008 (Today!!)

[Travis Leithead]

Also have a conflict at this time. This makes two weeks in a row :(

I send my regrets that I cannot attend this week.

Status:

* Very little progress on DOM L3 Events action items--expect to have completed 
a few of those by next telecom.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anne van Kesteren
Sent: Wednesday, May 14, 2008 4:57 AM
To: Web API WG (public)
Subject: Re: DOM3 Events Telcon Agenda, 14 May 2008 (Today!!)


On Wed, 14 May 2008 13:41:45 +0200, Doug Schepers <[EMAIL PROTECTED]> wrote:
> This is a reminder that we will have a DOM 3 Events telcon today, 14
> May.  Please reply to public-webapi@w3.org to express regrets if you
> cannot attend.

Can't attend. Leaving at 6 here (4PM UTC) for a hosted dinner.


--
Anne van Kesteren

RE: Modal dialogs in HTML5

[Travis Leithead]

>> Most modality discussed so far has been about the view modality, ie
disallowing the user from accessing the original page content until
the dialog has been dismissed. Browser modality may also be about
not letting the browser unload/reload the page until a dialog has
been dismissed (eg "do you want to save before closing the window?").
Is there any way to force a user to respond to a modal dialog
section before unloading the page?
If not, ideally a generic modality feature could be added to assist
both sections and current style HTML dialogs in achieving this
unload modality.

I'm not a big fan of allowing a web application to have that level of control 
of a user's browsing experience (a web page preventing a user from closing a 
tab, for example). The desktop paradigm is like allowing a program to prevent 
the user from restarting or shutting down the OS--seems like a bad design 
decision.

RE: [selectors-api] Proposal to Drop NSResolver from Selectors API v1

[Travis Leithead]

From IE8's perspective, I'm obviously in favor of this. There is great benefit 
to getting this spec to recommendation now that there is critical mass from 
browser implementers.



-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lachlan Hunt
Sent: Wednesday, April 23, 2008 2:19 PM
To: public-webapi
Subject: [selectors-api] Proposal to Drop NSResolver from Selectors API v1


Hi,
   Anne and I have discussed the possibility of dropping the NSResolver
features from Selectors API, and possibly moving it to version 2 of the
spec instead.  These are the reasons that we have for doing so:

1. Simplifies the API

2. Lack of Support

Current builds of WebKit and IE8 don't support namespaces yet. So far,
their implementation efforts have focussed on the other sections.

3. Lack of use cases that necessitate the use of namespaces in selectors

The majority of use cases don't need namespaces. Even the examples in
the spec don't need them.

As evidence, witness how often namespaces are used for selectors in CSS.
  In practice, even mixed namespace documents, such as XHTML+MathML+SVG,
can get away without using namespaces in CSS at all.  Since the tag
names in those languages differ enough to allow for mostly unambiguous
selection without namespaces.

4. Reduces the attack surface

Many of the problems with the current spec relate directly to
implementation issues with handling unexpected behaviour from
NSResolver's, even though it's an edge case for a feature that won't be
used all that much relative to the other parts.  Obviously, removing
support for namespaces also removes all the potential problems they cause.

5. Provides more time to work out the issues

Moving it to v2 gives more time to work out the issues with the
NSResolver.  This will allow v1 compliant implementations to ship sooner
rather than later, which will allow us to see how the APIs actually get
used in practice.

With more implementation and usage experience, we'll be able to study
the use cases more closely, and determine whether or not namespace
support is really needed.  As long as the API is defined in a forwards
compatible way, introducing namespace support later if needed shouldn't
be too much of a problem.

6. Allows for better interoperability

Implementers will be able to prioritise their efforts and focus on
getting interoperability between the most important parts of the spec,
instead of spending a disproportionate amount of time on less freqently
used features.  This will allow for more implemenation and testing time
for the other parts of the spec, and thus greater interoperability.

7. Reduced test suite size for v1.

Significantly reduces the number of features to be tested in the test
suite, and allows for more time to be allocated to writing test cases
for the more important features, which will actually allow for more
thorough testing.

The changes required to the spec would not be too difficult.  It would
basically just require removing all NSResolver related sections and
examples, and requiring implementations to throw NAMESPACE_ERR if a
namespace prefix is used.  This approach would be forwards compatible
with a future version of the spec that defined the NSResolver.

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

RE: [selectors-api] Handling :link and :visited Pseudo Classes

[Travis Leithead]

Ok, I think this feedback has been good and productive. With the relative 
agreement here on the list, I think I will modify the current :link/:visited 
mitigation to match the proposal here:

Selectors that include :link will match all hyperlinks whether visited or not, 
and
Selectors that include :visited will match nothing.

As was previously stated, this ensures the following selector will retrieve all 
links regardless of the UA:
":link, :visited"

-Travis

-Original Message-
From: Lachlan Hunt [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 16, 2008 4:17 PM
To: Travis Leithead
Cc: public-webapi
Subject: Re: [selectors-api] Handling :link and :visited Pseudo Classes

Travis Leithead wrote:
>>> what is wrong with treating all links as unvisited as far as
>>> these APIs are concerned.
>
> This is the alternate option I'd prefer, if you insist on changing
> the spec in this way. However, my first choice would be to not alter
> the spec :)

I only want to alter the spec to prevent loopholes that allow for major
interoperability issues.

> To recap your proposal: * :link - matches all links (essentially
> document.links, but without the href constraint) whether visited or
> not

In (X)HTML, I believe :link should be equivalent to:

   "a[href], area[href], link[href]"

>  * :visited - matches none.
>
> Is that correct?

Yes.  Any solution is fine with the condition that every link in the
document is matched by either one of :link or :visited.

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

RE: [selectors-api] Handling :link and :visited Pseudo Classes

[Travis Leithead]

Scratch that one.

-Original Message-
From: Boris Zbarsky [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 16, 2008 3:52 PM
To: Travis Leithead
Cc: public-webapi
Subject: Re: [selectors-api] Handling :link and :visited Pseudo Classes

Travis Leithead wrote:
> To recap your proposal:
> * :link - matches all links (essentially document.links, but without the href 
> constraint)

Without the href constraint?

-Boris

RE: [selectors-api] Handling :link and :visited Pseudo Classes

[Travis Leithead]

>> Travis, last time I asked about this you declined how to say how this
could be solved but said you thought it was possible. Would you be
willing to explain further now?

Sorry Maciej, I'm still going to decline to say how, but insist that it is 
possible. With Software, anything's possible :)

-Original Message-
From: Maciej Stachowiak [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 16, 2008 2:40 PM
To: Arve Bersvendsen
Cc: Travis Leithead; Lachlan Hunt; public-webapi
Subject: Re: [selectors-api] Handling :link and :visited Pseudo Classes


On Apr 16, 2008, at 2:26 PM, Arve Bersvendsen wrote:

>
> On Wed, 16 Apr 2008 22:49:30 +0200, Travis Leithead <[EMAIL PROTECTED]
> > wrote:
>
>> Yes, the selectors API will ignore any selector with a :link
>> or :visited pseudo-class. We shipped that with the intention of
>> providing a 360 degree protection from the :link/:visited problem
>> in our final release, but I believe that the rest of the plan has
>> been cut.
>
> I am curious as to what the benefit of this would be.

Agreed. Besides what Arve posted, there are all sorts of ways
for :link vs :visited to affect the layout of other elements. Besides
normal flow siblings it could affect the size and/or position of other
floats in the same containing block (if floated), its children, its
parent, and so forth. So I don't see how you could hide visited link
information for attackers short of doing an extra style resolution and
layout solely to handle queries for  style or layout information.
Furthermore, giving answers from these queries that don't match the
true layout could break scripts doing animations or script-driven
layout.

In addition, CSS inheritence could alter non-size properties of
children like color, so restricting :link and :visited to properties
that don't affect size or position wouldn't work either.

I'd like us to understand how it is feasible to every fully solve this
problem before catering to partial solutions in the Selectors API spec.

Travis, last time I asked about this you declined how to say how this
could be solved but said you thought it was possible. Would you be
willing to explain further now?

Regards,
Maciej

> A simple exploit that routes around the entire problem roughly
> consists of this:
>
> 
> 
> 
> p,body,a { margin: 0; padding: 0 }
> a:link { display: block; }
> a:visited { display: none; }
> 
> 
>  onload = function(){
>var ele = document.getElementById('adjacentElement')
>if (0 == ele.offsetTop){
>  ele.innerText = "FAIL: Visit to slashdot.org detected"
>}
>  }
> 
> 
> 
>  http://slashdot.org";>Visit this link id="adjacentElement">PASS
> 
> 
>
> Note that I could replace the particular means of getting the
> reference to the paragraph with any number of other means:
>
>  var ele = document.querySelector('p');
>  var ele = document.querySelector('a+p');
>  var ele = document.querySelector('#adjacentElement');
>  var ele = document.getElementsByTagName('a').nextSibling;
>
> Which leaves you only the option of checking whether layout has been
> affected and refuse to return anything whenever layout has been
> affected by the :visited state of a link.
>
> Also note that it is impossible to protect against Anne's suggested
> exploit where you load a randomized and unique tracker image as
> background or content for visited links, and do the data collection
> serverside instead.
>
> --
> Arve Bersvendsen
>
> Developer, Opera Software ASA, http://www.opera.com/
>

RE: [selectors-api] Handling :link and :visited Pseudo Classes

[Travis Leithead]

>> what is wrong with treating all links as unvisited as far as these
APIs are concerned.

This is the alternate option I'd prefer, if you insist on changing the spec in 
this way. However, my first choice would be to not alter the spec :)

To recap your proposal:
* :link - matches all links (essentially document.links, but without the href 
constraint) whether visited or not
* :visited - matches none.

Is that correct?

-Original Message-
From: Lachlan Hunt [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 16, 2008 2:35 PM
To: Travis Leithead
Cc: public-webapi
Subject: Re: [selectors-api] Handling :link and :visited Pseudo Classes

Travis Leithead wrote:
>>> I'm considering adjusting the spec to allow just two options, and
>>> making IE8's behaviour non-conforming.
>
> That sounds like you're trying to play hardball. :)

My main concern is that interoperability is not sacrificed in the name
of a security measure that's not entirely effective anyway.  I believe
there are alternative approaches that would achieve the same level of
security without sacrificing too much interoperability.

Although, ideally, both :link and :visited used in these APIs would
match the same elements as they do when used in CSS.  However, failing
that, what is wrong with treating all links as unvisited as far as these
APIs are concerned.

Consider this:

foo bar


var list1 = document.querySelectorAll(":link"); // Returns both links
var list2 = document.querySelectorAll(":visited"); // Returns empty list


That retains sufficient functionality to make at least :link useful,
without revealing which links have or have not been visited.  This
doesn't really affect interoperability too much, since the result is
effectively the same as if the user just cleared their history.

Alternatively, implementing a variation of that solution such as that
described by Bjoern [1] would, perhaps, be even better.

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

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

RE: [selectors-api] Handling :link and :visited Pseudo Classes

[Travis Leithead]

>> How is it more secure though? You can still get the same information using
currentStyle... Or using #google-com:visited
{ background:url(tracker?google-com) } or something like that.

Yes, and many other techniques in IE, like 'expression' in CSS. The point isn’t 
that we're solving the entire problem now, it's that we're not adding new 
attack surface with the introduction of this new API. Yes, it's a pretty lame 
problem, but I'd not like to be responsible for spoon-feeding attackers the 
list of elements that allows them to detect unvisited (:link) and visited 
(:visited) links with one API call.

>> document.links doesn't return , , , etc. document.links
also doesn't allow selectors like
>>   :link > span, :visited > span

Again, correct, but couldn't that be simplified to:
a > span
?

BTW, .links does include areas.  cannot be navigated per se.

-Original Message-
From: Anne van Kesteren [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 16, 2008 1:58 PM
To: Travis Leithead; Lachlan Hunt; public-webapi
Subject: Re: [selectors-api] Handling :link and :visited Pseudo Classes

On Wed, 16 Apr 2008 22:49:30 +0200, Travis Leithead
<[EMAIL PROTECTED]> wrote:
> However, I recently decided to keep the Selectors API behavior the same
> because 1) we have had no customer-reported problems/feedback on the
> current mitigation, and 2) I'd like to make IE8 just that much more
> secure. (On reason #1, I concede that this is a Beta, and the Selectors
> API has not had large public adoption as of yet.)

How is it more secure though? You can still get the same information using
currentStyle... Or using #google-com:visited
{ background:url(tracker?google-com) } or something like that.


> The current mitigation does exclude the ability to retrieve a list of
> links. However, I'm sure I don't have to remind you folks that for this
> scenario, there's already an excellent pre-established list of links off
> of the document [1]. The only thing you're not getting is the subset of
> links that the user has visited, and while there are use-cases for
> styling said list, the exploitation of this list for destructive
> purposes is a reality that I don’t think a good security-minded browser
> should ignore.

document.links doesn't return , , , etc. document.links
also doesn't allow selectors like

   :link > span, :visited > span

etc.


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

RE: [selectors-api] Handling :link and :visited Pseudo Classes

[Travis Leithead]

Good to see people read my whitepaper :)

Yes, the selectors API will ignore any selector with a :link or :visited 
pseudo-class. We shipped that with the intention of providing a 360 degree 
protection from the :link/:visited problem in our final release, but I believe 
that the rest of the plan has been cut.

However, I recently decided to keep the Selectors API behavior the same because 
1) we have had no customer-reported problems/feedback on the current 
mitigation, and 2) I'd like to make IE8 just that much more secure. (On reason 
#1, I concede that this is a Beta, and the Selectors API has not had large 
public adoption as of yet.)

The current mitigation does exclude the ability to retrieve a list of links. 
However, I'm sure I don't have to remind you folks that for this scenario, 
there's already an excellent pre-established list of links off of the document 
[1]. The only thing you're not getting is the subset of links that the user has 
visited, and while there are use-cases for styling said list, the exploitation 
of this list for destructive purposes is a reality that I don’t think a good 
security-minded browser should ignore.

>> I'm considering adjusting the spec to allow just two options, and making
IE8's behaviour non-conforming.

That sounds like you're trying to play hardball. :) Seriously, in both of your 
alternative suggestions, the document.links collections is a more direct route 
for the web developer (and I would point them there as a workaround). There 
really only appear to be two choices: mitigate (as IE8 Beta1 has done, and the 
spec [in its current form] allows, or allow the matching to happen un-mitigated.

[1] http://www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/html.html#ID-7068919

-Original Message-
From: Lachlan Hunt [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 16, 2008 5:12 AM
To: public-webapi
Cc: Travis Leithead
Subject: [selectors-api] Handling :link and :visited Pseudo Classes

Hi,
   The current Selectors API draft states:

   "... user agents may treat all links as unvisited links, or implement
other measures to preserve the user’s privacy."

I have noticed that to address this issue, Microsoft's implementation in
the current IE8 beta, both :link and :visited pseudo-classes are being
completely ignored.  That approach would technically fall under "other
measures to preserve the user’s privacy", but it seems like it could be
an interoperability issue.

Current WebKit builds and our internal Opera builds don't take any
action.  Both :link and :visited return unvisited and visted links,
respectively.  This also appears to be the approach Mozilla are planning
to take [1].  I think we need to be interoperable with our handling of this.

I'm considering adjusting the spec to allow just two options, and making
IE8's behaviour non-conforming.

Either:
1. Match unvisited and visted links normally with :link and :visited,
respecitively.
2. Match all links with :link, and no links with :visted (i.e. treat all
links as unvisited)

Another option would be to effectively treat :link and :visited as
synonymous and match all links with both, but I'm not so comfortable
with that.

Feedback from implementers on this issue, particularly from Microsoft,
would be appreciated.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=416317#c16

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

RE: [DOML3Events] Add success/failure boolean to add/removeEventListener?

[Travis Leithead]

Sending to the right list...

-Original Message-
From: Travis Leithead
Sent: Wednesday, April 09, 2008 1:02 PM
To: '[EMAIL PROTECTED]'; 'Doug Schepers'
Subject: [DOML3Events] Add success/failure boolean to add/removeEventListener?


I just wanted to send this request to the list to generate some discussion. 
Today, addEventListener and removeEventListener return 'void' (nothing). In 
other words, a web-dev cannot know if one of these methods succeeded or not.

Currently the only way for a script to check to see if these succeeded, is to 
do validation in the EventListener itself. (Fire the event programmatically, 
ensure that it was fired in the callback.)

The spec does mention that repeated adding of event listeners (with all the 
same params) is a no-op.

Admittedly, there are fewer use-cases for testing a return value from 
addEventListener, than there are for removeEventListener.

IE supports a return value from its proprietary attachEvent/detachEvent APIs.

Back compat in scripts is not an issue since these API's never returned a value 
before--thus scripts will not be checking for return values.


-Travis

RE: [DOML3Events] ACTION-267 Proposal for event iterator

[Travis Leithead]

I'll try to dig up some specific use cases.

Yes, the workaround below would work great as well, until we ratify this API :)

-Original Message-
From: Jonas Sicking [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 09, 2008 3:49 PM
To: Travis Leithead
Cc: Anne van Kesteren; Doug Schepers; Web API public
Subject: Re: [DOML3Events] ACTION-267 Proposal for event iterator

Travis Leithead wrote:
> From your link, it appears the only reason this was dropped was because the 
> folks in discussion at the time thought the only use case for this feature 
> was Accessibility venders (ATs).

It wasn't just dropped because it wasn't needed (because AT doesn't need
to use DOM APIs). It was also dropped since it would mean that internal
code can not use the generic DOM APIs to add event listeners. This is
something that we do a lot in Firefox code and that is done by a lot of
Firefox extensions. See
http://lists.w3.org/Archives/Member/member-webapi/2006Feb/0301.html
and the followups.

I agree that this is something that we could work around if absolutely
needed. I'm definitely an advocate for not designing Web APIs for
internal consumers. However it is always a very nice bonus when public
APIs are also useful internally.

So I too would be interested in hearing more about the use cases here.
Could the following be used as a solution?

oldAddEL = EventTarget.prototype.addEventListener;
Node.prototype.addEventListener = function(type,
   listener, useCapture) {
   if (!this.getUserData("listeners")) {
 this.setUserData("listeners", [], null);
   }
   this.getUserData("listeners").push(listener);
   oldAddEL.call(this, type, listener, useCapture);
}

This should let the page access all listeners added to any node using
getUserData("listeners").

/ Jonas

RE: [DOML3Events] ACTION-267 Proposal for event iterator

[Travis Leithead]

From your link, it appears the only reason this was dropped was because the 
folks in discussion at the time thought the only use case for this feature was 
Accessibility venders (ATs).

=
JS: I don't see the point in time spent on hasEventListener etc. as we don't 
need them.
RB: so the use case for them could be that AT tools could introspect another 
DOM.
MJS: said it was a convincing argument but not enough to solve the problem.
 chaals, http://www.w3.org/2005/06/tracker/webapi/issues/17
JL: If the only use case for AT tools, then it should be in a seperate AT spec. 
that includes everything for AT tools.
JS: I agree it's not the place of the DOM to define plugin api's which this 
seems to be.
CMN: So you don't think that's how AT should work?
JS: I think that AT shouldn't be in DOM spec, as the DOM spec is for page 
authors.
... AT needs to enumerate all listeners and figure out "what it does".
CMN: The argument likely to come back is being able to find out event listeners 
would be a huge step forward.
JS: so I'd ask why have it in a DOM specification?
CMN: their rationale is so that it will get done...
JL: AT's can already do this.
... so speccing it as part of DOM3 for the one use case is overkill.
RB: So am I hearing that dropping it is a good idea due to not really meeting 
the use case and there being many other issues.
RESOLUTION: keep stopImmediatePropogation
... drop willTriggerNS and hasEventListener
=

I've been specifically requested to add such support into IE by various 
customers. Most of their use-cases involve script that is trying to 'clean-up' 
event handlers for which they did not set, and do not have a pre-existing 
handle to the function callback.

The proposed API allows enumeration of the function callbacks (which is what I 
mean by EventListener objects--native JS functions in EmcaScript).

As for issue 5, we're still trying to figure out if event handlers specified 
via onclick=" " in HTML should be counted in the enumeration (this is useful to 
spec regardless of the existence of this API, as you may want to do:
[EventTarget].removeEventListener('[type]', [EventTarget].on[type], bool);

and there is discussion as to whether that's possible or not.

As for issue 11, only "public" events should be exposed through this 
mechanism--this should not be used for getting internal listeners--such 
functionality is a security risk--I agree.


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anne van Kesteren
Sent: Wednesday, April 09, 2008 1:13 PM
To: Travis Leithead; Doug Schepers; Web API public
Subject: Re: [DOML3Events] ACTION-267 Proposal for event iterator


On Wed, 09 Apr 2008 21:54:56 +0200, Travis Leithead
<[EMAIL PROTECTED]> wrote:
> // New in DOM Level 3:
> typedef sequence EventListenerList;

The EventListener object only has a handle() method unless I'm missing
something obvious. Having a list of those does not exactly seem useful. I
think that's why DOM Level 3 Events once had a hasEventListenerNS() method.

We resolved to remove hasEventLisenerNS here:

http://lists.w3.org/Archives/Public/public-webapi/2006Mar/att-0092/23-webapi-minutes.html

This proposal would also need to deal with the various issues raised here:

   http://www.w3.org/2005/06/tracker/webapi/issues/5
   http://www.w3.org/2005/06/tracker/webapi/issues/11


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

RE: [DOML3Events] ACTION-267 Proposal for event iterator

[Travis Leithead]

Thanks to all the feedback on the Telecon. Here's the revised proposal:

=
IDL Definition // Introduced in DOM Level 2:

// New in DOM Level 3:
typedef sequence EventListenerList;

// Introduced in DOM Level 2:
Interface Event {
  // PhaseType
  const unsigned short CAPTURING_PHASE = 1;
  const unsigned short AT_TARGET = 2;
  const unsigned short BUBBLING_PHASE = 3;
  // Introduced in DOM Level 3:
  // Used specifically for the eventPhaseFilter param
  const unsigned short ALL_PHASES = 4;
  ...
}

interface EventTarget {
  ...

  // Introduced in DOM Level 3:
  EventListenerList  getEventListeners(in DOMString typeFilter,
   in unsigned short eventPhaseFilter);

  // Introduced in DOM Level 3:
  // (BIG QUESTION: Is this needed? If *NS methods are tossed, then toss this 
too)
  EventListenerList  getEventListenersNS(in DOMString namespaceURIFilter,
 in DOMString typeFilter,
 in unsigned short eventPhaseFilter);
};

* For DOMString parameters, the value of "*" represents the 'all' filter.
Examples:
[EventTarget].getEventListeners('click', 4);
 returns all of the 'click' events added to the object for all event phases.
[EventTarget].getEventListeners('*', 4);
 returns all events in all phases.

* The sequence of EventListeners returned from this API _must_ be in the order 
in which said event listeners will fire on the object (i.e., the order must be 
[capture events first sorted in order in which they will be fired, then bubble 
events sorted in the order in which they will fire).

Given this, what is the behavior for calling getEventListeners("*", 2)? I'd 
assume that since no events can be registered only for the "target phase" that 
the returned EventListenerList would always be empty.


Travis Leithead - OM Program Manager - Internet Explorer

[1] http://lists.w3.org/Archives/Public/public-webapi/2008Apr/0001.html
[2] 
http://dev.w3.org/cvsweb/~checkout~/2006/webapi/Binding4DOM/Overview.html?rev=1.66&content-type=text/html;%20charset=iso-8859-1

[DOML3Events] ACTION-267 Proposal for event iterator

[Travis Leithead]

In considering a design for the event iterator (allow devs to enumerate what 
events have been _added_ via addEventListener to a given object), I looked at 
too general approaches:

1) Defining a new collection on every object that supports the EventTarget 
interface
2) Defining a 'getNextEvent' function for every object that supports the 
EventTarget interface
3) Defining a function that returns a static/dynamic list of event handlers for 
a given object that supports the EventTarget interface

Ultimately, my design was to go with the 3rd option. Here's why:

Option 1 Pros:
* A collection property is easy to directly access via an object of interest
* A collection property is harmonious with other design decisions in the DOM 
(.childNodes, .attributes)

Option 1 Cons:
* There are many event 'types' that can be added to any given object as well as 
the characteristic of whether that listener is triggered on the capture/bubble 
phase, and a single collection merges all of these events in a way that is hard 
to split out individual types without the use of two keys (in other words, such 
a proposal would look a lot like the original HTML5-spec'd design for the 
globalStorage collection, except with two keys--unless we ignore the 
capture/bubble param).
* Requires a more rigid object or collection design than option 3.

Option 2 Pros:
* Supports the common incremental-access programming pattern (just get me the 
'next' defined event handler, if any).

Option 2 Cons:
* Does not support the random-access programming pattern (see discussion on 
.childElements collection [1])

Option 3 Pros:
* The 'retrieval function' approach has precedence in other DOM specs, such as 
getComputedStyle(...) and querySelector(...) where the returned collection can 
be either LIVE or not depending on need.
* The 'retrieval function' appraoch can support multiple parameters that can 
alter the collection that gets returned. This seemed like the most natural 
approach given that event listeners always have at least two parameters (event 
type string and isCapture bool).
* Provides random-access and iterative access through the returned collection.

Option 3 Cons:
* Not as convenient as a direct-access collection property

Without futher ado, here's my proposal for DOM L3 Events per-object enumerator 
(with a little help from the current Bindings [2] spec).

=
IDL Definition // Introduced in DOM Level 2:

// New in DOM Level 3:
typedef sequence EventListenerList;

interface EventTarget {
  void   addEventListener(in DOMString type,
  in EventListener listener,
  in boolean useCapture);
  void   removeEventListener(in DOMString type,
 in EventListener listener,
 in boolean useCapture);
  // Modified in DOM Level 3:
  booleandispatchEvent(in Event evt)
raises(EventException,
   DOMException);
  // Introduced in DOM Level 3:
  void   addEventListenerNS(in DOMString namespaceURI,
in DOMString type,
in EventListener listener,
in boolean useCapture);
  // Introduced in DOM Level 3:
  void   removeEventListenerNS(in DOMString namespaceURI,
   in DOMString type,
   in EventListener listener,
   in boolean useCapture);
  // Introduced in DOM Level 3:
  EventListenerList  getEventListeners(in DOMString typeFilter,
   in boolean useCaptureFilter);
  // Introduced in DOM Level 3:
  EventListenerList  getEventListenersNS(in DOMString namespaceURIFilter,
 in DOMString typeFilter,
 in boolean useCaptureFilter);
};

* getEventListeners[NS] - each parameter is allowed to be null.

* If null is provided for all parameters, then the sequence of EventListeners 
returned includes all event listeners added 1) from all namespaces, 2) for all 
event types, and 3) in all event phases (capture/bubble).

* Providing a non-null value for any of the parameters to these methods filters 
the set of returned Event Listeners in the sequence. For example:
[EventTarget].getEventListeners('click', null);
 returns all of the 'click' events added to the object for all event phases.

* The sequence of EventListeners returned from this API _must_ be in the order 
in which said event listeners will fire on the object (i.e., the order must be 
[capture events first sorted in order in which they will be fired, then bubble 
e

RE: DOM3 Events Keyflow

[Travis Leithead]

I think it would still be worthwhile to continue to explore methods of 
characterizing event flow for the purposes of attempting to unify browser 
differences even across multiple operating environments (say Opera on the 
Nintendo Wii, for example).

As Doug mentioned in our telecom, some operating environments may need to 
design a thin-client layer between what OS messages are generated and what 
events are dispatched to the web application.

I don't think we should throw up our hands at this point.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alexey 
Proskuryakov
Sent: Thursday, March 27, 2008 12:14 PM
To: Web API public
Subject: Re: DOM3 Events Keyflow



On Mar 27, 2008, at 9:04 PM, Doug Schepers wrote:

> I've made a trial schematic to get us started [1].  I've also
> modeled it in Graphviz, and I've included the Dot format file here
> (attached). Graphviz is free open source software [2], and the Dot
> format is really simple to edit.


  I've been looking at the diagram periodically for the last couple of
weeks, and I finally have some idea about what to say from a point of
view of someone who has touched this code in WebKit code quite a bit
recently.

  I think that possibly a better way to characterize event flow would
be to think of it in terms of default handlers, not state diagrams.
That would better match what browsers do (we don't really maintain
much state in WebKit, although some is definitely maintained by the OS).

  A state diagram necessarily
a) could only be valid for a single type of focused element, as they
all have different default handlers;
b) conflates very different notions of keyboard events and text input;
c) encompasses several layers of functionality (OS and browser);
d) omits important details about the events (e.g. what
preventDefault() does).

  As I have it in my head, there is really no order for input events -
e.g. textInput can be dispatched because of a mouse click. You even
cannot guarantee that  keypress always comes after a keydown that
caused it! One example: when pressing the key right to "1" on a German
keyboard layout twice, one gets keydown, keydown, keypress, keypress.
Also, keydown may be totally missing if text input comes from some
utility (such as a virtual keyboard, enhanced clipboard manager etc.).
On Windows, any process that sends a WM_CHAR message to a browser view
will generate keypress without a keydown.

  I wish I had realized this earlier, when there wasn't so much work
put into this diagram, sorry about that.

- WBR, Alexey Proskuryakov

RE: What is Microsoft's intent with XDR vis-à-vis W3C? [Was: Re: IE Team's Proposal for Cross Site Requests]

[Travis Leithead]

>I strongly object to the Web API working group adopting a proprietary
>solution developed by one vendor with no external consultation, when the
>group has already spent several man-years' worth of time on a
>technologically superior, safer, and more comprehensive solution that has
>as much implementation experience and significantly more authoring
>experience, based on extending existing APIs instead of arbitarily
>introducing new, incompatible APIs.

I don't see how introducing a new object is 'incompatible'. It seems to have 
the same degree of 'compatibility' as introducing new APIs on the XHR object.

RE: [Bindings] 'new' behavior on interface objects

[Travis Leithead]

Mmm. Good points all. Allowing them to be factory methods is rather interesting.

-Original Message-
From: Garrett Smith [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 19, 2008 10:23 AM
To: Jonas Sicking
Cc: Travis Leithead; Web APIs WG (public)
Subject: Re: [Bindings] 'new' behavior on interface objects

On Wed, Mar 19, 2008 at 9:12 AM, Jonas Sicking <[EMAIL PROTECTED]> wrote:
>
>
>  Travis Leithead wrote:
>  > Since this spec is presumably creating a language binding for JavaScript, 
> (and assuming interface objects are Functions, as seen by Opera), then why 
> does:
>  >
>  > var div = new HTMLDivElement();
>  >
>  > produce a script error?
>  >
>  > Seems like a perfectly valid thing to do, essentially a shortcut to 
> document.createElement('div')
>
>  The problem is that this doesn't make sense for lots of interfaces. What
>  does
>
>  var a = new HTMLElement();
>
>  do for example? And while there might only be one object that implement
>  HTMLDivElement right now, who's to say that is true in the future.
>
>  As it so happens there are actually at least 2 objects in firefox that
>  implement that interface, a HTML  and an XHTML  (they differ
>  in case sensitivity handling), which one should be instantiated by your
>  code?
>

A Factory allows subclasses to define which classes to instantiate, as
Jonas mentioned. In this case: HTML document and XHTML document.

The design of a Factory method allows for implementation details for
complex operations (creating a SCRIPT or IMG, or
XXXTAG_NOT_IMPLEMENTED, or branches for categories of elements).

Creating a constructor would make browser implementation code a lot
more complicated, I imagine, though Jonas would know better than I do
about that.

Factory Method was a good choice over Constructor here.

Exposing a constructor of the same name as the interface - what,
besides compatibility problems, would that acheive?

The result would be exposed objects - Element - for example, that
might or might not create an element, depending on the browser.  Each
javascript call to new Element would have to be wrapped in a
try-catch, as there is no way to determine if the object in question -
Element  - implemented [[Construct]] and, currently, at least 3
browsers expose an object of a name corresponding to the interface and
none of them implement [[Construct]].

Garrett

>  / Jonas
>
>

RE: [Bindings] What does typeof return for interface objects?

[Travis Leithead]

I can think of some interesting use cases for implementing [[call]] on an 
interface object... I'd prefer to leave it unspecified at best. I agree with 
Hixie on the point of specifying the behavior of typeof, and to me typeof 
HTMLDocument == 'function' makes sense, since I think of these as 'constructor 
objects' (even if they don't allow object construction in some cases).

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Cameron McCormack
Sent: Tuesday, March 18, 2008 4:19 PM
To: Web APIs WG (public)
Subject: Re: [Bindings] What does typeof return for interface objects?


Hi Travis.

Travis Leithead:
> From the spec...
>
>   4.2.1. Interface object
>
>   The interface object for a particular interface has an internal
>   [[Prototype]] object whose value is the Object prototype object.
>
> So, can infer that the interface object (lets use HTMLDocument) *is
> an* Object? Or is it a Function?

I don’t think you can infer either of these.  Whether ‘typeof x’ will
evaluate to "object" or "function", assuming ‘x’ is an object, depends
only on whether the object implements [[Call]].  The spec doesn’t say
anything about [[Call]] on interface objects at the moment, so I think
either would be acceptable.

> ("object" == typeof HTMLDocument) ? "It's an object"
>   : ("function" == typeof HTMLDocument) ? "It's a function"
>   : "What is it?";
>
> I see that browsers disagree and that FF3 B4 recently changed to be
> 'object'. Leaving Opera in the wrong?

I wouldn’t say Opera is wrong, but there is probably no need to an
interface object to implement [[Call]] anyway.

Do you think the spec should explicitly say that [[Call]] must not be
implemented?  IMO there isn’t much gain from doing that.

Cameron

--
Cameron McCormack, http://mcc.id.au/
xmpp:[EMAIL PROTECTED]  ▪  ICQ 26955922  ▪  MSN [EMAIL PROTECTED]

RE: Please Review: Mousewheel Event Proposal

[Travis Leithead]

In these examples, I think it's up to the application to decide how to 
interpret the wheelDelta. For a map application, you would might get the 
wheelDelta info in the event plus the modifiers that are currently active, and 
decide that the map needs to tilt (or something like that). I'm just saying 
that it doesn't make sense to supply different event names for different types 
of scrolling/zooming/etc., because it's up to the client application to define 
that behavior.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Olli Pettay
Sent: Tuesday, March 18, 2008 3:29 PM
To: Web API public
Subject: Re: Please Review: Mousewheel Event Proposal


Hi,

few comments

[...]

It is open what wheelDelta means. Is it "mousescroll clicks"?
Moving finger over touchpad?
But what if system can generate several kinds of data - line scrolling
and pixel scrolling, maybe even page scrolling or screen scrolling.
Should we have different event names for different kinds of scrolling.

Should web application know somehow that what is the default action of
mouse wheel scrolling: scrolling or zooming...
On my browser ctrl+wheel is zoom, alt+wheel is slower-than-normal-
scrolling.

[...]

-Olli

Re: DOM3 Events Telcon Minutes, 27 Feb 2008

[Travis Leithead]

> The reason we needed a new event is that mousewheel is not dispatched for
> anything but vertical scrolling and that authors are expecting it to be
> dispatched for vertical scrolling only.

I don't think it is wise to complicate the API to cater to developers that 
don't handle horizontal scrolling in their web app. I prefer an 
easier-to-manage and simpler approach for the long term.

For existing apps, it doesn't seem like it would be that hard to short-circuit 
the mousewheel event handlers to check for a non-zero wheelDelta before 
continuing with the code.

Safari 3.1 adding showModalDialog??

[Travis Leithead]

Not to say that I object... :)

...but why this API and not showModelessDialog too? I'd be interested to know 
the rationale for this decision on WebKit's part.

Also, was openDialog considered (from FF)?

[Bindings] 'new' behavior on interface objects

[Travis Leithead]

Since this spec is presumably creating a language binding for JavaScript, (and 
assuming interface objects are Functions, as seen by Opera), then why does:

var div = new HTMLDivElement();

produce a script error?

Seems like a perfectly valid thing to do, essentially a shortcut to 
document.createElement('div')

[Bindings] What does typeof return for interface objects?

[Travis Leithead]

>From the spec...

4.2.1. Interface object

The interface object for a particular interface has an internal [[Prototype]] 
object whose value is the Object prototype object.

>> So, can infer that the interface object (lets use HTMLDocument) *is an* 
>> Object? Or is it a Function?

>> ("object" == typeof HTMLDocument) ? "It's an object" : ("function" == typeof 
>> HTMLDocument) ? "It's a function" : "What is it?";

>> I see that browsers disagree and that FF3 B4 recently changed to be 
>> 'object'. Leaving Opera in the wrong?

RE: [selectors-api] Why no querySelector(All) on DocumentFragments?

[Travis Leithead]

I had this conversation with Lachlan awhile back (but I can't find the thread 
to dig up). I believe it was his intention for these APIs to work on 
DocumentFragments.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Sayre
Sent: Thursday, March 13, 2008 8:30 PM
To: Ian Hickson
Cc: Boris Zbarsky; liorean; Web APIs WG (public)
Subject: Re: [selectors-api] Why no querySelector(All) on DocumentFragments?


On Thu, Mar 13, 2008 at 11:24 PM, Ian Hickson <[EMAIL PROTECTED]> wrote:
>
>  Yeah, I was just jumping in to clarify the :root thing. Personally I think
>  you're right, it would be useful to have the method on DocumentFragment,

I agree.

>  but that's up to Lachlan. :-)

Fully disagree.

--

Robert Sayre

"I would have written a shorter letter, but I did not have the time."

Regarding my ACTION-249 for DOM L3 Events

[Travis Leithead]

Attached is V1 beta of the abstraction library (TestLib), and a page that uses 
it.

So far the library provides:

1.   Abstraction API for adding event listeners to objects x-browser 
(tested on FF2/IE7/Saf3/O9.2 all on Windows platform).

/* TestLib -- Simple Testing Library 
   Abstracts common browser inconsistencies where the purpose of the test case does not depent on testing the given functionality
*/

// [global scope]
function TestLibrary() { }
// [TestLib scope] addEvent( [in] Object  /* HTMLElement / HTMLDocument / Window */,
//  [in] String /* event name */,
//  [in] FunctionPointer /* JS function pointer variable */,
//  [in] Bool /* useCapture (optional)*/ )
TestLibrary.prototype.addEvent = function (ob, name, func, capture) 
{ 
   if (!ob || (typeof ob != 'object'))
	  throw new Error("Call to TestLib.addEvent([ob], name, func, capture): Please provide the object (element, document, window) to which the event should be attached.", "Call to TestLib.addEvent: Please provide the object (element, document, window) to which the event should be attached.");
   if (!name || (typeof name != 'string'))
  throw new Error("Call to TestLib.addEvent(ob, [name], func, capture): Please provide the name of the event to attach (sans the 'on' prefix). For example: 'click' not 'onclick'.", "Call to TestLib.addEvent(ob, [name], func, capture): Please provide the name of the event to attach (sans the 'on' prefix). For example: 'click' not 'onclick'.");
   if (!func || (typeof func != 'function'))
  throw new Error("Call to TestLib.addEvent(ob, name, [func], capture): Please provide the function pointer to be called when the event is raised. For example: function () { ... }", "Call to TestLib.addEvent(ob, name, [func], capture): Please provide the function pointer to be called when the event is raised. For example: function () { ... }");

   // Param 4 is optional. if specified it will be used--however, some browsers (IE) do not support the capture phase.
   if (capture == undefined)
  capture = false;
   if (document.addEventListener)
  return ob.addEventListener(name, func, capture);
   else // IE special case
  return ob.attachEvent("on" + name, func);
}

var TestLib = new TestLibrary();Title: DOM Events API Test Suite - doubleclick-001 

 


 
  
 
   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 1This Value should change as you double click on this table.   
 
  
  

Re: Issue Request for DOM L3 Events

[Travis Leithead]

Following up... It was decided to include examples of this type of behavior as 
a non-normative appendix to the events 3 spec. This allows implementers and 
developers to be aware of this peculiarity without imposing unnecessary 
restrictions/limits on the behavior.

Issue Request for DOM L3 Events

[Travis Leithead]

I'd like to propose a discussion about the handling of the ALT + key 
combination that will hopefully end in a normative requirement.

In observing IE as well as other browsers, there is "good" x-browser 
consistency between the handling of ALT and pressing a modifier key.

While the browsers are mostly consistent, they do so in a way that is not very 
reliable for web developers because key down/key up pairs are often not 
respected (key events get dropped in some scenarios).

I've identified the following scenarios that we can discuss:

Scenarios for ALT handling where the key combination is not a 
'browser-reserved' key:
(Using 'X' which is a non-reserved accelerator key-at least in IE/Firefox3.)


1.   Scenario 1: down ALT, down x, up ALT, up x

2.   Scenario 2: down ALT, down x, up x, up ALT

3.   Scenario 4: down ALT, up ALT, down ALT, down x, up ALT, up x

4.   Scenario 5: down ALT, up ALT, down ALT, down x, up x, up ALT

In each of these scenarios, an ALT key up or down event is lost, resulting in 
an inconsistent pairing of down/up events for the web developer.

When handing scenarios for "browser-reserved" accelerator keys, more key events 
are lost (including the simple ALT down/up pair repeated twice). It would be 
nice to specify (perhaps in an appendix) the behavior of browser-reserved 
accelerator key combinations and what should be expected.

To help push the discussion along, I would like to propose two potential ideas 
(one is more drastic than the other):


1.   Create a requirement that browsers emit proper ALT key sequences 
(up/down pairs) to the web page unless focus has shifted out of the web page 
itself-here we would need to try to define where to draw the line of when ALT 
is in focus and when it is not in focus related to browser-reserved accelerator 
actions.

2.   Remove the emission of modifier key (e.g., Shift/Alt/etc.) events from 
the key identifiers set. Thus, pressing ALT (for example) would not emit any 
keyboard events until a corresponding key was pressed. The KeyboardEvent 
interface will continue to support the Boolean modifier key flags so that 
distinctions between a key + a modifier can be made by the web developer, but 
this will cut back and the number of events raised and eliminate the 
out-of-order key event problems (ALT down > key down > ALT up > Key up versus 
ALT down > key down > key up > ALT up). Of course, a side effect is that this 
outcome will also effectively remove the detection of single modifier key 
presses for use in web applications.

RE: Ambiguity in removeAttributeNode

[Travis Leithead]

Thanks for the sanity check ;)

-Original Message-
From: Bjoern Hoehrmann [mailto:[EMAIL PROTECTED] 
Sent: Friday, July 27, 2007 11:07 PM
To: Travis Leithead
Cc: public-webapi@w3.org; Chris Wilson
Subject: Re: Ambiguity in removeAttributeNode

* Travis Leithead wrote:
>We happened to notice an interesting behavior difference in
>removeAttributeNode recently, and an appeal to the standard didn't seem
>to help...

>var pElem = document.getElementById('foo');
>var newAttr = document.createAttribute('align');
>newAttr.value = "right";
>try {
>  var oldAttr = pElem.removeAttributeNode(newAttr);

>  Sample text

>IE fails in this example and triggers the try/catch. FF works, Opera
>also fails. It seems that some browser implementers deciphered the DOM
>Core spec::removeAttributeNode to mean that "object" comparison is used
>as the delete criteria, but others seem to only base it on the "name" of
>the Attr. 

Well, removeAttributeNode removes the specified attribute node from the
element the method is called on, and raises a NOT_FOUND_ERR exception
"if oldAttr is not an attribute of the element"; that seems very clear
to me, in your example newAttr is not an attribute of pElem since new-
Attr.ownerElement != pElem.

>Is there hope in coming to harmony across implementations on this point?

This just seems to be a bug in Firefox, if somebody files it, it should
be fixed sooner or later.
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Ambiguity in removeAttributeNode

[Travis Leithead]

In light of the DOM Core L3 Second Edition...

 

We happened to notice an interesting behavior difference in
removeAttributeNode recently, and an appeal to the standard didn't seem
to help...

 



 

   

  function doFoo()

  {

var pElem = document.getElementById('foo');

var newAttr = document.createAttribute('align');

// To illustrate that these are not the same attribute
exactly...

newAttr.value = "right";

try {

  var oldAttr = pElem.removeAttributeNode(newAttr);

  alert(oldAttr.value + ": command successful");

} catch (e) {

  alert("removeAttributeNode failed with message: " +
e.message);

}

  }

   

 

 

  Sample text

 



 

IE fails in this example and triggers the try/catch. FF works, Opera
also fails. It seems that some browser implementers deciphered the DOM
Core spec::removeAttributeNode to mean that "object" comparison is used
as the delete criteria, but others seem to only base it on the "name" of
the Attr. 

 

Is there hope in coming to harmony across implementations on this point?
Or how should the spec be interpreted?

 

-Travis Leithead

MS Windows Internet Explorer