See also: IRC log
<trackbot> Date: 26 June 2013
presen+ Plh
James: At Velocity, people loved this attribute. For example, Amazon liked the idea of never loading some resources that have been lazyloaded and are not visible.
Jatinder: James, so would you never kick off the resource if it's not visible? Typically, resource are fetched in the early stages of loading a page, formatting and layout information wouldn't come in until later.
James: I think we would put it on a queue and if the resource hasn't been fetched and we now know the formatting/layout information, we won't kick off the resource until its visible.
Jatinder: I do think we still need to work out what this attribute means for <script>. Currently we were leaning towards not blocking the window onload event for lazyload scripts. However, does this mean a developer will need to register an onload handler on each script element to know when to execute the script? Or do we create a new event that indicates when all resources (including lazyloaded resources) has been loaded?
James: I think the pattern where developers add load events to each <script lazyload> is reasonable.
<plh> https://www.w3.org/2002/09/wbs/35125/TPAC2013/
James: That's especially the case
if we don't ever fetch a resource because we know that it's not
visible. If we add a special event that fires for all
resources, including lazyloaded resources when they are loaded,
that event may never fire.
... I think developers will use the pattern of adding an onload
handler on the lazyloaded resource if they want to know when
it's loaded.
Jatinder: On the topic of when the element is visible on the screen, if we were to fetch the resource only when it was visible, they may be a delay before the user sees it, which may be an even worse experience. Most browsers have a render region that's greater than the window size. We should leave the definition of 'visibile' loose here so that the browser can fetch the resource before the user is able to scroll to it.
James: I completely agree. I think we should keep this loose enough that the browser will fetch by the time it's in the rendered region.
Jatinder: I also don't think we
should specify the exact algorithm here, especially if there
are future optimizations browser vendors want to make on the
render region.
... On the topic of visibility, not all resources are visible
resource, e.g., Audio. The purpose of this attribute is really
to help the browser better organize the priority in which it
downloads resources, so I don't think this is necessarily tied
to visibility. I like the concept that we have one attribute
that we can add to all elements capable of downloading a
resource to indicate that this is a lower priority
download.
,,, we should consider each element on its own merit, and pull them if we don't think they should use this attribute.
James: I agree with that as
well.
... I think we should add additional examples to the spec to
make it clear that there are other cases covered here as well,
not just above vs. below the fold.
... I like the idea of leaving the exact algorithm that the
browser uses off the spec, so to allow the browser to
adapt.
Jatinder: I also agree that this should only be a hint.
Philippe: If we don't have any normative requirements, then what are we going to test? I think the spec should have some normative statements.
Jatinder: If we add the behavior
that lazyload doesn't block the window load event, that should
be a normative requirement to test.
... I think we need to do a few updates the spec: add
additional examples that aren't related to above/below fold,
add seperate sections for each element type and define the
expected behavior, and clarify loosely correlate visibility
here.
Phiippe: There has been quite a bit of interest for an element visibility definition for Web Drivers, requestAnimationFrame, and possibly others. We spoke about this in the past.
Jatinder: Yes, ad vendors would be interested as well. Today they use a series of different techniques for each browser to determine if their ad is more than 50% visible. I can propose a specification here if there is interest.
Philippe: TPAC registration has
opened today. Please feel free to register for our event.
... Also, we can start publishing draft specs now in this
working group as the charter has been updated.
Jatinder: IE11 Release Preview was released today. It supports Navigation Timing L2 and also an implementation of lazyload in the connection management layer. I'll send a seperate email that details the changes.
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) No ScribeNick specified. Guessing ScribeNick: JatinderMann Inferring Scribes: JatinderMann Default Present: [Microsoft], +1.949.754.aaaa, +1.650.214.aabb, Philippe Present: [Microsoft] +1.949.754.aaaa +1.650.214.aabb Philippe JatinderMann AaronHeady RobDickenson JamesSimonsen WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 26 Jun 2013 Guessing minutes URL: http://www.w3.org/2013/06/26-webperf-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]