Re: before/after editaction

[Ojan Vafai]

On Tue, Aug 30, 2011 at 6:39 PM, Jonas Sicking  wrote:

> On Tue, Aug 30, 2011 at 5:07 PM, Ryosuke Niwa  wrote:
> > On Tue, Aug 30, 2011 at 4:34 PM, Darin Adler  wrote:
> >>
> >> My question was not about the undo command. I meant that if I
> implemented
> >> a handler for the aftereditaction event that changed b tags to strong
> tags,
> >> how would the undo machinery undo what I had done?
> >
> > Ah, I see.  So UA won't be able to undo/redo those DOM changes as of now.
> >  However, authors can use UndoManager and transactions (see
> > http://rniwa.com/editing/undomanager.html) to hook into UA's undo
> manager.
> >  e.g. if authors wanted UAs to manage undo/redo for those changes, they
> can
> > make those changes as a managed transaction.
>
> My suggestion during the above mentioned Toronto meeting was that the
> UA starts a managed transaction before firing the beforeEditAction
> event.  This transaction would record any changes done during the
> beforeEditAction and the afterEditAction event. It would also record
> the changes done by the UA itself as the actual edit action.
>
> This way, and changes done during the beforeEditAction and
> afterEditAction events would be automatically part of the "undo-able"
> action created in response to the command. So if the page cancels the
> beforeEditAction in response to a "bold" command, and instead inserts
>  elements, then this modification would be undone if the user
> or the page initiates an undo.
>
> I think this proposal got minuted for the first day.
>
> The one thing that this doesn't solve is what to do in cases when the
> page wants to replace the current action with a manual transaction
> rather than the managed one usually created. Ideas for how to solve
> that are welcome.


Overall I really like the proposal (both having the events and Jonas's
addition to include them in the undo transaction). We'd fire the
afterEditAction exactly everywhere we currently fire the input event though.
Instead of adding two new events, could we instead add a beforeInput event
as the beforeEditAction. Then add to both beforeInput and input an "action"
property that is the edit action that was taken.*

The only downside I see to reusing input is that it might complicate Jonas's
suggestion to include edits during the afterEditAction in the undo
transaction. Although, my intuition is that there is *not* web content that
depends on script executed during the input event not entering the undo
stack.

Ojan

* Those of you who read www-dom will remember I proposed this a long time
ago to that working group. At the time, I coupled with this that we should
kill the textInput event as well since beforeInput would be a super-set.
There wasn't really opposition to adding beforeInput/input except that some
felt the DOM Events spec was too far along to add new features and some were
really attached to keeping textInput.

Re: [indexeddb] Calling IDBDatabase.close inside onupgradeneeded handler

[Jonas Sicking]

On Thu, Oct 13, 2011 at 11:27 AM, Israel Hilerio  wrote:
> On Thursday, October 13, 2011 12:15 AM, Jonas Sicking wrote:
>>On Wednesday, October 12, 2011, Israel Hilerio  wrote:
>>> On Wednesday, October 12, 2011 4:21 PM, Jonas Sicking wrote:
 On Wed, Oct 12, 2011 at 4:06 PM, Israel Hilerio 
 wrote:
 > If a db connection is closed inside the onupgradeneeded handler, section 
 > 4.1
 step #8 states that we should return an ABORT_ERR and abort steps. This
 implies that the transaction should fail. Since today, the db is closed 
 after all
 requests have been processed, we don't see the reason why we would return
 an error instead of just allowing the db connection to follow its natural
 course. The worst that can happen is that we return a handle to a closed 
 db,
 which is what the developer intended.
 >
 > Should we remove this constraint and not error out on this particular 
 > case
 (i.e. calling db.close from onupgradeneeded)? Or, are there reasons to keep
 this logic around?

 I agree, we should not abort the VERSION_CHANGE transaction.

 It'd still make sense to fire an "error" event on the request returned from
 indexeddb.open though, after the transaction is committed. This since the
 database wasn't successfully opened.

 / Jonas
>>>
>>> Couldn't you make the case that it was successfully opened and therefore 
>>> you were able to run the >upgrade logic.  However, the developer chose to 
>>> close it before returning from the handler.  This will >provide us a 
>>> pattern to upgrade DBs without having to keep the db opened or a handle 
>>> around.  It will also >help devs differentiate this pattern from a real db 
>>> open problem.
>>
>>My thinking was that we should only fire the success event if we can really 
>>hand the success handler a >opened database. That seems to make the open 
>>handler easiest to implement for the web page.
>>
>>If we do fire the success handler in this case, what would we hand the 
>>handler as result? Null? A closed >database? Something else?
>>
>>/ Jonas
>
> We were thinking that we would give back a closed db (i.e. closed connection 
> and a closePending flag set to true). We believe that this mimics the intent 
> of the developer when they closed the db inside of their onupgradeneeded 
> handler.

Ok, that works for me.

/ Jonas

Re: [File API] Blob.slice()

[Arun Ranganathan]

On 8/31/11 4:48 AM, Anne van Kesteren wrote:

It's defined as a single algorithm:

http://dev.w3.org/2006/webapi/FileAPI/#dfn-slice

and cribs from ECMAScript's definition of slice.  It's the only host 
object with a slice.



It still looks like several independent algorithms to me. There should 
be one that includes processing of the arguments.


(Forgot to respond to this).

Fixed this as well.  There is now a single algorithm, with normalizing 
parameters part of parameters and slice part of method description.


-- A*

Re: [File API] dependencies

[Arun Ranganathan]

On 8/31/11 4:39 AM, Anne van Kesteren wrote:
On Wed, 31 Aug 2011 06:20:58 +0200, Arun Ranganathan 
 wrote:

Done.


Thanks!

I noticed a few small things:

 * HTML5 should be without space
 * Progress Events is pointing to a dated version rather than the 
latest; Charles is also no longer an editor; 1.0 can be dropped




Fixed.

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

Re: [File API] FileList

[Arun Ranganathan]

On 8/31/11 4:43 AM, Anne van Kesteren wrote:
On Wed, 31 Aug 2011 06:12:06 +0200, Arun Ranganathan 
 wrote:

On 8/14/11 5:36 AM, Anne van Kesteren wrote:
I think FileList should talk less about selected files and more 
about being a collection or list of File objects. That way it can be 
reused in the future without people tripping over its current narrow 
definition.


It is a collection of File objects, but they must be user selected.  
HTMLInputElement and DataTransfer don't make a sufficient virtue of 
user selection, so I feel it useful to keep it a part of FileList.


Why must they be user selected? I do not think that will necessarily 
be true over time. And it also seems to put some kind of artificial 
constraint on UI that should not be there.




OK, this constraint has been removed now.

-- A*

Re: [File API] Dereferencing Model for Blob URIs

[Arun Ranganathan]

On 8/31/11 3:49 AM, Anne van Kesteren wrote:
This model should be rephrased a bit to make it more clear what the 
requirements are. E.g. I think if you use POST it should not be a MAY 
but a MUST that 500 is returned.


Also what are the security errors you can get a 500 for? Are they not 
handled by 403? I think handling them with 403 is counter to how they 
are handled elsewhere though. Usually any kind of error is handled as 
a generic network error. I think it might be better to simply use 200 
if the method was GET and 500 for everything else. You should probably 
also state what needs to happen with user/password arguments and maybe 
add a note that request headers are ignored. Furthermore, it has a 
note of sorts that you can expect a Content-Type header in the 
response, but it should be more detailed about what 
getAllResponseHeaders() will return. I.e. give a more complete 
definition of the response.


1. I've made it clearer what all the request and response headers should be.

2. I've simplified the model to only include 200 and 500 responses; in 
particular, I was swayed by the argument not to leak information, and 
felt that a minimum number of response codes would be most useful.


3. An open question is what ought to be done about user/password 
arguments.  Servers honor them, but I'm not entirely certain browsers on 
top of file systems need to do anything here.  I sense there's a use 
case here, but if there is, it hasn't been articulated.  For now, the 
protocol doesn't really allow or disallow them.  What is your opinion 
for what should be done?


-- A*

RE: [indexeddb] Calling IDBDatabase.close inside onupgradeneeded handler

[Israel Hilerio]

On Thursday, October 13, 2011 12:15 AM, Jonas Sicking wrote:
>On Wednesday, October 12, 2011, Israel Hilerio  wrote:
>> On Wednesday, October 12, 2011 4:21 PM, Jonas Sicking wrote:
>>> On Wed, Oct 12, 2011 at 4:06 PM, Israel Hilerio 
>>> wrote:
>>> > If a db connection is closed inside the onupgradeneeded handler, section 
>>> > 4.1
>>> step #8 states that we should return an ABORT_ERR and abort steps. This
>>> implies that the transaction should fail. Since today, the db is closed 
>>> after all
>>> requests have been processed, we don't see the reason why we would return
>>> an error instead of just allowing the db connection to follow its natural
>>> course. The worst that can happen is that we return a handle to a closed db,
>>> which is what the developer intended.
>>> >
>>> > Should we remove this constraint and not error out on this particular case
>>> (i.e. calling db.close from onupgradeneeded)? Or, are there reasons to keep
>>> this logic around?
>>>
>>> I agree, we should not abort the VERSION_CHANGE transaction.
>>>
>>> It'd still make sense to fire an "error" event on the request returned from
>>> indexeddb.open though, after the transaction is committed. This since the
>>> database wasn't successfully opened.
>>>
>>> / Jonas
>>
>> Couldn't you make the case that it was successfully opened and therefore you 
>> were able to run the >upgrade logic.  However, the developer chose to close 
>> it before returning from the handler.  This will >provide us a pattern to 
>> upgrade DBs without having to keep the db opened or a handle around.  It 
>> will also >help devs differentiate this pattern from a real db open problem.
>
>My thinking was that we should only fire the success event if we can really 
>hand the success handler a >opened database. That seems to make the open 
>handler easiest to implement for the web page.
>
>If we do fire the success handler in this case, what would we hand the handler 
>as result? Null? A closed >database? Something else?
>
>/ Jonas 

We were thinking that we would give back a closed db (i.e. closed connection 
and a closePending flag set to true). We believe that this mimics the intent of 
the developer when they closed the db inside of their onupgradeneeded handler.

Israel

RE: [indexeddb] Implicit Transaction Request associated with failed transactions

[Israel Hilerio]

On Monday, October 10, 2011 10:10 PM, Jonas Sicking wrote:
> On Thu, Oct 6, 2011 at 3:30 PM, Israel Hilerio  wrote:
> > On Tuesday, October 04, 2011 3:01 AM, Jonas Sicking wrote:
> >> On Mon, Oct 3, 2011 at 7:59 PM, Jonas Sicking  wrote:
> >> > On Mon, Sep 12, 2011 at 2:53 PM, Israel Hilerio 
> >> > 
> >> wrote:
> >> >> Based on previous conversations, it seems we've agreed that 
> >> >> there are
> >> situations in which a transaction could failed independent of 
> >> explicit requests (i.e. QUOTA_ERR, TIMEOUT_ERR).  We believe that 
> >> this can be represented as an implicit request that is being 
> >> triggered by a transaction.  We would like to add this concept to 
> >> the spec.  The benefit of doing this is that it will allow 
> >> developers to detect the error code associated with a direct 
> >> transaction failure.  This is
> how we see the concept being used:
> >> >>
> >> >> trans.onerror = function (e) {
> >> >> //eventTarget is mapped to an implicit transaction that was 
> >> >> created behind the scenes to track the transaction
> >> >>
> >> >>  if (e.eventTarget.errorCode === TIMEOUT_ERR) {
> >> >>    // you know the transaction error because of a timeout 
> >> >> problem
> >> >>  }
> >> >>  else if (e.eventTarget.errorCode === TIMEOUT_ERR) {
> >> >>   // you know the transaction error because of a quota problem
> >> >>  }
> >> >> }
> >> >>
> >> >> Our assumption is that the error came not from an explicit 
> >> >> request but
> >> from the transaction itself.  The way it is today, the 
> >> e.eventTarget will not exists (will be undefined) because the error 
> >> was not generated from an explicit request.  Today, eventTargets 
> >> are only populated from explicit requests.
> >> >
> >> > Good catch!
> >> >
> >> > We had a long thread about this a while back with the subject 
> >> > "[IndexedDB] Reason for aborting transactions". But it seems to 
> >> > have fizzled with no real conclusion as to changing the spec. In 
> >> > part that seems to have been my fault pushing back at exposing 
> >> > the reason for a aborted transaction.
> >> >
> >> > I think I was wrong :-)
> >> >
> >> > I think I would prefer adding a .errorCode on IDBTransaction 
> >> > through (or .errorName or .error or whatever we'll end up changing it 
> >> > to).
> >> > This seems more clear than creating a implicit request object.
> >> > It'll also make it easy to find the error if you're outside the 
> >> > error handler. With the implicit request, you have no way of 
> >> > getting to the request, and thus the error code, from code 
> >> > outside the error handler, such from code that looks at the 
> >> > transaction after it has
> run.
> >> >
> >> > And the code above would work exactly as is!
> >> >
> >> > Let me know what you think?
> >>
> >> In detail, here is what I suggest:
> >>
> >> 1. Add a .errorCode (or .errorName/.error) property on 
> >> IDBTransaction/IDBTransactionSync.
> >> 2. The property default to 0 (or empty string/null) 3. In the 
> >> "Steps for aborting a transaction" add a new step between the 
> >> current steps
> >> 1 and 2 which says something like "set the errorCode property of 
> >> transaction to code".
> >>
> >> This way the reason for the abort is available (through the
> >> transaction) while firing the "error" event on all still pending 
> >> requests in step 2. The reason is also available while firing the 
> >> "abort" event on the transaction itself.
> >>
> >> / Jonas
> >
> > Independent on how we handler error, we like this approach!  This is 
> > our
> interpretation of the impact it will have on the overall feature.
> >
> > SCENARIO #1:
> > Whenever there is an error on a request, the error value associated 
> > with the
> request will be assigned to the transaction error value.
> > The error value in the transaction will be available on the
> IDBTransaction.onerror and IDBTransaction.onabort handlers.
> >
> > SCENARIO #2:
> > Whenever there is an error associated with the transaction (e.g. 
> > QUOTA or
> TIMEOUT ), the error value associated with the failure (e.g. QUOTA or
> TIMEOUT) will be assigned to the transaction error value.  The error 
> value in the transaction will be available on the 
> IDBTransaction.onerror and IDBTransaction.onabort handlers.
> >
> > SCENARIO #3:
> > A developer uses the IDBTransaction.abort() method to cancel the
> transaction.  No error will be assigned to the transaction error 
> value. The error value will be 0 (or empty string/null) when the 
> IDBTransaction.onabort handler is called.
> >
> > SCENARIO #4 (to be complete):
> > Whenever there is an error on a request, the error value associated 
> > with the
> request will be assigned to the transaction error value. However, if 
> the
> event.preventDefault() method is called on the request, the only 
> handler that will be called will be IDBTransaction.onerror and the 
> error value will be available in the transaction.  This implies that 
> the value of the first transaction event error that

