Proposed errata for DOM2 Range regarding insertNode()

[Ian Hickson]

DOM2 Traversal and Range has a number of problems, and really needs a 
rewrite. However, in the absence of the resources to do that, I realised 
that we could settle for releasing some errata. Arguably we as a working 
group have somewhat the authority to do that, so here's a proposal for a 
simple errata for DOM2 Range. If this works process out well, I'll see if 
there are other things in DOM2 we should errata sooner rather than waiting 
for wholesale DOM3 or DOM4 updates.

DOM2 Range says of the insertNode() method that "A node may be inserted 
into a Range using the following method". However, if the range is 
collapsed, according to a strict reading of the specification, calling 
insertNode() actually inserts the node _after_ the range. I propose that 
we change the spec to explicitly say that if you call insertNode() on a 
collapsed range, the end point offset is increased by one, as if the node 
was inserted before the end point, which I believe to be the intent of the 
specification. This is implemented by Opera and WebKit already, and is 
tested by Acid3.

If the working group chair will forgive me, I suggest we set a deadline of 
May 21st (a week from today) at which point if there have been no 
objections raised we go ahead and make the change to the DOM2 errata.

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

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

[Doug Schepers]

Hi WebAPI Fans-

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.

The regular time is Wednesdays, 18:30-20:00 UTC. See the DOM3 Events
wiki page for timezones adjustments. [1]

The tentative agenda is as follows:

   1. Convene, take roll, review agenda, plan next meeting
   2. Issue/Action review
   3. Halvord Steen's "legacy" key events proposal
   4. Adding an editor


For each week's telcon, we will maintain an agenda page [2] so you can
track what the discussion will be, add agenda topics, and see the
minutes afterward.

We will also maintain a list of all the past and planned telcons, with a
brief summary of issues discussed. [3]

[1] http://www.w3.org/2008/webapps/wiki/DOM3Events#Day_and_Time
[2] http://www.w3.org/2008/webapps/wiki/14_May_2008
[3] http://www.w3.org/2008/webapps/wiki/DOM3Events_Agenda

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

Re: Proposed errata for DOM2 Range regarding insertNode()

[Olli Pettay]

Ian Hickson wrote:

DOM2 Range says of the insertNode() method that "A node may be inserted
into a Range using the following method". However, if the range is
collapsed, according to a strict reading of the specification, calling
insertNode() actually inserts the node _after_ the range. I propose that
we change the spec to explicitly say that if you call insertNode() on a
collapsed range, the end point offset is increased by one, as if the node
was inserted before the end point,
inserted node can be document fragment in which case end offset should 
be increased more than one.




which I believe to be the intent of the
specification. This is implemented by Opera and WebKit already, and is
tested by Acid3.


Gecko does what the current spec says.


If the working group chair will forgive me, I suggest we set a deadline of
May 21st (a week from today) at which point if there have been no
objections raised we go ahead and make the change to the DOM2 errata.

Does web content rely on the current spec behavior?
Did Webkit or Opera change their behavior just to pass ACID3 (but not to 
follow Range spec)?




-Olli

Telecon

[Carmelo]

Hi all:

Need to pick uo my son from college and thus unable to join.  Will try
towards the later part of the call.

Carmelo

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

[Anne van Kesteren]

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: XHR LC comments

[Julian Reschke]

Anne van Kesteren wrote:
On Sun, 04 May 2008 11:47:13 +0200, Julian Reschke 
<[EMAIL PROTECTED]> wrote:

Review of .

General points:

a) I'm confused about the approach to this document. On the one hand, 
we're being told that it can't define anything not already in use (and 
that new stuff belongs into XHR2), on the other hand it relies on 
HTML5, which is a moving target. It's good that this stuff is being 
written down, but if it relies on HTML5, I'd propose to consider other 
publication options.


The problem is that concepts such "origin" and determining the encoding 
of a text/html stream are not defined anywhere else. It's not really 
clear to me what to do about that.


In some cases, it may be possible to copy the current definition. In 
other cases, it may be possible just not to depend on it (for instance, 
by not specifying encoding sniffing).


b) Algorithms: the spec uses a method to describe algorithms that IMHO 
is extremely hard to read (see for instance send() method). This may 
be good for implementors, but seems to be bad for everybody else. 
Minimally, the lists should be structured for better readability.


Could you elaborate on what kind of change you envision? I'm not sure 
how they are not structured right now.


An example would be steps 8..11 in the description of open():

- these steps deal with credentials, and the whole list would be more 
readable if each group of steps that belong together would me structured 
that way;


- optimally, thing like this shouldn't be expressed as a set of 
instructions, but in a declarative way.


c) Structure: It would be nice if Section 4 had more structure. Right 
now it's ugly to navigate and refer to.


This is better in XMLHttpRequest Level 2. I rather not revise that 
entire section editorially as it might introduce new errors.


But then, it makes a comparison with XHR2 harder. Please reconsider.


