Mozilla and the Shadow DOM

[Anne van Kesteren]

We have done some brainstorming internally around what we want out of
Shadow DOM and components in general, between those working on Gaia
(Firefox OS applications) and those working on Platform (Gecko). We
hope to be able to discuss this at the meeting later this month and
also at the Extensible Web Summit that precedes it. And of course on
this list, happy to answer any questions.

For custom elements https://wiki.whatwg.org/wiki/Custom_Elements is
still an accurate summary of where we are at. For shadow DOM I wrote
this summary:

* Layout containment. We hope that evolving
http://dev.w3.org/csswg/css-containment/ further could allow for some
interesting optimizations and hopefully something akin to element
queries or a resize event down the road. (This is basically a feature
of  that components lack.)

* Declarative shadow DOM. Mostly for performance it would be nice if
the composed tree could be serialized and cached. That way first
render only requires HTML and CSS with JavaScript kicking in at the
end. We reasoned it might not be too hard to add something like
 given our experience with . The only difference
would be that  itself would also not be appended to the
tree and that the DocumentFragment nee ShadowRoot is associated with
"its parent".

* Isolated shadow DOM. This is the idea of having a "DOM worker" so
that instead of ten s with ten globals you can have one global
with ten somethings. This would give applications more parallelization
opportunities and would hopefully enable a large number of companies
from moving away of the practice of using cross-origin 

Re: [W3C TCP and UDP Socket API]: Status and home for this specification

[Wayne Carr]

On 2015-04-07 07:07, Nilsson, Claes1 wrote:

Hi Frederick,

The implementations I am aware of are:
  
* Mozilla FFOS: There is an ongoing implementation of the UDP API. See https://bugzilla.mozilla.org/show_bug.cgi?id=745283

* Crosswalk: An experimental implementation of the old, non-stream-based 
version. See https://crosswalk-project.org/documentation/apis/web_apis.html


