Re: RfC: LCWD of Custom Elements; deadline November 21

[Bjoern Hoehrmann]

* Ryosuke Niwa wrote:
>Now we know that there has been an effort to decouple the various Web 
>Components
>features and specifications, and the Custom Elements specification was going to
>the Last Call on its own.
>
>Unfortunately, we didn't know about this until fairly recently, which is why 
>our
>thorough review of these specifications did not happen until mid-September
>(by which time this spec had already reached the Last Call).

To ensure fair application of section 3.5 of the W3C Process document in
the future, I would like to note that I consider this a failure to meet
obligations as per section 6.2.1.7 of the current W3C Process document.
This also demonstrates that the "CfC" process fails to meet requirements
under section 3.3 of the current W3C Process document in matters related
to section 7 of the same.
-- 
Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: Cross Origin Web Components: Fixing iframes

[Dominic Cooney]

On Wed, Dec 4, 2013 at 11:45 AM, Ryosuke Niwa  wrote:

>
> On Nov 26, 2013, at 10:15 PM, Dominic Cooney  wrote:
>
> On Wed, Nov 27, 2013 at 2:19 PM, Ryosuke Niwa  wrote:
>
>>
>> On Nov 27, 2013, at 8:57 AM, Dominic Cooney  wrote:
>>
>> On Tue, Nov 26, 2013 at 2:03 PM, Ryosuke Niwa  wrote:
>>
>>> Hi,
>>>
>>> I have been having informal discussions of our earlier proposal for
>>> cross-orign use cases and declarative syntax for web components, and I
>>> realized there was a lot of confusion about our motivations and decision
>>> decisions.  So I wanted to explain why/how we came up that proposal in this
>>> email.
>>>
>>>
>>> *Problem*: A lot of websites embed SNS widgets, increasing the security
>>> surface of embedders.  The old version of techcrunch.com, for example,
>>> had 5+ social share buttons on each article.  If any one of those SNS
>>> websites got compromised, then the embedder will also get compromised.
>>>
>>
>> This is a valid problem. Does anyone have related use cases that might be
>> in-scope for this discussion?
>>
>>
>> Comment forms (e.g. DISQUS) is another important use case.
>>
>> *What if we used iframe?*
>>> What if we replaced each such instance with an iframe?  That would give
>>> us a security boundary.
>>>
>>> On the other hand, using an iframe for each social button is very
>>> expensive because each iframe loads a document, creates its own security
>>> origin, JS global object, and so forth. Initializing new script context
>>> (a.k.a. "VM", "world", "isolate", etc…) for every single SNS widget on a
>>> page is quite expensive.  If we had 10 articles, and each article had 5
>>> social buttons, we'll have 50 iframes, each of which needs to load
>>> megabytes of JavaScript.
>>>
>>> iframe is also heavily restricted in terms of its ability to layout
>>> itself. Comment widgets (e.g. DISQUS) for example need to stretch
>>> themselves to the height of its content.
>>>
>>> We also need a better mechanism to pass arguments and communicate with
>>> cross-origin frames than postMessage.
>>>
>>>
>>> *What if we made iframe lighter & used seamless iframe?*
>>> The cost of iframe could be reduced substantially if we cached and
>>> internally shared each page's JavaScript.  However, we still have to
>>> instantiate its own script context, document, and window objects.
>>>
>>> We can also use seamless iframe to address the comment widget use case.
>>>
>>>
>>> *What if we let each iframe create multiple "views"?*
>>> The problem with using an iframe for a cross-origin widget is that each
>>> iframe creates its own document, window, etc… even if there are multiple
>>> widgets from the same origin.  e.g. if we had a tweet button on 10
>>> different articles, we have to create its own document ,window, etc… for
>>> each tweet button.
>>>
>>> We can reduce this cost if we could share the single frame, and have it
>>> render multiple "views".  Naturally, each such view will be represented as
>>> a separate DOM tree.  In this model, a single iframe owns multiple DOM
>>> trees, each of which will be displayed at different locations in the host
>>> document.  Each such a DOM tree is inaccessible from the host document, and
>>> the host document is inaccessible from the iframe.
>>>
>>> This model dramatically reduces the cost of having multiple widgets from
>>> the same origin.  e.g. if we have 10 instances of widgets from 5 different
>>> social networks, then we'll have only 5 iframes (each of which will have 10
>>> "views") as opposed to 50 of them.
>>>
>>>
>>> *What if we provided a declarative syntax to create such a view?*
>>> Providing a better API proved to be challenging.  We could have let page
>>> authors register a custom element for each cross-origin widget but that
>>> would mean that page authors have to write a lot of script just to embed
>>> some third-party widgets.  We need some declarative syntax to let authors
>>> wrap an iframe.
>>>
>>> Furthermore, if we wanted to use the multiple-views-per-iframe, then
>>> we'll need a mechanism to declare where each instance of such a view is
>>> placed in the host document with arguments/configuration options for each
>>> view.
>>>
>>> A custom element seemed like a natural fit for this task but the
>>> prototype/element object cannot be instantiated in the host document since
>>> the cross-origin widgets' script can't run in the host document and
>>> prototype objects, etc… cannot be shared between the host document and the
>>> shared iframes.  So we'll need some mechanism for the shared iframe to
>>> define custom element names, and have the host document explicitly import
>>> them as needed.
>>>
>>>
>>> At this point, the set of features we needed looked very similar to the
>>> existing custom element and shadow DOM.  Each "view" of the shared iframe
>>> was basically a shadow DOM with a security boundary sitting between the
>>> host element and the shadow root.  The declarative syntax for the "view"
>>> was basically a declarative syntax of

