- From: Dael Jackson <daelcss@gmail.com>
- Date: Sun, 9 Oct 2016 20:39:22 -0400
- To: public-houdini@w3.org
- Cc: www-style@w3.org
================================================= These are the official Houdini Task Force minutes. Unless you're correcting the minutes, please respond by starting a new thread with an appropriate subject line. ================================================= Next F2F -------- - Pending room availability, Houdini will meet on 10 Jan in Seattle. AnimationWorklet ---------------- - rbyers walked the group through the updates made to the spec which include addressing the worklet and address synchronization concerns. - There were concerns that this was exposing the ability for webdevs to make bad choices. However, it was felt that this was no worse than what existed currently. - RESOLVED: AnimationWorklet moves to WICG Serialization of TypedOM ------------------------ - RESOLVED: Turning a basic property into a shorthand or into a list-valued property should work correctly and not break things. Properties and Values --------------------- - RESOLVED: Replace deregistration with a note that we're likely to add it later. - RESOLVED: For the grammar accepted by syntax, accept option 3 (Just take the literal string. register("--foo-*", ...) succeeds, has to be written as "--foo-\*: ...;") - There was interest in writing spec text to provide a generalized resource mechanism by making a dictionary, though this quite possibly will end up in level 2. - RESOLVED: Use CSS grammar definition syntax for defining grammar of custom properties. ====== FULL MINUTES BELOW ======= Agenda: https://github.com/w3c/css-houdini-drafts/wiki/TPAC-F2F-September-2016 Scribe: jet Next F2F ======== Rossen: Seattle Jan 11-13 for CSS Rossen: MSFT hosting. Rossen: Do we want 1 day of Houdini? When? Rossen: I suggest Tues 1/10 Rossen: We'll arrange for 1/10 pending room availability Rossen: in Seattle. dbaron: Following meeting dates? dbaron: April is tougher to schedule (easter & AC meeting) Rossen: June or July in Japan also possible per Hiroshi shane: let's defer summer scheduling until January? AnimationWorklet ================ <nainar> https://github.com/majido/animation-worklet-proposal/blob/gh-pages/README.md rbyers: We can scope down to bare minimum now rbyers: but that we can get consensus on in ~6 months or so. rbyers: Addresses synchronization concerns (eg. scrolling use cases) rbyers: ...but more synchronization can be a future level. rbyers: Addresses Apple feedback via a worklet design. dino: How does this cover parallax, spring, etc. TabAtkins: Houdini version of Scrolling Animations spec. rbyers: [goes over the Explainer] rbyers: [shows demo of custom timing function for a fade-in animation] rbyers: We already throttle rAF based on visibility. iank: Animation functions return TypedOM objects. dino: When do animations fire? esprehn: They start when the animator property is set. esprehn: We resolve then apply keyframes when animator prop is set. bz: It only returns a current keyframe? esprehn: Yes, the JS returns one per callback. dino: getComputedStyle() returns ___? run the animation loop first? shane: You get a null start time if you query an animation before a compositor round-trip shane: ...that computes the actual start time. dino: Explain root & children? rbyers: [demo: parallax scroll] rbyers: In this case, root is the document element rbyers: and the children are the items animating. bz: Is animator-root a comma-separated list? rbyers: Yes. rbyers: [demo: position-sticky] rbyers: Chromium position-sticky implementation won't be built on Houdini esprehn: but authors can use AnimationWorklets for such use cases. dino: Element transforms are clobbered by AnimationWorklet mutations? rbyers: Yes, just as with other animation libraries today. rbyers: [demo: synced scroller] rbyers: [shows how animator is slaved to another one] rbyers: [shows running demos] bz: Why is it hanging off window? iank: That will change. rbyers: [shows spring demo] rbyers: That's it for demos. rbyers: Open issues can be seen in GitHub. rbyers: Spec will change to apply to all properties (not just currently animatable ones). rbyers: We want webdevs to be able to reason about performance, eg., via console/devtools. rbyers: We expect to be able to animate off-main-thread (ie, no relayout-causing). esprehn: Seems reasonable to animate on main thread when needed. rbyers: Yes, but we should warn authors. dino: webdevs might make choices that suck on platforms that they don't test on. dino: eg., watch performance? rbyers: API specify root & all children, but not for different children. rbyers: Do we need that? esprehn: will-change is now implicitly set for all animations. dino: All the popular animatable properties create stacking contexts already anyway. rbyers: Are we past skepticism re: JS on the scrolling thread? Current design moves to a separate thread, not the scrolling thread. dino: Safari on iOS scrolls on a UI process. rbyers: Edge, Chrome going that way too. dino: I think my concerns were re: declarative vs. imperative model for these effects. rbyers: We should do both. dino: Fear of webdevs not using these tools correctly dino: are we providing tools that are easily misused? dino: With a declarative system, we can change implementations under the covers dino: but when we expose internals (eg, compositing thread) we get constrained to that model in the future. Rossen: And further, our architectures are a lot more different than say, the Style system Rossen: and we all do crazy stuff to get performance. Rossen: Edge is moving scrolling lower-level in the OS (not a separate process) Rossen: and exposing these primitives limits our ability to do that. rbyers: For user-driven scrolls, you already have to synch every frame? dino: Not Safari nor Edge. ojan: Compare a position:sticky polyfill today ojan: that slow down scrolling ojan: nothing in this proposal makes that worse. rbyers: Now in a worklet, no synch guarantees, but higher chance of keeping synch because of separate worklet thread. RESOLVED: AnimationWorklet moves to WICG <break length=20> Serialization of TypedOM ======================== shane: Firefox canonicalizes values for unconnected nodes dbaron: We always resolve ems but there are differences for computed style when unconnected. bz: Or display:none. dbaron: But that's mostly just our getComputedStyle serialization. esprehn: Would be a different serialization (like getComputedStyle but without resolving things that require unavailable knowledge, e.g., rem for unconnected font elements) shane: 1st phase: canonicalization 2nd phase: resolve relative units (eg, ems) dbaron: How is canonicalization different from OM getters now? shane: Today, either you never do canonicalization, or you do both phases. TabAtkins: Write out Value types for all of CSS over the next 2 weeks TabAtkins: or just define the representation of everything. shane: How about we do that now and come back later? dbaron: OK...I just don't want us to invent new things unless there's a good reason for them. TabAtkins: Where there's no existing serialization, we'll define a CSSOM serialization TabAtkins: and TypedOM later on will use that. gregwhitworth: Will this quantify serialization for specified values? shane: Yes. TabAtkins: We'll try to match getComputedStyle when we can. plinss: Don't carry over bad decisions. dbaron: Problem with old CSSOM is that it was poorly specified, and thus became UA-specific. dbaron: Shorthands does not occur in TypedOM spec. TabAtkins: Exist in Style values now. shane: Shorthands will be a CSS Style value. shane: We'll start with all longhands first. dbaron: btw, background-position is a shorthand Scribe: fantasai TabAtkins: Have to make sure turning a property into a shorthand doesn't mess everything up. ?: What does StyleValue.parse("backgroundposition", "center center") return? [answer missed] TabAtkins: Need to make sure upgrade to a list value works smoothly shane: Need to prepare 400 serialization things, then we can discuss stuff. RESOLVED: Turning a basic property into a shorthand or into a list-valued property should work correctly and not break things. Properties and Values ===================== Should property deregistration be possible? ------------------------------------------- shane: Want to move on to properties and values issues. shane: Last issue on agenda topics list is, should property deregistration be possible? shane: Currently can register and deregister type ? property. shane: But people point out custom elements, the houdini of HTML world, ... [missed] shane: Problems with deregistering type of custom properties. shane: Requires an expensive flush. shane: Or have to carry around a lot of extra values. shane: Certain attraction to just not allowing property types to be deregistered. bkardell: What's the use case for deregistering? shane: Don't think there was ever a use case. TabAtkins: Because we wanted to have a declarative version of property type registration at some point. TabAtkins: When that happen, style sheets can go away and change. TabAtkins: Mess around with typed OM. TabAtkins: Didn't want anything to be time/order dependent. esprehn: Requires reprocessing the entire sheet. <dbaron> http://dev.w3.org/houdini/css-properties-values-api/ TabAtkins: Adding or removing a custom property requires reparsing the whole sheet. Rossen: What is problem of deregistering? Rossen: Is there an actual technical reason to disallow it? Rossen: I heard something along the lines of hard and performance-taxing. TabAtkins: Requires the same full-world reparse that adding does. ojan: My feeling is the declarative thing you described, we can add deregistering when we add that. Don't have to do it now. shane: Can we resolve on that? plinss: As long as we make sure we don't build on the assumption it's not there. shane: So maybe add a note that it will be added later. RESOLVED: Replace deregistration with a note that we're likely to add it later. Need to define the exact grammar accepted by "syntax" ----------------------------------------------------- <shane> (this is https://github.com/w3c/css-houdini-drafts/issues/112) TabAtkins: Simon brought this up before ... algos here, e.g. register property, TabAtkins: Have to take a property name and parse it. TabAtkins: Easiest way is to parse as an ident. Allows us to throw if it's messed up. TabAtkins: Do we have full CSS parsing? E.g. handle escapes, comments. TabAtkins: Or do we just do simplistic check for ident characters? TabAtkins: Simpler concept. TabAtkins: Useful possibly for other places in the platform where we want to invoke CSS parsing, but don't want to invoke comment processing etc. plinss: My one concern is that you can use CSS escapes to put in characters into the ident that otherwise wouldn't parse. TabAtkins: We could take up a straight up string, use that directly with no other parsing. Then have to manually implement "is this an ident" check, e.g. no spaces. dbaron: You can put escaped spaces into an ident. TabAtkins: It's extremely weird, can't literally type it. plinss: In general I think escaping should be kept where it's meant to be used, e.g. no CSS escapes in JS. plinss: Use a JS escape in JS. plinss: In favor of not doing any CSS parsing here. TabAtkins: querySelectorAll uses CSS escapes. bz: That's a much more complicated syntax, makes sense to reuse CSS parser. ... bz: In this case plinss was saying just use any valid string as the ident. SimonSapin: In the APi it's just a property name. SimonSapin: But in syntax definition of a custom property, using syntax of custom ident with escaping and all that. TabAtkins: Oh hey TabAtkins: Example {syntax: "red | blue ";} TabAtkins: What if I want "red | blue | 3d"? TabAtkins: Understand that as an Ident that I want to do. SimonSapin: Except it's JS so you'd have to do \\33 d. plinss: That's why you don't want to mix escaping. TabAtkins: This is invalid, not what I just said, cuz doesn't match <custom-ident>. TabAtkins: Even though technically possible to have a keyword "3d" in CSS if you escape the three w eg --foo: \33 d; TabAtkins: You can of course just take a <custom-ident> {syntax: "red | blue | <custom-ident>" } TabAtkins: But then you're being really weird. TabAtkins: So I will change register property to not do anything weird, just check it. TabAtkins: Right now checking if ident and throwing syntax error, then checking if already registered. TabAtkins: Can get rid of first check. TabAtkins: Oh, I remember why has to be an ident. TabAtkins: registerProperty("--foo", ...) TabAtkins: Need to check that the first one is a valid ident, so that when you write your stylesheet you're writing something useful TabAtkins: Suppose I put registerProperty("3d", ...); TabAtkins: Then .foo { \33 d: ...; } ... shane: That would parse as invalid in CSS. ... bz: So real question is "-- d" bz: You can express that as --\ d: ...; plinss: I think it's ugly, don't really see why anyone would want to do that, but don't see why it's bad. plinss: You didn't write CSS escape in JS string, because you're not writing CSS, writing JS. <SimonSapin> plinss +1 TabAtkins: Rules for CSS idents are somewhat arcane. e.g. "--foo-*" be confused why it doesn't work fantasai: I don't think authors will be confused. Most people know a CSS ident is alphanumerics plus hyphens. Not gonna try that, or if see that expect the star to be some kind of magic syntax... if don't know about said magic syntax wouldn't try to use it. ... plinss: Need to escape that in the registered property. "--foo-\\*" fremy: In CSS can escape any character, e.g. \o plinss: My concern isn't people doing this, my concern is the tools. TabAtkins: If we throw on this thing, obvious right away. plinss: Dunno what custom CSS preprocessors are doing right now. plinss: .... TabAtkins: Won't work with registerProperty. shane: Three options, can we put it for a vote? <TabAtkins> 1. Manually check for name chars, then check it's an ident. (register("--foo-*", ...) will throw) <TabAtkins> 2. Just parse as custom-ident. register("--foo-\\*", ...) succeeds, has be written as "--foo-\*: ...;" <TabAtkins> 3. Just take the literal string. register("--foo-*", ...) succeeds, has to be written as "--foo-\*: ...;" <dbaron> 4. instead of escaping the characters, escape from the meeting :-) shane: Currently CSS allows an ident to include *any* character in Unicode, if you use escapes for certain ones. If you do some half-parse-check thing, then you're introducing a limitation through registerProperty that isn't in CSS. TabAtkins: ident check would be reasonable-ASCII or above-ASCII fremy: What do we do if you use getPropertyValue. SimonSapin: Pretty sure getPropertyValue doesn't do any escaping. Just compares strings. plinss: Problem with #1 is that --foo-* is a perfectly valid CSS property name. Can just use it by escaping * . Now you prevent me from using it. TabAtkins: getPropertyValue + this plus other thing are new enough we can change it later if problematic. [Votes: <TabAtkins> 1 <dino> 1 <plinss> 3 <shane> 1, then 4 <fantasai> 3 <SimonSapin> 3 <dbaron> 3, then 1 <nainar> 1 <frremy> 3 <surma> 1 <gregwhitworth> 1 <iank> 4 <JakeA> 3 ] shane: No consensus! shane: Any objections to doing whatever getPropertyValue does right now so we don't have to change it? SimonSapin: It does 3 RESOLVED: 3 (Just take the literal string. register("--foo-*", ...) succeeds, has to be written as "--foo-\*: ...;") Provide generalized resource mechanism -------------------------------------- <shane> https://github.com/w3c/css-houdini-drafts/issues/215 shane: Make a dictionary, use it later. shane: @font-face does this. shane: @keyframes does this. shane: Seems like a useful way of providing bundles of info to subsystems in CSS. shane: Do we want to ? in custom paint sometime? dbaron: Fun issues like scoped style sheets. gregwhitworth: Does this feel like a requirement for v1? shane: Would want to push to v2, but wanted to get other opinions. gregwhitworth: Personally think everything else is really solid, so bringing up something brand new with issues dbaron mentioned, better push to v2. eae: Use cases? shane: Really nice things, you can specify paint resources in custom paint, can ??? rather than having to pass image into every single thing. shane: But don't have to have for v1. shane: Sounds like interest to put into spec prose? [general nodding] How to express syntax of a custom property ------------------------------------------ shane: Pretty much all I have. shane: Saved easiest question for last shane: Grammar issue TabAtkins: How to express syntax of a custom property. TabAtkins: Forcing authors to write CSS grammar in a string would be confusing. TabAtkins: Instead proposed using the constructors directly. TabAtkins: E.g. if only take lengths, instead of taking string that says <length>, would take CSSLengthValue ( represent a length). TabAtkins: If take multiple lengths, take an array TabAtkins: This doesn't work. TabAtkins: We allow other types of combinations other than alternations TabAtkins: e.g. repetition. TabAtkins: We'd have to invent new syntax for that. TabAtkins: Also as we expand, we'll want to allow || and &&. TabAtkins: Want to allow full range of CSS grammar to be used. TabAtkins: Trying to base that on constructors becomes crazy. TabAtkins: Seems better to use a grammar syntax designed to do that. TabAtkins: We have one already: the CSS Grammar Definition Syntax. TabAtkins: So we shoudl use this. dbaron: Are you starting with a subset? TabAtkins: Yes, strictly. TabAtkins: Single values, single bar, and the plus combinator. No brackets either. TabAtkins: But want to expand on that in the future. fantasai: I'm strongly in favor of this. Authors who are working with CSS will be most familiar with this, and it has the full expressivity that we will want. leaverou: Totally agree. shane: Also lots of resources, easy to look up what it means, or to be "I want to be like this property" and just copy the grammar from that property. ... bkardell: By using the grammar, you create a giant crib sheet, people can go "I want to be like box-shadow, let me look up that and copy it" bkardell: Can you ask the constructors for the grammar? TabAtkins: Right now in CSS, if you want another property like box shadow, you use <'box-shadow'> TabAtkins: If a dev does that, and then we change box-shadow in the future, their code then breaks. TabAtkins: If you have a CSS box-shadow constructor and ask it for that, same problem. <fantasai> +1 TabAtkins: Fine to copy from spec, cuz that's static. <leaverou> +1 shane: At risk of calling down ire of Tantek... [tantek joins IRC as if summoned] RESOLVED: Use CSS grammar definition syntax for defining grammar of custom properties. shane: Break, then parser API. Official Houdini meeting is over. TabAtkins: Parser thing gonna give intro to WICG. <TabAtkins> SimonSapin: Parser API sketch https://wicg.github.io/CSS-Parser-API/
Received on Monday, 10 October 2016 00:40:22 UTC