On Thu, 07 Jan 2016 20:12:44 +0100, Boris Zbarsky wrote:
On 12/18/15 3:53 AM, Simon Pieters wrote:
Note that it requires liveness. Does that work for a frozen array?
No. You'd have to create a new array object at the point when you want
to update the set of values in the array.
OK...
On 12/18/15 3:53 AM, Simon Pieters wrote:
Note that it requires liveness. Does that work for a frozen array?
No. You'd have to create a new array object at the point when you want
to update the set of values in the array.
Maybe this particular API should be a method instead that returns a
On Fri, 18 Dec 2015 18:04:27 +0100, Olli Pettay wrote:
On 12/18/2015 06:20 PM, Domenic Denicola wrote:
From: Simon Pieters [mailto:sim...@opera.com]
Note that it requires liveness. Does that work for a frozen array?
Frozen array instances are frozen and cannot change. However, you can
ha
On 12/18/2015 06:20 PM, Domenic Denicola wrote:
From: Simon Pieters [mailto:sim...@opera.com]
Note that it requires liveness. Does that work for a frozen array?
Frozen array instances are frozen and cannot change. However, you can have the
property that returns them start returning a new fro
From: Simon Pieters [mailto:sim...@opera.com]
> Note that it requires liveness. Does that work for a frozen array?
Frozen array instances are frozen and cannot change. However, you can have the
property that returns them start returning a new frozen array. The spec needs
to track when these ne
On Thu, 16 Jul 2015 18:16:04 +0200, Boris Zbarsky wrote:
Other references:
·CSS OM
Presumably this is Document.styleSheetSets? In practice, I believe no
one except Gecko implements this and I therefore don't expect it to make
it to REC... Updating this draft to use FrozenArray<> would b
On Thu, Jul 16, 2015 at 8:45 AM, Travis Leithead
wrote:
> Recommendations:
> ·HTML5
> ·Web Messaging
>
> Other references:
> ·CSS OM
> ·Web Sockets
> ·WebRTC
Note that in practice I would think that most implementations return
objects which have a .item() f
On 16 July 2015 at 09:36, Domenic Denicola wrote:
> - https://w3c.github.io/webrtc-pc/
Specifically:
https://w3c.github.io/webrtc-pc/#rtctrackevent - should be OK
https://github.com/w3c/webrtc-pc/issues/251
So in terms of concrete updates, we'd need to fix
- https://html.spec.whatwg.org/
- https://w3c.github.io/webrtc-pc/
- http://dev.w3.org/csswg/cssom/ (sigh, still no https?)
The other documents mentioned are either obsolete or forks of (sections of) the
first. Once the LS/EDs are fixed, then we
On 7/16/15 12:02 PM, cha...@yandex-team.ru wrote:
But would just abandoning T[] break anything elsewhere?
It's hard to break something that never worked. No browser ever
implemented anything for T[] to my knowledge.
-Boris
On 7/16/15 11:45 AM, Travis Leithead wrote:
Now that WebIDL has added FrozenArray<> and dropped T[], it’s time to
switch over! On the other hand, there are a number of specs that have
already gone to Rec that used the old syntax.
Note that since the old syntax was never supported by any UA in a
On Thu, Jul 16, 2015 at 6:02 PM, wrote:
> But would just abandoning T[] break anything elsewhere? Is there any value in
> having it mapped and deprecated?
If specifications were written by a team the size of a browser that
might be reasonable, but it really seems like more trouble than it's
wor
16.07.2015, 17:59, "Anne van Kesteren" :
> On Thu, Jul 16, 2015 at 5:45 PM, Travis Leithead
> wrote:
>> Should we consider keeping T[] in WebIDL, but having it map to
>> FrozenArray<>?
>
> We should just update the relevant specifications.
That seems a rational approach in any event.
But would
On Thu, Jul 16, 2015 at 5:45 PM, Travis Leithead
wrote:
> Should we consider keeping T[] in WebIDL, but having it map to FrozenArray<>?
We should just update the relevant specifications. We'll continue to
hit this as IDL still needs to evolve quite a bit.
--
https://annevankesteren.nl/
14 matches
Mail list logo