Re: [webcomponents] HTML Imports

[Bjoern Hoehrmann]

* Brian Di Palma wrote:
>Neither did I mean it to be taken to mean "This work is rushed". I said,
>
>"I get the feeling that Web Components seems a specification that
>seems really pushed/rushed",
>
>by that I meant it seemed as if the current spec is being pushed as
>fast as possible toward standardization.

As far as I can tell, the Web Components proponents have been very clear
in the past that they want something very soon, including that they are
willing to live with issues that cannot be solved soon. So, sure, they
are pushing this.

>I was not commenting on the amount of time put into making the spec
>but more the amount of time given to interested parties to digest,
>implement, and comment on it.

I believe the general sentiment in the Working Group is that feedback
coming from people developing applications running in web browsers is
extremely sought after. They do not, however, have much of an interest
in creating an environment where such people can easily and do gladly
provide such feedback when it would be most useful. Ordinarily there
would be mandatory procedures Working Groups and Working Group parti-
cipants are held to that should provide such an environment.

But as you can see in a nearby thread, it's already too much to ask of
the Chairs that they make sure Apple and Mozilla have finished their
final review of the "Custom Elements" draft and are satisfied that all
their comments have been addressed before considering it ready for Last
Call. That has destroyed Last Call as a synchronisation mechanism, you
cannot use it to prioritise reviews because you do not know whether any
given Last Call will have one, two, or six more following it. That re-
sults in "late" comments and late changes which make temporal planning
impossible. People get frustrated that things take so long, that they
cannot keep up with the pace, stuff falls through the cracks, and so on.
-- 
Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: RE : Sync IO APIs in Shared Workers

[Charles Pritchard]

On 12/4/13, 2:43 AM, Ke-Fong Lin wrote:

IMHO, we should make sync APIs available in both dedicated and shared workers.
In order of importance:

1) Sync APIs are inherently easier to use than async ones, and they are much
less error prone. JS developers are not C++ developers. Whenever possible, it's
just better to make things more simpler and convenient.


This argument is not particularly helpful. Apart from that, many JS APIs 
use callbacks,

all developers are-or-have to be aware of them.


2) Sync APIs do the job. We are talking about web-apps, not heavy load servers.
High performance applications will use async APIs anyway. I'd rather think there
are a lot of use cases where the dedicated or shared worker would do a lot of 
small
and short duration work, suitable for sync coding. Why force the complication 
of async
on developers ? If easy things can be done easily, then let it be.


Promises seem to have solved quite a it of the syntactic cruft/issues.
Devs are already in an async world when doing JS.


3) It does no harm.


