[W3C TCP and UDP Socket API] Informal CfC on moving the SysApps TCP and UDP Socket APi to a Community Group

2015-04-14 Thread Nilsson, Claes1
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

2015-04-14 Thread Yves Lafon

 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

2015-04-14 Thread Melvin Carvalho
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

2015-04-14 Thread bugzilla
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

2015-04-14 Thread Boris Zbarsky

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

2015-04-14 Thread Dimitri Glazkov
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

2015-04-14 Thread bugzilla
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

2015-04-14 Thread bugzilla
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

2015-04-14 Thread Daniel Freedman
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

2015-04-14 Thread Daniel Freedman
!-- 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

2015-04-14 Thread Janina Sajka

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

2015-04-14 Thread Arthur Barstow

[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

2015-04-14 Thread Anne van Kesteren
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/