On Tue, Dec 3, 2013 at 2:22 PM, Bryan McQuade bmcqu...@google.com wrote:
Second question: should *rendering* of page content block on the load of
link rel=import
Steve Souders wrote another nice post about this topic:
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
On Wed, 04 Dec 2013 08:18:31 +0100, Marcos Caceres w...@marcosc.com 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,
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
On Dec 3, 2013 11:18 PM, Marcos Caceres w...@marcosc.com 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
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
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 if the
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.
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 jo...@sicking.cc wrote:
On Dec 3, 2013 9:25 PM, Marcos Caceres w...@marcosc.com wrote:
On Wednesday, December 4, 2013 at 9:40 AM, Jonas Sicking wrote:
We currently have both script.../script and script src=..., as
well as both style.../style 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 not
On Tue, Dec 3, 2013 at 3:51 PM, Philippe Le Hegaret p...@w3.org 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
Hi!
On Wed, Dec 4, 2013 at 6:25 AM, Mounir Lamouri mou...@lamouri.fr 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
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
On Wed, Dec 4, 2013 at 2:13 AM, Aymeric Vitte vitteayme...@gmail.comwrote:
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
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 feras.mou...@hotmail.com wrote:
On Wed, Dec 4, 2013 at 4:32 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Dec 4, 2013 at 9:21 AM, Brian Di Palma off...@gmail.com 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
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
On Wed, Dec 4, 2013 at 9:56 AM, Dimitri Glazkov dglaz...@chromium.orgwrote:
On Wed, Dec 4, 2013 at 4:32 AM, Anne van Kesteren ann...@annevk.nlwrote:
On Wed, Dec 4, 2013 at 9:21 AM, Brian Di Palma off...@gmail.com wrote:
I would say though that I get the feeling that Web Components seems a
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
On Dec 4, 2013 6:20 AM, Henri Sivonen hsivo...@hsivonen.fi wrote:
meta name=manifest content='{
a: 1,
b: foopy
}'
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
* Anne van Kesteren wrote:
On Wed, Dec 4, 2013 at 9:21 AM, Brian Di Palma off...@gmail.com 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
On Wed, Dec 4, 2013 at 10:37 AM, Dimitri Glazkov dglaz...@chromium.orgwrote:
On Wed, Dec 4, 2013 at 9:56 AM, Dimitri Glazkov dglaz...@chromium.orgwrote:
On Wed, Dec 4, 2013 at 4:32 AM, Anne van Kesteren ann...@annevk.nlwrote:
On Wed, Dec 4, 2013 at 9:21 AM, Brian Di Palma off...@gmail.com
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
On Wed, Dec 4, 2013 at 7:04 PM, Jatinder Mann jm...@microsoft.com 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
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
On Sat, Nov 23, 2013 at 1:51 AM, Jonas Sicking jo...@sicking.cc 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 module
tags in the main document. Otherwise there's a risk that named modules
introduced by the
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 standardization.
On Wed, Dec 4, 2013 at 11:45 AM, Ryosuke Niwa rn...@apple.com wrote:
On Nov 26, 2013, at 10:15 PM, Dominic Cooney domin...@google.com wrote:
On Wed, Nov 27, 2013 at 2:19 PM, Ryosuke Niwa rn...@apple.com wrote:
On Nov 27, 2013, at 8:57 AM, Dominic Cooney domin...@google.com wrote:
On Tue,
* 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
33 matches
Mail list logo
