Re: SpellCheck API?

2011-07-20 Thread 坊野 博典
Greetings web-application developers, Sorry for my slow update. I would like to post the updated version of my proposal (applied comments in this thread as much as possible) since it is not so easy to read through this thread. I would be great to correct me if I'm wrong. Regards, Hironori Bono E

Re: Mutation events replacement

2011-07-20 Thread David Flanagan
On 7/20/11 7:17 PM, Boris Zbarsky wrote: On 7/20/11 4:14 PM, Ryosuke Niwa wrote: I'm not sure if we can have a concept of atomicity in DOM. Boris might have a strong opinion on this. I don't yet. What I do have a strong opinion on is that it would be good to have some data on how common "mo

Re: Mutation events replacement

2011-07-20 Thread Boris Zbarsky
On 7/20/11 4:14 PM, Ryosuke Niwa wrote: I'm not sure if we can have a concept of atomicity in DOM. Boris might have a strong opinion on this. I don't yet. What I do have a strong opinion on is that it would be good to have some data on how common "move" operations are compared to "remove" an

Re: Mutation events replacement

2011-07-20 Thread Boris Zbarsky
On 7/20/11 4:10 PM, Bjoern Hoehrmann wrote: Simple example: you get a notification whenever a script could observe the .getAttribute value changes, and you get it before the change is applied. Right, the synchronous "will mutate" notification. Having that does simplify things. As discussed on

Re: Mutation events replacement

2011-07-20 Thread Sean Hogan
On 21/07/11 6:18 AM, David Flanagan wrote: On 7/20/11 12:11 PM, Ryosuke Niwa wrote: On Wed, Jul 20, 2011 at 11:56 AM, Aryeh Gregor mailto:simetrical%2b...@gmail.com>> wrote: On Wed, Jul 20, 2011 at 1:43 AM, David Flanagan mailto:dflana...@mozilla.com>> wrote: > Finally, I still thi

Re: Mutation events replacement

2011-07-20 Thread Jonas Sicking
On Wed, Jul 20, 2011 at 10:30 AM, Olli Pettay wrote: > On 07/20/2011 06:46 PM, Jonas Sicking wrote: > Hence I'm leaning towards using the almost-asynchronous proposal for now. If we end up getting the feedback from people that use mutation events today that they won't be able to sol

Re: [IndexedDB] setVersion is cra... is not good

2011-07-20 Thread Jonas Sicking
On Wed, Jul 20, 2011 at 1:33 PM, Israel Hilerio wrote: > On Monday, July 18, 2011 10:50 AM, Jonas Sicking wrote: >> On Mon, Jul 18, 2011 at 10:20 AM, Israel Hilerio >> wrote: >> > On Sunday, July 17, 2011 1:46 PM, Jonas Sicking wrote: >> >> On Fri, Jul 15, 2011 at 5:55 PM, Israel Hilerio >> wrot

Re: Mutation events replacement

2011-07-20 Thread Ojan Vafai
On Wed, Jul 20, 2011 at 10:30 AM, Olli Pettay wrote: > On 07/20/2011 06:46 PM, Jonas Sicking wrote: > > Hence I'm leaning towards using the almost-asynchronous proposal for now. If we end up getting the feedback from people that use mutation events today that they won't be able to solve

Re: Mutation events replacement