2.1 Dependencies

"DOM

 A conforming user agent must support some subset of the 
functionality defined in DOM Events and DOM Core that this 
specification relies upon. [DOM2Events] [DOM3Core]"


That reads a bit strange. Must the subset be non-empty?


Yes, as stated it must be a subset that matches what XMLHttpRequest 
requires from the eventing and core specifications.


Then it would be clearer if it said "the subset" instead of "some subset".


2.2 Terminology

"Two URIs are same-origin if after performing scheme-based 
normalization on both URIs as described in section 5.3.3 of RFC 3987 
the scheme, ihost and port components are identical. If either URI 
does not have an ihost component the URIs must not  be considered 
same-origin. [RFC3987]"


Why are we referring to the IRI spec (RFC3987) when talking about 
URIs, as defined RFC3986?


For scheme-bases normalization and ihost. Maybe I should use IRI instead 
of URI?


Well, if we're talking about URIs (and I think we do), then we need to 
refer to RFC3986 grammar and comparison rules.


Besides that: this may be a non-optimal example unless we can point to 
a definition of "HttpOnly cookies". Can we?


I don't believe we can, but since this was put in mostly for HttpOnly 
cookies I rather not remove that. I think it will be clear enough for 
people reading the document.


So why don't we refer to the specification for httpOnly? Do you consider 
it a problem that it's a Microsoft document?


- TRACK??? There's probably a rational for that. If there is, please 
include it in the spec.


It's a security issue, as should be clear from the next bullet point.


As TRACK doesn't seem to be documented anywhere, and not implemented in 
current IIS versions anymore, I'd really like to see this made a foot 
node. The way it's written now is just totally confusing to every reader 
who doesn't know the full story around it.


"If the user argument was not omitted and is not null let stored user 
be user  encoded using the encoding specified in the relevant 
authentication scheme or UTF-8 if the scheme fails to specify an 
encoding."


Why is XHR talking about the encoding here? Is "stored user" a string 
or a byte array?


(same for password)


They're a string (in the API).


When they are a string, then taking about character encoding doesn't 
make any sense here.


"If the value argument is null terminate these steps. (Do not raise an 
exception.)."


This makes it impossible to set empty headers, which are allowed in 
HTTP. Even worse, it silently fails.


Empty headers can be set using the empty string, no? Not raising an 
exception is consistent with implementations and I don't think it 
matters much as it doesn't have any effect.


Sorry, was reading one thing, but thinking about something else.

Thinking of it, could you please add a clarification that setting to an 
empty string is legal, and MUST NOT be ignored? I recall that 
Microsoft's original XHR (ActiveX) implementation got that wrong, not 
setting the header at all.

Re: XHR LC comments

[Bjoern Hoehrmann]

* Anne van Kesteren wrote:
>> "For security reasons, these steps should be terminated if the header  
>> argument case-insensitively matches one of the following headers:
>>
>>  * Accept-Charset
>>  * Accept-Encoding
>>  * Connection
>>  * Content-Length
>>  * Content-Transfer-Encoding
>>  * Date
>>  * Expect
>>  * Host
>>  * Keep-Alive
>>  * Referer
>>  * TE
>>  * Trailer
>>  * Transfer-Encoding
>>  * Upgrade
>>  * Via "
>>
>> It's unclear why there's a security reason not to allow things like  
>> "Accept-Charset" or "Accept-Encoding". Please explain.
>
>This was done based on implementation feedback. I haven't investigated  
>what the reasons were for the various headers. If implementors read this  
>maybe they could chime in and point it out.

Note that there are more headers on the list than the ones listed above,
specifically Proxy-*, Sec-*, and it is unclear how to handle, say, the
Cookie and Authorization header.

The correct value, if any, of the Connection, Content-Length, Expect,
Keep-Alive, Trailer, Transfer-Encoding, and Upgrade depends on decisions
about how to transfer the message and how to maintain the connection
that the implementation alone can make, therefore the implementation
rather than the script controls these headers. The Host header is on the
list to ensure scripts cannot bypass same origin restrictions.

Date, Referer, and Via inform about the origin of the request, they are
controlled by the implementation to prevent origin spoofing. The case
for these is much less clear, considering that other headers like User-
Agent are not on the list, and that cross-site requests are not allowed.

Accept-Charset, Accept-Encoding, and TE inform about client capabilities
and it seems the worst that could happen for them is that the server
offers a response the implementation cannot handle, which the server may
do anyway. I don't think their presence is particularily justified. This
is also because some environments treat "X-Y" named headers as if they
were "X_Y" headers and vice versa, if, say, Accept-Encoding is a problem
so would be Accept_Encoding.

Why Content-Transfer-Encoding is on the list I have no idea, HTTP does
not use this header at all, and when I researched this some months ago,
I could not find any particular security problems associated to it, as
far as I remember.

