> -Original Message-
> From: whatwg-boun...@lists.whatwg.org
> [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of
> whatwg-requ...@lists.whatwg.org
> Sent: den 29 mars 2011 20:33
> To: whatwg@lists.whatwg.org
> Subject: whatwg Digest, Vol 84, Issue 69
> >> > I also believe that the re
On Tue, Mar 29, 2011 at 9:05 PM, Ian Hickson wrote:
> On Tue, 29 Mar 2011, Jer Noble wrote:
>>
>> Contained is Eric and my feedback as to the difficulty of implementing
>> this proposal in Apple's port of WebKit:
>
> Thank you very much for your feedback. I'll look into it more tomorrow
> when I u
On Tue, 29 Mar 2011, Jer Noble wrote:
>
> Contained is Eric and my feedback as to the difficulty of implementing
> this proposal in Apple's port of WebKit:
Thank you very much for your feedback. I'll look into it more tomorrow
when I update the spec, but in the meantime I had some additional
q
On 3/29/11 5:53 PM, Aryeh Gregor wrote:
So is anyone planning on actually trying to remove DOM mutation events, or not?
I think Jonas is still planning on it; we just need to implement a
replacement for them first...
Just something simple like running execCommand("bold") when "bar" is
selec
On Tue, Mar 29, 2011 at 10:34 AM, Adam Barth wrote:
> In this HyBi thread:
>
> http://www.ietf.org/mail-archive/web/hybi/current/msg06951.html
>
> Folks are arguing that the WebSocket protocol should support HTTP
> redirects during the handshake and that dealing with the security
> consequences of
On Tue, Mar 29, 2011 at 2:37 PM, Boris Zbarsky wrote:
> In theory, yes. In practice, you have to cover various edge cases (like
> what happens if the result of the insertBefore call is that the node is
> removed from the old location but NOT inserted at the new one); specifying
> this properly co
On Mar 27, 2011, at 8:01 PM, Ian Hickson wrote:
>
> It's been brought to my attention that there are aspects of the
> MediaController design that are hard to implement; in particular around
> the ability to synchronise or desynchronise media while it is playing
> back.
>
> To help with this,
On Tue, 29 Mar 2011, Wilhelm Joys Andersen wrote:
>
> The spec says:
>
> "If there is no child summary element [of the details element], the
> user agent should provide its own legend (e.g. "Details")." [1]
>
> How exactly should this legend be provided?
In the rendering.
> Should the user
On 3/29/11 2:37 PM, Boris Zbarsky wrote:
That already has to happen for
insertData()/deleteData()/appendData(), right? All browsers treat
those differently from just setting the data to the equivalent
string.
Those map directly to atomic operations on CharacterData, for what it's
worth.
Oh, I
On 3/29/11 2:19 PM, Aryeh Gregor wrote:
It would be possible to work around it by requiring that
insertBefore() and similar methods do special magic for Ranges
independent of the actual DOM mutations done, however.
In theory, yes. In practice, you have to cover various edge cases (like
what h
On Mon, Mar 28, 2011 at 7:09 PM, Ehsan Akhgari wrote:
> I was talking about the way that the spell checking dialog works in
> OpenOffice Writer, for example. The selection would be visible on the
> screen, and its contents might get changed if the user chooses to. But spell
> checking is just
On Mon, Mar 28, 2011 at 8:05 PM, Boris Zbarsky wrote:
> One problem here is that there is not a concept of "moved" in the DOM.
> There's just removed and inserted. Trying to insert something that already
> has a parent will remove it and then do the insert. Thanks to the wonders
> of mutation ev
On Tue, 29 Mar 2011, Matthew Kaufman wrote:
> On Mar 29, 2011, at 3:00 AM, Ian Hickson wrote:
> > On Thu, 24 Mar 2011, Matthew Kaufman wrote:
> >>
> >> That goal is incompatible with legacy interoperability.
> >
> > There is no legacy when it comes to UDP data media streams. This is a
> > new p
In this HyBi thread:
http://www.ietf.org/mail-archive/web/hybi/current/msg06951.html
Folks are arguing that the WebSocket protocol should support HTTP
redirects during the handshake and that dealing with the security
consequences of redirects should be dealt with at the API layer.
If/when that oc
On 03/29/2011 03:27 PM, Wilhelm Joys Andersen wrote:
Hi,
I'm currently writing tests in preparation for Opera's implementation
of and . In relation to this, I have a few questions
about issues that, as far as I can tell, are currently undefined in the
specification.
The spec says:
"If there i
> > > > !The web application must be able to!If the video
> is going to be displayed !
> > > > !define the media format to be used for !in a large
> window, use higher bit-!
> > > > !the streams sent to a peer.
> !rate/resolution. Should media settings!
> > > > !
Hi,
I'm currently writing tests in preparation for Opera's implementation
of and . In relation to this, I have a few questions
about issues that, as far as I can tell, are currently undefined in the
specification.
The spec says:
"If there is no child summary element [of the details element],
> I also believe that the recording interface should be removed from this
> part of the specification; there should be no requirement that all
> streams be recordable.
Recording of streams is needed for some use cases unrelated to video
conferencing, such as recording messages.
Having a record
On 03/29/11 03:00, Ian Hickson wrote:
On Wed, 23 Mar 2011, Harald Alvestrand wrote:
>
> Is there really an advantage to not using SRTP and reusing the RTP
> format for the data messages?
Could you elaborate on how (S)RTP would be used for this? I'm all in
favour of defering as much of this to
On 03/29/11 03:00, Ian Hickson wrote:
> It is stated that the data size can be up to 65467 bytes in "send()".
> Our network guys tell us that this is unrealistic to get over such big
> chunks using UDP.
Is that true? I thought they'd just get fragmented at the IP level, but
would still make i
On Mar 29, 2011, at 3:00 AM, Ian Hickson wrote:
>
>
> On Thu, 24 Mar 2011, Matthew Kaufman wrote:
>>
>> That goal is incompatible with legacy interoperability.
>
> There is no legacy when it comes to UDP data media streams. This is a new
> protocol, no existing servers implement it.
>
>
21 matches
Mail list logo
