SV_MEETING_TITLE -- 02 Apr 2014

<slightlyoff> (discussion of lightweight vs. CSS element boxes)

<slightlyoff> annevk: "--" has to be at the beginning?

<slightlyoff> (yes, but this is all new)

<slightlyoff> (discussion of pseudos, what they are, what tree they live in, etc.)

<slightlyoff> (discussion about conclusions)

<slightlyoff> Domenic: this is largely background and groundwork

<slightlyoff> ending for the day!

<Yves> https://pbs.twimg.com/media/BkI7VdfCAAA8h6i.png

<JeniT> this is running here in SF today: http://www.w3.org/2014/04/annotation/submissions/

<wycats> scribenick: wycats

<dka> Scribe: Yehuda

<dka> For discussion this morning: https://www.w3.org/wiki/TAG/Reviews

Tracking our reviews

<Domenic> https://github.com/w3ctag/spec-reviews/issues

<Domenic> https://github.com/w3ctag/spec-reviews/commits/master

Yves: Most of you may not be aware that we need to report from time to time to the AC and Jeff to show the progress of the TAG
... we discussed this morning about documenting that our new work style is actually working and having good effects on the specification and general work on APIs
... I put together a dashboard to show the work we're doing
... it's not like the previous product page - we don't need to document actions
... just dates and the impact we've had on the specification
... for example, with Push, we can see that we've had effects

wycats: do Jeff and the AC know what we're doing?

dka: yes
... this is about recording it for our own purposes
... and showing the positive impact
... the idea is to do it in a light-touch way so we're not adding a ton of bureaucracy

wycats: I thought the style of work on the quota management API was very good

Domenic: I just added quota management
... and Sergey's work on web animations

Yves: we don't want a heavyweight process here, just a basic dashboard

dka: Github has a lot of stuff in it, and this is a way to track where we've had an impact

Yves: or not

wycats: I was really happy about the CSS dashboard, and having a way to point people at what we're doing sounds great
... I've had people approach me with thoughts and helping them see what we're doing is awesome

dka: People can add stuff whenever, and this shouldn't add any more work for people who want to do reviews

Website

dka: I ripped off the web apps WG for us

http://www.w3.org/2001/tag/Overview-beta.html

<slightlyoff> scribenick: slightlyoff

dka: how does package url relate to zip urls?

wycats: they're the same

Package URLs

wycats: the reason this is important because we already have a packaging problem. JavaScript exascerbates this
... having maintainable content requires that you use multiple files
... in JS, e.g., ember apps, people use server-side concatenation
... this can mostly resemble a package of JS in one file. This is important to the way the web works today.
... however, I and Sam and Dave have done a bad thing with ES6 modules
... also the WC folks ahve done the same thign with imports
... we could have added syntax in ES6 modules that let you do "inline modules" for use in concatenation
... but we didn't do that

dherman: (clarification)

(one stream of bytes)

dka: you decided not to do this?

<Yves> like mime multipart?

wycats: yes. Andreas Rossberg of V8 pointed out that we were trying to solve a network problem; meanwhile people on the committee were advocating that poeple write this way when it wasn't for this use-case
... separately we also noticed that there are other places on the web where they have this problem (base64 encoding images inlining, inlining templates, etc.)

slightlyoff: we also built compilers that inline templates (Dojo & Closure)

wycats: we noticed that trying to solve this in JS was the wrong layer to solve it at

dka: sprites, etc.

wycats: so we punted to the W3C and said "they'll solve it"

timbl: mnot would say that HTTP 2.0 will solve it

wycats: because of the way people are doing bundling today, we're going to remove the current solution (inlining) in the module world
... and we find the "HTTP 2.0 or bust" message to not be compelling
... the way I'm imagining the system needing to work, these systems will start to predict what's needed and try to pre-emptively serve
... and they'll have to get very sophisticated to reason about the set of related resources

dherman: we're going to have to continue to reckon with a world where people can't control the servers they deploy on

timbl: yes. Every time we need to control the server we fail. e.g., real content type
... in practice, we've seen this pushback so much that I'm astonished mnot is making the argument

slightlyoff: FB, twitter, and Google all have lots of control
... the initial HTTP2.0 deployment environment doesn't look like an average webdev's experience

