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.
On 20/07/11 00:56, Jonas Sicking wrote:
On Tue, Jul 19, 2011 at 4:18 PM, Ryosuke Niwarn...@webkit.org 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
On 07/20/2011 02:01 AM, Jonas Sicking wrote:
On Thu, Jul 7, 2011 at 6:38 PM, Jonas Sickingjo...@sicking.cc wrote:
On Thu, Jul 7, 2011 at 5:23 PM, Rafael Weinsteinrafa...@google.com wrote:
So yes, my proposal only solves the usecase outside mutation handlers.
However this is arguably better
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
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)
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:
Context:
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
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
On Wed, Jul 20, 2011 at 5:20 AM, Olli Pettay olli.pet...@helsinki.fi wrote:
On 07/20/2011 02:01 AM, Jonas Sicking wrote:
On Thu, Jul 7, 2011 at 6:38 PM, Jonas Sickingjo...@sicking.cc wrote:
On Thu, Jul 7, 2011 at 5:23 PM, Rafael Weinsteinrafa...@google.com
wrote:
So yes, my proposal only
On Wed, Jul 20, 2011 at 8:43 AM, Dave Raggett d...@w3.org 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
On 7/19/11, Cameron McCormack c...@mcc.id.au 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
On 20/07/11 17:05, Ryosuke Niwa wrote:
On Wed, Jul 20, 2011 at 8:43 AM, Dave Raggett d...@w3.org
mailto:d...@w3.org 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
On Wed, Jul 20, 2011 at 9:32 AM, Dave Raggett d...@w3.org 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
* 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 is
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?
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
* 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 width,
On Wed, Jul 20, 2011 at 1:43 AM, David Flanagan dflana...@mozilla.com 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.
* 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-mutation
On Wed, Jul 20, 2011 at 12:53 PM, David Flanagan dflana...@mozilla.comwrote:
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
On 7/20/11 12:11 PM, Ryosuke Niwa wrote:
On Wed, Jul 20, 2011 at 11:56 AM, Aryeh Gregor
simetrical+...@gmail.com mailto:simetrical%2b...@gmail.com wrote:
On Wed, Jul 20, 2011 at 1:43 AM, David Flanagan
dflana...@mozilla.com mailto:dflana...@mozilla.com wrote:
Finally, I still
On Tue, Jul 19, 2011 at 8:23 PM, Boris Zbarsky bzbar...@mit.edu 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
On Monday, July 18, 2011 10:50 AM, Jonas Sicking wrote:
On Mon, Jul 18, 2011 at 10:20 AM, Israel Hilerio isra...@microsoft.com
wrote:
On Sunday, July 17, 2011 1:46 PM, Jonas Sicking wrote:
On Fri, Jul 15, 2011 at 5:55 PM, Israel Hilerio isra...@microsoft.com
wrote:
Jonas,
We like
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] },
On Wed, Jul 20, 2011 at 10:30 AM, Olli Pettay olli.pet...@helsinki.fiwrote:
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
On Wed, Jul 20, 2011 at 1:33 PM, Israel Hilerio isra...@microsoft.com wrote:
On Monday, July 18, 2011 10:50 AM, Jonas Sicking wrote:
On Mon, Jul 18, 2011 at 10:20 AM, Israel Hilerio isra...@microsoft.com
wrote:
On Sunday, July 17, 2011 1:46 PM, Jonas Sicking wrote:
On Fri, Jul 15, 2011 at
On Wed, Jul 20, 2011 at 10:30 AM, Olli Pettay olli.pet...@helsinki.fi 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
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
simetrical+...@gmail.com mailto:simetrical%2b...@gmail.com wrote:
On Wed, Jul 20, 2011 at 1:43 AM, David Flanagan
dflana...@mozilla.com
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
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
30 matches
Mail list logo
