[Bug 28157] New: [Shadow]: Link to CSS Scoping module spec?

2015-03-06 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28157

Bug ID: 28157
   Summary: [Shadow]: Link to CSS Scoping module spec?
   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: m...@w3.org, public-webapps@w3.org
Blocks: 14978

From https://github.com/w3c/webcomponents/issues/37:

Looking for scope or /deep or similar terms in the spec doesn't produce any
meaningful result--because there is no mention to said selectors in the Shadow
DOM spec.

But as a developer I would expect at least a mention to:
http://dev.w3.org/csswg/css-scoping/

This is the web, right? we link things together

-- 
You are receiving this mail because:
You are on the CC list for the bug.



[Bug 28158] New: [Custom]: inflexible extends as fixed element type

2015-03-06 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28158

Bug ID: 28158
   Summary: [Custom]: inflexible extends as fixed element type
   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: m...@w3.org, public-webapps@w3.org
Blocks: 14968

From: https://github.com/w3c/webcomponents/issues/33

rjharmon commented on Jan 25

I'd like to be able to specify any type (or perhaps certain types) of tags,
with is= to augment functionality of any element. The initialization sequence
I'm imagining is passed the native element instance, and then the component
would be able to add its own capabilities to that instance's prototype chain
(could also choose to prepare the prototype chain so that element.prototype is
already distinguished from that element's native prototype, as a helpful
refinement to developers).

A similar technique could be used to add multiple mixins to a tag, assuming
they'd been designed them to be complementary/concerned with orthogonal aspects
of the markup/content. I think of that as with= rather than is=.

-- 
You are receiving this mail because:
You are on the CC list for the bug.



RE: [manifest] RE: Manifest for web application; review deadline March 5

2015-03-06 Thread Nilsson, Claes1
Yes, that covers my first question. I have also seen Anssi’s CSP extension 
specification. I guess that the approach is to see how far we can get in the 
TrustPermissions CG on the ideas we experimented with for FFOS, i.e. to find a 
way to securely open up sensitive APIs to server hosted web sites using a 
signed manifest and secure transport. Then we have to work on any needed 
extensions to the Manifest specification.

BR
  Claes

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@01D057FC.02E74370]

From: Christiansen, Kenneth R [mailto:kenneth.r.christian...@intel.com]
Sent: den 6 mars 2015 10:46
To: Nilsson, Claes1; 'Kenneth Rohde Christiansen'; Kostiainen, Anssi; Arthur 
Barstow; public-webapps
Subject: RE: [manifest] RE: Manifest for web application; review deadline March 
5

Yes, indeed. I just didn´t remember the final name.

Does that cover your first question?

Regarding the second questions, Anssi wrote an extension spec: 
http://w3c.github.io/manifest-csp/

He can probably comment on that.

Kenneth

From: Nilsson, Claes1 [mailto:claes1.nils...@sonymobile.com]
Sent: Friday, March 6, 2015 10:39 AM
To: 'Kenneth Rohde Christiansen'; Arthur Barstow; public-webapps
Subject: RE: [manifest] RE: Manifest for web application; review deadline March 
5

Ok thanks Kenneth. I assume that you refer to the Trust  Permissions Community 
Group, https://www.w3.org/community/trustperms/?

BR
  Claes

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:image004.png@01D057FB.6AE53B40]

From: Kenneth Rohde Christiansen [mailto:kenneth.christian...@gmail.com]
Sent: den 6 mars 2015 10:09
To: Nilsson, Claes1; Arthur Barstow; public-webapps
Subject: Re: [manifest] RE: Manifest for web application; review deadline March 
5

Hi Claes,

The web app manifest spec allows extensions (it has extension points), so we 
would expect the Permissions WG/CG to come up with a proper way to deal with 
permissions. If they come to the conclusion that we need some permission field 
in the manifest, their spec can add that. It is not yet clear at this point 
that that is the solution that they are aiming at.

Cheers,
Kenneth

On Thu, Mar 5, 2015 at 4:50 PM Nilsson, Claes1 
claes1.nils...@sonymobile.commailto:claes1.nils...@sonymobile.com wrote:
Hi,

We support that this version of the specification is moved to Candidate status 
but we have a few comments/questions:

In this version 1 we miss:

* A permissions field
* A content security policy field. This is only included as a way to state 
allowed origins from which the manifest file itself could be loaded. However, 
there is, in this first version, no CSP-field defined for the manifest 
document, allowing restriction of origins the web app could download scripts 
and other content types from. There is also a draft companion document, 
http://w3c.github.io/manifest-csp/, defining this CSP-member of the manifest.

