[Bug 27785] [Shadow]: broken link in draft spec section 9.3
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27785 Hayato Ito changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Hayato Ito --- Thank you. Fixed in https://github.com/w3c/webcomponents/commit/416ad0180985619984546b5ad5aa0843aa3c5bd3 -- You are receiving this mail because: You are on the CC list for the bug.
Re: Custom element lifecycle callbacks
On Thu, Jan 8, 2015 at 7:56 AM, Anne van Kesteren wrote: > 1) Can we use symbols to identify these instead? That gives us a > guarantee they won't be used for other things and makes it somewhat > safer to put them where they are located now. > As Dimitri noted, I've expressed mild concerns about this in the past, but I may be coming around to the idea. The main advantage of using Symbols is that it would guarantee us the ability to add new callbacks in the future without fear of breaking existing elements, though I don't know how realistic a concern that is given the "Callback" suffix all these names have. Do you have a proposal for where these symbols would be vended? In ES, builtin symbols are available as properties on the Symbol object, but clearly WebIDL shouldn't be adding things there. This might be a good question for public-script-coord. - Adam
Re: PSA: Indexed Database API is a W3C Recommendation
\o/ On Thu, Jan 8, 2015 at 12:20 PM, Arthur Barstow wrote: > Congratulations All! This was a job very well done. > > On 1/8/15 2:37 PM, Coralie Mercier wrote: >> >> It is my pleasure to announce that Indexed Database API is published as >> a W3C Recommendation >> http://www.w3.org/TR/2015/REC-IndexedDB-20150108/ >> >> This specification defines an API for a database of records holding >> simple values and hierarchical objects. >> >> All Members who responded to the Call for Review [1] of the Proposed >> Recommendation supported the publication of this specification as a >> W3C Recommendation, or abstained. >> >> Please join us in thanking the Web Applications Working Group [2] >> for their achievement. >> >> This announcement follows section 8.1.2 [3] of the W3C Process Document. >> >> For Tim Berners-Lee, Director, >> Philippe Le Hegaret, Interaction Domain Lead, >> Xiaoqian Wu, Team Contact, >> Yves Lafon, Team contact; >> Coralie Mercier, W3C Communications >> >> [1] https://www.w3.org/2002/09/wbs/33280/IndexedDB-PR/results >> [2] https://www.w3.org/2008/webapps/ >> [3] https://www.w3.org/2014/Process-20140801/#ACReviewAfter > >
PSA: Indexed Database API is a W3C Recommendation
Congratulations All! This was a job very well done. On 1/8/15 2:37 PM, Coralie Mercier wrote: It is my pleasure to announce that Indexed Database API is published as a W3C Recommendation http://www.w3.org/TR/2015/REC-IndexedDB-20150108/ This specification defines an API for a database of records holding simple values and hierarchical objects. All Members who responded to the Call for Review [1] of the Proposed Recommendation supported the publication of this specification as a W3C Recommendation, or abstained. Please join us in thanking the Web Applications Working Group [2] for their achievement. This announcement follows section 8.1.2 [3] of the W3C Process Document. For Tim Berners-Lee, Director, Philippe Le Hegaret, Interaction Domain Lead, Xiaoqian Wu, Team Contact, Yves Lafon, Team contact; Coralie Mercier, W3C Communications [1] https://www.w3.org/2002/09/wbs/33280/IndexedDB-PR/results [2] https://www.w3.org/2008/webapps/ [3] https://www.w3.org/2014/Process-20140801/#ACReviewAfter
Re: Custom element lifecycle callbacks
On 1/8/15 10:56 AM, Anne van Kesteren wrote:
2) For normal elements we act directly when they are cloned or
adopted. How much interest is there in delaying what happens for
normal elements to align them with custom elements?
Which things are we talking about delaying?
I'm pretty sure the prototype change that happens in Gecko on adopt
right now is part of our security model and can't easily be delayed.
The other main thing that happens sync on clone is state propagation
(e.g. copying of values for inputs, right)? There are some security
considerations there too that would need to be considered for every bit
of state that's propagated; consider:
var input = document.createElement("input");
input.value = "file:///etc/passwd";
var newInput = input.cloneNode();
newInput.type = "file";
I would like to see an actual list of the things we're considering
delaying so we can think about the implications of doing that.
-Boris
Re: Custom element lifecycle callbacks
On Thu, Jan 8, 2015 at 7:56 AM, Anne van Kesteren wrote: > 1) Can we use symbols to identify these instead? That gives us a > guarantee they won't be used for other things and makes it somewhat > safer to put them where they are located now. > cc'ing a few folks I heard expressing an opinion on this. > > 2) For normal elements we act directly when they are cloned or > adopted. How much interest is there in delaying what happens for > normal elements to align them with custom elements? > I am interested in at least trying. I think Domenic is too. :DG<
Custom element lifecycle callbacks
1) Can we use symbols to identify these instead? That gives us a guarantee they won't be used for other things and makes it somewhat safer to put them where they are located now. 2) For normal elements we act directly when they are cloned or adopted. How much interest is there in delaying what happens for normal elements to align them with custom elements? -- https://annevankesteren.nl/
[Manifest] Navigation Scope is unclear
Hi, I'm trying to understand the navigation scope section of the manifest spec. More or less all the links are circular references, which isn't making it any clearer. An example or two would really help... cheers -- Charles McCathie Nevile - web standards - CTO Office, Yandex cha...@yandex-team.ru - - - Find more at http://yandex.com
