On Tue, Jan 28, 2014 at 5:11 PM, Jake Archibald jaffathec...@gmail.comwrote:
(I'm late to this party, sorry)
I'm really fond of the link rel=import elements=x-foo, x-bar
pattern, but I yeah, you could end up with a massive elements list.
How about making link[rel=import] async by default,
On 28 January 2014 18:19, Ryosuke Niwa rn...@apple.com wrote:
How about making link[rel=import] async by default, but make elements
with a dash in the tagname display:none by default?
Is it really the right thing to do in all cases?
Nope, but no default is. The default shouldn't be slow for
:unresolved { display: none; } plus lazyload (
https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourcePriorities/Overview.html#attr-lazyload)
would allow devs to create the non-blocking behaviour. But this is the
wrong way around. Devs should have to opt-in to the slow thing and get the
fast
On Wed, Jan 29, 2014 at 12:09 PM, Jake Archibald jaffathec...@gmail.comwrote:
:unresolved { display: none; } plus lazyload (
https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourcePriorities/Overview.html#attr-lazyload)
would allow devs to create the non-blocking behaviour. But this is the
My bad, many apologies. I get what you mean now.
However, if web components are explaining the platform then body is
:resolved by browser internals (I don't know if this is how :resolved works
currently). Eg, imagine select as a built-in component which is resolved
and given a shadow DOM by
On Wed, Jan 29, 2014 at 12:30 PM, Jake Archibald jaffathec...@gmail.comwrote:
My bad, many apologies. I get what you mean now.
However, if web components are explaining the platform then body is
:resolved by browser internals (I don't know if this is how :resolved works
currently). Eg,
I'm not excited about making render blocking easier, but I think you're
right.
However, this is all premature detail while the behaviour is blocking-first.
On 29 January 2014 09:53, Brian Kardell bkard...@gmail.com wrote:
On Wed, Jan 29, 2014 at 12:30 PM, Jake Archibald
(I'm late to this party, sorry)
I'm really fond of the link rel=import elements=x-foo, x-bar pattern,
but I yeah, you could end up with a massive elements list.
How about making link[rel=import] async by default, but make elements with
a dash in the tagname display:none by default?
On a news
On Jan 28, 2014, at 2:11 PM, Jake Archibald jaffathec...@gmail.com wrote:
I'm really fond of the link rel=import elements=x-foo, x-bar pattern,
but I yeah, you could end up with a massive elements list.
How about making link[rel=import] async by default, but make elements with a
dash in
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:
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
It seems that there are two distinct questions being discussed on this
thread:
1. should script tags that come after link rel=import block their
execution on load of the link rel=import completing?
2. should rendering of page content block on the load of link rel=import
These are related, but
Second question: should *rendering* of page content block on the load of
link rel=import
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
* Bryan McQuade wrote:
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).
That should be
Stepping back a bit, I think we're struggling to ignore the elephant in the
room. This elephant is the fact that there's no specification (or API) that
defines (or provides facilities to control) when rendering happens. And for
that matter, what rendering means.
The original reason why script
On Wed, Nov 27, 2013 at 9:46 AM, Dimitri Glazkov dglaz...@google.comwrote:
Stepping back a bit, I think we're struggling to ignore the elephant in
the room. This elephant is the fact that there's no specification (or API)
that defines (or provides facilities to control) when rendering happens.
Right on Dimitri, I couldn't agree more. It seems like an involved (but
highly beneficial) pursuit - but heck, maybe we'll find an answer quickly,
let's give it a shot!
Alex, I completely agree that declarative features should play a huge role
in the solution, and I love the power/granularity
I just can't help thinking this is whole line of reasoning all too
complicated to achieve wide adoption and thus impact.
The supposed power of declarative languages is ability to reason from top
to bottom. Creating all of these exceptions causes the very problems being
discussed: FOUC occurs
JJB, this is precisely why the paint concept seemed like a good idea to
me:
- Easy to use in just one or two places if needed, without a steep cliff
- The choice shouldn't be: either put up with the browser's default
render flow, or become a low-level, imperative, perf hacker
What if:
head
...
link rel=import href=elements/pi-app.html
...
/head
body
...
pi-app theme=polymer-ui-light-theme
div class=app-loading/div
/pi-app
...
was instead:
pi-app import=elements/pi-app.html theme=polymer-ui-light-theme
div class=app-loading/div
/pi-app
If I want to avoid
(way behind, slowly catching up...)
On Thu, Nov 21, 2013 at 2:21 PM, Daniel Buchner dan...@mozilla.com wrote:
Steve and I talked at the Chrome Dev Summit today and generated an idea
that may align the stars for our async/sync needs:
link rel=import elements=x-foo, x-bar /
+1. I think this
I agree that we should allow developers to set 'sync' attribute on link
tags to block rendering until load. That will allow them to create sites
that appear to load slowly rather than render their standard HTML/CSS.
I think that the default should be the current solution and 'sync' should
be
Personally I don't have any issues with this solution, it provides for the
use-cases we face. Also, it isn't without precedent - you can opt for a
sync XMLHttpRequest (not much different).
The best part of an explicit 'sync' attribute, is that we can now remove
the block if a script comes after
On Fri, Nov 22, 2013 at 8:22 AM, Daniel Buchner dan...@mozilla.com wrote:
Personally I don't have any issues with this solution, it provides for the
use-cases we face. Also, it isn't without precedent - you can opt for a
sync XMLHttpRequest (not much different).
The best part of an explicit
On Nov 22, 2013 8:24 AM, Daniel Buchner dan...@mozilla.com wrote:
Personally I don't have any issues with this solution, it provides for
the use-cases we face. Also, it isn't without precedent - you can opt for a
sync XMLHttpRequest (not much different).
Except that sync XHR is considered one
I'm not talking about the script blocking as usual - I'm referencing the
presence of a script causing the import to block until completed, when the
script follows it.
On Fri, Nov 22, 2013 at 8:57 AM, John J Barton
johnjbar...@johnjbarton.comwrote:
On Fri, Nov 22, 2013 at 8:22 AM, Daniel
Of course I realize this Jonas, but I assure you, if you burden the most
common use-cases with poor ergonomics, developers will find even more
ghastly ways to degrade perf. Can someone post an overview of the proposed
solutions, and how they apply to the use-cases stated a few posts back?
On
Steve and I talked at the Chrome Dev Summit today and generated an idea
that may align the stars for our async/sync needs:
link rel=import elements=x-foo, x-bar /
The idea is that imports are always treated as async, unless the developer
opts-in to blocking based on the presence of specific
I guess this is designed to solve the flash of unstyled content problem by
blocking rendering of tags dependent upon unloaded custom elements?
On Thu, Nov 21, 2013 at 2:21 PM, Daniel Buchner dan...@mozilla.com wrote:
Steve and I talked at the Chrome Dev Summit today and generated an idea
Yes, that's the primary motivation. Getting FUC'd is going to be a
non-starter for serious app developers. We were just thinking of ways to
satisfy the use-case without undue burden.
I don't see this solution scaling at all.
Imports are a tree. If you have any import that includes any other import,
now the information about what tags to wait for has to be duplicated
along every node in that tree.
If a library author chooses to make any sort of all-in-one import to
reduce
Ok, so my 2 cents: it's ok but it gives a very Web 1.0 solution. We had to
invent AJAX so developers could control the user experience in the face of
significant network delay. As I said earlier, most apps will turn this
problem over to the design team rather than cause users to leave while the
DanielF: You would only list the custom tags that should be treated as
blocking. If *every* tag in Brick and Polymer should be blocking, then we
have a really big issue because right now they're NOT-blocking and there's
nothing in Web Components per se to specify a blocking behavior.
JJB: Website
I don't see this solution scaling at all.
Imports are a tree. If you have any import that includes any other import,
now the information about what tags to wait for has to be duplicated
along every node in that tree.
If a library author chooses to make any sort of all-in-one import to
John's commentary just triggered a thought in my head. We should stop
saying that HTML Imports block rendering. Because in reality, they don't.
It's the scripts that block rendering.
Steve's argument is not about HTML Imports needing to be async. It's about
supporting legacy content with HTML
On Wed, Nov 20, 2013 at 9:51 AM, John J Barton
johnjbar...@johnjbarton.comwrote:
Another alternative:
First let's agree that Souder's example must block:
link rel=import href=import.php
...
div id=import-container/div
script
var link = document.querySelector('link[rel=import]');
var
Dimitri: right on.
The use of script-after-import is the forcing function in the blocking
scenario, not imports. Let's not complicate the new APIs and burden the
overwhelming use-case to service folks who intend to use the technology in
alternate ways.
For my bit, as long as the size of the
On Wed, Nov 20, 2013 at 10:41 AM, Daniel Buchner dan...@mozilla.com wrote:
Dimitri: right on.
The use of script-after-import is the forcing function in the blocking
scenario, not imports.
Yes.
Let's not complicate the new APIs and burden the overwhelming use-case to
service folks who
On Nov 20, 2013 11:07 AM, John J Barton johnjbar...@johnjbarton.com
wrote:
On Wed, Nov 20, 2013 at 10:41 AM, Daniel Buchner dan...@mozilla.com
wrote:
Dimitri: right on.
The use of script-after-import is the forcing function in the blocking
scenario, not imports.
Yes.
Let's not
I sent this to Scott only by accident, then noticed when I realized I need
to correct myself. First a softer version of my message to Scott:
On Mon, Nov 18, 2013 at 5:53 PM, Scott Miles sjmi...@google.com wrote:
I believe the primary issue here is 'synchronous with respect to
rendering'. Seems
Now a correction:
On Tue, Nov 19, 2013 at 4:25 PM, John J Barton
johnjbar...@johnjbarton.comwrote:
Last is an asynchronous declarative model (quote because such solutions
are not declarative).
Broadly I am advocating using ES6 modules with HTML imports. The
particular example I made up
Maybe Steve's example[1] could be on JS rather than on components:
System.component(import.php, function(component) {
var content = component.content
document.getElementById('import-container').appendChild(content.cloneNode(true));
});
Here we mimic System.load(jsId, success, error). Then
I love the idea of making HTML imports *not* block rendering as the
default behavior
So, for what it's worth, the Polymer team has the exact opposite desire. I
of course acknowledge use cases where imports are being used to enhance
existing pages, but the assertion that this is the primary use
On Mon, Nov 18, 2013 at 2:33 PM, Scott Miles sjmi...@google.com wrote:
I love the idea of making HTML imports *not* block rendering as the
default behavior
So, for what it's worth, the Polymer team has the exact opposite desire. I
of course acknowledge use cases where imports are being used
I'll assert that the primary use case for JS interacting with HTML
components ought to be 'works well with JS modules'.
You can happily define modules in your imports, those two systems are
friends as far as I can tell. I've said this before, I've yet to hear the
counter argument.
But if you
Mixed response here...
I love the idea of making HTML imports *not* block rendering as the
default behavior
In terms of custom elements, this creates as a standard, the dreaded FOUC
problem about which a whole different group of people will be blogging and
tweeting... Right? I don't know that
Scott, is that because of what I said above (why polymer has the exact
opposite desire)?
Yes. Plus some salt from the KISS principle.
I feel like it is maybe valuable to think that we should worry about
how you express [dependencies] in JS
I guess I thought ES6 modules already went through
On Mon, Nov 18, 2013 at 3:06 PM, Scott Miles sjmi...@google.com wrote:
I'll assert that the primary use case for JS interacting with HTML
components ought to be 'works well with JS modules'.
You can happily define modules in your imports, those two systems are
friends as far as I can tell.
I believe the primary issue here is 'synchronous with respect to
rendering'. Seems like you ignored this issue. See Brian's post.
Scott
On Mon, Nov 18, 2013 at 5:47 PM, John J Barton
johnjbar...@johnjbarton.comwrote:
On Mon, Nov 18, 2013 at 3:06 PM, Scott Miles sjmi...@google.com wrote:
49 matches
Mail list logo
