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
To be fair though Web Components are bleeding edge and the vast
majority of developers have had no interaction with them at all.
I work in a company that should see huge benefits from Web Components
as we build large scale browser applications and not one developer has
had the time to investigate W
On Wed, 04 Dec 2013 08:18:31 +0100, Marcos Caceres wrote:
On Wednesday, December 4, 2013 at 4:16 PM, Jonas Sicking wrote:
> I’m not saying we shouldn’t allow it - just sayin’ its kinda crappy >
because it encourages bad development practices (leading to single
> page apps, etc.).
For simpl
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?
Regards
A
On Dec 3, 2013 11:18 PM, "Marcos Caceres" wrote:
> On Wednesday, December 4, 2013 at 4:16 PM, Jonas Sicking wrote:
>
> > > I’m not saying we shouldn’t allow it - just sayin’ its kinda crappy
because it encourages bad development practices (leading to single page
apps, etc.).
> >
> > For simple app
Hi everyone,
The original email from Jonas has been posted a while ago, here are a few
comments about it.
Sorry for being late.
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 t
On Wed, Dec 4, 2013, at 10:17, Marcos Caceres wrote:
> On Wednesday, December 4, 2013 at 7:43 AM, Charles McCathie Nevile wrote:
>
> > Yes. In-apge Search is something that might also be useful within an app -
> > especially if you can find out it is happening and respond to it
> > intelligently i
On 12/3/13 11:46 PM, ext Dimitri Glazkov wrote:
I don't have any objections to waiting for the folks to catch up.
We'll just keep it in LC until next year.
Given the feedback on this thread, I don't think we have broad consensus
to move Custom Elements to CR so I support Dimitri's proposal.
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.
More comments inline, but I’ve started running a developer survey here about
the proposed solutions:
https://gist.github.com/marcoscaceres/7783977
See also:
https://twitter.com/marcosc/status/408150324629630976
Some really great feedback from the dev community on twitter! Please take a
look.
On Wed, Dec 4, 2013 at 8:16 AM, Jonas Sicking wrote:
> On Dec 3, 2013 9:25 PM, "Marcos Caceres" wrote:
>> On Wednesday, December 4, 2013 at 9:40 AM, Jonas Sicking wrote:
>> > We currently have both ... and
On Tue, Dec 3, 2013, at 6:48, Mitar wrote:
> And there are real use cases. For example, go to some long document in
> Google Docs and invoke browser search by going through menu (Edit ->
> Find or something similar). You will see that it does not work except
> for the current document page. It does
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 tha
Hi!
On Wed, Dec 4, 2013 at 6:25 AM, Mounir Lamouri wrote:
> So, it's not clear to me why the inability to search in unloaded pages
> will be fixed by intercepting the system find in page unless let the UA
> doing the search but then it is no longer clear why you want to know
> that a search is ac
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.
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
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?) referen
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
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 decisio
> 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
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 y
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/rushe
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 retu
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
* 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 b
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 Comp
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
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
(htt
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
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 r
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
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 documen
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,
* 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 standa
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
* 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
36 matches
Mail list logo