Re: [DOM3Events] Oustanding issues (was: [DOM3Events] CR)

[Anne van Kesteren]

On Thu, 13 Oct 2011 12:33:40 +0900, Anne van Kesteren   
wrote:
On Thu, 13 Oct 2011 11:32:34 +0900, Jacob Rossi  
 wrote:
Your welcome, I appreciate your tolerance! I made a sweep in good faith  
through the list archives and was unable to find other unanswered  
issues.


It is somewhat sad comments are not being tracked. I just went through  
the archives again
http://lists.w3.org/Archives/Public/www-dom/2011JulSep/0107.html does  
not seem to have a response.


The same goes for  
http://lists.w3.org/Archives/Public/www-dom/2011JulSep/0252.html and  
http://lists.w3.org/Archives/Public/www-dom/2011JulSep/0253.html it seems.



--
Anne van Kesteren
http://annevankesteren.nl/

CfC: publish LCWD of Web Storage; deadline Oct 20

[Arthur Barstow]

Although the bug list for Web Storage is back to zero, rev 1.182 [1] 
which replaces the initXXXEvent method with a constructor (ala DOM4) 
requires a new LC. As such, this a Call for Consensus to publish a new 
LCWD of this spec:


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

The Process Document states the following regarding the 
significance/meaning of a LCWD:


[[
http://www.w3.org/2005/10/Process-20051014/tr.html#last-call

Purpose: A Working Group's Last Call announcement is a signal that:

* the Working Group believes that it has satisfied its relevant 
technical requirements (e.g., of the charter or requirements document) 
in the Working Draft;


* the Working Group believes that it has satisfied significant 
dependencies with other groups;


* other groups SHOULD review the document to confirm that these 
dependencies have been satisfied. In general, a Last Call announcement 
is also a signal that the Working Group is planning to advance the 
technical report to later maturity levels.

]]

Positive response to this CfC is preferred and encouraged and silence 
will be assumed to mean agreement with the proposal.


The deadline for comments is October 20 and please send all comments to: 
public-webapps at w3.org.


If any new bugs are submitted before this CfC completes and this CfC 
passes, those bugs will be will be considered as LC comments.


-AB

[1] 
http://dev.w3.org/cvsweb/html5/webstorage/Overview.html.diff?r1=1.181;r2=1.182;f=h 

Re: Mutation Observers: a replacement for DOM Mutation Events

[Olli Pettay]

On 10/13/2011 11:32 AM, Sean Hogan wrote:

On 13/10/11 2:33 PM, Ryosuke Niwa wrote:

On Wed, Oct 12, 2011 at 8:14 PM, Sean Hogan mailto:shogu...@westnet.com.au>> wrote:

Maybe you can provide concrete examples (i.e. with code snippets,
actual instances of use cases, etc...)


Actually, it is the proponents of changing the status-quo and of
the more complex solution who bear more responsibility for
providing these. But if it helps, here's a specific example:

MathJax (http://mathjax.org) is a js lib for rendering math in
web-pages. One feature it provides is converting LaTeX into
(typically) a HTML representation of the math. It is desirable for
the LaTeX source to remain available in the document, and MathJax
stores it as the content of a 

Re: Mutation Observers: a replacement for DOM Mutation Events

[Olli Pettay]

On 10/13/2011 05:51 AM, Sean Hogan wrote:

My main reservation towards the proposal is its complexity - it promises
a lot and I will be surprised if it is as trivial to implement as you
have implied. Even then, I'm expecting that it isn't the improvement
(over the status-quo) that everyone is speculating. It's great that
there is going to be an implementation real-soon-now so that my concerns
can be allayed / confirmed.



I haven't said this API is trivial to implement.
In fact, it is a bit tricky to implement, but while I've been
implementing it, the API itself has felt pretty good.


-Olli

Re: Mutation Observers: a replacement for DOM Mutation Events

[Sean Hogan]

On 13/10/11 7:58 PM, Ryosuke Niwa wrote:


On Thu, Oct 13, 2011 at 1:32 AM, Sean Hogan > wrote:



Why do you assume that all other mutation observers should ignore
such changes? If there's a library that's automatically syncing
the document with a server, then such an observer certainly needs
to know any mutations that happen in the document.

- Ryosuke



In the case of MathJax, the HTML rendering for math is generated
in the browser. It is only the LaTeX that you would want synced on
the server.


No, my use case addresses the case where you want to mirror the exact 
DOM state (except event handlers and script elements) elsewhere. And 
for that to work, I need to be able to see whatever MathJax is 
generating, NOT the LaTeX code.


For that use case I think you would be happy with my proposal which 
doesn't implement any filtering of mutation events at all.


By the way, I'm not arguing that the mutation observers proposal should 
provide a mechanism for hiding some mutations. I'm arguing that whatever 
solution is provided (even a complex one) still won't make mutation 
handling straight-forward... so why not just provide the simplest 
solution and let the js libs sort out the details.


Sean

Re: Mutation Observers: a replacement for DOM Mutation Events

[Ryosuke Niwa]

On Wed, Oct 12, 2011 at 7:51 PM, Sean Hogan  wrote:
>
> It is different to event listeners. The following
>
>document.body.**addEventListener("**DOMAttrModified", handler, false);
>document.getElementById("**target").addEventListener("**DOMAttrModified",
> preferred_handler, false);
>

What prevents scripts from then doing
document.getElementById("**target").addEventListener("**DOMAttrModified",
handler, false);
?

allows preferred_handler to prevent handler receiving the event.


The problem with allowing some event observer to prevent other observers to
receive certain mutation events is that we'll then lose any
integrity guarantee once we do that. e.g. when an observer is called with
some list of mutations, you wouldn't know whether the current DOM state is
the result of those mutations or there had been some other mutations.

Without this guarantee, you can't unwind mutation lists to restore the
original DOM state for example, and it makes mutation observation useless in
some use cases.

As such, I'll be strongly opposed to allow such a prevention mechanism.

On Wed, Oct 12, 2011 at 8:14 PM, Sean Hogan  wrote:
>
> Another way of phrasing this deficiency is that the proposal provides a way
> to signal interest in mutations in regions of a page, but doesn't provide a
> way to ignore mutations within those regions. So the libs using this API may
> have to provide their own mechanism for this.


Right, and I'd argue that we should NOT provide such a mechanism.

On Thu, Oct 13, 2011 at 1:32 AM, Sean Hogan  wrote:
>
> Why do you assume that all other mutation observers should ignore such
> changes? If there's a library that's automatically syncing the document with
> a server, then such an observer certainly needs to know any mutations that
> happen in the document.
>
> - Ryosuke
>
>
> In the case of MathJax, the HTML rendering for math is generated in the
> browser. It is only the LaTeX that you would want synced on the server.
>

No, my use case addresses the case where you want to mirror the exact DOM
state (except event handlers and script elements) elsewhere. And for that to
work, I need to be able to see whatever MathJax is generating, NOT the LaTeX
code.


> - it still doesn't allow different mutation event listeners to safely
> ignore the possibility of each-other.
>

I repeat myself again that we shouldn't allow mutation observers to do this.

- Ryosuke

Re: Mutation Observers: a replacement for DOM Mutation Events

[Sean Hogan]

On 13/10/11 2:33 PM, Ryosuke Niwa wrote:
On Wed, Oct 12, 2011 at 8:14 PM, Sean Hogan > wrote:


Maybe you can provide concrete examples (i.e. with code snippets,
actual instances of use cases, etc...)


Actually, it is the proponents of changing the status-quo and of
the more complex solution who bear more responsibility for
providing these. But if it helps, here's a specific example:

MathJax (http://mathjax.org) is a js lib for rendering math in
web-pages. One feature it provides is converting LaTeX into
(typically) a HTML representation of the math. It is desirable for
the LaTeX source to remain available in the document, and MathJax
stores it as the content of a 

Re: [indexeddb] Calling IDBDatabase.close inside onupgradeneeded handler

[Jonas Sicking]

On Wednesday, October 12, 2011, Israel Hilerio 
wrote:
> On Wednesday, October 12, 2011 4:21 PM, Jonas Sicking wrote:
>> On Wed, Oct 12, 2011 at 4:06 PM, Israel Hilerio 
>> wrote:
>> > If a db connection is closed inside the onupgradeneeded handler,
section 4.1
>> step #8 states that we should return an ABORT_ERR and abort steps. This
>> implies that the transaction should fail. Since today, the db is closed
after all
>> requests have been processed, we don't see the reason why we would return
>> an error instead of just allowing the db connection to follow its natural
>> course. The worst that can happen is that we return a handle to a closed
db,
>> which is what the developer intended.
>> >
>> > Should we remove this constraint and not error out on this particular
case
>> (i.e. calling db.close from onupgradeneeded)? Or, are there reasons to
keep
>> this logic around?
>>
>> I agree, we should not abort the VERSION_CHANGE transaction.
>>
>> It'd still make sense to fire an "error" event on the request returned
from
>> indexeddb.open though, after the transaction is committed. This since the
>> database wasn't successfully opened.
>>
>> / Jonas
>
> Couldn't you make the case that it was successfully opened and therefore
you were able to run the upgrade logic.  However, the developer chose to
close it before returning from the handler.  This will provide us a pattern
to upgrade DBs without having to keep the db opened or a handle around.  It
will also help devs differentiate this pattern from a real db open problem.

My thinking was that we should only fire the success event if we can really
hand the success handler a opened database. That seems to make the open
handler easiest to implement for the web page.

If we do fire the success handler in this case, what would we hand the
handler as result? Null? A closed database? Something else?

/ Jonas