- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 18 Jul 2018 18:06:55 -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. ================================================= Properties and Values --------------------- - RESOLVED: Add custom property observers to L1 of Properties and Values. (Issue #555) - The PR in issue #767 (Multiple base URLs) should be merged in and a WPT added if there isn't already one. - RESOLVED: Add # to Properties and Values grammar syntax with the same definition and abilities as +. (Issue #768) Layout API ---------- - RESOLVED: No change in behavior [around constructors for layout fragments], add a note as to why constructors are not exposed. (Issue #760) - RESOLVED: Add a new LayoutFragmentResult object with a constructor. (Issue #760) - RESOLVED: Keep the layoutNextFragment name. (Issue #760) ===== FULL MINUTES BELOW ====== Agenda: https://github.com/w3c/css-houdini-drafts/wiki/Sydney-F2F-July-2018#proposed-topics Present: Rachel Andrew, Invited Expert Rossen Atanassov, Microsoft Tab Atkins-Bittner, Google L. David Baron, Mozilla Brian Birtles, Mozilla Tantek Çelik, Mozilla Emil A Eklund, Google Elika Etemad, Invited Expert Koji Ishii, Google Dean Jackson, Apple Ian Kilpatrick, Google Chris Lilley, W3C Peter Linss, Invited Expert, TAG Myles C. Maxfield, Apple Cameron McCormack, Mozilla Xidorn Quan, Mozilla Francois Remy, Microsoft Alan Stearns, Adobe Shane Stephens, Google Lea Verou, Invited Expert Philip Walton, Google Eric Willigers, Google Scribe: heycam ===== FULL MINUTES BELOW ====== Properties and Values ===================== Editors ------- TabAtkins: One thing is editorship, since Shane is leaving Rossen: Who are the current editors? Rossen: We currently have Tab Atkins, Daniel Glazman, Alan Stearns, and Greg W. astearns: This surprises me. Rossen: There are currently two issues in this spec TabAtkins: There are a few in GitHub. shane: 16 open, a few need edits. TabAtkins: We can run over them. Observer for property being applied? ------------------------------------ github: https://github.com/w3c/css-houdini-drafts/issues/555 TabAtkins: This has been something we're aiming for at some point TabAtkins: You want to be able to observe when and where a given custom property is put on an element TabAtkins: Right now the best you can do is you can do some processing on a custom prop, tell what grammar it's meant to have TabAtkins: You can't say that for every element with this property, do this JS TabAtkins: Only way right now is to walk the tree and ask the style for every element, not great to do in a tight loop TabAtkins: We already have things like this TabAtkins: xidorn pointed out you can use the transition events to get at this TabAtkins: but that's hacky, clearly TabAtkins: we're planning on this for level 2 TabAtkins: At minimum, to observe specified values TabAtkins: and older proposal shunted out is for computed value hooks, don't know if we want to do that immediately TabAtkins: We have to define in more detail how that interacts with animations and transitions, which is complicated TabAtkins: so at least getting the specified value out of things is probably worthwhile TabAtkins: So we could put it in this level, or wait to the next level iank: This would only be useful for non-inherited properties iank: otherwise you are going to walk the whole tree anyway, because everything is ... TabAtkins: You would only do it for everything that doesn't have the initial value. shane: Unless, like observers, they're applied per element shane: in which case the inheritance doesn't matter iank: I think the use case is that you want to do some computation ... TabAtkins: Here's an example from a script that does this TabAtkins: A bunch of things they need extra JS for <TabAtkins> http://endtwist.github.io/kerning.js/ TabAtkins: So I think it will be find on specified values for now iank: We're getting someone ramped up to finish the P&V implementation iank: had it landed behind a flag for 18 months now iank: getting it finished off next quarter iank: Given the number of cool demos, shipping it before Christmas Rossen: End of 2018 iank: Probably earlier Rossen: The reason I'm asking, is the current proposed feature for Level 1, that's fine, it's still a WD Rossen: so I'm curious whether you're pressing to start shipping, we might need to start stabilizing this spec Rossen: With that said, I think it's still worthwhile to take this in L1 and see if we can make progress TabAtkins: Anyone else have implementation? heycam: We have half an impl, might pick up again in Q4 but probably not ready to ship in Q4 TabAtkins: I'm going to fill in the parser section on how to parse a grammar string TabAtkins: obvious but handwavy TabAtkins: I have a lot of edits to apply to the spec Rossen: For this particular issue, we are resolving to have the observer for custom properties in L1, see how it goes Rossen: Concerns or objections? fantasai: I would say mark it as risk, I know we're not in CR now Rossen: We can do it once we get closer to CR dbaron: One other comment is, I think this is at a stage where it's ok to be adding new features, as long as they're reasonably solidly specified off the bat dbaron: So I think it's ok to add this if the text gets written relatively soonish and gets reviewed relatively soonish <fantasai> +1 to dbaron TabAtkins: I can promise to have the text written, and do as many other edits as I can, by the end of this month fantasai: Stabilizing for CR takes time, we don't want freshly added text that is shaky dino: The way this spec is now, it allows you to specify a way to interpolate custom props iank: You can define it to be non inherited iank: and also give it an initial value TabAtkins: And a level of grammar checking dino: Parse errors TabAtkins: Yes iank: A lot of demos at the moment are using it for animation, Ana Tudor has a bunch <iank> Ana Tudor demo: https://codepen.io/thebabydino/pen/MrZvNm (chrome canary + flag) iank: that's probably the biggest value as a standalone spec TabAtkins: This feature will be a huge uptick in use cases, when you can tell what elements have that property applied TabAtkins: So you think it should go in L1 to increase the value of the spec dino: I'm not necessarily saying that dino: but I'm fine with it philipwalton: Do we have any other observers? philipwalton: Are we thinking too small just looking at custom properties? TabAtkins: Possibly TabAtkins: The API shape that's in my head right now can definitely work with any property, just a string name TabAtkins: Only defined it for custom properties at the moment, but no objection to widening it if there's reasonable use cases and no major implementation issues TabAtkins: I know we handle custom props a bit differently from regular props TabAtkins: If you have use cases, please put it into the issue philipwalton: I think a lot of these use cases would be handled by calc() on the property dino: Might be nice to put more examples in, beyond animations dino: parse errors, non-inheriting, ... TabAtkins: Definitely. iank: [demos Ana Tudor's demo: https://codepen.io/thebabydino/pen/MrZvNm ] dino: So she's registering custom props for height, shadow, width, ... iank: Specifying things as angles, numbers iank: and then she's plumbing them into a huge transform effectively iank: So you can see scale effects, ... iank: all driven by one big transform, but animating different parts of the animation separately iank: and then setting a bunch of animations on it TabAtkins: It's being driven by one big transform prop, but independent animations on bits of it TabAtkins: This is a one element demo ericwilligers: This is one of the motivations for the separate translate/scale/... props frremy: She also has a demo animating gradients TabAtkins: Several examples of gradient animation RESOLVED: Add custom property observers to L1 of Properties and Values Multiple base URLs ------------------ github: https://github.com/w3c/css-houdini-drafts/issues/767 TabAtkins: There was a question of how should URLs resolve in a typed custom prop TabAtkins: If you give it an image type, how should you absolutize it TabAtkins: The resolution was to resolve like it would a real property, relative to the file it's in heycam: So where it was declared TabAtkins: Yes TabAtkins: As opposed to an untyped property, in which case the URL gets resolved in the property declaration where it gets substituted in TabAtkins: Now on to issue 767 TabAtkins: Here we have two separate custom props, in two different style sheets TabAtkins: declaring relative URLs. And in a third style sheet, using the two together in a background-image TabAtkins: The question is, how will these resolve according to where the custom prop was declared? TabAtkins: The answer is yes astearns: There's a PR in the issue iank: This is Anders in Oslo, working on Blink fantasai: Seems reasonable to me dbaron: Even better would be a WPT iank: Anders will definitely add one TabAtkins: No resolution needed then astearns: Should Anders be an editor? TabAtkins: He's not in the WG yet eae: Probably not yet Allow comma-separated lists in registered properties ---------------------------------------------------- github: https://github.com/w3c/css-houdini-drafts/issues/768 TabAtkins: The request is from Sam Richard, pointing out a lot of properties are comma separated lists TabAtkins: Right now the grammar for custom props allows just values separated by spaces, no repetition TabAtkins: I think it's reasonable to allow top level comma repetition TabAtkins: Would be happy to put this into the syntax spec fantasai: Do we have the ability to repeat without commas? TabAtkins: No TabAtkins: Not currently fantasai: Then I think those two should be added together, so people aren't forced to add commas just because they want repetition even when it would be inappropriate to use commas TabAtkins: That's probably reasonable TabAtkins: The grammar work to allow commas like a CSS grammar is similar to the work for space repetition TabAtkins: Will have to add a way to make that unambiguous, require the repeating part at the end or something birtles: We also need to specify how to animate the lists, if they're mismatched lengths <dbaron> (animation types are in https://drafts.csswg.org/css-transitions/#interpolated-types ) fantasai: Currently do you have multi valued properties at all? TabAtkins: Yes TabAtkins: Right now, you can do space separated repetition, but only of the entire thing fantasai: So you would add comma repetition of the entire thing TabAtkins: We don't have brackets yet fantasai: You just need a hash TabAtkins: That would only allow <length>#, not [<length> | <percentage>]# TabAtkins: Can only repeat a single term fantasai: That's a limitation currently for space separated values TabAtkins: Yes TabAtkins: At minimum, just adding that would work out ok though TabAtkins: The big issue is to define what the default list animation behavior is, and possibly allow a way to change which behavior you want there fantasai: Don't you have that question for <length>+ as well? TabAtkins: I'm not sure how that one animates TabAtkins: I think they just have to match in length right now dbaron: So that's the "simple list" definition in Transitions dbaron: The least common denominator thing is a generic thing that repeats the list dbaron: There are other things like for shadows with values used to fill missing spots dbaron: filters should have something similar TabAtkins: I think it does frremy: I think we should try to find an easy way to handle animations now in L1, then look at more complicated animations in L2 frremy: I feel like we should have an easy answer in L1, try to find use cases for more something complex TabAtkins: So we can use simple list behavior now, then figure out what we need for later TabAtkins: Objections to adding the # multiplier to L1 grammar? dbaron: Adding both the # and +? TabAtkins: + is already in the grammar Rossen: Any objections? fantasai: So add # with the same definition and abilities as + RESOLVED: Add # to Properties and Values grammar syntax with the same definition and abilities as + Properties and values API generally, again ------------------------------------------ dino: Google has implemented it behind a flag, hopefully by the end of the year dino: Mozilla has a vague implementation heycam: Two vague implementations dino: So maybe for Q4 you'll have three vague implementations dino: ;) iank: For our implementation, most of the work was teaching the animation subsystem how to animate these things. Layout API ========== TAG feedback ------------ github: https://github.com/w3c/css-houdini-drafts/issues/760 iank: This is a bunch of assorted TAG feedback iank: A lot of editorial stuff, but 3 or 4 issues we can talk about iank: The first one is having a constructor for layout fragments iank: In summary, currently today the only thing that can produce a layout fragment is the rendering engine iank: Call on the child, say lay out this fragment, it does some work, and gives back a fragment iank: The useful information is the width and height of the fragment, and you can return it in your list of children iank: Do we want a constructor for this? iank: We can add this, I'm not objecting, but the constraint is that this isn't a valid fragment you could return to the engine iank: Just a placeholder for testing Rossen: The current design has a fairly rigid assumption of who can produce fragments Rossen: and be responsible for their lifetime Rossen: and it's not the script, it's the layout engine Rossen: Exposing a constructor, you are fooling the user that they have control over it Rossen: so I would push back on this issue with that reasoning eae: Unless it's a valid fragment, it would be more confusing than it's worth Rossen: Again, it would lead down the path of considering those as user space objects when they're actually browser objects dbaron: What would it mean to have a real constructor for a fragment? iank: What Travis brings up here is events in the platform iank: Synthesizing an event through the system iank: This is quite often used for testing iank: It's not a real event iank: They're already second class citizens iank: For us, I'm struggling to come up with use cases for synthesizing events like that Rossen: Again, the fragment projection we give back to the user is just an interface with a bunch of functionality to interrogate properties Rossen: It's meant to be a black box that you can move around and that's it iank: The things you can read from it are the width, height, baseline info in the future, and basically just position it iank: If the child is also a custom layout it can pass information up via structured cloning iank: but that's basically it iank: dbaron or plinss anything to add? plinss: That's reasonable Rossen: Probably something that they didn't grok entirely, and they look similar on the surface but they're not plinss: In general the TAG likes to see constructors on everything plinss: but I agree here astearns: Would it make sense to add a note saying usually we have constructors but not here? Rossen: If it's lacking explanation let's add that RESOLVED: No change in behavior, add a note as to why constructors are not exposed iank: The second point, is that we return an options bag from layout iank: which does some magic iank: Explicitly you return the child fragments, auto block size, some other info iank: The engine goes and synthesizes a fragment for you with correct internal representation iank: Should that operation have a constructor, so you can create a new layout result fragment iank: and check if that operation fails iank: There are some cases where that operation could fail iank: For example, you pass it auto block size, create a new result fragment, at the moment it's just an options bag iank: and then inspect what your output box size is going to be, maybe do something different based on that iank: The other thing that can fail is when you deserialize the extra data you can pass up the tree iank: When you try to structured clone that, like adding a SharedArrayBuffer or something iank: currently we just say it threw an exception iank: With a constructor the user could detect that it threw an exception iank: I think it's reasonable, but would need to work out what the constructor's option bag argument would be iank: It's not entirely clear to me yet frremy: When I tried it, something I found frustrating is you can have a big option you want to give, only a few props on the object can't be serialized frremy: then you have to clone the entire object yourself, by removing the stuff you can't serialize frremy: Maybe would be nicer to set null for props you can't serialize for example iank: I think that's a bigger ask iank: Structured clone is painful for people to use iank: Would that have been useful? there's a bit out of your control iank: Would it be useful to ensure that operation doesn't fail? frremy: Something like JSON.stringify, with a callback to handle the unserializable stuff iank: That would be a slightly larger change in the HTML spec frremy: I don't think having a constructor would change anything frremy: Only solution is to clone iank: Would it have been useful to just get say the auto block size? frremy: Not sure iank: I think that's a reasonable ask, shouldn't be too much work, not sure many people would use it iank: Can always add it and use count it, remove if it's unused iank: We need to add a constructor, not just returning a FragmentResultOptions, but a constructor for a type like FragmentResult iank: then run all the steps for user and layout, structure clone, sanitize the output iank: By running the constructor you could catch an error that would happen during that process Rossen: As to the larger question, about expectations of what happens if the script starts throwing? iank: I think we just fall back iank: I think that larger question is just a misunderstanding, editorial Rossen: Objections to adding the new LayoutFragmentResult object? RESOLVED: Add a new LayoutFragmentResult object with a constructor. iank: Final piece of discuss-able feedback here iank: Confusion about layoutNextFragment name iank: Do we want to go back to layout? Rossen: No Rossen: That's like call everything object iank: David or Peter? dbaron: I already disagreed with Travis on that one frremy: I like that "next fragment" knowing that you're getting a fragment frremy: "layout" is too general iank: Rossen and David want layout plinss: I tend to prefer verbosity iank: Ian and Francois don't care Rossen: Other opinions or objections? RESOLVED: Keep the layoutNextFragment name.
Received on Wednesday, 18 July 2018 22:07:54 UTC