Aryeh Gregor , 2011-08-04 14:22 -0400:
> On Wed, Aug 3, 2011 at 5:06 PM, Ehsan Akhgari wrote:
> > Is it possible to get a unique QA contact (or default CC address) for this
> > component please, so that people who are interested in watching it can watch
> > that email address instead of member-we
On Fri, Aug 5, 2011 at 5:17 PM, Ryosuke Niwa wrote:
> On Fri, Aug 5, 2011 at 5:06 PM, Jonas Sicking wrote:
>> For example in the collaborative editing case I would think that the
>> page generally wants to get a semantic understanding of the editing
>> operations so that it can reapply them even
On Fri, Aug 5, 2011 at 5:06 PM, Jonas Sicking wrote:
>
> Though I guess you can always supply the same function for apply and
> reapply, but that means you can't use the convenient inline syntax
> that you've used in your examples.
>
> Or does 'reapply' default to the 'apply' function if it's not
On Fri, Aug 5, 2011 at 8:43 AM, Aryeh Gregor wrote:
> On Fri, Aug 5, 2011 at 1:57 AM, Jonas Sicking wrote:
>> It would make sense to me to match ES here. The main concern is of
>> course website compat. Could someone detail what the differences would
>> be compared to what implementations/the HTM
On Fri, Aug 5, 2011 at 2:40 PM, Ryosuke Niwa wrote:
> On Fri, Aug 5, 2011 at 1:59 PM, Jonas Sicking wrote:
>>
>> > In the case of collaborative editing apps, reapply is different from
>> > apply because the backend server may have a tree of transaction history and
>> > may need to consult on dema
On Tue, Aug 2, 2011 at 8:31 PM, Ryosuke Niwa wrote:
> I've read a part of sections 7 and 8 but I've kind of lost here. The spec
> is very detailed and I can't really get a high-level view of what will
> happen. It might be helpful to have some high-level summary of what it
> tries to do for each
2011/8/3 Kornel Lesiński :
> On Wed, 03 Aug 2011 16:26:41 +0100, Tab Atkins Jr.
> wrote:
>
What do you think?
>>>
>>> Implementing this seems rather complicated for such a niche use. It also
>>> seems better to let sites handle this by themselves so these physical
>>> codes can evolve more ea
On Fri, Aug 5, 2011 at 1:59 PM, Jonas Sicking wrote:
> > In the case of collaborative editing apps, reapply is different from
> apply because the backend server may have a tree of transaction history and
> may need to consult on demand in order to determine exactly what mutations
> have to happe
>> Why is there a need for a 'reapply' action? How is it different from
>> the 'apply' action?
>
>
> In the case of collaborative editing apps, reapply is different from apply
> because the backend server may have a tree of transaction history and may
> need to consult on demand in order to deter
On Fri, Aug 5, 2011 at 2:24 PM, Boris Zbarsky wrote:
> On 8/5/11 1:59 PM, Aryeh Gregor wrote:
>>
>> Yeah, it's a problem. The basic issue is that there are no standard
>> interfaces to query things like "what's the height of this?"
>
> That depends on how you define "height" (esp when clearance i
On 8/5/11 1:59 PM, Aryeh Gregor wrote:
Yeah, it's a problem. The basic issue is that there are no standard
interfaces to query things like "what's the height of this?"
That depends on how you define "height" (esp when clearance is involved).
or "are these two nodes in the same line box?"
T
On Thu, Aug 4, 2011 at 5:22 PM, Ryosuke Niwa wrote:
> I see. It's an interesting point. In WebKit, we're quite inconsistent in
> relying on CSS/rendering engine and pure DOM. This is an inherent issue in
> RTE because user would like the editor to work like WYSIWYG yet we have to
> produce conf
The current description of draw*FocusRing does not have "inform the
user" in the correct priority.
It currently follows cases where the user should be informed, but the
steps have been aborted.
Please review the following an provide feedback. This attempts to serve
the use cases put
forward fo
On Fri, Aug 5, 2011 at 10:01 AM, Ryosuke Niwa wrote:
> On Fri, Aug 5, 2011 at 9:57 AM, Jonas Sicking wrote:
>>
>> Why treat documentElement specially here? Just make the documentElement
>> *not* have a undoManager by default and have it just use it's ancestor's,
>> just like all other elements.
>
On Fri, Aug 5, 2011 at 9:57 AM, Jonas Sicking wrote:
> Why treat documentElement specially here? Just make the documentElement
> *not* have a undoManager by default and have it just use it's ancestor's,
> just like all other elements.
>
> The document is an ancestor of the documentElement after a
On Aug 4, 2011 5:31 PM, "Ryosuke Niwa" wrote:
>
> On Wed, Aug 3, 2011 at 2:46 PM, Anne van Kesteren
wrote:
>>
>> On Wed, 03 Aug 2011 23:40:27 +0200, Ryosuke Niwa
wrote:
>>>
>>> On Wed, Aug 3, 2011 at 2:36 PM, Anne van Kesteren
wrote:
If they are identical I think it is even more clear
On Fri, Aug 5, 2011 at 1:57 AM, Jonas Sicking wrote:
> It would make sense to me to match ES here. The main concern is of
> course website compat. Could someone detail what the differences would
> be compared to what implementations/the HTML5 spec do now?
As far as I know, the only difference bet
On Fri, 05 Aug 2011 02:31:10 +0200, Ryosuke Niwa wrote:
Not sure. This happens all the time in design mode. We've had plenty of
crash reports that only reproduce when there are no document element.
It might also be hard to implement such a behavior in WebKit at least
because documents / frame
18 matches
Mail list logo