2011-07-20 Thread David Flanagan
On 7/19/11 4:01 PM, Jonas Sicking wrote: 'listener' above would be a function which receives a single argument when notifications fire. The value of this argument would be an Array which could look something like this: [ { target: node1, type: "childlist", added: [a, b, c, d], removed: [x, y] },

RE: [IndexedDB] setVersion is cra... is not good

2011-07-20 Thread Israel Hilerio
On Monday, July 18, 2011 10:50 AM, Jonas Sicking wrote: > On Mon, Jul 18, 2011 at 10:20 AM, Israel Hilerio > wrote: > > On Sunday, July 17, 2011 1:46 PM, Jonas Sicking wrote: > >> On Fri, Jul 15, 2011 at 5:55 PM, Israel Hilerio > wrote: > >> > Jonas, > >> > > >> > We like the concepts and princip

Re: Mutation events replacement

2011-07-20 Thread Ryosuke Niwa
On Tue, Jul 19, 2011 at 8:23 PM, Boris Zbarsky wrote: > On 7/19/11 7:18 PM, > Ryosuke Niwa > Software Engineer > Google Inc. > > > wrote: > >> For editing purposes, it's also crucial to know from/to where nodes are >> removed/inserted. It seems like adding an offset trivially solves this >> prob

Re: Mutation events replacement

2011-07-20 Thread David Flanagan
On 7/20/11 12:11 PM, Ryosuke Niwa wrote: On Wed, Jul 20, 2011 at 11:56 AM, Aryeh Gregor mailto:simetrical%2b...@gmail.com>> wrote: On Wed, Jul 20, 2011 at 1:43 AM, David Flanagan mailto:dflana...@mozilla.com>> wrote: > Finally, I still think it is worth thinking about trying to

Re: Mutation events replacement

2011-07-20 Thread Ryosuke Niwa
On Wed, Jul 20, 2011 at 12:53 PM, David Flanagan wrote: > On 7/20/11 12:11 PM, Ryosuke Niwa wrote: > > But internally, a node movement is a removal then an insertion. There's > always possibility that a node gets removed then inserted again after > mutation observers are invoked. Also, what ha

Re: Mutation events replacement

2011-07-20 Thread Bjoern Hoehrmann
* Boris Zbarsky wrote: >On 7/20/11 2:19 PM, Bjoern Hoehrmann wrote: >> Depending on the design of the mutation notification system and what >> level of complexity people find palatable, it would naturally also be >> possible to serialize lazily > >The only way to do that is to make sure the pre-mut

Re: Mutation events replacement

2011-07-20 Thread Ryosuke Niwa
On Wed, Jul 20, 2011 at 11:56 AM, Aryeh Gregor wrote: > On Wed, Jul 20, 2011 at 1:43 AM, David Flanagan > wrote: > > Finally, I still think it is worth thinking about trying to model the > > distinction between removing nodes from the document tree and moving them > > (atomically) within the tree

Re: Mutation events replacement

2011-07-20 Thread Aryeh Gregor
On Wed, Jul 20, 2011 at 1:43 AM, David Flanagan wrote: > Finally, I still think it is worth thinking about trying to model the > distinction between removing nodes from the document tree and moving them > (atomically) within the tree. I'll chip in that I think this is useful. It makes things som

Re: Mutation events replacement

2011-07-20 Thread Boris Zbarsky
On 7/20/11 2:19 PM, Bjoern Hoehrmann wrote: It's pretty common to have situations where lots (10-20) of properties are set in inline style, especially in cases where the inline style is being changed via CSS2Properties from script (think animations and the like, where the objects being animated t

Re: Mutation events replacement

2011-07-20 Thread Bjoern Hoehrmann
* Boris Zbarsky wrote: >It's pretty common to have situations where lots (10-20) of properties >are set in inline style, especially in cases where the inline style is >being changed via CSS2Properties from script (think animations and the >like, where the objects being animated tend to have widt

Re: Mutation events replacement

2011-07-20 Thread Olli Pettay
On 07/20/2011 06:46 PM, Jonas Sicking wrote: Hence I'm leaning towards using the almost-asynchronous proposal for now. If we end up getting the feedback from people that use mutation events today that they won't be able to solve the same use cases, then we can consider using the synchronous noti

Re: Mutation events replacement

2011-07-20 Thread Boris Zbarsky
On 7/20/11 11:43 AM, Dave Raggett wrote: Perhaps we need to distinguish auto generated attributes from those that are set by markup or scripts. I'm not sure what you mean. Could you please clarify for me the difference between the html "style" attribute and the one you are referring to? The

Re: Mutation events replacement

2011-07-20 Thread Bjoern Hoehrmann
* Dave Raggett wrote: >Perhaps we need to distinguish auto generated attributes from those that >are set by markup or scripts. Could you please clarify for me the >difference between the html "style" attribute and the one you are >referring to? My understanding is that the html style attribute

Re: Mutation events replacement

2011-07-20 Thread Ryosuke Niwa
On Wed, Jul 20, 2011 at 9:32 AM, Dave Raggett wrote: > > Isn't there a cheap way to distinguish changes to the DOM (setAttribute) > from indirect changes to how CSSMutableStyleDeclaration is formatted to > text? It sounds as if you already have a setter function that knows how to > update the CS

Re: Mutation events replacement

2011-07-20 Thread Dave Raggett
On 20/07/11 17:05, Ryosuke Niwa wrote: On Wed, Jul 20, 2011 at 8:43 AM, Dave Raggett > wrote: Perhaps we need to distinguish auto generated attributes from those that are set by markup or scripts. Could you please clarify for me the difference between the html "st

Re: Global variables and id lookup for elements

2011-07-20 Thread Garrett Smith
On 7/19/11, Cameron McCormack wrote: > Ian Hickson: >> Is this still something I should do, or did this get resolved using >> another solution? > > http://www.w3.org/Bugs/Public/show_bug.cgi?id=8241 > > The proposed solution I made in the bug was to have the [[Get]] etc. > internal methods of Wind

Re: Mutation events replacement

2011-07-20 Thread Ryosuke Niwa
On Wed, Jul 20, 2011 at 8:43 AM, Dave Raggett wrote: > > Perhaps we need to distinguish auto generated attributes from those that > are set by markup or scripts. Could you please clarify for me the difference > between the html "style" attribute and the one you are referring to? My > understandin

Re: Mutation events replacement

2011-07-20 Thread Jonas Sicking
On Wed, Jul 20, 2011 at 5:20 AM, Olli Pettay wrote: > On 07/20/2011 02:01 AM, Jonas Sicking wrote: >> >> On Thu, Jul 7, 2011 at 6:38 PM, Jonas Sicking  wrote: >>> >>> On Thu, Jul 7, 2011 at 5:23 PM, Rafael Weinstein >>>  wrote: > > So yes, my proposal only solves the usecase outside mutati

Re: Mutation events replacement

2011-07-20 Thread Dave Raggett
On 20/07/11 16:32, Boris Zbarsky wrote: On 7/20/11 4:26 AM, Dave Raggett wrote: You note that style attributes may be long as an argument against permitting applications to see the before value. The problem is not the length per se. The problem is that the value is not stored anywhere and h

Re: Mutation events replacement

2011-07-20 Thread Boris Zbarsky
On 7/20/11 4:26 AM, Dave Raggett wrote: You note that style attributes may be long as an argument against permitting applications to see the before value. The problem is not the length per se. The problem is that the value is not stored anywhere and has to be generated based on other data s

Re: Global variables and id lookup for elements

2011-07-20 Thread Allen Wirfs-Brock
To follow up, this issue is https://bugs.ecmascript.org/show_bug.cgi?id=78 On Jul 19, 2011, at 7:44 PM, Allen Wirfs-Brock wrote: > > On Jul 19, 2011, at 6:47 PM, Boris Zbarsky wrote: > >> On 7/19/11 7:43 PM, Ian Hickson wrote: >>> On Thu, 28 Apr 2011, Magnus Kristiansen wrote: Conte

CfC: publish Proposed Recommendation of view-mode Media Feature; deadline July 27

2011-07-20 Thread Arthur Barstow
As mentioned in [1], the exit criteria of the view-mode Media Feature Candidate Recommendation [2] has been met (at least two implementations pass every test): http://dev.w3.org/2006/waf/widgets-vmmf/imp-report/ As such, this is Call for Consensus to publish a Proposed Recommendation (PR) o

Re: Seeking view-mode Media Feature implementation data

2011-07-20 Thread Arthur Barstow
FYI, Marcos now has sufficient data to meet the CR's exit criteria and to move this spec to Proposed Recommendation: http://dev.w3.org/2006/waf/widgets-vmmf/imp-report/ On 7/19/11 9:46 AM, ext Arthur Barstow wrote: [ Bcc www-style ] Marcos is gathering and organizing implementation data for t

Re: Mutation events replacement

2011-07-20 Thread Olli Pettay
On 07/20/2011 02:01 AM, Jonas Sicking wrote: On Thu, Jul 7, 2011 at 6:38 PM, Jonas Sicking wrote: On Thu, Jul 7, 2011 at 5:23 PM, Rafael Weinstein wrote: So yes, my proposal only solves the usecase outside mutation handlers. However this is arguably better than never solving the use case as i

Re: Mutation events replacement

2011-07-20 Thread Dave Raggett
On 20/07/11 00:56, Jonas Sicking wrote: On Tue, Jul 19, 2011 at 4:18 PM, Ryosuke Niwa wrote: For editing purposes, it's also crucial to know from/to where nodes are removed/inserted. It seems like adding an offset trivially solves this problem without much overhead. I'm not really sure how yo

Re: Mutation events replacement

2011-07-20 Thread Dave Raggett
Thanks Jonas for the proposal. For changes to attributes and changes to the value of text nodes, it should be possible to applications to request to see the before/after values. You note that style attributes may be long as an argument against permitting applications to see the before value. B