It's not particularly fun re-writing async methods from the webpage to 
be sync for workers, or otherwise using shims to avoid redundancy. The 
extra semantic load on the namespaces (docs and otherwise) isn't all 
that pleasing either. There is a cost.

Re: [HTML Imports]: what scope to run in

[Jonas Sicking]

On Sat, Nov 23, 2013 at 1:51 AM, Jonas Sicking  wrote:
> One thing that we did discuss but that I think we never reached a
> conclusion on was if imported HTML documents need to block 
> tags in the main document. Otherwise there's a risk that named modules
> introduced by the imported HTML document won't be known at the time
> when name resolution happens in the main document. Whether this is a
> problem or not depends on now this name resolution works. I think this
> is still an outstanding question to resolve.

Some further thoughts.

ES6 modules does not have a way for sub-modules to add additional
names. Only top-level  elements can introduce new named
modules.

Following that logic, a HTML-imported document should not be allowed
to introduce additional names. I.e. they can use  elements,
but those  elements should not be able to add new named
modules. Only the top-level HTML document should be able to use
 to introduce names.

If we do that, then that might reduce the race-problems around names
that we were discussing.

/ Jonas

Re: [webcomponents] HTML Imports

[Brian Di Palma]

I never meant my comments to be taken as a slight toward anyone
involved in the Web Components work.
Neither did I mean it to be taken to mean "This work is rushed". I said,

"I get the feeling that Web Components seems a specification that
seems really pushed/rushed",

by that I meant it seemed as if the current spec is being pushed as
fast as possible toward standardization.

I was not commenting on the amount of time put into making the spec
but more the amount of time given to interested parties to digest,
implement, and comment on it.
I believe Dimitri has responded to comments to this effect by
extending the time between spec transitions.

I'm very excited by the possibilities that Web Components open up.
I would love to see the representatives from all the implementers as
excited or convinced about the spec.

On Wed, Dec 4, 2013 at 7:30 PM, Rafael Weinstein  wrote:
> On Wed, Dec 4, 2013 at 10:37 AM, Dimitri Glazkov 
> wrote:
>>
>> On Wed, Dec 4, 2013 at 9:56 AM, Dimitri Glazkov 
>> wrote:
>>>
>>> On Wed, Dec 4, 2013 at 4:32 AM, Anne van Kesteren 
>>> wrote:

 On Wed, Dec 4, 2013 at 9:21 AM, Brian Di Palma  wrote:
 > I would say though that I get the feeling that Web Components seems a
 > specification that seems really pushed/rushed and I worry that might
 > lead to some poor design decisions whose side effects will be felt by
 > developers in the future.

 I very much share this sentiment.
>>>
>>>
>>> It's a very reasonable and normal worry to have. I lose sleep over this
>>> worry all the time. The trick that helps me is balancing it out with the
>>> sadness of the geological timescale that it takes for Web platform to
>>> advance.
>>
>>
>> Just to help visualize the geological timescale, the work on Web
>> Components began in late 2010
>> (http://wiki.whatwg.org/index.php?title=Component_Model_Use_Cases&oldid=5631),
>> and was chartered in this WG over 2 years ago
>> (http://www.w3.org/2008/webapps/wiki/CharterChanges#Additions_Agreed).
>>
>> To clarify my previous email: Web Components is an extremely hard problem
>> with lots of constraints, and a concern would be that we miss some bits is
>> totally fair. Qualifying this work as "pushed/rushed" probably ain't.
>
>
> I'd like to make an aside about having respect for one-another's work.
>
> Dimitri, Alex, Dominic, Scott, Elliot and many others have put massive time
> into this problem over the course of many years now, and my view is that the
> design has evolved and accommodated a dizzying number of challenges and
> constraints.
>
> "What this is attempting is big & scary" is fair. "I haven't had time to
> digest the design" is fair. "I have the following specific issues" is fair.
> "This work is rushed" is always understood as an indictment.
>
> I've seen too many talented people vote with their feet and decide life will
> be less frustrating working on a closed system. Let's remember we're all on
> the same team.
>
> AFAICT, evolving the web is fundamentally an exercise in not letting perfect
> be the enemy of good. I have no doubt Web Components is imperfect, but from
> what I can tell, it is *extremely* good.
>
> Also, go hug your mother.
>
>
>>
>>
>> :DG<
>
>

Re: Request for feedback: Streams API

[Rob Manson]

Hi Feras/Takeshi,

thanks for proactively dealing with all our feedback 8)

I'll definitely see if there's any further feedback on the updated spec 
from the people that participated at the FOMS session.


And I'd also be happy to do the same with the Media Capture and Streams 
TF/WG too as this relates directly to the post-processing use cases I'm 
particularly interested in.


roBman


On 5/12/13 8:04 AM, Feras Moussa wrote:

Thanks Art.

We've also had Rob (cc'd) interested from the FOMS (Open Media Standards) 
group. I'll follow up with Rob for further feedback from that group.


