[Bug 26033] New: Make distribution algorithm forward compatible with as function call.

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26033

Bug ID: 26033
   Summary: Make distribution algorithm forward compatible with
 as function call.
   Product: WebAppsWG
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Component Model
  Assignee: dglaz...@chromium.org
  Reporter: wc...@mozilla.com
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org

Opening this bug to continue
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24288#c2

Bug 24288 reverted  as a function call behavior due to an
implementation difficulty in blink and it looks like the intent was to remove
the behavior until a reasonable implementation is found.

The spec change in bug 24288 neuters children of the  element to
preserve its use for the future, but it should also prevent distribution of
nodes into content insertion points of older shadow trees if we want to be able
to reintroduce  as a function call. Right now, the behavior is to
distribute 'left over' nodes in the distribution pool.

This can be done by bringing back "Let POOL be an empty ordered list."

in
https://github.com/w3c/webcomponents/commit/61745e0b40c8d609ad1070e7babc7915fca637ea

I bring this up because it seems like the intent was to eventually reintroduce
 as a function call and it looks like people are interested in this
feature.

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

RE: IE - Security error with new Worker(URL.createObjectURL(new Blob([workerjs],{type:'text/javascript'})))

[Travis Leithead]

Unfortunately, there is not presently a way for you to track it externally. :-(

MS Connect is the best we have so far, and I know that it is not great. We 
recognize this is a problem and hope to be able to improve the situation soon.
 
-Original Message-
From: Aymeric Vitte [mailto:vitteayme...@gmail.com] 
Sent: Tuesday, June 10, 2014 3:00 AM
To: Travis Leithead; Web Applications Working Group WG (public-webapps@w3.org)
Subject: Re: IE - Security error with new Worker(URL.createObjectURL(new 
Blob([workerjs],{type:'text/javascript'})))

Thanks, any way to track/be notified when this will be available?

Regards

Aymeric

Le 06/06/2014 19:42, Travis Leithead a écrit :
> Well, in IE's defense, this is not specifically allowed by: 
> http://www.w3.org/TR/workers/#dom-worker. Regardless, the product team is 
> working to fix this so that it works in IE as well. Stay tuned. I updated the 
> Connect bug below.
>
> -Original Message-
> From: Aymeric Vitte [mailto:vitteayme...@gmail.com]
> Sent: Friday, June 6, 2014 6:25 AM
> To: Web Applications Working Group WG (public-webapps@w3.org)
> Cc: Travis Leithead
> Subject: IE - Security error with new Worker(URL.createObjectURL(new 
> Blob([workerjs],{type:'text/javascript'})))
>
> Why IE(11) does not allow this while this is working on FF and Chrome?
> [1] seems to suggest that it is "by design".
>
> Regards
>
> Aymeric
>
> [1]
> https://connect.microsoft.com/IE/feedback/details/779379/unable-to-spawn-worker-from-blob-url
>

-- 
Peersm : http://www.peersm.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

Re: Custom-elements: document.registerPolyfillElement ?

[Brett Zamir]

Thanks, this is helpful to know, though I'd still prefer a solution at 
some point which didn't require one to use extra code and once the 
polyfill was no longer needed, requiring alteration of code to be 
semantically correct (e.g., if it no longer is a "x-polyfill-dialog" 
because the registration for it was removed) and non-redundant.


Best wishes,
Brett

On 6/10/2014 2:00 PM, Dominic Cooney wrote:
On Mon, Jun 9, 2014 at 4:00 PM, Brett Zamir > wrote:


I was looking to make a genuine polyfill for  (not just a
shim), and I found Polymer's CustomElements helpful, but realized
too late that the spec required "x-" prefixes.

I still feel like it would be useful to have a means for polyfills
to be built according to well-recognized semantics via a standard
extension mechanism.


It is possible to do this using a "type extension". For example:

document.register('x-polyfill-dialog', {prototype: ..., extends: 
'dialog'})


This produces a type extension of the HTMLUnknownElement with the tag 
name "dialog" in browsers that don't support dialog, and a type 
extension of the HTMLDialogElement of ones that do.


The only wrinkle is that markup must use .

Your polyfill can degrade gracefully in whichever way you decide. For 
example, you could detect HTMLDialogElement and not register the 
Custom Element, in which case the markup will create unresolved type 
extensions of HTMLDialogElement that get the browser's native dialog. 
Or you could go ahead and register your polyfill anyway, in which case 
your prototype object would hide the browser's HTMLDialogElement 
prototype. Or you could do something dynamic inbetween.


HTH,

Dominic

Re: [webcomponents]: Telcon on as-needed basis from now on

[Arthur Barstow]

On 6/9/14 12:09 PM, Dimitri Glazkov wrote:

I think it might be best to flip the "regular" bit to "off" for now,
and only use this time slot when we have other participants. Thus,
consider the weekly call cancelled unless there's an announcement
otherwise.


That sounds like a good plan Dimitri.


Another idea Hayato-san and I discussed is moving it to Tokyo-friendly
timezone, so that him and I could just use as a weekly spec
coordination call, rather than office hours-style arrangement.


I think that would be fine too (D3E's call is 17:00 PM SFO time for that 
reason), provided  has a chance to voice a contrary opinion (and I need 
a day or two to change the voice conf reservation.


-Thanks, AB

Re: IE - Security error with new Worker(URL.createObjectURL(new Blob([workerjs],{type:'text/javascript'})))

[Aymeric Vitte]

Thanks, any way to track/be notified when this will be available?

Regards

Aymeric

Le 06/06/2014 19:42, Travis Leithead a écrit :

Well, in IE's defense, this is not specifically allowed by: 
http://www.w3.org/TR/workers/#dom-worker. Regardless, the product team is 
working to fix this so that it works in IE as well. Stay tuned. I updated the 
Connect bug below.

-Original Message-
From: Aymeric Vitte [mailto:vitteayme...@gmail.com]
Sent: Friday, June 6, 2014 6:25 AM
To: Web Applications Working Group WG (public-webapps@w3.org)
Cc: Travis Leithead
Subject: IE - Security error with new Worker(URL.createObjectURL(new 
Blob([workerjs],{type:'text/javascript'})))

Why IE(11) does not allow this while this is working on FF and Chrome?
[1] seems to suggest that it is "by design".

Regards

Aymeric

[1]
https://connect.microsoft.com/IE/feedback/details/779379/unable-to-spawn-worker-from-blob-url



--
Peersm : http://www.peersm.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

Re: HTML imports: new XSS hole?

[Anne van Kesteren]

On Tue, Jun 10, 2014 at 10:36 AM, Frederik Braun  wrote:
> Were you saying  or  import>?

The former. The latter is reserved for loading and executing scripts.


> I, by the way, wholeheartedly agree that  tags become more
> dangerous through HTML imports and that they are somehow breaking the
> dogma of "security by no surprises" :)


-- 
http://annevankesteren.nl/

Re: HTML imports: new XSS hole?

[Frederik Braun]

On 04.06.2014 11:00, Anne van Kesteren wrote:
> On Tue, Jun 3, 2014 at 7:20 PM, Oda, Terri  wrote:
>> Perhaps it would make sense to also require explicit allowing of imports via
>> CSP?  Scripts are allowed when no CSP is provided for historical
>> compatibility so you'd need to make sure that imports fell under a separate
>> directive, but there's no need for backwards compatibility so it probably
>> makes sense to choose a more conservative default behaviour for HTML
>> Imports.
> 
> Using  seems like a solution that would be better in
> that case, as it does not provide opt-in through HTTP. Whenever we
> require HTTP for a feature, we get a ton of complaints. And