I very much agree the rationale for each header needs to be in the spec,
in a manner that also allows telling why other headers are not.
-- 
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/ 

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

[Doug Schepers]

Hi, Folks-

I have a conflict later on in the call, so it will be a short D3E 
telcon.  I plan to end at 3:30.


Thanks-
-Doug

Doug Schepers wrote (on 5/14/08 7:41 AM):


Hi WebAPI Fans-

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.

The regular time is Wednesdays, 18:30-20:00 UTC. See the DOM3 Events
wiki page for timezones adjustments. [1]

The tentative agenda is as follows:

   1. Convene, take roll, review agenda, plan next meeting
   2. Issue/Action review
   3. Halvord Steen's "legacy" key events proposal
   4. Adding an editor


For each week's telcon, we will maintain an agenda page [2] so you can
track what the discussion will be, add agenda topics, and see the
minutes afterward.

We will also maintain a list of all the past and planned telcons, with a
brief summary of issues discussed. [3]

[1] http://www.w3.org/2008/webapps/wiki/DOM3Events#Day_and_Time
[2] http://www.w3.org/2008/webapps/wiki/14_May_2008
[3] http://www.w3.org/2008/webapps/wiki/DOM3Events_Agenda

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













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

Re: XHR setting headers

[Bjoern Hoehrmann]

* Julian Reschke wrote:
>Peter Michaux wrote:
>> I think all XMLHttpRequest headers should be specified as blank when
>> the object is created. Then the JavaScript can add any headers it
>> needs to add. If, when the call to send() occurs, some essential
>> header(s) is missing the XHMLHttpRequest object should add these
>> automatically but only according to specified behavior.
>
>The whole "append" semantics is problematic as long as the user can't 
>find out what the current value is.
>
>IMHO we need either removeRequestHeader(), getRequestHeader(), or both.

I once suggested making setRequestHeader with null remove the stored
value, I am not sure why this has no effect instead. I do note that it
is unlikely that the set of headers the implementation will ultimately
pass on to the next hop will ever be fully deterministic based only on
published specifications. Similarily, I don't think mixing control over
your own headers, and those added or modified by the implementation in
the same API is a good idea: it cannot know whether removeRH is meant
to simply clear a previous setRequestHeader value, or meant to somehow
surpress an implementation default; the implementation also may not be
able to accurately predict the value of certain headers at the point
where the script wants to know them (or what it does report becomes in-
valid because other headers are set by the script). One case here is if
the client learns about certain features of the server only the moment
before the request is dispatched (like whether it supports HTTP/1.1 or
pipelined requests or has some particular bug that needs to be worked
around). So I would suggest a separate API is in order here, if one is
needed at all.
-- 
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/ 

Re: [July 1-3] [face to face] Agenda?

[Anne van Kesteren]

On Tue, 13 May 2008 23:21:57 +0200, Jonas Sicking <[EMAIL PROTECTED]> wrote:
Access-Control is developed by a wholly different WG though (at least  
until the two groups merge).


Has it been properly announced to the members, and other participants,  
of that WG that this meeting is taking place?


Yes, through Member-only space:  
http://lists.w3.org/Archives/Member/member-appformats/2008May/0007.html



--
Anne van Kesteren

Re: Proposed errata for DOM2 Range regarding insertNode()

[Boris Zbarsky]

Ian Hickson wrote:
I propose that we change the spec to explicitly say that if you call insertNode() on a 
collapsed range, the end point offset is increased by one


Increased at what point in time, exactly?  Specifically, if there is a 
DOMNodeInserted listener that repositions the range when the node insertion 
happens, or even mutates the DOM, what is the expected behavior?


-Boris

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

[DOM Events] Key events tests

[Olli Pettay]

Hi all,

I made some testing on WinXP using IE7, FF3pre, Opera9.5b, Safari3.1

http://mozilla.pettay.fi/moztests/events/browser-keyCodes.htm


-Olli

RE: IE Team's Proposal for Cross Site Requests

[Chris Wilson]