If it had 2 fairly significant implementations, that can be an argument 
for keeping it in a WG rather than moving it to a Community Group (where 
it doesn't need 2) (I think that may have been what the question was about.)


Crosswalk has an experimental implementation of a previous version that 
was fairly different.   We (Intel) have quit the SysApps WG and think it 
should have closed when the Charter expired.

https://crosswalk-project.org/documentation/apis/web_apis.html

Mozilla looks like they have their own, different API
https://developer.mozilla.org/en-US/docs/Web/API/TCPSocket





There is no public web page with this information.

BR
   Claes



Claes Nilsson
Master Engineer - Web Research
Advanced Application Lab, Technology

Sony Mobile Communications
Tel: +46 70 55 66 878
claes1.nils...@sonymobile.com

sonymobile.com




-Original Message-
From: Frederick Hirsch [mailto:w...@fjhirsch.com]
Sent: den 7 april 2015 13:53
To: Nilsson, Claes1
Cc: public-sysa...@w3.org; public-webapps; Device APIs Working Group;
Domenic Denicola; slightly...@chromium.org; yass...@gmail.com
Subject: Re: [W3C TCP and UDP Socket API]: Status and home for this
specification


Lastly, if there is a decision to continue to work on this API I can

remain as main editor. However, I can currently not commit to more
extensive tasks such as implementation and test cases.

Claes

Do you have information on W3C members committed to implementation &
test cases going forward? This might be useful before considering venue
for the work and detailed issues. (Is there a public web page with
information on current implementations?)

thanks

regards, Frederick

Frederick Hirsch

www.fjhirsch.com
@fjhirsch




On Apr 1, 2015, at 5:22 AM, Nilsson, Claes1

 wrote:

Hi all,

Related to the recent mail thread about the SysApps WG and its

deliverables I would like to make a report of the status of the TCP and
UDP Socket API, http://www.w3.org/2012/sysapps/tcp-udp-sockets/.

Note that this specification is still being worked on. Latest merged

PR was March 30. I think it is time for a new Public Working Draft.

This API is used to send and receive data over the network using TCP

or UDP.

Examples of use cases for the API are:
• An email client which communicates with SMTP, POP3 and

IMAP servers

• An irc client which communicates with irc servers
• Implementing an ssh app
• Communicating with existing consumer hardware, like

internet connected TVs

• Game servers
• Peer-to-peer applications
• Local network multicast service discovery, e.g. UPnP/SSDP

and mDNS

The TCP and UDP Socket API is a phase 1 deliverable of the SysApps WG.

SysApps was originally chartered to provide a runtime and security
model so that it would be possible to open up sensitive APIs to SysApps
enabled runtimes. Accordingly, it was assumed that the TCP and UDP
Socket API would be exposed to such a “trusted runtime”. Looking at
existing TCP and UDP Socket APIs they are implemented in proprietary
web runtimes, FFOS and Chrome, which provide a security model for
installed packaged web runtimes.

Today we can conclude that it has not been possible to standardize a

runtime and security model in SysApps. However, there still seems to be
an interest in the TCP and UDP Socket API, at least from individuals at
Google and Mozilla. For example, there has been extensive work,
supported by Google, to adapt this API to the Streams API specification,
https://streams.spec.whatwg.org/.

To meet the issue that we don’t have a standardized secure “web

system applications” runtime and that the current open web browser
sandbox is not secure enough for this kind of API (but the security
features are evolving through the Web Application Security Working
Group) I recently added “permission methods”, partly inspired by the
W3C Push API. A webapp could for example request permission to create a
TCP connection to a certain host. The ambition is to isolate the
permission system from the socket interfaces specifications and the
manner in which permission to use this API is given differs depending
on the type of web runtime the API is implemented in. For example, a
web runtime for secure installed web applications may be able to open
up this API so that no explicit user content is needed, while an
implementation in a web browser may use a combination of web security
mechanisms, such as secure transport (https:), content security
policies (CSP), signed manifest, certificate pinning, and user consent
to open up the API.

If SysApps WG is closed and the scop

PSA: publishing new WD of Input Method Editor (IME) API on April 9

[Arthur Barstow]

Hi All,

A new Working Draft publication of IME API is planned for April 9 using 
the following version as the basis:




If anyone has any major concerns about this, please reply right away.

A few notes about this spec:

* Travis is now the sole Editor of this spec. Many thanks to Travis for 
agreeing to take the lead and to the previous Editors Takayoshi Kochi, 
Kenji Baheux and Hironori Bono.


* This spec is now using Github  and 
the ED is .


* The permissions of the spec's now obsolete Hg repository will be set 
to read-only. The spec's Bugzilla component will be marked `Historical` 
and set to read-only and all open bugs will be closed after they are 
copied as Github issues.


-Thanks, ArtB

RE: [W3C TCP and UDP Socket API]: Status and home for this specification

[Nilsson, Claes1]

Hi again Frederick,

I plan to issue a CFC for moving the TCP and UDP Socket API specification to a 
CG. However, before that, do you think that one option could be DAP? I assume 
that would require a modified charter.

BR
  Claes



Claes Nilsson
Master Engineer - Web Research
Advanced Application Lab, Technology

Sony Mobile Communications
Tel: +46 70 55 66 878
claes1.nils...@sonymobile.com

sonymobile.com




> -Original Message-
> From: Nilsson, Claes1
> Sent: den 7 april 2015 16:08
> To: 'Frederick Hirsch'
> Cc: public-sysa...@w3.org; public-webapps; Device APIs Working Group;
> Domenic Denicola; slightly...@chromium.org; yass...@gmail.com
> Subject: RE: [W3C TCP and UDP Socket API]: Status and home for this
> specification
> 
> Hi Frederick,
> 
> The implementations I am aware of are:
> 
> * Mozilla FFOS: There is an ongoing implementation of the UDP API. See
> https://bugzilla.mozilla.org/show_bug.cgi?id=745283
> * Crosswalk: An experimental implementation of the old, non-stream-
> based version. See https://crosswalk-
> project.org/documentation/apis/web_apis.html
> 
> There is no public web page with this information.
> 
> BR
>   Claes
> 
> 
> 
> Claes Nilsson
> Master Engineer - Web Research
> Advanced Application Lab, Technology
> 
> Sony Mobile Communications
> Tel: +46 70 55 66 878
> claes1.nils...@sonymobile.com
> 
> sonymobile.com
> 
> 
> 
> > -Original Message-
> > From: Frederick Hirsch [mailto:w...@fjhirsch.com]
> > Sent: den 7 april 2015 13:53
> > To: Nilsson, Claes1
> > Cc: public-sysa...@w3.org; public-webapps; Device APIs Working Group;
> > Domenic Denicola; slightly...@chromium.org; yass...@gmail.com
> > Subject: Re: [W3C TCP and UDP Socket API]: Status and home for this
> > specification
> >
> > > Lastly, if there is a decision to continue to work on this API I
> can
> > remain as main editor. However, I can currently not commit to more
> > extensive tasks such as implementation and test cases.
> >
> > Claes
> >
> > Do you have information on W3C members committed to implementation &
> > test cases going forward? This might be useful before considering
> > venue for the work and detailed issues. (Is there a public web page
> > with information on current implementations?)
> >
> > thanks
> >
> > regards, Frederick
> >
> > Frederick Hirsch
> >
> > www.fjhirsch.com
> > @fjhirsch
> >
> >
> >
> > > On Apr 1, 2015, at 5:22 AM, Nilsson, Claes1
> >  wrote:
> > >
> > > Hi all,
> > >
> > > Related to the recent mail thread about the SysApps WG and its
> > deliverables I would like to make a report of the status of the TCP
> > and UDP Socket API, http://www.w3.org/2012/sysapps/tcp-udp-sockets/.
> > >
> > > Note that this specification is still being worked on. Latest
> merged
> > PR was March 30. I think it is time for a new Public Working Draft.
> > >
> > > This API is used to send and receive data over the network using
> TCP
> > or UDP.
> > > Examples of use cases for the API are:
> > >   • An email client which communicates with SMTP, POP3 and
> > IMAP servers
> > >   • An irc client which communicates with irc servers
> > >   • Implementing an ssh app
> > >   • Communicating with existing consumer hardware, like
> > internet connected TVs
> > >   • Game servers
> > >   • Peer-to-peer applications
> > >   • Local network multicast service discovery, e.g. UPnP/SSDP
> > and mDNS
> > >
> > > The TCP and UDP Socket API is a phase 1 deliverable of the SysApps
> WG.
> > SysApps was originally chartered to provide a runtime and security
> > model so that it would be possible to open up sensitive APIs to
> > SysApps enabled runtimes. Accordingly, it was assumed that the TCP
> and
> > UDP Socket API would be exposed to such a “trusted runtime”. Looking
> > at existing TCP and UDP Socket APIs they are implemented in
> > proprietary web runtimes, FFOS and Chrome, which provide a security
> > model for installed packaged web runtimes.
> > >
> > > Today we can conclude that it has not been possible to standardize
> a
> > runtime and security model in SysApps. However, there still seems to
> > be an interest in the TCP and UDP Socket API, at least from
> > individuals at Google and Mozilla. For example, there has been
> > extensive work, supported by Google, to adapt this API to the Streams
> > API specification, https://streams.spec.whatwg.org/.
> > >
> > > To meet the issue that we don’t have a standardized secure “web
> > system applications” runtime and that the current open web browser
> > sandbox is not secure enough for this kind of API (but the security
> > features are evolving through the Web Application Security Working
> > Group) I recently added “permission methods”, partly inspired by the
> > W3C Push API. A webapp could for example request permission to create
> > a TCP connection to a certain host. The ambition is to isolate the
> > permission system from the socket interfaces specifications and the
> > manner in which permission to use this API is given differs depending

RE: [W3C TCP and UDP Socket API]: Status and home for this specification

[Nilsson, Claes1]

Hi Frederick,

The implementations I am aware of are:
 
* Mozilla FFOS: There is an ongoing implementation of the UDP API. See 
https://bugzilla.mozilla.org/show_bug.cgi?id=745283 
* Crosswalk: An experimental implementation of the old, non-stream-based 
version. See https://crosswalk-project.org/documentation/apis/web_apis.html 

There is no public web page with this information.

BR
  Claes



Claes Nilsson
Master Engineer - Web Research
Advanced Application Lab, Technology

Sony Mobile Communications
Tel: +46 70 55 66 878
claes1.nils...@sonymobile.com

sonymobile.com



> -Original Message-
> From: Frederick Hirsch [mailto:w...@fjhirsch.com]
> Sent: den 7 april 2015 13:53
> To: Nilsson, Claes1
> Cc: public-sysa...@w3.org; public-webapps; Device APIs Working Group;
> Domenic Denicola; slightly...@chromium.org; yass...@gmail.com
> Subject: Re: [W3C TCP and UDP Socket API]: Status and home for this
> specification
> 
> > Lastly, if there is a decision to continue to work on this API I can
> remain as main editor. However, I can currently not commit to more
> extensive tasks such as implementation and test cases.
> 
> Claes
> 
> Do you have information on W3C members committed to implementation &
> test cases going forward? This might be useful before considering venue
> for the work and detailed issues. (Is there a public web page with
> information on current implementations?)
> 
> thanks
> 
> regards, Frederick
> 
> Frederick Hirsch
> 
> www.fjhirsch.com
> @fjhirsch
> 
> 
> 
> > On Apr 1, 2015, at 5:22 AM, Nilsson, Claes1
>  wrote:
> >
> > Hi all,
> >
> > Related to the recent mail thread about the SysApps WG and its
> deliverables I would like to make a report of the status of the TCP and
> UDP Socket API, http://www.w3.org/2012/sysapps/tcp-udp-sockets/.
> >
> > Note that this specification is still being worked on. Latest merged
> PR was March 30. I think it is time for a new Public Working Draft.
> >
> > This API is used to send and receive data over the network using TCP
> or UDP.
> > Examples of use cases for the API are:
> > • An email client which communicates with SMTP, POP3 and
> IMAP servers
> > • An irc client which communicates with irc servers
> > • Implementing an ssh app
> > • Communicating with existing consumer hardware, like
> internet connected TVs
> > • Game servers
> > • Peer-to-peer applications
> > • Local network multicast service discovery, e.g. UPnP/SSDP
> and mDNS
> >
> > The TCP and UDP Socket API is a phase 1 deliverable of the SysApps WG.
> SysApps was originally chartered to provide a runtime and security
> model so that it would be possible to open up sensitive APIs to SysApps
> enabled runtimes. Accordingly, it was assumed that the TCP and UDP
> Socket API would be exposed to such a “trusted runtime”. Looking at
> existing TCP and UDP Socket APIs they are implemented in proprietary
> web runtimes, FFOS and Chrome, which provide a security model for
> installed packaged web runtimes.
> >
> > Today we can conclude that it has not been possible to standardize a
> runtime and security model in SysApps. However, there still seems to be
> an interest in the TCP and UDP Socket API, at least from individuals at
> Google and Mozilla. For example, there has been extensive work,
> supported by Google, to adapt this API to the Streams API specification,
> https://streams.spec.whatwg.org/.
> >
> > To meet the issue that we don’t have a standardized secure “web
> system applications” runtime and that the current open web browser
> sandbox is not secure enough for this kind of API (but the security
> features are evolving through the Web Application Security Working
> Group) I recently added “permission methods”, partly inspired by the
> W3C Push API. A webapp could for example request permission to create a
> TCP connection to a certain host. The ambition is to isolate the
> permission system from the socket interfaces specifications and the
> manner in which permission to use this API is given differs depending
> on the type of web runtime the API is implemented in. For example, a
> web runtime for secure installed web applications may be able to open
> up this API so that no explicit user content is needed, while an
> implementation in a web browser may use a combination of web security
> mechanisms, such as secure transport (https:), content security
> policies (CSP), signed manifest, certificate pinning, and user consent
> to open up the API.
> >
> > If SysApps WG is closed and the scope of W3C is limited to APIs that
> could be exposed the “normal browser context” (which is evolving, once
> again referring to Web Apps Sec WG) a new home for this API could be
> the Device API WG. A Community Group, similar to what we have for Web
> Bluetooth and NFC, would also be a possibility.
> >
> > WDYT?
> >
> > Lastly, if there is a decision to continue to work on this API I can
> remain as main editor. However, I can currently not commit to more
> extensiv

Re: [W3C TCP and UDP Socket API]: Status and home for this specification

[Frederick Hirsch]

> Lastly, if there is a decision to continue to work on this API I can remain 
> as main editor. However, I can currently not commit to more extensive tasks 
> such as implementation and test cases. 

Claes

Do you have information on W3C members committed to implementation & test cases 
going forward? This might be useful before considering venue for the work and 
detailed issues. (Is there a public web page with information on current 
implementations?)

thanks

regards, Frederick

Frederick Hirsch

www.fjhirsch.com
@fjhirsch



> On Apr 1, 2015, at 5:22 AM, Nilsson, Claes1  
> wrote:
> 
> Hi all,
>  
> Related to the recent mail thread about the SysApps WG and its deliverables I 
> would like to make a report of the status of the TCP and UDP Socket API, 
> http://www.w3.org/2012/sysapps/tcp-udp-sockets/. 
>  
> Note that this specification is still being worked on. Latest merged PR was 
> March 30. I think it is time for a new Public Working Draft.
>  
> This API is used to send and receive data over the network using TCP or UDP.
> Examples of use cases for the API are:
>   • An email client which communicates with SMTP, POP3 and IMAP servers
>   • An irc client which communicates with irc servers
>   • Implementing an ssh app
>   • Communicating with existing consumer hardware, like internet 
> connected TVs
>   • Game servers
>   • Peer-to-peer applications
>   • Local network multicast service discovery, e.g. UPnP/SSDP and mDNS
>  
> The TCP and UDP Socket API is a phase 1 deliverable of the SysApps WG. 
> SysApps was originally chartered to provide a runtime and security model so 
> that it would be possible to open up sensitive APIs to SysApps enabled 
> runtimes. Accordingly, it was assumed that the TCP and UDP Socket API would 
> be exposed to such a “trusted runtime”. Looking at existing TCP and UDP 
> Socket APIs they are implemented in proprietary web runtimes, FFOS and 
> Chrome, which provide a security model for installed packaged web runtimes.
>  
> Today we can conclude that it has not been possible to standardize a runtime 
> and security model in SysApps. However, there still seems to be an interest 
> in the TCP and UDP Socket API, at least from individuals at Google and 
> Mozilla. For example, there has been extensive work, supported by Google, to 
> adapt this API to the Streams API specification, 
> https://streams.spec.whatwg.org/. 
>  
> To meet the issue that we don’t have a standardized secure “web system 
> applications” runtime and that the current open web browser sandbox is not 
> secure enough for this kind of API (but the security features are evolving 
> through the Web Application Security Working Group) I recently added 
> “permission methods”, partly inspired by the W3C Push API. A webapp could for 
> example request permission to create a TCP connection to a certain host. The 
> ambition is to isolate the permission system from the socket interfaces 
> specifications and the manner in which permission to use this API is given 
> differs depending on the type of web runtime the API is implemented in. For 
> example, a web runtime for secure installed web applications may be able to 
> open up this API so that no explicit user content is needed, while an 
> implementation in a web browser may use a combination of web security 
> mechanisms, such as secure transport (https:), content security policies 
> (CSP), signed manifest, certificate pinning, and user consent to open up the 
> API.
>  
> If SysApps WG is closed and the scope of W3C is limited to APIs that could be 
> exposed the “normal browser context” (which is evolving, once again referring 
> to Web Apps Sec WG) a new home for this API could be the Device API WG. A 
> Community Group, similar to what we have for Web Bluetooth and NFC, would 
> also be a possibility. 
>  
> WDYT?
>  
> Lastly, if there is a decision to continue to work on this API I can remain 
> as main editor. However, I can currently not commit to more extensive tasks 
> such as implementation and test cases. 
>  
> Best regards
>   Claes
>  
>  
> Claes Nilsson
> Master Engineer - Web Research
> Advanced Application Lab, Technology
>  
> Sony Mobile Communications
> Tel: +46 70 55 66 878
> claes1.nils...@sonymobile.com
>  
> sonymobile.com
>  
> 

Reminder: [admin] Registration for April 24 2015 Web Components f2f meeting; deadline April 10

[Arthur Barstow]

On 2/24/15 3:37 PM, Arthur Barstow wrote:
The registration page for the April 24 Web Components f2f meeting at 
Google's Mount View CA office is now open:




The meeting/agenda page is: 
.


Please register by April 10.

-Thanks, AB