Re: Custom-elements: document.registerPolyfillElement ?
On Mon, Jun 9, 2014 at 4:00 PM, Brett Zamir bret...@gmail.com wrote:
I was looking to make a genuine polyfill for dialog (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 dialog is=x-polyfill-dialog.
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: Blob URL Origin
On Tue, Jun 10, 2014 at 12:16 AM, Arun Ranganathan a...@mozilla.com wrote: Right now, the Blob URL Store is defined in terms of units of similar-origin browsing contexts; each unit is required to have a Blob URL Store. As you point out, that allows all origins within document.domain access to a given Blob URL Store. Yeah, so unlike what the discussion claimed thus far, we did not in fact allow that much cross-origin blob URL usage. Only origins within the document.domain reach. 1. Require that entries in the Blob URL Store also store origin I thought this was the idea. The identifier would be http://someorigin:70/uuid;. 2. Define it strictly as a same-origin store. I’m a bit fuzzy on how exactly to define this; for instance, strictly the origin and not the effective script origin of a Document? We could say that the store is bound to a global object. And then both URL.createObjectURL() and places that parse URLs hook into the entry setting object's global object's blob URL store. At that point the only benefit of putting the origin into the URL is so that new URL(blob).origin works. Something that is still unclear to me is what happens when you navigate to a blob URL. I guess that still technically works as the URL parsing would happen within the correct global. -- http://annevankesteren.nl/
Re: HTML imports: new XSS hole?
On 04.06.2014 11:00, Anne van Kesteren wrote: On Tue, Jun 3, 2014 at 7:20 PM, Oda, Terri terri@intel.com 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 script import 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 script import is not that bad authoring-wise either: script import/script link rel=import href (Okay, you win two code points if you omit the quotes with link.) Were you saying script import=url/script or script src=url import/script? I, by the way, wholeheartedly agree that link tags become more dangerous through HTML imports and that they are somehow breaking the dogma of security by no surprises :)
Re: HTML imports: new XSS hole?
On Tue, Jun 10, 2014 at 10:36 AM, Frederik Braun fbr...@mozilla.com wrote: Were you saying script import=url/script or script src=url import/script? The former. The latter is reserved for loading and executing scripts. I, by the way, wholeheartedly agree that link tags become more dangerous through HTML imports and that they are somehow breaking the dogma of security by no surprises :) -- http://annevankesteren.nl/
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: [webcomponents]: Telcon on as-needed basis from now on
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: Custom-elements: document.registerPolyfillElement ?
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 bret...@gmail.com
mailto:bret...@gmail.com wrote:
I was looking to make a genuine polyfill for dialog (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 dialog is=x-polyfill-dialog.
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: IE - Security error with new Worker(URL.createObjectURL(new Blob([workerjs],{type:'text/javascript'})))
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
[Bug 26033] New: Make distribution algorithm forward compatible with shadow as function call.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26033 Bug ID: 26033 Summary: Make distribution algorithm forward compatible with shadow 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 shadow 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 shadow 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 shadow 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 shadow 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.
