On Sat, May 16, 2015 at 12:41 AM Olli Pettay o...@pettay.fi wrote:
On 05/15/2015 06:39 PM, Wilson Page wrote:
Wouldn't it likely need to be called just before layout?
Probably yes, but it is not defined when that actually happens.
Yeah, the exact timing is not defined. That's intentional.
Wouldn't it likely need to be called just before layout? All the issues
Dimitri highlighted are symptoms of layout running before distribution.
On Fri, May 15, 2015 at 3:46 PM, Olli Pettay o...@pettay.fi wrote:
On 05/15/2015 05:37 PM, Wilson Page wrote:
Would it be possible to leave the
On 05/15/2015 06:39 PM, Wilson Page wrote:
Wouldn't it likely need to be called just before layout?
Probably yes, but it is not defined when that actually happens.
All the issues Dimitri highlighted are symptoms of layout running before
distribution.
On Fri, May 15, 2015 at 3:46 PM, Olli
On 05/15/2015 05:37 PM, Wilson Page wrote:
Would it be possible to leave the calling of the shadowRoot's distribute()
function to the engine? This way the engine can be in full control over
*when* distribution happens.
We would need to define when the engine calls it, otherwise web pages
Would it be possible to leave the calling of the shadowRoot's distribute()
function to the engine? This way the engine can be in full control over
*when* distribution happens.
On Wed, May 13, 2015 at 5:46 PM, Dimitri Glazkov dglaz...@google.com
wrote:
I did a quick experiment around
I wonder if there is some sort of imperative-declarative model that we could
adopt here? I mean, allow script to specify the distribution logic, but do it
with a static model. After all, what is being asked for is a relatively simple
mapping from candidate node to content distribution point.
I did a quick experiment around distribution timing:
https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Distribution-Timing-Experiment.md.
Hope you find it helpful.
:DG
I'm happy to implement some of these proposals in blink to compare the
performance when the time comes, if I or other guys can afford to do.
On Thu, May 7, 2015 at 1:20 PM Hayato Ito hay...@chromium.org wrote:
I'm wondering how we should estimate the performance impact of these
proposals.
In
On Wed, May 6, 2015 at 2:05 AM, Anne van Kesteren ann...@annevk.nl wrote:
It seems we have three contenders for the distribution API.
1) Synchronous, no flattening of content. A host element's shadow
tree has a set of slots each exposed as a single content element to
the outside. Host
On May 6, 2015, at 10:57 AM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, May 6, 2015 at 2:05 AM, Anne van Kesteren ann...@annevk.nl wrote:
1) Synchronous, no flattening of content. A host element's shadow
tree has a set of slots each exposed as a single content element to
the outside.
On May 6, 2015, at 2:39 PM, Elliott Sprehn espr...@chromium.org wrote:
The 3 proposal is what the houdini effort is already researching for custom
style/layout/paint. I don't think it's acceptable to make all usage of Shadow
DOM break when used with libraries that read layout information
The 3 proposal is what the houdini effort is already researching for custom
style/layout/paint. I don't think it's acceptable to make all usage of
Shadow DOM break when used with libraries that read layout information
today, ie. offsetTop must work. I also don't think it's acceptable to
introduce
On Wed, May 6, 2015 at 11:07 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, May 6, 2015 at 7:57 PM, Jonas Sicking jo...@sicking.cc wrote:
Has at-end-of-microtask been debated rather than 1/2? Synchronous
always has the downside that the developer has to deal with
reentrancy.
1/2 are
On Wed, May 6, 2015 at 2:05 AM, Anne van Kesteren ann...@annevk.nl wrote:
1) Synchronous, no flattening of content. A host element's shadow
tree has a set of slots each exposed as a single content element to
the outside. Host elements nested inside that shadow tree can only
reuse slots from
On Wed, May 6, 2015 at 7:57 PM, Jonas Sicking jo...@sicking.cc wrote:
Has at-end-of-microtask been debated rather than 1/2? Synchronous
always has the downside that the developer has to deal with
reentrancy.
1/2 are triggered by the component author. Synchronous just means that
they run within
I'm wondering how we should estimate the performance impact of these
proposals.
In the era of Web Components, I expect that one page has 1k Web Components.
The page must work without any significant noticeable performance
regression, compared to a page which doesn't use Web Components. That's our
16 matches
Mail list logo
