See also: IRC log
<trackbot> Date: 17 April 2013
Jatinder: James had raised that considering the level of detailed information we are considering sharing, we should go through a security and privacy review of this feature. I plan on reviewing this feature with the IE security team in the next week or so and can get back to the working group.
James: Our security team has reviewed this and generally they are fine with this feature on a same origin. I need to follow up with the privacy team as well.
Arvind: I think we should definitely seperate out the historical and current interfaces, and probably in seperate specs.
Dan: If the historical interface has a higher privacy or security implications, we should seperate specs.
Jatinder: We may want to consider updating the spec to include JavaScript errors as well?
Dan: We may want to consider that in the future.
Jatinder: I propose we touch base on this topic after the security review.
Jatinder: I had put together a draft of the Resource Priorities spec as a framework for discussion:
https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourcePriorities/Overview.html.
<plh> note that video has preload
<plh> which is a hint
Jatinder: This aligns closely
with the discussion on the mailing list. Adding "defer" to any
element or object capable of fetching a resource, will mean
that the UA may choose to not download that resource until
after all other resources without the attribute have started
downloading.
... Adding "defer" to a script element will mean that in
addition to not beginning the download, the UA may also not
execute the script until after the page has been parsed.
... What I don't currently agree with is that style information
or viewport visibility shouldn't impact whether the resource is
downloaded. Determining intent is easiest for the developer and
the developer should choose or not choose to add the defer
tag.
... Also, I don't think any of these statements should be must
clauses. They should be may.
<simonjam> load event blockers: http://www.whatwg.org/specs/web-apps/current-work/#delay-the-load-event
Dan: Considering the script element uses defer, I wonder if we should seperate this to another attribute.
Jatinder: Seeing that script execution is already delay executed, it may make sense to combine these. But we may choose to use a new term like "delay".
James: What about changing the load event such that it's not impacted by the defer attribute resources.
Jatinder: I think we should think
about this one some more. I wonder if we want to redefine the
load event.
... If we do decide to define that this spec does not impact
load, it may make sense to give the attribute a seperate name,
as real world sites may already use 'defer' with script and it
will change behavior.
Dan: That's a good reason to change the name.
Arvind: Redefining load to push it out has the benefit of improving performance, as scripts can now execute sooner and not be delayed by deferred resources.
Jatinder: Let's treat changing
the load event and using defer or a different name as open
items that need further discussion.
... I don't think style information should impact whether a
resource is delayed or not.
James: I agree with that as well.
Dan: Seems odd that something at layer 7, formatting, impacts something at layer 4, transport. I agree that style shouldn't impact.
Jatinder: There's also a
performance impact on the browser to calculate that information
at an earlier time.
... Let's agree to not include style information. What about
viewport or above/below the fold? I think that the developer is
the best person to determine that and they can do so by
including or not including the tag.
Arvind: Is our goal to have a seperate spec or should this be put into HTML5? Seems small enough to add to HTML5.
Jatinder: I think this spec is a good framework for discussion. If we feel that this is more approperiately placed in HTML5, we should do that.
Jatinder: Spec has been updated
to no longer refer to not well defined terms like "networking
layer".
... Is adding a redirect-origin-clean flag really
necessary?
James: We may not need the flag, but we may want to improve the redirectEnd definition.
Jatinder: Good feedback, I'll look into it.
Jatinder: We have posted a draft
of the HRT L2 spec, which now includes support for
performance.now() in the worker context. Spec is here:
https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/HighResolutionTime2/Overview.html
... Does everyone agree that the start of creation of a shared
worker is step 1 of the worker processing model, here: http://www.w3.org/TR/workers/#processing-model
... "Create a separate parallel execution environment (i.e. a
separate thread or process or equivalent construct), and run
the rest of these steps asynchronously in that context."
James: I agree, makes sense.
plh: I can get help get that editorial change made.
plh: There is a discussion on whether or not rAF calls should be made for display:none or below the fold animations. Seeing that the spec is in last call, we need to decide how whether we want to take that feedback or not.
This is scribe.perl Revision: 1.137 of Date: 2012/09/20 20:19:01 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.626.379.aaaa, +1.408.203.aabb, +1.650.214.aacc, Plh Present: [Microsoft] +1.626.379.aaaa +1.408.203.aabb +1.650.214.aacc Plh JatinderMann DanAustin simonjam Arvind WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 17 Apr 2013 Guessing minutes URL: http://www.w3.org/2013/04/17-webperf-minutes.html People with action items:[End of scribe.perl diagnostic output]