In the spec, we tried to capture all the various areas we think this spec can 
affect - this is the stream consumers/producers section 
(http://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm#producers-consumers)

In addition to the ones you've outlined,the one that comes to mind from the 
list in the spec would be the web-crypto group.

-Feras



Date: Wed, 4 Dec 2013 12:57:50 -0500
From: art.bars...@nokia.com
To: feras.mou...@hotmail.com; dome...@domenicdenicola.com; 
vitteayme...@gmail.com
CC: public-webapps@w3.org
Subject: Re: Request for feedback: Streams API

Thanks for the update Feras.

Re getting `wide review` of the latest [ED], which groups, lists and
individuals should be asked to review the spec?

In IRC just now, jgraham mentioned TC39, WHATWG and Domenic. Would
someone please ask these two groups to review the latest ED?

Aymeric - would you please ask the WebRTC list(s) to review the latest
ED or provide the list name(s) and I'll ask them.

-Thanks, ArtB

[ED] 

On 12/4/13 11:27 AM, ext Feras Moussa wrote:

The editors of the Streams API have reached a milestone where we feel
many of the major issues that have been identified thus far are now
resolved and incorporated in the editors draft.

The editors draft [1] has been heavily updated and reviewed the past
few weeks to address all concerns raised, including:
1. Separation into two distinct types -ReadableByteStream and
WritableByteStream
2. Explicit support for back pressure management
3. Improvements to help with pipe( ) and flow-control management
4. Updated spec text and diagrams for further clarifications

There are still a set of bugs being tracked in bugzilla. We would like
others to please review the updated proposal, and provide any feedback
they may have (or file bugs).

Thanks.
-Feras


[1] https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm

Re: Last Call for High Resolution Time Level 2

[Anne van Kesteren]

On Wed, Dec 4, 2013 at 7:04 PM, Jatinder Mann  wrote:
> ... by creating a separate WorkerPerformance interface we can ensure that the
>  High Resolution Time Level 2 spec is only defining the now() method in the
> worker scope.

Given that the global environment is different, you don't technically
need a new interface name. IDL still needs upgrading to deal better
with workers, but naming interfaces differently for workers that do
not have to be named differently seems unneeded.


-- 
http://annevankesteren.nl/

RE: Request for feedback: Streams API

[Feras Moussa]

Thanks Art.

We've also had Rob (cc'd) interested from the FOMS (Open Media Standards) 
group. I'll follow up with Rob for further feedback from that group.


