[W3C TCP and UDP Socket API] Informal CfC on moving the SysApps TCP and UDP Socket APi to a Community Group
The SysApps WG charter expired Oct 1 2014 and no re-chartering process is in progress. Similar to Wayne Carr's CfC on Intel's SysApps specification, https://lists.w3.org/Archives/Public/public-sysapps/2015Mar/0001.html, I am issuing an informal CfC on moving the SysApps TCP and UDP Socket API to a Community Group. The latest version of the TCP and UDP Socket API is: http://www.w3.org/2012/sysapps/tcp-udp-sockets/. The main reason why moving to a Community Group, instead of a Working Group, is proposed is that the original assumption for this API was a secure Web System Applications Runtime, standardized by the SysApps WG. As this has not been defined the main issue with the TCP and UDP Socket API is security, i.e. it does not fit with the Web Security model as it is defined today. However, in the current version of the API there is defined an approach to meet this issue, see https://lists.w3.org/Archives/Public/public-sysapps/2015Apr/0001.html for more information. The purpose of this informal CfC is to determine consensus on the following proposition: The members of the SysApps WG do not object to moving the TCP and UDP Socket API to a Community Group where other Community Groups or anyone outside W3C would be allowed to take and develop them (as allowed by the Community Group Contributor License Agreement). Please respond be end of day 24 April 2014. As usual in a CfC, silence is considered agreement with the proposal, but a direct response is preferred. It would be very helpful to express any objection. Best regards Claes Nilsson Master Engineer - Web Research Advanced Application Lab, Technology Sony Mobile Communications Tel: +46 70 55 66 878 claes1.nils...@sonymobile.commailto:firstname.lastn...@sonymobile.com sonymobile.comhttp://sonymobile.com/ [cid:image003.png@01D0769A.D6CA7CE0]
Re: WebIDL Plans
On 10 Apr 2015, at 18:49, Boris Zbarsky bzbar...@mit.edu wrote: On 4/10/15 8:53 AM, Yves Lafon wrote: * Everything from old v1 expect ArrayClass which is not used, nor implemented anywhere. It's implemented in Gecko and used for both DOMRectList and MediaList in Gecko, fwiw. I'm not saying we should include it, just correcting the factual statement. I remember ArrayClass removed from NodeList for the reason of lack of implementations, and even plans for implementation, glad to see it’s not dead, and I indeed missed CSSOM when I checked what parts of IDL was used in some specifications. At least it means there is no need to remove ArrayClass from the edcopy :) * Add PromiseT, Iterators, NewObject, Dictionary constructors, Buffer types (USVString and ByteString as well, depending on their status) This is pretty hard to evaluate for me coming from the perspective of knowing what's in v2. Which things are _not_ included then? maplike/setlike, right? Anything else? Currently maplike/setlike/ RegExp [Unscopeable] [PrimaryGlobal] [ImplicitThis], most probably iterable. But of course this is also subject to the number of bugs attached to them, issues with test etc... So many things will still be considered “at risk”. I didn’t see any trace of [ImplicitThis] either, so that will make it hard to test (the Window interface given in the example is no longer using it). Is someone actually using dictionary constructors somewhere? Are they implemented by anyone? Ah indeed no, and now I wonder why I added it in my list… (so as no specs seems to use them, I don’t think there are implementations around). -- Baroula que barouleras, au tiéu toujou t'entourneras. ~~Yves
Re: PSA: Seeking feedback on W3C's Modern Tooling project
On 14 April 2015 at 14:29, Arthur Barstow art.bars...@gmail.com wrote: [Bcc public-openw3c ] Hi All, In case you missed it, last February, Robin, Philippe and others (see [1] for a list of contributors) started a project to capture the state of the discussion about modernising the tooling that supports the making of W3C standards. The working document is http://w3c.github.io/modern-tooling/ and the repository is https://github.com/w3c/modern-tooling. This is an important effort so if you have feedback, please use the project's Issues system https://github.com/w3c/modern-tooling/issues or submit a Pull Request https://github.com/w3c/modern-tooling/pulls. I'm currently using a nice tool to document my projects: https://github.com/csarven/linked-research I mention it here because it has a variety of style sheets. It can be a regular blog post, a W3C base/draft/rec specification, or an academic paper by clicking the menu at the top right. It doesnt require external tooling. Going from zero I was able to get a skeleton up in about 30 minutes. I find it useful for knocking out a quick brain dump, which could later become the basis of brain storming, or specifications. -Thanks, ArtB P.S. PSA = Public Service Announcement [1] https://github.com/w3c/modern-tooling/graphs/contributors
[Bug 28491] New: [Shadow]: [Meta] Unblock Mozilla's shipping of Shadow DOM
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28491 Bug ID: 28491 Summary: [Shadow]: [Meta] Unblock Mozilla's shipping of Shadow DOM Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: dglaz...@chromium.org QA Contact: public-webapps-bugzi...@w3.org CC: ann...@annevk.nl, m...@w3.org, public-webapps@w3.org Blocks: 14978 This is a meta bug for everything Mozilla needs to be addressed in spec before shipping Shadow DOM. -- You are receiving this mail because: You are on the CC list for the bug.
Re: WebIDL Plans
On 4/14/15 8:22 AM, Yves Lafon wrote: I remember ArrayClass removed from NodeList for the reason of lack of implementations, and even plans for implementation It was removed because as things stand it's not web-compatible. Once @@isConcatSpreadable exists in implementations, we could and should reinstate ArrayClass on NodeList, I expect, while making it concat-spreadable at the same time. Certainly I plan to do so in Gecko. Thank you for the summary of stuff we're considering unstable for now. Comments inline. Currently maplike/setlike/ RegExp [Unscopeable] [PrimaryGlobal] [ImplicitThis], most probably iterable. OK. So I'm fine with maplike/setlike being considered unstable at the moment, because they are. I have no strong opinion on RegExp, since I suspect in practice no one uses it anywhere so far. [Unscopeable] is not implemented in UAs yet, but doing that blocks implementing some DOM APIs, fwiw. [PrimaryGlobal] is needed for [Exposed] stuff to make any sense. I see no reason not to keep it; it's supported in Gecko fwiw. [ImplicitThis] is, I agree, unstable in terms of IDL syntax. The functionality is obviously needed for basic web compat; I think we should just make it a priority to get this part sorted out and stabilized. But of course this is also subject to the number of bugs attached to them, issues with test etc... Sure. So many things will still be considered “at risk”. That's fine. I didn’t see any trace of [ImplicitThis] either, so that will make it hard to test (the Window interface given in the example is no longer using it). It's trivial to test its effects. If this script puts up an alert: script alert(Hello); /script then something like [ImplicitThis] is being done somewhere, whether the specs call for it or not. What that something is should probably be specced, of course. ;) Ah indeed no, and now I wonder why I added it in my list… (so as no specs seems to use them, I don’t think there are implementations around). I'm not aware of any implementations, correct. -Boris
Re: Mozilla and the Shadow DOM
On Tue, Apr 14, 2015 at 5:38 AM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Apr 8, 2015 at 6:11 PM, Dimitri Glazkov dglaz...@google.com wrote: Thanks for the feedback! While the iron is hot I went ahead and created/updated bugs in the tracker. A problem I have with this approach is that with Shadow DOM (and maybe Web Components in general) there's a lot of open bugs. Of those bugs it's not at all clear which the editors plan on addressing. Which makes it harder to plan for us. This seems like something we can fix by bug triage. Both Hayato and I periodically garden the bug tree ( https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=14978hide_resolved=1 ). The process works as follows: 1) The bug tree is broken by categories of work, with each category being a meta bug (title prefixed with [meta]). 2) As new bugs are filed, they end up at the bottom of the tree 3) Periodically, we triage these bugs at the bottom and mark them as blocking meta bugs. 4) Those meta bugs that no longer have blocking bugs are closed as fixed. To make it easier for you to track Mozilla-related bugs, we need to create a meta bug, like I did a while back for custom elements: https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=20684hide_resolved=0 Here's the new bug for Shadow DOM: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28491. I started added things I know as blocking to it, please feel free to add those that I missed. Also, a point that I forgot to make in my initial email is that Polymer makes it rather hard for us to ship any part of Web Components without all the other parts (and in the manner that Chrome implemented the features): https://bugzilla.mozilla.org/show_bug.cgi?id=1107662 I am sure Polymer folks will be super-happy to help. Let's continue discussion on your bug. :DG
[Bug 27637] [Shadow]: Explain the CSS inheritance in terms of Composed Tree
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27637 Hayato Ito hay...@chromium.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Hayato Ito hay...@chromium.org --- I've filed a bug for CSS Scoping. https://www.w3.org/Bugs/Public/show_bug.cgi?id=28492 Let me close the bug in Shadow DOM side. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 27359] [Shadow]: Need to define interaction with directionality
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27359 Hayato Ito hay...@chromium.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #16 from Hayato Ito hay...@chromium.org --- I think we can close this issue now. kojiishii@, if you have any remaining issue, please reopen this. -- You are receiving this mail because: You are on the CC list for the bug.
Re: Mozilla and the Shadow DOM
Just to close the loop, filed https://github.com/webcomponents/webcomponentsjs/issues/289 to track the specific Polymer web component polyfill blocker. On Tue, Apr 14, 2015 at 5:38 AM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Apr 8, 2015 at 6:11 PM, Dimitri Glazkov dglaz...@google.com wrote: Thanks for the feedback! While the iron is hot I went ahead and created/updated bugs in the tracker. A problem I have with this approach is that with Shadow DOM (and maybe Web Components in general) there's a lot of open bugs. Of those bugs it's not at all clear which the editors plan on addressing. Which makes it harder to plan for us. Also, a point that I forgot to make in my initial email is that Polymer makes it rather hard for us to ship any part of Web Components without all the other parts (and in the manner that Chrome implemented the features): https://bugzilla.mozilla.org/show_bug.cgi?id=1107662 The linked bug is simply incorrect. Polymer depends on webcomponentsjs ( https://github.com/webcomponents/webcomponentsjs) for browsers without all the Web Components specs, but each part is feature detected, with separate checks for Custom Elements, HTML Imports, and ShadowDOM, as well as HTML Template, constructable URL, and MutationObserver Chrome did not implement and ship all the specs at once, so Polymer has had to feature detect from the start. -- https://annevankesteren.nl/
Re: Mozilla and the Shadow DOM
!-- Whoops, my draft got cut off. -- We found some timing issues with polyfill HTML Imports and native Custom Elements in Chrome that made us force the Custom Elements polyfill when HTML Imports is polyfilled. I don't remember the specifics, but I filed the github issue to either track down and resolve the issues, or provide a flag to override this behavior for Mozilla to use in testing. Sorry for the grumbly note, we've tried very hard to make sure Polymer !== Web Components in public discourse to keep people from conflating the two. On Tue, Apr 14, 2015 at 12:29 PM, Daniel Freedman dfre...@google.com wrote: Just to close the loop, filed https://github.com/webcomponents/webcomponentsjs/issues/289 to track the specific Polymer web component polyfill blocker. On Tue, Apr 14, 2015 at 5:38 AM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Apr 8, 2015 at 6:11 PM, Dimitri Glazkov dglaz...@google.com wrote: Thanks for the feedback! While the iron is hot I went ahead and created/updated bugs in the tracker. A problem I have with this approach is that with Shadow DOM (and maybe Web Components in general) there's a lot of open bugs. Of those bugs it's not at all clear which the editors plan on addressing. Which makes it harder to plan for us. Also, a point that I forgot to make in my initial email is that Polymer makes it rather hard for us to ship any part of Web Components without all the other parts (and in the manner that Chrome implemented the features): https://bugzilla.mozilla.org/show_bug.cgi?id=1107662 The linked bug is simply incorrect. Polymer depends on webcomponentsjs ( https://github.com/webcomponents/webcomponentsjs) for browsers without all the Web Components specs, but each part is feature detected, with separate checks for Custom Elements, HTML Imports, and ShadowDOM, as well as HTML Template, constructable URL, and MutationObserver Chrome did not implement and ship all the specs at once, so Polymer has had to feature detect from the start. -- https://annevankesteren.nl/
IndieUI Teleconference Agenda; 15 April at 21:00Z
Cross-posting as is usual ... What: IndieUI Task Force Teleconference When: Wednesday 15 April 2:00 PMSan Francisco -- U.S. Pacific Time (PDT: UTC -7) 4:00 PMAustin -- U.S. Central Time(CDT: UTC -5) 5:00 PMBoston -- U.S. Eastern Time(EDT: UTC -4) 10:00 PMLondon -- British Time (BST: UTC +1) 11:00 PMParis -- Central European Time (CET: UTC +2) 5:00 AMBeijing -- China Standard Time (Thursday, 16 April CST: UTC +8) 6:00 AMTokyo -- Japan Standard Time(Thursday, 16 April JST: UTC +9) Where: W3C Teleconference--See Below * Time of day conversions Please verify the correct time of this meeting in your time zone using the Fixed Time Clock at: http://timeanddate.com/worldclock/fixedtime.html?msg=IndieUI+Teleconferenceiso=20150415T1700p1=43ah=1 ** Preliminary Agenda for IndieUI Task Force Teleconference 15 April 2015 Meeting: IndieUI Task Force Teleconference Chair: Janina_Sajka agenda+ preview agenda with items from two minutes agenda+ Editors' Reports agenda+ Checkin with Web Apps' Editing TF [See below] agenda+ Future of IndieUI Work (Continued) agenda+ Schema.org Mappings (Continued) -- Rich Andy [See Below] agenda+ User Context Issues Actions https://www.w3.org/WAI/IndieUI/track/products/3 agenda+ Events Issues Actions https://www.w3.org/WAI/IndieUI/track/products/2 agenda+ Other Business agenda+ Be Done Resource: Teleconference Minutes http://www.w3.org/2015/04/01-indie-ui-minutes.html Resource: Results from WBS Survey on IndieUI's Future https://www.w3.org/2002/09/wbs/54997/201503_planning/results Resource: Schema.org meta data mapping to Indie UI User context https://docs.google.com/spreadsheets/d/1pb92piOlud5sXQadXYnbmtp9LCut26gv8ku-qqZTwec/edit#gid=0 Resource: Web Apps Editing TF Editing Explainer: http://w3c.github.io/editing-explainer/ User Intentions: http://w3c.github.io/editing-explainer/commands-explainer.html Resource: For Reference Home Page: http://www.w3.org/WAI/IndieUI/ Email Archive: http://lists.w3.org/Archives/Public/public-indie-ui/ Resource: Teleconference Logistics Dial the Zakim bridge using either SIP or the PSTN. PSTN: +1.617.761.6200 (This is a U.S. number). SIP: za...@voip.w3.org You should be prompted for a pass code, This is 46343# (INDIE#) Alternatively, bypass the Zakim prompts and SIP directly into our teleconference. SIP: 0046...@voip.w3.org Instructions for connecting using SIP: http://www.w3.org/2006/tools/wiki/Zakim-SIP Place for users to contribute additional VoIP tips. http://www.w3.org/2006/tools/wiki/Zakim-SIP-tips IRC: server: irc.w3.org, channel: #indie-ui. During the conference you can manage your participation with Zakim commands as follows: 61# to mute yourself 60# to unMute yourself 41# to raise your hand (enter speaking queue) 40# to lower your hand (exit speaking queue) The system acknowledges these commands with a rapid, three-tone confirmation. Mobile phone users especially should use the mute function if they don't have a mute function in their phone. But the hand-raising function is a good idea for anyone not using IRC. * IRC access An IRC channel will be available. The server is irc.w3.org, The port number is 6665 (Note this is not the normal default) and The channel is #indie-ui. * Some helpful Scribing and Participation Tips http://www.w3.org/WAI/PF/wiki/Teleconference_cheat_sheet For more on the IRC setup and the robots we use for agenda and speaker queuing and for posting the log to the web, see: - For RRSAgent, that captures and posts the log with special attention to action items: http://www.w3.org/2002/03/RRSAgent - For Zakim, the IRC interface to the bridge manager, that will maintain speaker and agenda queues: http://www.w3.org/2001/12/zakim-irc-bot - For a Web gateway to IRC you can use if your network administrators forbid IRC, see: http://www.w3.org/2001/01/cgi-irc - For more on W3C use of IRC see: http://www.w3.org/Project/IRC/ -- Janina Sajka, Phone: +1.443.300.2200 sip:jan...@asterisk.rednote.net Email: jan...@rednote.net The Linux Foundation Chair, Open Accessibility: http://a11y.org The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI) Chair, Protocols Formats http://www.w3.org/wai/pf IndieUI http://www.w3.org/WAI/IndieUI/
PSA: Seeking feedback on W3C's Modern Tooling project
[Bcc public-openw3c ] Hi All, In case you missed it, last February, Robin, Philippe and others (see [1] for a list of contributors) started a project to capture the state of the discussion about modernising the tooling that supports the making of W3C standards. The working document is http://w3c.github.io/modern-tooling/ and the repository is https://github.com/w3c/modern-tooling. This is an important effort so if you have feedback, please use the project's Issues system https://github.com/w3c/modern-tooling/issues or submit a Pull Request https://github.com/w3c/modern-tooling/pulls. -Thanks, ArtB P.S. PSA = Public Service Announcement [1] https://github.com/w3c/modern-tooling/graphs/contributors
Re: Mozilla and the Shadow DOM
On Wed, Apr 8, 2015 at 6:11 PM, Dimitri Glazkov dglaz...@google.com wrote: Thanks for the feedback! While the iron is hot I went ahead and created/updated bugs in the tracker. A problem I have with this approach is that with Shadow DOM (and maybe Web Components in general) there's a lot of open bugs. Of those bugs it's not at all clear which the editors plan on addressing. Which makes it harder to plan for us. Also, a point that I forgot to make in my initial email is that Polymer makes it rather hard for us to ship any part of Web Components without all the other parts (and in the manner that Chrome implemented the features): https://bugzilla.mozilla.org/show_bug.cgi?id=1107662 -- https://annevankesteren.nl/