We consider the above features important for allowing server hosted web apps 
access to more sensitive APIs and have been experimenting with this for FFOS:
https://lists.w3.org/Archives/Public/public-sysapps/2014Sep/att-/SoMC_FFOS_Trusted_Hosted_Apps.pdf.
 Accordingly we want to discuss these features for the further work on the 
manifest specification.

We also would like to ask the WG if it has been discussed if https: transport 
should be required for downloading the manifest? Other specifications are 
moving towards requirement for https:. See for example the discussion 
https://lists.w3.org/Archives/Public/public-device-apis/2015Feb/0045.html. For 
the manifest version 1 this may not be critical but if above features are added 
the transport probably have to be protected.

However, once again note that these comments do not prevent that we support 
that the current version of the manifest is moved to candidate status, I am 
just taking the opportunity state our views on the further work on the manifest 
specification.

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:claes1.nils...@sonymobile.com

sonymobile.comhttp://sonymobile.com




 -Original Message-
 From: Arthur Barstow 
 [mailto:art.bars...@gmail.commailto:art.bars...@gmail.com]
 Sent: den 13 februari 2015 01:31
 To: public-webapps
 Subject: RfC: Manifest for web application; review deadline March 5

 [ Bcc: public-webappsec, www-style, public-privacy, public-sysapps,
 public-digipub-ig, public-pfwg, public-web-mobile, www-international,
 chairs^1, public-review-announce; 

Re: [manifest] RE: Manifest for web application; review deadline March 5

2015-03-06 Thread Kenneth Rohde Christiansen
Hi Claes,

The web app manifest spec allows extensions (it has extension points), so
we would expect the Permissions WG/CG to come up with a proper way to deal
with permissions. If they come to the conclusion that we need some
permission field in the manifest, their spec can add that. It is not yet
clear at this point that that is the solution that they are aiming at.

Cheers,
Kenneth

On Thu, Mar 5, 2015 at 4:50 PM Nilsson, Claes1 
claes1.nils...@sonymobile.com wrote:

 Hi,

 We support that this version of the specification is moved to Candidate
 status but we have a few comments/questions:

 In this version 1 we miss:

 * A permissions field
 * A content security policy field. This is only included as a way to
 state allowed origins from which the manifest file itself could be loaded.
 However, there is, in this first version, no CSP-field defined for the
 manifest document, allowing restriction of origins the web app could
 download scripts and other content types from. There is also a draft
 companion document, http://w3c.github.io/manifest-csp/, defining this
 CSP-member of the manifest.

 We consider the above features important for allowing server hosted web
 apps access to more sensitive APIs and have been experimenting with this
 for FFOS:
 https://lists.w3.org/Archives/Public/public-sysapps/2014Sep/
 att-/SoMC_FFOS_Trusted_Hosted_Apps.pdf. Accordingly we want to
 discuss these features for the further work on the manifest specification.

 We also would like to ask the WG if it has been discussed if https:
 transport should be required for downloading the manifest? Other
 specifications are moving towards requirement for https:. See for example
 the discussion https://lists.w3.org/Archives/Public/public-device-apis/
 2015Feb/0045.html. For the manifest version 1 this may not be critical
 but if above features are added the transport probably have to be protected.

 However, once again note that these comments do not prevent that we
 support that the current version of the manifest is moved to candidate
 status, I am just taking the opportunity state our views on the further
 work on the manifest specification.

 Best regards

 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: Arthur Barstow [mailto:art.bars...@gmail.com]
  Sent: den 13 februari 2015 01:31
  To: public-webapps
  Subject: RfC: Manifest for web application; review deadline March 5
 
  [ Bcc: public-webappsec, www-style, public-privacy, public-sysapps,
  public-digipub-ig, public-pfwg, public-web-mobile, www-international,
  chairs^1, public-review-announce; Reply-to: public-webapps ]
 
  This is a Request for Comments (RfC) for WebApp's Manifest for web
  application specification:
 
  http://www.w3.org/TR/2015/WD-appmanifest-20150212/
 
  This specification defines a JSON-based manifest that provides
  developers with a centralized place to put metadata associated with a
  web application.
 
  This Working Draft is intended to meet the wide review requirements as
  defined in the 2014 Process Document. The deadline for comments is 5
  March 2015 and all comments should be sent to the public-webapps @
  w3.org mail list [Archive] with a Subject: prefix of [manifest]. The
  next anticipated publication of this specification is a Candidate
  Recommendation. (See [CR-Plan] for the specification's Candidate
  Recommendation status.)
 
  WebApps welcomes review and comments from all individuals and/or groups
  and we explicitly ask the following groups to review the document and
  to submit comments: WebAppSec, CSS WG (in particular, the display
  mode
  media feature), PING, SysApps, Digital Publishing IG, WAI (PF, User
  Agent, Authoring Tools), and I18N WG.
 
  In addition to substantive comments, to help us get a sense of how much
  review the document receives, we also welcome data about silent
  reviews, f.ex. I reviewed section N.N and have no comments.
 
  -Thanks, AB
 
  ^1 RfC is the new LCWD TransAnn
  [CR-Plan] https://github.com/w3c/manifest/issues/308
  [Archive] https://lists.w3.org/Archives/Public/public-webapps/
 
 




Re: [manifest] RE: Manifest for web application; review deadline March 5

2015-03-06 Thread Anders Rundgren

On 2015-03-06 10:55, Nilsson, Claes1 wrote:


Yes, that covers my first question. I have also seen Anssi’s CSP extension 
specification. I guess that the approach is to see how far we can get in the 
TrustPermissions CG on the ideas we experimented with for FFOS, i.e. to find a 
way to securely open up sensitive APIs to server hosted web sites using a signed 
manifest and secure transport.



This indeed a major concern.  Permissions and Trustworthy Code are 
unfortunately not particularly related.

Cheers,
Anders



Then we have to work on any needed extensions to the Manifest specification.

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 mailto:firstname.lastn...@sonymobile.com

sonymobile.com http://sonymobile.com/

Sony logotype_23px height_Email_144dpi

*From:*Christiansen, Kenneth R [mailto:kenneth.r.christian...@intel.com]
*Sent:* den 6 mars 2015 10:46
*To:* Nilsson, Claes1; 'Kenneth Rohde Christiansen'; Kostiainen, Anssi; Arthur 
Barstow; public-webapps
*Subject:* RE: [manifest] RE: Manifest for web application; review deadline 
March 5

Yes, indeed. I just didn´t remember the final name.

Does that cover your first question?

Regarding the second questions, Anssi wrote an extension spec: 
http://w3c.github.io/manifest-csp/

He can probably comment on that.

Kenneth

*From:*Nilsson, Claes1 [mailto:claes1.nils...@sonymobile.com]
*Sent:* Friday, March 6, 2015 10:39 AM
*To:* 'Kenneth Rohde Christiansen'; Arthur Barstow; public-webapps
*Subject:* RE: [manifest] RE: Manifest for web application; review deadline 
March 5

Ok thanks Kenneth. I assume that you refer to the Trust  Permissions Community 
Group, https://www.w3.org/community/trustperms/?

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 mailto:firstname.lastn...@sonymobile.com

sonymobile.com http://sonymobile.com/

Sony logotype_23px height_Email_144dpi

*From:*Kenneth Rohde Christiansen [mailto:kenneth.christian...@gmail.com]
*Sent:* den 6 mars 2015 10:09
*To:* Nilsson, Claes1; Arthur Barstow; public-webapps
*Subject:* Re: [manifest] RE: Manifest for web application; review deadline 
March 5

Hi Claes,

The web app manifest spec allows extensions (it has extension points), so we 
would expect the Permissions WG/CG to come up with a proper way to deal with 
permissions. If they come to the conclusion that we need some permission field 
in the manifest, their spec can add that. It is not yet clear at this point 
that that is the solution that they are aiming at.

Cheers,

Kenneth

On Thu, Mar 5, 2015 at 4:50 PM Nilsson, Claes1 claes1.nils...@sonymobile.com 
mailto:claes1.nils...@sonymobile.com wrote:

Hi,

We support that this version of the specification is moved to Candidate status 
but we have a few comments/questions:

In this version 1 we miss:

* A permissions field
* A content security policy field. This is only included as a way to state 
allowed origins from which the manifest file itself could be loaded. However, there is, 
in this first version, no CSP-field defined for the manifest document, allowing 
restriction of origins the web app could download scripts and other content types from. 
There is also a draft companion document, http://w3c.github.io/manifest-csp/, defining 
this CSP-member of the manifest.

We consider the above features important for allowing server hosted web apps 
access to more sensitive APIs and have been experimenting with this for FFOS:
https://lists.w3.org/Archives/Public/public-sysapps/2014Sep/att-/SoMC_FFOS_Trusted_Hosted_Apps.pdf.
 Accordingly we want to discuss these features for the further work on the 
manifest specification.

We also would like to ask the WG if it has been discussed if https: transport 
should be required for downloading the manifest? Other specifications are 
moving towards requirement for https:. See for example the discussion 
https://lists.w3.org/Archives/Public/public-device-apis/2015Feb/0045.html. For 
the manifest version 1 this may not be critical but if above features are added 
the transport probably have to be protected.

However, once again note that these comments do not prevent that we support 
that the current version of the manifest is moved to candidate status, I am 
just taking the opportunity state our views on the further work on the manifest 
specification.

Best regards

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

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

sonymobile.com http://sonymobile.com




 -Original Message-
 From: Arthur Barstow [mailto:art.bars...@gmail.com 
mailto:art.bars...@gmail.com]
 Sent: den 13 februari 2015 01:31
 To: public-webapps
 Subject: RfC: 

RE: [manifest] RE: Manifest for web application; review deadline March 5

2015-03-06 Thread Nilsson, Claes1
Ok thanks Kenneth. I assume that you refer to the Trust  Permissions Community 
Group, https://www.w3.org/community/trustperms/?

BR
  Claes

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:image001.png@01D057F9.BEF1DF60]

