Re: [WebIDL] T[] migration

[Simon Pieters]

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...


Maybe this particular API should be a method instead that returns a
sequence?


Will that cause anyone to implement it?  Because if no one is planning  
to ever implement it, it should probably be removed, not twiddled.


Yes, you're right. Removed.

https://github.com/w3c/csswg-drafts/commit/e5353d078e686136fdb28c7de37ffd375cd6d79f
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29471

--
Simon Pieters
Opera Software

Re: [WebIDL] T[] migration

[Boris Zbarsky]

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
sequence?


Will that cause anyone to implement it?  Because if no one is planning 
to ever implement it, it should probably be removed, not twiddled.


-Boris

Re: [WebIDL] T[] migration

[Simon Pieters]

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  
have the property that returns them start returning a new frozen array.  
The spec needs to track when these new instances are created.



Changing the array object wouldn't be backwards compatible.
(The attribute used to be DOMStringList)

Maybe this particular API should be a method instead that returns a  
sequence?

Also not backwards compatible.

But I'd assume the first option (changing the array) would be less  
backwards incompatible, so I'd prefer that one.


OK, but... Document#styleSheetSets is not widely implemented, and appears  
to not be widely used. On github I see 80 code matches in javascript,  
where most are just listing stuff, some are browser sniffing, and some  
might be actual usage (maybe with a fallback for other browsers?).  
Although it has been implemented in Gecko for a long time, I think it is  
possible to make incompatible changes (or maybe drop altogether).


--
Simon Pieters
Opera Software

Re: [WebIDL] T[] migration

[Simon Pieters]

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 be possible,  
of course.


Fixed in  
https://github.com/w3c/csswg-drafts/commit/e8a91deb46b670d6c2d8d302492a64222928d08a


Note that it requires liveness. Does that work for a frozen array?

Maybe this particular API should be a method instead that returns a  
sequence?


--
Simon Pieters
Opera Software

RE: [WebIDL] T[] migration

[Domenic Denicola]

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 new instances are created.

> Maybe this particular API should be a method instead that returns a 
> sequence?

That does seem potentially better... Either could work, I think?

Re: [WebIDL] T[] migration

[Olli Pettay]

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 frozen array. The spec needs 
to track when these new instances are created.


Changing the array object wouldn't be backwards compatible.
(The attribute used to be DOMStringList)


Maybe this particular API should be a method instead that returns a 
sequence?

Also not backwards compatible.

But I'd assume the first option (changing the array) would be less backwards 
incompatible, so I'd prefer that one.




That does seem potentially better... Either could work, I think?

Re: [WebIDL] T[] migration

[Martin Thomson]

On 16 July 2015 at 09:36, Domenic Denicola d...@domenic.me 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

Re: [WebIDL] T[] migration

[Boris Zbarsky]

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

RE: [WebIDL] T[] migration

[Domenic Denicola]

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 can let The Process take over and 
worry about the copy-and-pasting/errata/etc., but getting the LS/EDs right is 
the important part for implementers.

Note that FrozenArrayT is not a drop-in replacement for T[]. In particular, 
T[] is read-only by authors but mutable by UAs, whereas FrozenArrayT is 
immutable. This might make things trickier.

---

From: Travis Leithead [mailto:travis.leith...@microsoft.com] 
Sent: Thursday, July 16, 2015 11:45
To: public-webapps; Ian Hickson
Subject: [WebIDL] T[] migration

Hey folks, 

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.

Recommendations:
• HTML5
• Web Messaging

Other references:
• CSS OM
• Web Sockets
• WebRTC

Legacy/Deprecated references:
• TypedArrays (replaced by ES2015)
• Web Intents

Thoughts on what to do about this? Should we consider keeping T[] in WebIDL, 
but having it map to FrozenArray? Should we issue errata to those Recs?

Re: [WebIDL] T[] migration

[Boris Zbarsky]

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 any 
meaningful way I'm aware of, those are basically problems in those specs 
that should technically have prevented them from going to REC (due to 
lack of two interoperable implementations).


Looking at the uses of IDL arrays in the relevant specs (links would 
have helped!):



Recommendations:
·HTML5


Assuming we're talking about 
http://www.w3.org/TR/2014/REC-html5-20141028/single-page.html, I don't 
see any uses of IDL arrays in this specification.  Am I missing something?



·Web Messaging


I'm not sure which specification this is referring to...


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 be possible, 
of course.



·Web Sockets


I assume we're talking about 
http://www.w3.org/TR/2012/CR-websockets-20120920/.  This is just buggy 
and needs to be fixed as should 
https://html.spec.whatwg.org/multipage/comms.html#the-websocket-interface; 
it's using an IDL array as an argument, which is pretty much never 
what's desired even back in the world where IDL arrays existed. 
Certainly it's not desired here.  What Gecko ships is a sequence 
argument instead.  I just checked, and so does Blink.  So does WebKit. 
What do Trident and Edge do?


Note that this is tracked by 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28102 at least.



·WebRTC


Are we talking about http://www.w3.org/TR/2015/WD-webrtc-20150210/?  I 
don't see usage of IDL arrays here.



Legacy/Deprecated references:

·TypedArrays (replaced by ES2015)


This has no bearing on reality; we should just mark it so somehow and 
move on.  IDL arrays are hardly the only problem in this document...



·Web Intents


This could use some mix of FrozenArray and sequence.  But does anyone 
care about this document?


-Boris

Re: [WebIDL] T[] migration

[Anne van Kesteren]

On Thu, Jul 16, 2015 at 5:45 PM, Travis Leithead
travis.leith...@microsoft.com 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/

Re: [WebIDL] T[] migration

[chaals]

16.07.2015, 17:59, Anne van Kesteren ann...@annevk.nl:
 On Thu, Jul 16, 2015 at 5:45 PM, Travis Leithead
 travis.leith...@microsoft.com 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 just abandoning T[] break anything elsewhere? Is there any value in 
having it mapped and deprecated?

cheers

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
cha...@yandex-team.ru - - - Find more at http://yandex.com

Re: [WebIDL] T[] migration

[Anne van Kesteren]

On Thu, Jul 16, 2015 at 6:02 PM,  cha...@yandex-team.ru 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
worth.


-- 
https://annevankesteren.nl/

Re: [WebIDL] T[] migration

[Jonas Sicking]

On Thu, Jul 16, 2015 at 8:45 AM, Travis Leithead
travis.leith...@microsoft.com 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() function on them. So replacing with just
a plain FrozenArrayT likely would not be web compatible :(

We likely need to introduce something like FrozenArrayWithItemT
which returns a subclass of Array that has a .item function.

Or we need to add Array.prototype.item, but that would require
convincing TC39 that that's a good idea, and would need testing for
web compatibility.

/ Jonas