Ian, in your response you claim four separate times that my statements are 
"FUD".  (I presume you mean 
http://en.wikipedia.org/wiki/Fear%2C_uncertainty_and_doubt.)  I'll address 
those individually below, but your invective seems to confuse "Chris has 
different opinions/beliefs than me" with "Chris is distorting truth to try to 
game the system," or perhaps that's just the way you would like to paint me.

You claimed my message contained an "ultimatum" - defined by Webster's Revised 
Unabridged Dictionary as "A final proposition, concession, or condition; 
especially, the final propositions, conditions, or terms, offered by either of 
the parties in a diplomatic negotiation; the most favorable terms a negotiator 
can offer, the rejection of which usually puts an end to the hesitation."  
(Webster's Revised Unabridged Dictionary, © 1996, 1998 MICRA, Inc.)

You are quite clearly incorrect in applying that word, as I stated no 
proposition, demanded no concession; and at any rate clearly stated that we 
plan to continue to participate in the cross-domain effort currently active in 
the WG regardless of the decisions made, in the hopes that Access Control + XHR 
can be improved; in fact, I stated no terms nor hesitation.  That time is 
clearly past.  I was correcting a misunderstanding.

You accuse us of blatant disregard for Web standards process, presumably if we 
ship XDR in IE.  I disagree.  We are ALLOWED, in fact, to disagree; in fact, if 
we believe a developing standard is a bad idea, we SHOULD speak up.  We are 
also NOT, in fact, required to have every feature we ship be based on an 
approved standard (or do I need to write out the list of features that are not 
in approved standards, but are in shipping versions of other browsers?  Isn't 
think how innovations like  happen?).  I do believe we must have good 
reasons to choose to go down a different path than a current standards effort - 
in this case, we believe we have quite good reason.

You appear to be unable to be objective about this matter, and would rather be 
indignant and self-righteous at our missteps than accept that perhaps, every 
once in a while, those complete dunces at Microsoft might just possibly have a 
point.  It's somewhat amusing to see how you react to proposals (even radical 
ones in conflict with current status quo) from people OTHER than Microsoft, 
e.g. Google's Blob proposal that overlaps with Opera and Mozilla work in the 
same area (http://lists.w3.org/Archives/Public/public-webapi/2008May/0106.html).

In your invective, you also (for the benefit of "other parties" not as clued 
in, apparently, as yourself) liken "what's going on here" to a poison pill, 
which I fail to understand.  http://en.wikipedia.org/wiki/Poison_pill would 
seem to suggest that you think Microsoft is taking some action that harms both 
us and the standards effort; however, I would point out 1) XDR doesn't harm 
Microsoft. 2) I just stated that we will continue working on the Web API 
group's proposal, in the hopes that it can become implementable for us in the 
future.

I want to be clear that the following paragraph is a personal statement by me, 
and should not be representing in any way to reflect the opinions, values or 
plans of Microsoft, nor should it reflect on them in any way.

I believe you just accused me personally of "poison pill" tactics to further 
the interests of Silverlight.  I will be offended by your accusation of moral 
bankruptcy once I stop laughing at the idea that I personally would do such a 
thing, given my personal feelings on Silverlight.  At any rate, please don't 
claim to be "explaining the situation" to anyone else when you have it so 
completely wrong, and don't impugn my moral character unless you really intend 
to do so.

Back to being a Microsoft employee: to address your individual statements:

>Sunava said last November that
>this feedback would be sent as soon as possible. As far as I know, nobody
>else spent six months writing up their feedback.

And we are to blame for that delay, yes.  However, despite your claims that we 
have not shared our concerns, I believe we have been sharing them, just at a 
higher level than you apparently want.

>> For example, today the current XHR draft proposes to block a list of
>> headers that are unsafe only in a cross-domain context; however, this is
>> difficult to deploy since XHR has already shipped
>
>This is FUD -- there is nothing difficult to deploy about this, since
>cross-site XHR has never been available before.

You seem to equate "deploying" with "writing code," rather than any kind of 
understanding of the effects that deploying that code into markets that already 
use your software might have.  Shipping releases of IE to half a billion 
customers tends to give us that understanding in spades.

>> and [it is] challenging to imagine that there are no other headers in
>> use by servers anywhere around the world that might not be good to
>> access.
>
>Actual

Re: specification of "legacy" key events

[Hallvord R. M. Steen]

On Thu, 08 May 2008 12:05:23 +0200, Ian Hickson <[EMAIL PROTECTED]> wrote:


We have had requests to fire some kind of identifiable event when typing
occurs during IME processing for use cases like the following:

1) To resize an area based on user typing, even during IME entry (yes,  
this

works right, the text is in the text field even when unconfirmed..
2) To have special keyboard shortcuts work in a text field even during  
IME entry.


As I already said, nice use cases and we should accomodate them. I think  
all UAs I tested send keyup events - perhaps that's all we need though?



Indeed, we (Google) would very much like our scripts to be notified of
what's going on, keyboard-wise, during IME. In particular when the user  
is working with a contentEditable section we really need to have access  
to

these events so that, for example, we can, if the user so desires, cancel
them


I think this can not be specified for the legacy key events (keydown,  
keypress) since existing IMEs and browser implementations ignore  
cancelling these events while an IME is processing the input. Firing "some  
kind of identifiable event" might be for example the input events Safari  
is currently firing, it does not have to be keydown and keypress.



and provide our own IME implementation (which might hook into
user-specific information that the UA might not be able to provide).


Ian, in general it's unclear to me how you see this working - if I have  
selected a specific IME and input mode to type in some text it's likely  
that this is a VERY conscious choice, and that the IME I'm using has  
learnt what words I'm more likely to want to type. (Pretty much any  
Japanese IME I've used does remember what kanji combinations I've used,  
and mobile phone IMEs are very good at re-ordering kanji options by your  
usage statistics.) I think any sort of script interference with this would  
be *extremely* annoying to me as an end user, and if you want to implement  
input method editors in JS you would be more likely to build this on top  
of an ASCII input mode anyway.