From: Kenneth Rohde Christiansen [mailto:kenneth.christian...@gmail.com]
Sent: den 6 mars 2015 10:09
To: Nilsson, Claes1; Arthur Barstow; public-webapps
Subject: Re: [manifest] RE: Manifest for web application; review deadline March 
5

Hi Claes,

The web app manifest spec allows extensions (it has extension points), so we 
would expect the Permissions WG/CG to come up with a proper way to deal with 
permissions. If they come to the conclusion that we need some permission field 
in the manifest, their spec can add that. It is not yet clear at this point 
that that is the solution that they are aiming at.

Cheers,
Kenneth

On Thu, Mar 5, 2015 at 4:50 PM Nilsson, Claes1 
claes1.nils...@sonymobile.commailto:claes1.nils...@sonymobile.com wrote:
Hi,

We support that this version of the specification is moved to Candidate status 
but we have a few comments/questions:

In this version 1 we miss:

* A permissions field
* A content security policy field. This is only included as a way to state 
allowed origins from which the manifest file itself could be loaded. However, 
there is, in this first version, no CSP-field defined for the manifest 
document, allowing restriction of origins the web app could download scripts 
and other content types from. There is also a draft companion document, 
http://w3c.github.io/manifest-csp/, defining this CSP-member of the manifest.