In the spec, we tried to capture all the various areas we think this spec can 
affect - this is the stream consumers/producers section 
(http://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm#producers-consumers)

In addition to the ones you've outlined,the one that comes to mind from the 
list in the spec would be the web-crypto group.

-Feras


> Date: Wed, 4 Dec 2013 12:57:50 -0500
> From: art.bars...@nokia.com
> To: feras.mou...@hotmail.com; dome...@domenicdenicola.com; 
> vitteayme...@gmail.com
> CC: public-webapps@w3.org
> Subject: Re: Request for feedback: Streams API
>
> Thanks for the update Feras.
>
> Re getting `wide review` of the latest [ED], which groups, lists and
> individuals should be asked to review the spec?
>
> In IRC just now, jgraham mentioned TC39, WHATWG and Domenic. Would
> someone please ask these two groups to review the latest ED?
>
> Aymeric - would you please ask the WebRTC list(s) to review the latest
> ED or provide the list name(s) and I'll ask them.
>
> -Thanks, ArtB
>
> [ED] 
>
> On 12/4/13 11:27 AM, ext Feras Moussa wrote:
>> The editors of the Streams API have reached a milestone where we feel
>> many of the major issues that have been identified thus far are now
>> resolved and incorporated in the editors draft.
>>
>> The editors draft [1] has been heavily updated and reviewed the past
>> few weeks to address all concerns raised, including:
>> 1. Separation into two distinct types -ReadableByteStream and
>> WritableByteStream
>> 2. Explicit support for back pressure management
>> 3. Improvements to help with pipe( ) and flow-control management
>> 4. Updated spec text and diagrams for further clarifications
>>
>> There are still a set of bugs being tracked in bugzilla. We would like
>> others to please review the updated proposal, and provide any feedback
>> they may have (or file bugs).
>>
>> Thanks.
>> -Feras
>>
>>
>> [1] https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm
>
> 

Re: Request for feedback: Streams API

[Marcos Caceres]

On Thursday, December 5, 2013 at 3:57 AM, Arthur Barstow wrote:

> Thanks for the update Feras.
>  
> Re getting `wide review` of the latest [ED], which groups, lists and  
> individuals should be asked to review the spec?
>  
> In IRC just now, jgraham mentioned TC39, WHATWG and Domenic. Would  
> someone please ask these two groups to review the latest ED?
>  
> Aymeric - would you please ask the WebRTC list(s) to review the latest  
> ED or provide the list name(s) and I'll ask them.


It’s still a big concern that there are two competing proposals. We can just 
“let the market sort it out”, but I think it would be best if there was a 
single spec with all the folks interested in this area working together.  

How can we work towards that?   

Re: [webcomponents] HTML Imports

[Rafael Weinstein]

On Wed, Dec 4, 2013 at 10:37 AM, Dimitri Glazkov wrote:

> On Wed, Dec 4, 2013 at 9:56 AM, Dimitri Glazkov wrote:
>
>> On Wed, Dec 4, 2013 at 4:32 AM, Anne van Kesteren wrote:
>>
>>> On Wed, Dec 4, 2013 at 9:21 AM, Brian Di Palma  wrote:
>>> > I would say though that I get the feeling that Web Components seems a
>>> > specification that seems really pushed/rushed and I worry that might
>>> > lead to some poor design decisions whose side effects will be felt by
>>> > developers in the future.
>>>
>>> I very much share this sentiment.
>>>
>>
>> It's a very reasonable and normal worry to have. I lose sleep over this
>> worry all the time. The trick that helps me is balancing it out with the
>> sadness of the geological timescale that it takes for Web platform to
>> advance.
>>
>
> Just to help visualize the geological timescale, the work on Web
> Components began in late 2010 (
> http://wiki.whatwg.org/index.php?title=Component_Model_Use_Cases&oldid=5631),
> and was chartered in this WG over 2 years ago (
> http://www.w3.org/2008/webapps/wiki/CharterChanges#Additions_Agreed).
>
> To clarify my previous email: Web Components is an extremely hard problem
> with lots of constraints, and a concern would be that we miss some bits is
> totally fair. Qualifying this work as "pushed/rushed" probably ain't.
>

I'd like to make an aside about having respect for one-another's work.

Dimitri, Alex, Dominic, Scott, Elliot and many others have put massive time
into this problem over the course of many years now, and my view is that
the design has evolved and accommodated a dizzying number of challenges and
constraints.

"What this is attempting is big & scary" is fair. "I haven't had time to
digest the design" is fair. "I have the following specific issues" is fair.
"This work is rushed" is always understood as an indictment.

I've seen too many talented people vote with their feet and decide life
will be less frustrating working on a closed system. Let's remember we're
all on the same team.

AFAICT, evolving the web is fundamentally an exercise in not letting
perfect be the enemy of good. I have no doubt Web Components is imperfect,
but from what I can tell, it is *extremely* good.

Also, go hug your mother.



>
> :DG<
>

Re: [webcomponents] HTML Imports

[Bjoern Hoehrmann]

* Anne van Kesteren wrote:
>On Wed, Dec 4, 2013 at 9:21 AM, Brian Di Palma  wrote:
>> I would say though that I get the feeling that Web Components seems a
>> specification that seems really pushed/rushed and I worry that might
>> lead to some poor design decisions whose side effects will be felt by
>> developers in the future.
>
>I very much share this sentiment.

"The growth of HTML with scripting as an application platform has
exploded recently. One limiting factor of this growth is that there is
no way to formalize the services that an HTML application can provide,
or to allow them to be reused as components in another HTML page or
application." -- http://www.w3.org/TR/NOTE-HTMLComponents

That was 15 years ago. You might be able to appreciate that this may be
a case where the past is a lot longer than the future and in another 15
years "Web Components" as they are being proposed currently have moved
to museums that exhibit them as important evolutionary step that finally
gave web developers some kind of robust re-usable component technology.
-- 
Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: inline declarative manifest, was Re: New manifest spec - ready for FPWD?

[Jonas Sicking]

On Dec 4, 2013 6:20 AM, "Henri Sivonen"  wrote:
> > 
>
> Are manifests really short enough for this kind of thing?

For single-page apps I would imagine it will be quite simple yes. Not quite
as short as the above, but will reasonable to type.

Additionally, since no extra escaping is done, you are not typing more than
what you'd type into the external file anyway.

/ Jonas

RE: Last Call for High Resolution Time Level 2

[Jatinder Mann]

Aside from the now() method, the Performance interface also has Navigation, 
Resource, and User Timing methods and attributes defined on it. Currently, the 
expected behavior for the Timing APIs hasn't been defined in the Web Workers 
scope. E.g., in a shared worker what should Resource Timing return? The timing 
related to resources downloaded in any of the documents sharing the worker, 
only resources initiated in the shared worker, or none of them? While the 
Working Group plans on eventually defining the Timing behavior in Web Workers 
in the different Timing specs, by creating a separate WorkerPerformance 
interface we can ensure that the High Resolution Time Level 2 spec is only 
defining the now() method in the worker scope.

Thanks,
Jatinder

-Original Message-
From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On Behalf Of 
Anne van Kesteren
Sent: Wednesday, December 4, 2013 6:47 AM
To: public-web-p...@w3.org
Cc: public-webapps
Subject: Re: Last Call for High Resolution Time Level 2

On Tue, Dec 3, 2013 at 3:51 PM, Philippe Le Hegaret  wrote:
> interface WorkerPerformance {
>   DOMHighResTimeStamp now();
> };

Is there any particular reason the Performance interface itself cannot be used? 
It seems somewhat cumbersome to have to prototype different interfaces (if 
you're into that kind of thing) depending on the global environment you're in.


--
http://annevankesteren.nl/

Re: [webcomponents] HTML Imports

[Dimitri Glazkov]

On Wed, Dec 4, 2013 at 9:56 AM, Dimitri Glazkov wrote:

> On Wed, Dec 4, 2013 at 4:32 AM, Anne van Kesteren wrote:
>
>> On Wed, Dec 4, 2013 at 9:21 AM, Brian Di Palma  wrote:
>> > I would say though that I get the feeling that Web Components seems a
>> > specification that seems really pushed/rushed and I worry that might
>> > lead to some poor design decisions whose side effects will be felt by
>> > developers in the future.
>>
>> I very much share this sentiment.
>>
>
> It's a very reasonable and normal worry to have. I lose sleep over this
> worry all the time. The trick that helps me is balancing it out with the
> sadness of the geological timescale that it takes for Web platform to
> advance.
>

Just to help visualize the geological timescale, the work on Web Components
began in late 2010 (
http://wiki.whatwg.org/index.php?title=Component_Model_Use_Cases&oldid=5631),
and was chartered in this WG over 2 years ago (
http://www.w3.org/2008/webapps/wiki/CharterChanges#Additions_Agreed).

To clarify my previous email: Web Components is an extremely hard problem
with lots of constraints, and a concern would be that we miss some bits is
totally fair. Qualifying this work as "pushed/rushed" probably ain't.

:DG<

Re: Request for feedback: Streams API

[Arthur Barstow]

Thanks for the update Feras.

Re getting `wide review` of the latest [ED], which groups, lists and 
individuals should be asked to review the spec?


In IRC just now, jgraham mentioned TC39, WHATWG and Domenic. Would 
someone please ask these two groups to review the latest ED?


Aymeric - would you please ask the WebRTC list(s) to review the latest 
ED or provide the list name(s) and I'll ask them.


-Thanks, ArtB

[ED] 

On 12/4/13 11:27 AM, ext Feras Moussa wrote:
The editors of the Streams API have reached a milestone where we feel 
many of the major issues that have been identified thus far are now 
resolved and incorporated in the editors draft.


The editors draft [1] has been heavily updated and reviewed the past 
few weeks to address all concerns raised, including:
1. Separation into two distinct types -ReadableByteStream and 
WritableByteStream

2. Explicit support for back pressure management
3. Improvements to help with pipe( ) and flow-control management
4. Updated spec text and diagrams for further clarifications

There are still a set of bugs being tracked in bugzilla. We would like 
others to please review the updated proposal, and provide any feedback 
they may have (or file bugs).


Thanks.
-Feras


[1] https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm

Re: [webcomponents] HTML Imports

[Scott Miles]

> seems a specification that seems really pushed/rushed

Since my team (Polymer) has been working with imports in practice for a
year-and-a-half (100% public and open-source, btw) this seems a strange
conclusion. But this is only my perspective, I'm still a standards n00b I
suppose.

In any case, I codified the concepts that our team has been espousing in a
document here:

https://docs.google.com/document/d/14qJlCgda7GX2_KKxYhj1EULmY_hqNH35wjqDgGSkkOo/edit#

The aim of this document was to address some of the questions around
pragmatic operation of the spec as we see it.

Scott

On Wed, Dec 4, 2013 at 4:32 AM, Anne van Kesteren  wrote:

> On Wed, Dec 4, 2013 at 9:21 AM, Brian Di Palma  wrote:
> > I would say though that I get the feeling that Web Components seems a
> > specification that seems really pushed/rushed and I worry that might
> > lead to some poor design decisions whose side effects will be felt by
> > developers in the future.
>
> I very much share this sentiment.
>
>
> --
> http://annevankesteren.nl/
>

Re: [webcomponents] HTML Imports

[Dimitri Glazkov]

On Wed, Dec 4, 2013 at 4:32 AM, Anne van Kesteren  wrote:

> On Wed, Dec 4, 2013 at 9:21 AM, Brian Di Palma  wrote:
> > I would say though that I get the feeling that Web Components seems a
> > specification that seems really pushed/rushed and I worry that might
> > lead to some poor design decisions whose side effects will be felt by
> > developers in the future.
>
> I very much share this sentiment.
>

It's a very reasonable and normal worry to have. I lose sleep over this
worry all the time. The trick that helps me is balancing it out with the
sadness of the geological timescale that it takes for Web platform to
advance.

:DG<

Re: Request for feedback: Streams API

[Kenneth Russell]

Looks great! Seems very well thought through.

The API seems large enough that it would be worth prototyping it and
writing test applications to make sure it addresses key use cases
before finalizing the spec.

-Ken


On Wed, Dec 4, 2013 at 8:27 AM, Feras Moussa  wrote:
> The editors of the Streams API have reached a milestone where we feel many
> of the major issues that have been identified thus far are now resolved and
> incorporated in the editors draft.
>
> The editors draft [1] has been heavily updated and reviewed the past few
> weeks to address all concerns raised, including:
> 1. Separation into two distinct types -ReadableByteStream and
> WritableByteStream
> 2. Explicit support for back pressure management
> 3. Improvements to help with pipe( ) and flow-control management
> 4. Updated spec text and diagrams for further clarifications
>
> There are still a set of bugs being tracked in bugzilla. We would like
> others to please review the updated proposal, and provide any feedback they
> may have (or file bugs).
>
> Thanks.
> -Feras
>
>
> [1] https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm

Re: IndexedDB, Blobs and partial Blobs - Large Files

[Joshua Bell]

On Wed, Dec 4, 2013 at 2:13 AM, Aymeric Vitte wrote:

> OK for the different records but just to understand correctly, when you
> fetch {chunk1, chunk2, etc} or [chunk1, chunk2, etc], does it do something
> else than just keeping references to the chunks and storing them again with
> (new?) references if you didn't do anything with the chunks?
>

I believe you understand correctly, assuming a reasonable[1] IDB
implementation. Updating one record with multiple chunk references vs.
storing one record per chunk really comes down to personal preference.

[1] A conforming IDB implementation *could* store blobs by copying the data
into the record, which would be extremely slow. Gecko uses references (per
Jonas); Chromium will as well, so updating a record with [chunk1, chunk2,
...] shouldn't be significantly slower than updating a record not
containing Blobs. In Chromium's case there will be extra book-keeping going
on but no huge data copies.



>
> Regards
>
> Aymeric
>
> Le 03/12/2013 22:12, Jonas Sicking a écrit :
>
>  On Tue, Dec 3, 2013 at 11:55 AM, Joshua Bell  wrote:
>>
>>> On Tue, Dec 3, 2013 at 4:07 AM, Aymeric Vitte 
>>> wrote:
>>>
 I am aware of [1], and really waiting for this to be available.

 So you are suggesting something like {id:file_id, chunk1:chunk1,
 chunk2:chunk2, etc}?

>>> No, because you'd still have to fetch, modify, and re-insert the value
>>> each
>>> time. Hopefully implementations store blobs by reference so that doesn't
>>> involve huge data copies, at least.
>>>
>> That's what the Gecko implementation does. When reading a Blob from
>> IndexedDB, and then store the same Blob again, that will not copy any
>> of the Blob data, but simply just create another reference to the
>> already existing data.
>>
>> / Jonas
>>
>
> --
> Peersm : http://www.peersm.com
> node-Tor : https://www.github.com/Ayms/node-Tor
> GitHub : https://www.github.com/Ayms
>
>

Request for feedback: Streams API

[Feras Moussa]

The editors of the Streams API have reached a milestone where we feel many of 
the major issues that have been identified thus far are now resolved and 
incorporated in the editors draft. 
The editors draft [1] has been heavily updated and reviewed the past few weeks 
to address all concerns raised, including:1. Separation into two distinct types 
-ReadableByteStream and WritableByteStream2. Explicit support for back pressure 
management 3. Improvements to help with pipe( ) and flow-control management4. 
Updated spec text and diagrams for further clarifications 
There are still a set of bugs being tracked in bugzilla. We would like others 
to please review the updated proposal, and provide any feedback they may have 
(or file bugs).
Thanks.-Feras

[1] https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm
  

Re: [HTML Imports]: Sync, async, -ish?

[Bryan McQuade]

Thanks Elliott! I'll admit I don't (yet) have a deep understanding of
imports/web components so I'm not surprised to have overlooked things.
Thank you for clarifying these areas for me.

So to summarize:
* imports should not block parsing/DOM tree construction
* imports should block rendering (e.g. render tree construction), just like
stylesheets
* we should add support for loading stylesheets and imports without
blocking rendering, so developers can load imports that they'll use in the
future without blocking rendering of other content on their load completing
* Elliott proposes adding support for an 'async' tag. 
indicates that the load of that stylesheet/import must not block rendering.
This is useful for both imports and stylesheets (more on this below)


On Tue, Dec 3, 2013 at 8:37 PM, Elliott Sprehn  wrote:

>
> On Tue, Dec 3, 2013 at 2:22 PM, Bryan McQuade  wrote:
>
>> Second question: should *rendering* of page content block on the load of
>> 
>>
>> Steve Souders wrote another nice post about this topic:
>> http://www.stevesouders.com/blog/2013/11/26/performance-and-custom-elements/which
>>  I recommend reading (read the comments too).
>>
>> We should start by looking to how the web platform behaves today. All
>> browsers I am aware of block rendering on the load of pending stylesheets.
>> Note that blocking rendering (blocking of render tree construction and
>> painting content to the screen) is different from blocking parsing.
>> Browsers do not block HTML parsing (DOM construction) on stylesheets. Nor
>> should they block DOM construction on loading of s.
>>
>>
> Correct. Imports are even better than the main document though.
> document.write doesn't work, and we allow the parser to "run ahead" and not
> block on  inside an import. That means putting