If we do want to go there, I think we should investigate specifying either  
Firefox's composition events or Safari's "input during IME composition"  
events and whether these could be made cancellable. We also need a  
developer who has worked on IME integration to confirm that the UA is  
technically able to "undo" a character that has been sent to the IME (and  
in a clean way please, not sending a backspace char or some hack like  
that!). I'm not sure if this is the case.


--
Hallvord R. M. Steen
Core QA JavaScript tester, Opera Software
http://www.opera.com/
Opera - simply the best Internet experience

Re: XHR LC comments

[Ian Hickson]

On Wed, 14 May 2008, Julian Reschke wrote:
> > 
> > The problem is that concepts such "origin" and determining the 
> > encoding of a text/html stream are not defined anywhere else. It's not 
> > really clear to me what to do about that.
> 
> In some cases, it may be possible to copy the current definition. In 
> other cases, it may be possible just not to depend on it (for instance, 
> by not specifying encoding sniffing).

I don't have an opinion on the exact issue here, but as a general rule I 
recommend against making decisions based on the political status (rather 
than technical status) of working groups and specs. Otherwise we just end 
up reinforcing the Web's experiment with Conway's Law. That is to say, we 
should rather change the rules that prevent us from doing the right thing, 
than blindly follow those rules and change our technology to match.

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

Re: specification of "legacy" key events

[Hallvord R. M. Steen]

On Wed, 14 May 2008 22:17:39 +0200, Hallvord R. M. Steen  
<[EMAIL PROTECTED]> wrote:


I think all UAs I tested send keyup events - perhaps that's all we need  
though?


(Sorry, ignore that. Only IE does - I should have re-tested before sending  
the E-mail..)


--
Hallvord R. M. Steen
Core QA JavaScript tester, Opera Software
http://www.opera.com/
Opera - simply the best Internet experience

Re: XHR LC comments

[Ian Hickson]

On Wed, 14 May 2008, Bjoern Hoehrmann wrote:
> 
> Note that there are more headers on the list than the ones listed above, 
> specifically Proxy-*, Sec-*, and it is unclear how to handle, say, the 
> Cookie and Authorization header.

I think I would lump the Cookie, Cookie2, and Authorization headers in the 
same bucket as, e.g., Host -- these are headers that the UA should be 
setting and not headers that should be under author control.

Incidentally, I think I would recommend removing the blacklist from AC, 
since AC has a whitelist. Having both seems pointless.

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

Re: Proposed errata for DOM2 Range regarding insertNode()

[Ian Hickson]

On Wed, 14 May 2008, Olli Pettay wrote:
> 
> > which I believe to be the intent of the specification. This is 
> > implemented by Opera and WebKit already, and is tested by Acid3.
> 
> Gecko does what the current spec says.

All three implementations do what the spec says now -- the spec can be 
interpreted both ways.


> Does web content rely on the current spec behavior?

To my knowledge, very little Web content relies on this spec at all. 
That's why Acid3 tested it, to make it interoperable enough that it could 
be used. :-)


> Did Webkit or Opera change their behavior just to pass ACID3 (but not to 
> follow Range spec)?

I didn't check whether they implemented this before Acid3 or not.


On Wed, 14 May 2008, Boris Zbarsky wrote:
> Ian Hickson wrote:
> > I propose that we change the spec to explicitly say that if you call
> > insertNode() on a collapsed range, the end point offset is increased by one
> 
> Increased at what point in time, exactly?  Specifically, if there is a 
> DOMNodeInserted listener that repositions the range when the node 
> insertion happens, or even mutates the DOM, what is the expected 
> behavior?

DOM2 Range doesn't define anything to this level of detail yet, 
unfortunately. For example regular old insertions and deletions near 
ranges cause changes to the range values but the spec doesn't say if this 
is before or after the events.

It seems that for sanity we should say it happens before, if we specify 
this. Should we do this as a separate errata?

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

Re: Proposed errata for DOM2 Range regarding insertNode()

[Robert Sayre]

On Wed, May 14, 2008 at 6:15 PM, Ian Hickson <[EMAIL PROTECTED]> wrote:
>
>
> To my knowledge, very little Web content relies on this spec at all.
> That's why Acid3 tested it, to make it interoperable enough that it could
> be used. :-)

I thought Acid3 tested things that have been written down for at least
5 years or something like that.

confused,

Rob

-- 

Robert Sayre

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

Re: specification of "legacy" key events

[Bjoern Hoehrmann]

* Hallvord R. M. Steen wrote:
>I've never really written English specification prose before (though I've  
>been an avid reader of W3C TRs) so please give this stuff a critical but  
>patient review ;-)

