On Fri, Jul 1, 2011 at 5:09 PM, Robin Berjon robin.ber...@gmail.com wrote:
On Jul 1, 2011, at 11:22 , Marcos Caceres wrote:
Want to add dereferencing model. Can be a new spec layered on top.
This would still be in scope of the charter, so it would not be an
issue to create a new spec.
I
On 03/07/11 04:52, Boris Zbarsky wrote:
On 7/2/11 2:27 PM, Dave Raggett wrote:
n.b. the current mutation events work nicely for the document editing
use cases.
Only if you have full control over the set of all registered
listeners. If you do not, you're SOL, because current mutation events
RFC2119 'Key words for use in RFCs to Indicate Requirement Levels'
defines the keyword 'SHOULD' as:
This word, or the adjective RECOMMENDED, mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
On Mon, Jul 4, 2011 at 10:47 AM, Rich Tibbett ri...@opera.com wrote:
RFC2119 'Key words for use in RFCs to Indicate Requirement Levels' defines
the keyword 'SHOULD' as:
This word, or the adjective RECOMMENDED, mean that there
may exist valid reasons in particular circumstances to ignore a
On Jul 4, 2011, at 11:47 , Rich Tibbett wrote:
Wondering if there is any set W3C thinking on this or a way of including
SHOULD tests in test suites but clearly indicating that they are, basically,
optional and do not count towards the overall compliance score? I couldn't
find anything in
Rich,
Le 4 juil. 2011 à 05:47, Rich Tibbett a écrit :
conformance testing.
and later on
implementations to claim 100% compliance
These are entirely two different things. The MUST/SHOULD or any systems of
Conformance help articulate the way the technology is organized.
The claim of being
On 7/3/2011 10:26 AM, Ryosuke Niwa wrote:
On Sun, Jul 3, 2011 at 8:41 AM, John J. Barton
johnjbar...@johnjbarton.com mailto:johnjbar...@johnjbarton.com wrote:
On 7/2/2011 8:50 PM, Boris Zbarsky wrote:
On 7/2/11 1:46 PM, John J. Barton wrote:
2) element transformation.
On 7/3/2011 1:23 PM, Boris Zbarsky wrote:
On 7/3/11 2:43 PM, John J. Barton wrote:
I'm not sure what you're asking... The whole point of the proposed
model is that if someone tries to do a mutation the mutation _will_
happen and will complete. _Then_ listeners, if any, will be notified.
Apologies in advance if my comment makes no sense. This is a long thread, I
tried to digest it all. :)
On Sat, Jul 2, 2011 at 7:07 AM, Boris Zbarsky bzbar...@mit.edu wrote:
That may be ok, if the use cases that incur this cost are rare and the
common case can be better served by a different
On 07/04/2011 07:23 PM, John J. Barton wrote:
On 7/3/2011 1:23 PM, Boris Zbarsky wrote:
On 7/3/11 2:43 PM, John J. Barton wrote:
I'm not sure what you're asking... The whole point of the proposed
model is that if someone tries to do a mutation the mutation _will_
happen and will complete.
On 07/04/2011 07:28 PM, Ojan Vafai wrote:
Apologies in advance if my comment makes no sense. This is a long
thread, I tried to digest it all. :)
On Sat, Jul 2, 2011 at 7:07 AM, Boris Zbarsky bzbar...@mit.edu
mailto:bzbar...@mit.edu wrote:
That may be ok, if the use cases that incur this
On Mon, 04 Jul 2011 11:47:22 +0200, Rich Tibbett ri...@opera.com wrote:
RFC2119 'Key words for use in RFCs to Indicate Requirement Levels'
defines the keyword 'SHOULD' as:
This word, or the adjective RECOMMENDED, mean that there
may exist valid reasons in particular circumstances to ignore
On 7/4/2011 9:38 AM, Olli Pettay wrote:
On 07/04/2011 07:23 PM, John J. Barton wrote:
On 7/3/2011 1:23 PM, Boris Zbarsky wrote:
On 7/3/11 2:43 PM, John J. Barton wrote:
I'm not sure what you're asking... The whole point of the proposed
model is that if someone tries to do a mutation the
On Mon, Jul 4, 2011 at 10:16 AM, Adam Klein ad...@chromium.org wrote:
On Mon, Jul 4, 2011 at 9:57 AM, Olli Pettay olli.pet...@helsinki.fi
wrote:
On 07/04/2011 07:28 PM, Ojan Vafai wrote:
Apologies in advance if my comment makes no sense. This is a long
thread, I tried to digest it all. :)
On 07/04/2011 09:01 PM, Dave Raggett wrote:
On 04/07/11 17:57, Olli Pettay wrote:
Mutation listener could easily
implement old/new value handling itself, especially if it knows which
attributes it is interested in.
How exactly would the listener know the previous state?
In the easiest case
On 07/05/2011 12:02 AM, Adam Klein wrote:
On Mon, Jul 4, 2011 at 1:45 PM, Olli Pettayolli.pet...@helsinki.fi wrote:
On 07/04/2011 08:16 PM, Adam Klein wrote:
On Mon, Jul 4, 2011 at 9:57 AM, Olli Pettayolli.pet...@helsinki.fi
wrote:
On 07/04/2011 07:28 PM, Ojan Vafai wrote:
The only bit
On Mon, Jul 4, 2011 at 11:01 AM, Dave Raggett d...@w3.org wrote:
How exactly would the listener know the previous state?
For a concurrent editing app, it is important to be able to describe
changes reversibly so that you can revert the DOM when a given local edit
isn't accepted, or you need
On 7/4/11 12:09 PM, John J. Barton wrote:
In the current proposal, the DOM API is manipulated while the
onModelChange mutation listeners run.
Citation please? I see nothing like that in the proposal.
In the present case, imagine that the mutation listeners have only one
function call
On 7/4/11 12:23 PM, John J. Barton wrote:
On 7/3/2011 1:23 PM, Boris Zbarsky wrote:
On 7/3/11 2:43 PM, John J. Barton wrote:
I'm not sure what you're asking... The whole point of the proposed
model is that if someone tries to do a mutation the mutation _will_
happen and will complete. _Then_
On 7/4/11 12:28 PM, Ojan Vafai wrote:
I'm not sure there really is a performance tradeoff. I believe that the
proposal Rafael put forward should almost always be faster. Storing the
list of changes and doing a JS callback once, for nearly all use-cases,
should be faster than frequent,
On 7/4/2011 6:34 PM, Boris Zbarsky wrote:
On 7/4/11 12:09 PM, John J. Barton wrote:
In the current proposal, the DOM API is manipulated while the
onModelChange mutation listeners run.
Citation please? I see nothing like that in the proposal.
On 7/4/2011 6:39 PM, Boris Zbarsky wrote:
On 7/4/11 12:23 PM, John J. Barton wrote:
By restricting mutation listeners to explicitly avoid DOM mutation, the
most sophisticated case is no different than the simple case. Then all
three can be accommodated.
If such a restriction were feasible,
22 matches
Mail list logo