We consider the above features important for allowing server hosted web apps 
access to more sensitive APIs and have been experimenting with this for FFOS:
https://lists.w3.org/Archives/Public/public-sysapps/2014Sep/att-/SoMC_FFOS_Trusted_Hosted_Apps.pdf.
 Accordingly we want to discuss these features for the further work on the 
manifest specification.

We also would like to ask the WG if it has been discussed if https: transport 
should be required for downloading the manifest? Other specifications are 
moving towards requirement for https:. See for example the discussion 
https://lists.w3.org/Archives/Public/public-device-apis/2015Feb/0045.html. For 
the manifest version 1 this may not be critical but if above features are added 
the transport probably have to be protected.

However, once again note that these comments do not prevent that we support 
that the current version of the manifest is moved to candidate status, I am 
just taking the opportunity state our views on the further work on the manifest 
specification.

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:claes1.nils...@sonymobile.com

sonymobile.comhttp://sonymobile.com




 -Original Message-
 From: Arthur Barstow 
 [mailto:art.bars...@gmail.commailto:art.bars...@gmail.com]
 Sent: den 13 februari 2015 01:31
 To: public-webapps
 Subject: RfC: Manifest for web application; review deadline March 5

 [ Bcc: public-webappsec, www-style, public-privacy, public-sysapps,
 public-digipub-ig, public-pfwg, public-web-mobile, www-international,
 chairs^1, public-review-announce; Reply-to: public-webapps ]

 This is a Request for Comments (RfC) for WebApp's Manifest for web
 application specification:

 http://www.w3.org/TR/2015/WD-appmanifest-20150212/

 This specification defines a JSON-based manifest that provides
 developers with a centralized place to put metadata associated with a
 web application.

 This Working Draft is intended to meet the wide review requirements as
 defined in the 2014 Process Document. The deadline for comments is 5
 March 2015 and all comments should be sent to the public-webapps @
 w3.orghttp://w3.org mail list [Archive] with a Subject: prefix of 
 [manifest]. The
 next anticipated publication of this specification is a Candidate
 Recommendation. (See [CR-Plan] for the specification's Candidate
 Recommendation status.)

 WebApps welcomes review and comments from all individuals and/or groups
 and we explicitly ask the following groups to review the document and
 to submit comments: WebAppSec, CSS WG (in particular, the display
 mode
 media feature), PING, SysApps, Digital Publishing IG, WAI (PF, User
 Agent, Authoring Tools), and I18N WG.

 In addition to substantive comments, to help us get a sense of how much
 review the document receives, we also welcome data about silent
 reviews, f.ex. I reviewed section N.N and have no comments.

 -Thanks, AB

 ^1 RfC is the new LCWD TransAnn
 [CR-Plan] https://github.com/w3c/manifest/issues/308
 [Archive] https://lists.w3.org/Archives/Public/public-webapps/