Re: [webcomponents] Proposal for Cross Origin Use Case and Declarative Syntax

[Scott Miles]

> pollute the window object with $, with ES6 modules around the corner

The $ was just an example, the import could also happily define one or more
modules. This concept allows us to decouple scoping from imports.

Now, the import is only a vehicle, but it advances the state of the art by
also delivering canonical HTML and CSS (instead of requiring JavaScript to
load or encode additional resources). We right away have an efficient
method for draining some of the existing resource management swamp.

>From there I can see paths to supporting opt-in isolation models, either
directly, or by delegating to an agent like DOMWorker.


On Tue, Nov 12, 2013 at 3:21 PM, Brian Di Palma  wrote:

> I'm not sure I would want jQuery UI to pollute the window object with
> $, with ES6 modules around the corner it seems like a step backwards
> for imports to start polluting window objects with their libraries...
>
> On Tue, Nov 12, 2013 at 9:01 PM, Elliott Sprehn  wrote:
> >
> > On Tue, Nov 12, 2013 at 12:45 AM, Ryosuke Niwa  wrote:
> >>
> >> [...]
> >>
> >> Script in the import is executed in the context of the window that
> >> contains the importingdocument. So window.document refers to the main
> page
> >> document. This has two useful corollaries:
> >>
> >> functions defined in an import end up on window.
> >> you don't have to do anything crazy like append the import's 

Re: [webcomponents] Proposal for Cross Origin Use Case and Declarative Syntax

[Ryosuke Niwa]

On Nov 13, 2013, at 7:21 AM, Brian Di Palma  wrote:

> I'm not sure I would want jQuery UI to pollute the window object with
> $, with ES6 modules around the corner it seems like a step backwards
> for imports to start polluting window objects with their libraries…

Indeed!

> On Tue, Nov 12, 2013 at 9:01 PM, Elliott Sprehn  wrote:
>> 
>> On Tue, Nov 12, 2013 at 12:45 AM, Ryosuke Niwa  wrote:
>>> 
>>> [...]
>>> 
>>> Script in the import is executed in the context of the window that
>>> contains the importingdocument. So window.document refers to the main page
>>> document. This has two useful corollaries:
>>> 
>>> functions defined in an import end up on window.
>>> you don't have to do anything crazy like append the import's 

Re: [webcomponents] Proposal for Cross Origin Use Case and Declarative Syntax

[Brian Di Palma]

I'm not sure I would want jQuery UI to pollute the window object with
$, with ES6 modules around the corner it seems like a step backwards
for imports to start polluting window objects with their libraries...

On Tue, Nov 12, 2013 at 9:01 PM, Elliott Sprehn  wrote:
>
> On Tue, Nov 12, 2013 at 12:45 AM, Ryosuke Niwa  wrote:
>>
>> [...]
>>
>> Script in the import is executed in the context of the window that
>> contains the importingdocument. So window.document refers to the main page
>> document. This has two useful corollaries:
>>
>> functions defined in an import end up on window.
>> you don't have to do anything crazy like append the import's 

Re: [webcomponents] Proposal for Cross Origin Use Case and Declarative Syntax

[Elliott Sprehn]

On Tue, Nov 12, 2013 at 12:45 AM, Ryosuke Niwa  wrote:

> [...]
>

>- Script in the import is executed in the context of the window that
>contains the importingdocument. So window.document refers to the main
>page document. This has two useful corollaries:
>   - functions defined in an import end up on window.
>   - you don't have to do anything crazy like append the import's
>   

Re: Thoughts behind the Streams API ED

[Aymeric Vitte]

OK, thanks, let's see what happens...

Regards

Aymeric

Le 12/11/2013 09:54, Takeshi Yoshino a écrit :
On Tue, Nov 12, 2013 at 5:20 PM, Aymeric Vitte > wrote:


Takeshi,

See discussion here too: https://github.com/whatwg/streams/issues/33

The problem with stop again is that I need to handle myself the
clone operations, the advantage of stop-eof is:

- clone the operation
- close it
- restart from the clone

And as I mentioned before this would work for any operation that
has unresolved bytes (TextDecoder, etc) without the need of
modifying the operation API for explicit clones or options.


OK. I understood your needs.

As explained in the previous mail, if we decide to take in your 
suggestion, I'd implement your stop-eof as a more generic in-band 
control signal. In other words, changing the draft to propose message 
stream than byte stream.


I estimate that this feature sophisticates implementation much. So, I 
want to hear more support and justification.


For now, I filed a bug to track discussion. 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23799


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

Re: Thoughts behind the Streams API ED

[Takeshi Yoshino]

On Tue, Nov 12, 2013 at 5:20 PM, Aymeric Vitte wrote:

>  Takeshi,
>
> See discussion here too: https://github.com/whatwg/streams/issues/33
>
> The problem with stop again is that I need to handle myself the clone
> operations, the advantage of stop-eof is:
>
> - clone the operation
> - close it
> - restart from the clone
>
> And as I mentioned before this would work for any operation that has
> unresolved bytes (TextDecoder, etc) without the need of modifying the
> operation API for explicit clones or options.
>

OK. I understood your needs.

As explained in the previous mail, if we decide to take in your suggestion,
I'd implement your stop-eof as a more generic in-band control signal. In
other words, changing the draft to propose message stream than byte stream.

I estimate that this feature sophisticates implementation much. So, I want
to hear more support and justification.

For now, I filed a bug to track discussion.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23799

[Bug 23799] New: [Streams API] Feature req: in-band control signal

[bugzilla]

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

Bug ID: 23799
   Summary: [Streams API] Feature req: in-band control signal
   Product: WebAppsWG
   Version: unspecified
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Streams API
  Assignee: tyosh...@google.com
  Reporter: tyosh...@google.com
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org

Request from Aymeric to make it able to transfer signals that can be
distinguished from ordinary byte stream.

For example, we can have TextDecoder understand such a signal. When TextDecoder
sees a signal, it flushes decodable bytes preceding the signal in its buffer as
a DOMString while keeping non-decodable bytes in the buffer.

His use case is making hash calculator to emit partial hash when received such
a signal.

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

Re: [webcomponents] Proposal for Cross Origin Use Case and Declarative Syntax

[Ryosuke Niwa]

On Nov 12, 2013, at 8:12 AM, Dimitri Glazkov  wrote:
> On Sun, Nov 10, 2013 at 6:49 PM, Arthur Barstow  wrote:
> On 11/9/13 3:24 AM, ext Ryosuke Niwa wrote:
> Hi all,
> 
> We have been discussing cross-orign use case and declarative syntax of web 
> components internally at Apple, and here are our straw man proposal to amend 
> the existing Web Components specifications to support it.
> 
> *1. Modify HTML Imports to run scripts in the imported document itself*
> 
> This allows the importee and the importer to not share the same script 
> context, etc…
> 
> This could be an option and shouldn’t be the default.

I don’t think we want to add a yet another flag to control the behavior.

> By running scripts in a different context, we are ejecting the primary use 
> case of enabling frameworks/libraries to better manage their assets and 
> dependencies (aka the Bootstrap use case).

That would force same-origin and cross-origin use cases to have different 
behaviors because we can’t run the untrusted script in the host document.

In particular, it’s important for the global (window) object to have a 
consistent behavior between untrusted cross-origin and trusted same-origin use 
cases.

> Rob Dodson’s article has a nice progression explaining the use case: 
> http://robdodson.me/blog/2013/08/20/exploring-html-imports/

I don’t think this blog post contains any argument for either behavior.

> Also, check out newly minted Eric Bidelman's article on imports (especially 
> the use cases section at the bottom): 
> http://www.html5rocks.com/en/tutorials/webcomponents/imports/

I see the following argument for the current behavior:
Script in the import is executed in the context of the window that contains the 
importingdocument. So window.document refers to the main page document. This 
has two useful corollaries:
functions defined in an import end up on window.
you don't have to do anything crazy like append the import's  blocks to 
the main page. Again, script gets executed.
What we’re proposing is to execute the script in the imported document so the 
only real argument is the point that “functions defined in an imported end up 
on window” (of the host document).

I think that’s a bad thing.  We don’t want imported documents to start 
polluting global scope without the user explicitly importing them.  e.g. 
"import X" in Python doesn’t automatically import stuff inside the module into 
your global scope.  To do that, you explicitly say “import * from X”.  
Similarly, “using std” is discouraged in C++.

I don’t think the argument that this is how external script and stylesheet fly 
either because the whole point of web components is about improving the 
modularity and reusability of the Web.

> Re: Custom Elements LC, this is an issue to handle in HTML Imports 
> specification, not related to Custom Elements. 
> 
> 
> *2. Add “importcomponents" content attribute on link element*
> 
> It defines the list of custom element tag names to be imported from the 
> imported HTML document.
> e.g.  will export 
> custom elements of tag names "tag-1" and "tag-2" from ~. Any name that didn't 
> have a definition in the import document is ignored (i.e. if "tag-2" was not 
> defined in ~, it would be skipped but "tag-1" will be still imported).
> 
> This mechanism prevents the imported document from defining arbitrary 
> components in the host document.
> 
> Re: Custom Elements LC, this should be handled in HTML Imports specification. 
> HTML Imports can rely on Custom Elements specification. Any additional hooks 
> that could be needed to facilitate this feature could be added in Custom 
> Elements Level 2 specification.
>  
> 
> *3. Support "static" (write-once) binding of a HTML template*
> 
> e.g.
> 
>