(discussion about SPDY, manifests, prediction, etc.)

(discussion of using the term "JIT")

(discussion of how to learn about related resources, etc.)

dherman: we need an interim solution in a pre-SPDY world

wycats: ember will *need* to be 100 files in a module world and we need a way to address that

timbl: I like the idea that a zipfile is an optimization and you don't refer to it directly

Yves: (question about using packaging)

slightlyoff: (discussion of layered packages)

Yves: was asking about local resources vs. over the network. wycats was targeting the network case

<JeniT> background: https://github.com/w3ctag/packaging-on-the-web

wycats: so there's one constraint -- having read Jeni's document -- discussing relative URLs
... there's the idea that you might have a directory and want to have urls like "../" continue to work
... e.g., I have thinger/index.html and an image at ../images/foo.png

JeniT: the idea was that the package would deal with fully resolved URLs

wycats: I think the relative lookup is the normal way people will want to use the system

JeniT: are you talking about files in the package relating to each other?

wycats: JeniT's proposal requires Content-Location header

for every item in the file

wycats: I'm trying to understand...if you don't specify Content-Location, would it be relative to the root of the package?

JeniT: how could you refer to it?

wycats: relative to the root of the package?

(some confusion)

JeniT: where would you get the filename if you don't do that?

wycats: oooh....I see...that's the name of the file

Yves: if you want to use a plain zip (vs. mulit-part mime), you could have location relative to the root of the document

wycats: how is this backwards compatible?

JeniT: you can continue to have the files on disk on the system

wycats: so if I have a script tag, and that's the entry point to the package, how do I refer to the files in the package?

JeniT: you point to the file you want to reference from your script element and it's loaded from the package

wycats: I'm confused...did I miss something?

JeniT: I tried to split up "how do we package it" from "how do we refer to it"

slightlyoff: JeniT's proposal is an overlay

<JeniT> https://github.com/w3ctag/packaging-on-the-web

<JeniT> https://github.com/w3ctag/packaging-on-the-web#requesting-a-package