I don't think it is useful to discuss specification prose if it's
unclear what is to be specified, and what the requirements are. I
am only familiar with how key events function in the Win32 API, I
will just point out some differences. This should be the same as
the differences to Internet Explorer running on Windows since it
essentially just passes the events along as far as I understand it.

>   * If the key does not cause text input and is not the Escape key (i.e. 
> if  
>the key is not is an alphanumerical key, a punctuation key, a repeated  
>press of a dead key or the Escape key), terminate this algorithm.

I may be misparsing this, but Escape key occurs twice, and I am not sure
what the text in the parens actually refers to (what is a key that ge-
nerates my name, or a combining character? those do not fall in any of
the items you list, yet they do generate text); I would also suggest to
remove some of the negations here.

>   * Set event meta key properties (shiftKey, ctrlKey, altKey, metaKey)  
>depending on what meta keys are pressed, if any

This should not be part of this, or you have to complete it and say,
among other things, to set the .view attribute.

>   * For backwards compatibility reasons the character code property has 
> two  
>different names. Define charCode and keyCode, set both to the decimal  
>value of the unicode reference number of the corresponding character.

See below.

>   * Fire the event. If it was not cancelled with event.preventDefault()  
>proceed to fire a textInput event.
>
>   * If the same keystroke inserts several characters, fire one keypress  
>event for each
>
>   * If the key is held down, repeatedly fire one keydown event and one or 
>  
>more keypress events at a rate determined by the system's repeat key  
>interval setting

I think the order here is off, and this is easy to misread. For example,
if the key generates multiple characters, do you send textInput only for
the first character, or one for each character, or one for all chars?

Further, some keys may generate multiple keydown events, for example,
the AltGr key on my keyboard will generate sequences of CTRL and Menu
keydown events; also, you may hold some keys down without any repetition
(e.g., hold a, additionally hold shift, release shift; you are holding
the a key but don't get events for that).

>TODO#1: note that IE does NOT take the upper-case value of certain  
>non-English character (for example ø/Ø on Norwegian keyboards). I believe  
>doing so makes the model cleaner and is unlikely to cause compatibility  
>problems - this needs investigation though. Here we also probably need to  
>specify some specific algorithm for upper/lower-casing characters?

If you use a cyrillic keyboard layout, you may not have any "english"
characters on it, but all the cyrillic keys specify the virtual key
codes in their keyboard events. So a U+0439 key may generate the same
code as a 'q' key. With your proposal, pretty much all the letter keys
would generate different codes. That seems a compatibility issue to me.

Also note that for keypress, Windows, and I would expect other systems
that use a UTF-16 variant internally, you get pairs of events specifying
surrogate codes points, rather than the unicode scalar value for non-BMP
characters.

>TODO#2: Step 4 of this algorithm is incomplete, probably needs to specify  
>how to get a virtual key from system? The issue step 4 is trying to solve  
>is: If a given key, say the I key is mapped to something else, say  
>"Hiragana I" keydown/keyup will still have the key code of an upper-case I  
>in reference implementations but not according to this algorithm without  
>some magic in step 4. Hence we need to fall back to reading virtual key  
>codes from the system in step 4, but how to do this exactly is  
>underspecified and will probably vary between operating systems.

It seems to me, at least in the cyrillic case above, nothing in step 4
can help there, since the algorithm exits at step 2.

>TODO: dead keys pressed twice fire two keypress events. Dead keys followed  
>by space fire keydown space, keypress for the dead key's accent, keyup  
>space (!). Dead keys are currently a bit underspecified in the above text.

Is there anything peculiar about this? `keypress` in Internet Explorer
maps to a WM_CHAR notification, and if you press a dead key twice you'll
generally get two characters, followed by space generates one character,
and the ups and downs follow naturally.
-- 
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/ 

Re: IE Team's Proposal for Cross Site Requests

[Bjoern Hoehrmann]

* Chris Wilson wrote:
>This sound like nothing short of demonstrating actual exploits against
>the design will demonstrate to you that it might be vulnerable.  Have
>you actually looked into secure coding principles at all?  Even, say,
>Writing Secure Code[1]?

I bought mine in the Microsoft MVP store back when I had points to spend
there, and read it cover to cover. However, I don't think discussing our
reading habits or who's got the bigger market share will do this dis-
cussion much good. What you wanted to say inevitably got lost in all the
lines of your message that deal only with what Ian said, and he did not
contribute much in his message to begin with.

In evaluating Microsoft's XDR proposal I believe two questions are most
important. First, how well does it address what people actually want to
do in terms of cross site requests. The mechanism is very crude, you can
not use methods other than GET and POST, you can't set headers, you have
no standard methods for authentication, you can only transfer strings,
you have to be able to manipulate the HTTP header, and it only works if
you can use the special new API, not if you use some other methods to
embed external resources.

If that is all developers want to do, XDR may be quite suitable. If, on
the other hand, developers actually need and want additional methods,
authentication, transfer data that isn't simply a string conveniently,
and other things, it is quite possible they will come up with crude ad-
hoc work arounds to address their requirements, and are highly likely to
implement security vulnerabilities in their applications in the process;
more so if many different applications require different workarounds.

It does not matter all that much to most users whether they get screwed
because of a browser bug, or a web site bug. It appears that Microsoft
realizes as much, citing how easily other solutions are misconfigured as
one motivation for the XDR work, but it is very much unclear to me why
developers are not going to make grave errors when setting up XDR-based
sites and services.

The second questions is simply whether this is all. Is there going to be
an "XDRv2" in "IE9" with more developer aids to build secure cross site
setups? Or other solutions in other Microsoft products? The latter would
http://lists.w3.org/Archives/Public/public-appformats/2008Apr/0073.html
seem to be so in the case of the next version of Microsoft Silverlight.

In the current Beta version you will find many of the things we hear are
bad from the Internet Explorer Team, that is, policy files, cookies are
sent, the same APIs are used for same-domain and cross-domain requests,
and while there are two differnt kinds of policy files, and an upcoming
full cross-domain model for socket access. But no apparent XDR support.

Improved support for web services of all kinds, including cross domain
access, is one of the main marketed features of the next Silverlight re-
lease, and I have great difficulty imagining that either will be dropped
or that Silverlight will simply switch to using XDR only, and it's less
than three months now that Silverlight 2 is supposed to be released to
all those wanting to access NBC's Summer Olympics coverage.

That Microsoft itself cannot agree on one technology, or at least only
one philosophy to approach the problem does not inspire confidence in
any of the solutions, and the prospect of having to cope with several
new cross domain access solutions, even though we already have too many,
is rather worrying.

Personally speaking, the IE Team's emphasis on security and simplicity
is a welcome contrast to the XHR2+AC design team's emphasis on broad
applicability, ease of deployment, and efficiency, but XDR is so limited
in its ability that I might aswell continue using remote 

Re: Proposed errata for DOM2 Range regarding insertNode()

[Robert Sayre]

On Wed, May 14, 2008 at 8:37 PM, Ian Hickson <[EMAIL PROTECTED]> wrote:
> On Wed, 14 May 2008, Robert Sayre wrote:
>>
>> I'm not sure why you're sending private email about this. I asked a
>> simple question on the public list.
>
> I replied privately to the first question because it seemed rude to spam
> the list about it. I've cc'ed www-archive on this mail.

I've changed it back to public-webapi. If you ask me, it seems a bit
rude to get all control freak about the venue and then republish what
was private mail.

>
>
>> Olli wrote:
>> "Gecko does what the current spec says."
>>
>> So clearly there is some disconnect about the nature of the change
>> you're proposing.
>
> Sure. Like I said, the spec right now contradicts itself. If it didn't
> there wouldn't be much reason to ask for errata. :-)

Why not fix it and supercede it?


>
> Included for archival purposes:
>
>> On Wed, May 14, 2008 at 6:48 PM, Ian Hickson <[EMAIL PROTECTED]> wrote:
>> > On Wed, 14 May 2008, Robert Sayre wrote:
>> >> On Wed, May 14, 2008 at 6:23 PM, Ian Hickson <[EMAIL PROTECTED]> wrote:
>> >> > On Wed, 14 May 2008, Robert Sayre wrote:
>> >> >> On Wed, May 14, 2008 at 6:15 PM, Ian Hickson <[EMAIL PROTECTED]> wrote:
>> >> >> >
>> >> >> > To my knowledge, very little Web content relies on this spec at
>> >> >> > all. That's why Acid3 tested it, to make it interoperable enough
>> >> >> > that it could be used. :-)
>> >> >>
>> >> >> I thought Acid3 tested things that have been written down for at
>> >> >> least 5 years or something like that.
>> >> >
>> >> > DOM2 Range came out in November 2000.
>> >>
>> >> So it tests what was written in 2000 or the proposed as yet unwritten
>> >> change?
>> >
>> > The spec right now does support what Acid3 does, it's just that it is
>> > ambiguous in its requirments and can be interpreted the other way around
>> > as well. Contradictions in specs happen, just like bugs in software.
>
> --
> Ian Hickson   U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>



-- 

Robert Sayre

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

Re: Proposed errata for DOM2 Range regarding insertNode()

[Ian Hickson]

On Wed, 14 May 2008, Robert Sayre wrote:
> >
> > Sure. Like I said, the spec right now contradicts itself. If it didn't 
> > there wouldn't be much reason to ask for errata. :-)
> 
> Why not fix it and supercede it?

As I said in the very first e-mail on this subject, that's what I'd like 
to do. However, that's a significantly higher cost (years vs weeks) than 
releasing an errata, and it was my impression that the Mozilla community 
would like a quick turnaround on this.

What I recommend is that we release an errata as soon as possible, while 
simultaneously looking for someone to rewrite the DOM Level 2 "Traversal 
and Range" specification.

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