(note that the <link> tag is how the package is ref'd)

slightlyoff: this gives rise to my issue; you need a way to get the original HTML from the package

wycats: yeah, if I have the full app in the package, how do i reference index.html out of the package?

JeniT: I was thinking you'd have all the files on your filesystem, and you'd reference other files in packages from whatever your entry point is

slightlyoff: this creates a challenge for signing

JeniT: you can include all the files in the package, no?

slightlyoff: yes, but what do I do for going to app.example.com?

Yves: it's the inverse to 209

JeniT: you could use 209 if it could be generalized

timbl: if you send mulit-part mail, there's one that's the "top-level" message in the package
... there's a clear distinction that the cover note is the thing being sent

JeniT: yeah, it could just be the first one in the package

wycats: I have a question about the <link>
... if I have <a href="...."> in a document...do I konw where that goes? do I have to block on package download?

slightlyoff: this is why I brought up extent

JeniT: I think it has to go on the <link>

wycats: this seems like my custom separator...
... if you say something like...<link rel="pkg" extent="/app/">
... <link rel="pkg" extent="http://example.org/app/">

JeniT: the other thing that was raised on the mailing list was some sort of glob

slightlyoff: I'd like the globbing to match up with whatever SW's do

wycats: this is the moral equivalent of what I'd proposed before
... you (dherman) objected because you wanted to find a separator to avoid the ergonomic cost of having to put the link tag in everywhere

dherman: we want the common programming patters not to require opt-in
... *every* time you use jquery, you need a link tag?

Yves: this a pre-HTTP2.0 solution

wycats: we don't think this is a transient thing...will need it for a long time
... imagine if this configured the browser (ES 6 module) loader
... JeniT's making the point that URLs matter and that if we use this overlay, we can not change the URLs

(discussion of spriting, packaging, etc.)

(wycats outlines JeniT's proposal to dherman)

dherman: somethign about this is making me worried
... this reminds me of Alex Limi's proposal...but that was on a much more fine-grained basis that required configuraiton

<annevk> http://limi.net/articles/resource-packages

discussion of CDNs, annoyance of configuration

annevk: this seems isomorphic to alex limi's proposal

Yves: the server could be smart about sending a header + package

JeniT: i looked at this. Does require a lot of configuration

<JeniT> see https://github.com/w3ctag/packaging-on-the-web#package-requests for that discussion

timbl: we should define a level of conformance about server capabilities

wycats: I think mod_spdy is eventually going to be a good solution for sites with dev-ops teams, etc.
... I hope that ghpages et all get the benfits

JeniT: annevk, you talked about this being tried (and failing) before
... is the environment different such that this will work better?

dherman: I thikn I can answer; this is very close to Alex Limi's proposal. There was another proposal (lost to time) that required more configuration. Alex Limi's work stopped at "SPDY will fix it". We're re-opening the discussion

dka: what is the deliverable?

wycats: the open question is Alex's concern about top-level?

dka: back to deliverable. What needs to be done? Who needs to do it?
... where?

wycats: I think the TAG is fine

dka: TAG is fine but theres an IPR issue, perhaps
... I'd like to understand what the shorter-term deliverable from us is

wycats: I missed a bunch of your proposal when I read it...I can perhaps accent the bits that help those like me who might have missed those bits

JeniT: it was written as proposal and not spec
... we can re-frame it as a spec and re-do it

wycats: was there a reason why in encapsulation section you rejected message-http as the boundary/header in multi-part mime?

JeniT: it was just kludgy
... it's horrible with multi-part because you ahve to have this parameter on the Content-Type. I thought, why not create a new Content-Type that sniffs th boundary instead. semantically mulit-part but has the sniffing added.

wycats: works for me
... the concern is server configuration

(discussion of configuration difficulty)

JeniT: 3 scenarios: (missed), spriting, and serving up the whole app from the package
... in that case (3rd) you have to serve up the starting page and the send the package

slightlyoff: smart servers should send the package + a 209-like-thing

(discussion of packaging, noting URL bar identifies a single thing)

annevk: this is using fragments?

group: no

slightlyoff: you can imagine a spec going either way about blocking or not

Yves: if you have that big a package...

slightlyoff: it's not about size. It's about blocking re: preload scanner

timbl: when you say that could be expensive...

slightlyoff: not in CPU, but in opportunity cost for missed download time

(discussion of costs)

(discussion about what to do with missing extent in the <link rel="pkg">

)

(discussion about optional vs. mandatory prefix/extents)

wycats: I think we're converging on the requirement

dherman: we should check with precsanner implementers

timbl: does this mean that packaging tools on the server need to be smart?

(discussion of headers and in-package metadata about extents)

<wycats> it's nice that you can explain the <link> tag in terms of service worker

timbl: is there a way that the requests could be redirected to packages in a stronger way? redirect to a package if we have an extent registered?

JeniT: in what I'd proposed, there was a Link header for retreiving CSV data so that for thigns which aren't HTML you can still reference packages

(discussion of header version)

wycats: we should make sure there's a way for the SW to handle this sort of thing as a polyfill

(discussion to about SW install flow)

dherman: so then the SW can handle this without requiring new clients

wycats: it'd be great if you could install some sort of a codec handler
... ...depending on perf
... there's likely going to be some sort of perf tradeoff

(agreement)

<scribe> ACTION: JeniT to make a respec document out of the proposal [recorded in http://www.w3.org/2014/04/02-tagmem-minutes.html#action01]

<trackbot> Created ACTION-857 - Make a respec document out of the proposal [on Jeni Tennison - due 2014-04-09].

<dka> ACTION: Jeni to make a new document on package URLs. [recorded in http://www.w3.org/2014/04/02-tagmem-minutes.html#action02]

<trackbot> Created ACTION-858 - Make a new document on package urls. [on Jeni Tennison - due 2014-04-09].

plinss: a proceedural question. I've heard conflicting things about wether or not the TAG can produce specs

dka: as everyone knows, the W3C operates under and RF policy
... everyone in the TAG is here as an Invited Expert

(per the charter)

dka: from an IPR perspective, if the TAG creates a spec, we're not automatically licensed under the W3C patent policy

wycats: Domenic, e.g., isn't an employee of a member company

dka: we can produce REC track docs, but we generally move things to WGs for expertise reasons
... e.g., this is why SW needs to be produced at WebApps

(everyone agrees this would suck)

(background around why TAG doesn't have patent policy)

<dka> See: http://www.w3.org/2003/12/22-pp-faq#taglic

wycats: we've put in the work. Would be good to get to the end from here without restarting the entire debate

slightlyoff: perhaps sysapps would take the work?

break

<timbl> dka, http://plane.ardupilot.com/

<timbl> http://diydrones.com/ etc

Integrity URLs

<Domenic> wycats: a good use case for integrity URLs is caching

<Domenic> JeniT: there are lots of caveats

<dka> ACTION: dan to talk to PSIG on whether or not it’s possible to amend the TAG charter to allow for rec track docs to run under the standard W3C IPR rules. [recorded in http://www.w3.org/2014/04/02-tagmem-minutes.html#action03]

<trackbot> Created ACTION-859 - Talk to psig on whether or not it’s possible to amend the tag charter to allow for rec track docs to run under the standard w3c ipr rules. [on Daniel Appelquist - due 2014-04-09].

<JeniT> http://w3c.github.io/webappsec/specs/subresourceintegrity/

<Domenic> wycats: the spec right now does say that this is a use case

<Domenic> JeniT/wycats: the caveats are about origins and security

<JeniT> http://w3c.github.io/webappsec/specs/subresourceintegrity/#caching-optional-1

<Domenic> wycats: the spec currently finds places URLs are used and adds places where you can add `integrity="""`

<Domenic> wycats: but finding every place URLs are used and adding attributes is a maintenance nightmare, sometimes impossible, lots of work, bad bad bad

<Domenic> wycats: I was thinking this is similar to packaging URLs and we might want to solve it the same way

<Domenic> wycats: maybe a Link tag?

<Domenic> JeniT: maybe site-wide would be better, e.g. a manifesty thing in a .well-known location

<Domenic> annevk: that seems problematic

<Domenic> annevk: you need this for CORS too

<Domenic> annevk: there are not that many things

<Domenic> wycats/dherman: there are many things

<Domenic> annevk: APIs should take a dictionary

<Domenic> annevk: the alternative is a generalized URL format that contains this metadata

<Domenic> wycats: we tried that with the package thing...

<Domenic> dherman: I'm not sure what I think ... it would be interesting to enumerate them

<JeniT> maybe use RDFa or microdata (?!?)

<JeniT> but that doesn't help in CSS

<Domenic> annevk: we've done the enumeration for many things, e.g. CSP or service worker

<Domenic> (discussion of `new Image` example)

<Domenic> annevk: CORS requires explicit metadata at fetch time

<Domenic> wycats: there are many different metadata things related to each fetch and they all use different syntax and it's hard

<Domenic> annevk: I agree

<Domenic> (meta violent agreement)

<Domenic> wycats: your objection to a Link tag or manifest solution is that it's too far away from the actual resource

<Domenic> wycats: I'm not sure that applies to integrity

<Domenic> annevk: (counterexample of an image in a templating system)

<Domenic> wycats: fair, but the crossorigin solution (extra attributes) extended to everything seems bad

<Domenic> annevk: what about a fetch attribute that takes a microsyntax expressing all these things

<Domenic> annevk: works in CSS and JS too

<Domenic> annevk: backward-compact in CSS works fine using fallback properties

<Domenic> Domenic: I'm worried about JS APIs mostly... how do we retrofit

<Domenic> (discussion of potential solutions ... usually just add a new parameter)

<Domenic> annevk: srcset is a big problem

<Domenic> annevk: even if crossorigin makes sense to apply to all the URLs in a srcset, integrity does not

<Domenic> annevk: integrityset!?

<Domenic> annevk: fetchset!?!?!?!

<JeniT> the existing design for providing metadata for URLs is RDF

<Domenic> wycats: I generally dislike microsyntax ... grumble grumble ...

<Domenic> wycats: I think the action item is to find all the extension points and consider how to invent a microsyntax, so that integrity could be hooking into an existing thing instead of having to do this work all over again and independently

<Domenic> slightlyoff: how are they explaining how verification is done?

<Domenic> wycats: it's very short

http://w3c.github.io/webappsec/specs/subresourceintegrity/#validation-3

<Domenic> wycats: I feel like this should be using webcrypto's algorithms?>

<Domenic> slightlyoff: at a minimum if a user agent provides integrity they should provide web crypto's SHA 256/512

<Domenic> (discussion of how webcrypto doesn't mandate things)

<Domenic> wycats: this whole integrity thing should be polyfillable with service worker + web crypto

<Domenic> (discussion of how to tie in to WebCrypto)

<Domenic> wycats: I think I am proposing a spec review of the integrity spec

<Domenic> wycats: I can try to do this but need help from annevk to understand all the constraints

<Domenic> wycats: there are two strategies

<Domenic> wycats: we need to create a new metadata mechanism on top of URLs regardless

<Domenic> wycats: we need to figure out how to express this everywhere

<Domenic> wycats: our options are either "close" or "far"

<Domenic> annevk: I have a pretty good handle on where URLs exist

<Domenic> annevk: srcset is the most problematic

<Domenic> wycats: we can just say it's legacy...

<Domenic> Domenic: already!?!

<Domenic> (some general incredulity)

<Domenic> JeniT: it is worth looking at RDF and RDFa for metadata about documents

<Domenic> JeniT: it doesn't help with CSS or JS but it does help with HTML

<Domenic> annevk: also it has many levels of indirection that will be problematic for authors

<Domenic> JeniT: I don't think so... you can put things inline with RDFa...

<Domenic> JeniT: I'd be happy to do a sketch of how it would look in RDFa

<JeniT> http://www.w3.org/TR/rdfa-lite/

<Domenic> wycats: I agree it would be a shame if we come up something extremely similar and not identical

<Domenic> ACTION: wycats and others to do an integrity URL spec review [recorded in http://www.w3.org/2014/04/02-tagmem-minutes.html#action04]

<trackbot> Created ACTION-860 - And others to do an integrity url spec review [on Yehuda Katz - due 2014-04-09].

<JeniT> timbl, you were talking about http://en.wikipedia.org/wiki/Extensible_Metadata_Platform

<Domenic> ACTION: wycats to collaborate with annevk on a plan for general metadata on URLs [recorded in http://www.w3.org/2014/04/02-tagmem-minutes.html#action05]

<trackbot> Created ACTION-861 - Collaborate with annevk on a plan for general metadata on urls [on Yehuda Katz - due 2014-04-09].

<Domenic> plinss: integrity URLs are heading in the direction (but not quite getting to) is doing cryptographic signatures, instead of just hashes

<Domenic> wycats: I think slightlyoff wants signatures also

<Domenic> slightlyoff: I sense that there is a need to be able to verify the contents of bundles etc.

<Domenic> slightlyoff: I think a packaging system is the first step

<Domenic> Domenic: can someone clarify how this is different from HTTPS?

<Domenic> slightlyoff: HTTPS is transport-level]

<Domenic> plinss: this would allow me to, once I get the resource, send it to you along with its signature so that you know it came from the original source

<Domenic> ... instead of from me

<Domenic> plinss: this could enable valuable other things in the future, e.g. a peer-to-peer mode

<Domenic> wycats: what's nice about this is that it solves the "omg too much javascript" problem, at least insofar as there are popular frameworks. E.g. jQuery gets downloaded very few times.

<Domenic> wycats: Google Ajax CDN is not perfect

<Domenic> Domenic: is there a potential for malicious collisions?

<Domenic> (you'd have to find a collision, which is not at all easy)

<Domenic> timbl/wycats: (discussion of the incentive structure this creates for library consumers)

<Domenic> wycats: rapid library releases actually encourage adoption of the latest version

<Domenic> wycats: I want this

<Domenic> https://github.com/w3ctag/promises-guide

<Domenic> + outstanding https://github.com/w3ctag/promises-guide/pull/21

Promises Guide

<wycats> Domenic: (goes through the sections of the Promises Guide)

<wycats> Domenic: suggests that people say "Promise objects are defined in [ECMAScript]"

<wycats> annevk: points out that people are using WebIDL anyway, which references ECMAScript already

<wycats> wycats: TC39 has been defining event loop concurrency and the browser has to hook into it

<wycats> (discussion about "continue running the following steps async"

<wycats> (discussion about tasks, microtasks, and "queue a task")

<wycats> (discussion about "run the following steps asynchronous", spawning a thread, await in ES7)

<wycats> dherman: we're talking about the meta-language vs. object-language

<wycats> Domenic: (explains what his spec is doing)

<wycats> annevk: in a normal situation, the spec would say "enqueue a task"

<wycats> Domenic: what language do we need to offer people about how to talk about running steps asynchronousl

<wycats> annevk: (talks about ways to explain how async works using the platform)

<wycats> dherman: this is where the extensible web goes off the rails

<wycats> dka: who is this document for?

<wycats> ... we need to tell people what TO do if we are telling them what NOT to do

<wycats> ... we should tell them what TO do first

<wycats> ... then tell them about antipatterns afterward

<wycats> dherman: about "run these steps asynchronously"... if there's a network fetch, shouldn't you say "when such and such happens, run these steps"

<wycats> annevk: (shows the XHR spec)

<wycats> dherman: I'm not sure how to read this

<wycats> (discussion about threads vs. running things async on the main thread)

<wycats> (discussion about how algorithms can keep running after returning)

<wycats> annevk: it seems like we're just discussing how to word things

<wycats> wycats: dherman, what are your thoughts?

<wycats> dherman: I've been doing a lot of thinking on the run-to-completion programming model

<wycats> ... it's fiendishly difficult to nail it down

<wycats> ... trying to get my head around what invariants we're trying to enforce

<wycats> ... this came to a head when I started fighting back against people who want to add data races into JS

<wycats> ... I really want to articulate why it's so critical

<wycats> ... I have been fighting the Balrog for years - YOU SHALL NOT PASS

<wycats> ... Yehuda is worried about avoiding a run-to-completion violation

<wycats> annevk: I'm not trying to change anything about the run to completion model

<wycats> dherman: the only way to know that is to read the spec carefully

<wycats> annevk: but how can you know?

<wycats> dherman: this is a constant vigilance we need to be careful about

<wycats> wycats: I think we need to beef up the meta-language so it can more easily protect against invariants

<wycats> dherman: yes

<wycats> annevk: I would love to migrate to something better

<wycats> wycats: this may be an extensible web hazard - we may have unobservable data races that we expose by accident

<wycats> annevk: I would love for TC39 to take over the role of WebIDL

<wycats> Domenic: WebIDL has a lot more than just some types

<wycats> annevk: WebIDL provides a central place for the platform to address general meta-language questions

<wycats> dherman: this is sometimes called "elaborative semantics"

<wycats> (discussion about ownership of the meta-language)

<wycats> dka: flagging that we have gone far beyond promises

<wycats> dka: should we be involving more WebIDL people?

<wycats> wycats + annevk: Cameron would love to have someone do this

<wycats> slightlyoff: we can use this to improve the idioms

JSIDL and WebIDL…

<wycats> (discussing TC39 ownership)

<wycats> dherman: Allen has been doing heroic work refactoring the ES spec incrementally dragging it into the 21st century

<wycats> (discussion about run to completion and garbage collection)

<wycats> (discussion about GC and WeakRefs)

<wycats> (discussion about why exposing GC is bad)

<wycats> dherman: GC produces non-determinism

<wycats> ... non-determinism produces interop hazards

<wycats> ... injecting randomness can help, but who knows

<wycats> dka: we need to have a meta-discussion around our design principles

Promises

<wycats> Domenic: we need to formalize "run asynchronously"

<wycats> (back to spec review)

<wycats> annevk: shorthand phrases should go in WebIDL

<wycats> Domenic: now that I finished promises I can finish up this guide

<wycats> ... comments are welcome

<dka> ACTION: Domenic to incoporate comments on guide and put it into respec… [recorded in http://www.w3.org/2014/04/02-tagmem-minutes.html#action06]

<trackbot> Created ACTION-862 - Incoporate comments on guide and put it into respec… [on Domenic Denicola - due 2014-04-09].

Web Animations

<Domenic> (twirl presents his slides)

<Domenic> twirl: seconds instead of milliseconds; we should probably recommend milliseconds

<Domenic> (discussion of origin of web animations. Is it flash inspired?)

<Domenic> slightlyoff: Google started on this; it is nice to unify the timeline models between SVG animations and CSS animations

<Domenic> slightlyoff: the answer is, this did not come from flash

<dka> Domenic: The specs don’t reflect reality to some extent.

<Domenic> wycats: if people claim to layer, we should teach them how to prove it

<Domenic> slightlyoff: not clear why twirl recommends building rAF on top of web animations

<Domenic> (discussion of whether it's possible for this spec to cause data races)

<Domenic> twirl: I am 95% sure there are no observable races

<Domenic> slightlyoff: (explains the idea of the coherent freely-manipulatable model vs. the synchronization with the rendering)

<Domenic> slightlyoff: our platform still has sync APIs that cause flushing between the model and the rendering

<Domenic> twirl: the spec should define what happens when I do getComputedStyle etc.

<Domenic> slightlyoff: it does, section 5.23

http://dev.w3.org/fxtf/web-animations/#script-execution-and-live-updates-to-the-model

<Domenic> wycats: specifically does getComputedStyle force a flush of the model into the view

<Domenic> slightlyoff: it does

<Domenic> (further discussion of interaction between layout forcing and animation)

<Domenic> twirl: my concerns are that this is not defined in the spec, and that the these two statements are confusing

<Domenic> slightlyoff: (explains the model and the layout/paint cycle and how changing properties of the model does not interact with layout/paint)

<Domenic> slightlyoff: style resolution can happen independently of anything being laid out or painted

<Domenic> annevk: I am concerned about the use of terms that don't mean anything like "execution block"

<annevk> In particular they need to define their terms and work on integrating with concepts defined outside their specification, such as tasks et al

<Domenic> https://github.com/twirl/spec-reviews/blob/master/2013/10/Web%20Animations.md

<Domenic> twirl: what next? More reviewers...

<Domenic> slightlyoff: the API feels odd in a few places...

<Domenic> slightlyoff: I can try to dump some of my thoughts into the review document

<Domenic> slightlyoff: I think you're right that there's confusion about how the models are meant to interact...

<Domenic> slightlyoff: the spec doesn't enunciate how layout relates to resolving styles and which of those two properties this operates on

<Domenic> Domenic: I can help nitpick APIs...

<Domenic> twirl: the spec is good, but very complex...

<Domenic> twirl: grouping in particular

<Domenic> wycats: how coupled is the grouping stuff to the simpler stuff

<Domenic> slightlyoff: I think it's not that coupled and it scales and composes pretty well

<Domenic> slightlyoff: the clone thing is very odd

<Domenic> wycats: there are callbacks, which maybe should be .... something different.

<Domenic> wycats: e.g. "finish" event?

<Domenic> dka/slightlyoff: we should have a call with an editor

<Domenic> ACTION: slightlyoff to do a brain dump on his thoughts [recorded in http://www.w3.org/2014/04/02-tagmem-minutes.html#action07]

<trackbot> Created ACTION-863 - Do a brain dump on his thoughts [on Alex Russell - due 2014-04-09].

<Domenic> ACTION: plinss to set up a call with web animations spec editor(s) [recorded in http://www.w3.org/2014/04/02-tagmem-minutes.html#action08]

<trackbot> Created ACTION-864 - Set up a call with web animations spec editor(s) [on Peter Linss - due 2014-04-09].

<twirl> http://dev.w3.org/fxtf/web-animations/#widl-Timing-easing

<Domenic> wycats: can easing be a general JS function instead of a string? E.g. like jQuery

<Domenic> Domenic: isn't it because then we'd have to have a story for executing arbitrary JS functions on another thread?

<Domenic> wycats: we should ask the jQuery people who work on animations whether they could replace jQuery's animations system on top of this spec. If not we've probably done the wrong thing.

<Domenic> ACTION: wycats to find jQuery animations people and ask if they could build on top of web animations [recorded in http://www.w3.org/2014/04/02-tagmem-minutes.html#action09]

<trackbot> Created ACTION-865 - Find jquery animations people and ask if they could build on top of web animations [on Yehuda Katz - due 2014-04-09].

<Domenic> plinss: to be clear that's not the goal of the web animations spec. It is geared toward explaining W3C specs

<Domenic> plinss: we *could* augment the existing spec with more things if necessary

- DRAFT -

SV_MEETING_TITLE

02 Apr 2014

Attendees

Contents