Re: Proposed errata for DOM2 Range regarding insertNode()

[Robert Sayre]

On Wed, May 14, 2008 at 9:02 PM, Ian Hickson <[EMAIL PROTECTED]> wrote:
>
> As I said in the very first e-mail on this subject, that's what I'd like
> to do. However, that's a significantly higher cost (years vs weeks) than
> releasing an errata, and it was my impression that the Mozilla community
> would like a quick turnaround on this.

It looks to me like you're retroactively specifying something in your
test. I asked a simple question to determine whether that was the
case, since I would like to know the exact nature of the bugs Google
is (rather pompously) flaming us for.[1]

If there is disagreement about a change to normative behavior, it
seems like the right thing to do would be to discuss it, not pick one
interpretation and try to jam it through as errata. I don't see how
one can claim the spec can be interpreted both ways, but also that the
intent is clear. Is one of the possible interpretations a real
stretch?

[1] http://diveintomark.org/archives/2008/05/07/when-the-fall-is-all-thats-left

-- 

Robert Sayre

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

Re: Proposed errata for DOM2 Range regarding insertNode()

[Ian Hickson]

On Wed, 14 May 2008, Robert Sayre wrote:
> On Wed, May 14, 2008 at 9:02 PM, Ian Hickson <[EMAIL PROTECTED]> wrote:
> >
> > As I said in the very first e-mail on this subject, that's what I'd 
> > like to do. However, that's a significantly higher cost (years vs 
> > weeks) than releasing an errata, and it was my impression that the 
> > Mozilla community would like a quick turnaround on this.
> 
> It looks to me like you're retroactively specifying something in your 
> test.

The test verifies that when you call insertNode() on a range, the node 
that is passed is inserted into the range, as is required by DOM2 range 
section 2.9. Inserting Content, sentences 1 and 2 (before and after the 
code snippet).

These sentences are contradicted by the more generic sentences in section 
2.12.1. Insertions, which don't take insertNode() into account for the 
case of a collapsed range, and thus end up not implementing the 
requirement in the former section.

I hold that the intent of the spec is clear, in that it would be pretty 
dumb for an API for inserting nodes into a range didn't actually insert 
nodes into a range; however, I agree that it is possible to interpret the 
spec in a way that assums that the generic rules in the latter section 
override the statements in the former section, hence my proposal that we 
raise this as an errata.


> If there is disagreement about a change to normative behavior, it seems 
> like the right thing to do would be to discuss it, not pick one 
> interpretation and try to jam it through as errata.

Right, that's why I raised on the list, so that we can discuss it.

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

Progress Events: heads-up regarding begin vs loadstart in HTML5

[Ian Hickson]

FYI, I just changed the HTML5 spec to use 'loadstart' instead of 'begin' 
for the first ProgressEvent. It turns out the reason I used 'begin' is 
that an older version of Progress Events used 'begin', and this was 
changed without me noticing.

Is there a place where I can track what feedback has or hasn't been 
responded to regarding Progress Events? In particular, the feedback in:

   http://lists.w3.org/Archives/Public/public-webapi/2008Feb/0178.html

...doesn't seem to have received a reply, but I can't tell if it is still 
in the queue or if it was dropped somehow. Is there some process by which 
I should raise issues to make sure they don't get lost?

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

Re: Proposed errata for DOM2 Range regarding insertNode()

[Boris Zbarsky]

Ian Hickson wrote:
DOM2 Range doesn't define anything to this level of detail yet, 
unfortunately.


Indeed.  The wonders of Conway's Law...

Nevertheless, this question is somewhat important in terms of deciding where the 
range should be positioned.


For example regular old insertions and deletions near 
ranges cause changes to the range values but the spec doesn't say if this 
is before or after the events.


I think it's pretty clear that it should be when the actual mutation occurs (so 
before the events for insert cases and after for removal cases), but that does 
mean that one can't implement Range on top of DOM MutationEvents.  Then again, 
there's no much one can implement on top of them, so that's OK, I think.


It seems that for sanity we should say it happens before, if we specify 
this. Should we do this as a separate errata?


I just wanted to point out that we have to be very careful in how we phrase this 
erratum (which I agree is a possibly useful one): we basically want to perform 
the insertion, then before firing the mutation event adjust the insertion 
endpoint after all the nodes we just inserted.  Or something.  In a UA that 
would fire multiple events here when inserting a DocumentFragment, we might lose 
no matter what we try to do.


-Boris

Re: Proposed errata for DOM2 Range regarding insertNode()

[Olli Pettay]

Ian Hickson wrote:

The test verifies that when you call insertNode() on a range, the node
that is passed is inserted into the range, as is required by DOM2 range
section 2.9. Inserting Content, sentences 1 and 2 (before and after the
code snippet).


The 2nd sentence doesn't require adding node to range. It talks about
context tree which isn't the same thing as range.

-Olli