IRC log of houdini on 2019-09-20
Timestamps are in UTC.
- 00:09:52 [RRSAgent]
- RRSAgent has joined #houdini
- 00:09:52 [RRSAgent]
- logging to https://www.w3.org/2019/09/20-houdini-irc
- 00:09:52 [plinss]
- present+
- 00:09:54 [oriol]
- present+
- 00:10:04 [mattwoodrow]
- mattwoodrow has joined #houdini
- 00:10:05 [cbiesinger]
- present+
- 00:10:06 [majidvp]
- Agenda https://github.com/w3c/css-houdini-drafts/wiki/TPAC-2019
- 00:10:11 [krit]
- present+
- 00:10:17 [dino]
- dino has joined #houdini
- 00:10:23 [dbaron]
- present+
- 00:10:28 [heycam]
- present+
- 00:10:35 [dino]
- present+
- 00:10:56 [TabAtkins]
- present+
- 00:11:02 [myles]
- myles has joined #houdini
- 00:11:04 [myles]
- ScribeNick: myles
- 00:11:11 [dino]
- dino has changed the topic to: https://github.com/w3c/css-houdini-drafts/wiki/TPAC-2019
- 00:11:12 [yigu]
- yigu has joined #houdini
- 00:11:14 [mattwoodrow]
- present+
- 00:11:16 [dino]
- Agenda: https://github.com/w3c/css-houdini-drafts/wiki/TPAC-2019
- 00:11:18 [myles]
- present+ myles
- 00:11:41 [yigu]
- present+
- 00:11:44 [myles]
- iank_: I have some demos!
- 00:12:02 [TabAtkins]
- Topic: Demo time
- 00:12:17 [myles]
- <room goes wild with excitement>
- 00:12:27 [myles]
- iank_: We got around to doing the line-by-line layout system.
- 00:12:45 [koji]
- present+
- 00:13:03 [myles]
- iank_: This means we considered blockifying all the children. This is the issue, we blockify everything. Here are some demos.
- 00:13:26 [myles]
- iank_: This is a multicol implementation, but it varies the column widths. The first one takes up 1/6 of the space, the next one 1/3, the last one 1/2. It doesn't do any column balancing.
- 00:13:32 [myles]
- iank_: it's pretty cool.
- 00:13:45 [myles]
- iank_: The next one is cool as well.
- 00:13:59 [myles]
- iank_: We did a quick line snapping
- 00:14:04 [myles]
- iank_: with koji
- 00:14:35 [myles]
- iank_: Instead of just pushing the line boxes down underneath one another, they's snapping ot a line grid
- 00:14:55 [myles]
- krit: Please select the text.
- 00:15:00 [myles]
- iank_: The selection is completely broken
- 00:15:13 [myles]
- iank_: The final cool one is: "initial two words"
- 00:15:34 [myles]
- iank_: it aligns the baseline of the first two words with the baseline of the third line of text
- 00:15:44 [myles]
- iank_: we're surprised about how powerful the line box API is. It's very flexible
- 00:15:48 [myles]
- Rossen: yaaaaaaay!
- 00:16:07 [myles]
- heycam: please show the code
- 00:16:12 [myles]
- iank_: Okay! The code is awful.
- 00:16:32 [myles]
- iank_: <shows the code>
- 00:16:56 [myles]
- iank_: All the demos are roughly 50 or 60 lines of code.
- 00:17:18 [myles]
- astearns: Is the grid just making sure the line height is a strict multiple?
- 00:17:29 [myles]
- iank_: It is. It's snapping the baselines to a multiple of 20px.
- 00:17:44 [myles]
- iank_: That's all, folks!
- 00:17:55 [TabAtkins]
- Topic: Inlinifying layout
- 00:17:57 [myles]
- myles: what's the name of the API that enables this?
- 00:17:59 [TabAtkins]
- github: https://github.com/w3c/css-houdini-drafts/issues/946
- 00:18:55 [myles]
- iank_: the "child display type" can be either "block" or "inline". When you layoutNextFragment, you can layout linebox by linebox. In the fragment you have the inline size, box size, and <missed> and that allows you to achieve all these effects
- 00:19:22 [myles]
- iank_: It's easy to do string-based layout when you blockify everything
- 00:19:39 [myles]
- iank_: Previously, we did normal child display, which didn't blockify. We think that's difficult to standardize, because all the engines do it differently, so we're proposing just inline-ifying everything
- 00:19:57 [myles]
- iank_: All the engines have a different way of splitting around block-level children and inlines. There's no consistency. This mitigates that problem.
- 00:20:05 [myles]
- heycam: Could those differences be exposed?
- 00:20:14 [dlibby]
- dlibby has joined #houdini
- 00:20:18 [myles]
- s/Could/Would/
- 00:20:21 [emilio]
- q+
- 00:20:34 [fremy]
- fremy has joined #houdini
- 00:21:00 [myles]
- iank_: Yeah, so, we, this was one of why we want to go down this path is it's quite difficult for us at the moment to not expose those differences. The way we build our box tree, children get squished down as a prepass to building the box tree. So, if we have something block-level inside something inline-level, it will get split into 3 pieces
- 00:21:05 [Zakim]
- Zakim has joined #houdini
- 00:21:19 [smfr]
- smfr has joined #houdini
- 00:21:31 [myles]
- emilio: When you have a block inside inline, you have to split into multiple things.
- 00:21:39 [myles]
- iank_: The engines don't agree on various edge cases here.
- 00:21:53 [smfr]
- present+
- 00:21:57 [myles]
- iank_: For example, if you've got only out-of-flow children, the engines handle the out-of-flow children and floats differently
- 00:22:00 [myles]
- emilio: That may be true
- 00:22:09 [myles]
- iank_: We didn't want to go down the rabbit hole by speccing everything
- 00:22:13 [myles]
- emilio: how do markers work?
- 00:22:17 [myles]
- iank_: <misseD>
- 00:22:29 [myles]
- iank_: You don't get a separate item from a list item at the moment
- 00:22:32 [myles]
- TabAtkins: Because it's explicitly inline?
- 00:22:34 [myles]
- iank_: yes.
- 00:22:41 [myles]
- emilio: What about an outside marker?
- 00:22:51 [myles]
- iank_: I think that will get wrapped in an anonymous block.
- 00:23:22 [myles]
- Rossen: What is the issue in the proposal?
- 00:23:30 [myles]
- iank_: To remove child display "normal" for now, and instead just do inlinification
- 00:23:42 [myles]
- Rossen: That makes sense for flow layout, but it doesn't make sense for anything else
- 00:23:53 [myles]
- iank_: YOu have to nest your custom layouts to get things like this
- 00:24:11 [myles]
- iank_: We have an explicit switch here which switches the display type. You can flip it to indicate you want to inline-ify your children
- 00:24:18 [myles]
- Rossen: So this just sets your content to be inline rather than block?
- 00:24:19 [myles]
- iank_: yes.
- 00:24:49 [myles]
- cbiesinger: What happens to block children? DO tey become inline block?
- 00:24:50 [myles]
- iank_: yes
- 00:25:37 [myles]
- Rossen: In your example in the issue, the ABC followed by DEF ...
- 00:25:47 [myles]
- iank_: This would be represented as one child, with its children inline-ified
- 00:26:10 [myles]
- Rossen: Are you going to ignore <missed>?
- 00:26:16 [myles]
- iank_: Yes, because it's ismpler.
- 00:26:19 [myles]
- Rossen: It makes no sense
- 00:26:29 [astearns]
- s/<missed>/the display-outside value of the div/
- 00:26:30 [myles]
- iank_: It's the same as flexbox or grid blockifying. Just hte reverse.
- 00:26:41 [myles]
- Rossen: So how can display:block continue to be block?
- 00:26:51 [myles]
- iank_: You can't. You need two levels of custom layout. They must communicate internally
- 00:26:59 [myles]
- Rossen: That sounds complicated and unnecessary
- 00:27:02 [myles]
- iank_: It's simple to implement
- 00:27:27 [myles]
- Rossen: Yes, I know that. But the expectation is that I'd be able to handle flow layout in a fairly straightforward way for me, that restriction makes everything much harder
- 00:27:31 [myles]
- iank_: It depends on the use case
- 00:27:35 [myles]
- Rossen: Use case is normal CSS 2.1 support
- 00:27:48 [myles]
- iank_: If you just care about line grid snapping, this is what you want. You don't want to have to handle block level things
- 00:28:12 [myles]
- TabAtkins: We're not saying "you will never be able to do layout with block and inlines" but right now you have to pick either all block or all inline, because that's simpler.
- 00:28:31 [myles]
- dbaron: They both seem like reasonable options to have. Maybe it's worth having a note in the spec about reintroducing something else?
- 00:28:32 [TabAtkins]
- q?
- 00:28:56 [myles]
- majidvp: If we go wiht a simple model now, can we change the model later without breaking existing layouts?
- 00:29:22 [myles]
- iank_: Yes. To respect the display of the node, you would set the child display to be normal in a future version
- 00:29:29 [myles]
- dbaron: What layout capabilities do you have in inline content in this midel?
- 00:29:46 [myles]
- iank_: You can vary the given available space in the inline. You can shrink and expand how big the lines are (like the multicol layout)
- 00:30:50 [myles]
- iank_: The code for this is layout out many line boxes across the columns. You can also change how percentages resolve. You can also get the baseline information out. This one works by laying out the first two words with 0 available width, and then given available space to allow these other words to fix next to them, and then lay everything out with maximum available space
- 00:31:22 [myles]
- TabAtkins: Wouldn't that have a line break between "lorem ipsum"?
- 00:31:22 [myles]
- iank_: I have a non-breaking space between them
- 00:31:32 [myles]
- dbaron: It sounds like you've got a lot of control about the inputs and outputs of line layout, but nothing the internals of line layout
- 00:31:33 [myles]
- iank_: yes.
- 00:32:17 [myles]
- TabAtkins: Was this just an introduction, or do you want a resolution for this change?
- 00:32:25 [myles]
- TabAtkins: Proposed resolution: Remove
- 00:32:54 [myles]
- RESOLVED: Remove normal layout and replace it with "block" and inline" and add a note saying we will reintroduce normal layout later
- 00:33:42 [myles_]
- myles_ has joined #houdini
- 00:33:59 [myles_]
- ScribeNick: myles_
- 00:34:16 [masonfreed]
- masonfreed has joined #houdini
- 00:34:28 [myles_]
- emilio: At which point does the simplification happen? If I put float:right in the div, do I get a div with floating style and display none?
- 00:34:37 [myles_]
- iank_: The float will switched to an intermediate line in this case, because we don't handle it
- 00:34:45 [dino_]
- dino_ has joined #houdini
- 00:34:46 [myles_]
- emilio: Do you also modify the computed style, or just layout box
- 00:34:55 [myles_]
- iank_: The computed style, just like flex and grid
- 00:34:58 [myles_]
- emilio: No.
- 00:35:12 [myles_]
- TabAtkins: Flex and grid blockify at computed value time
- 00:35:19 [myles_]
- emilio: They don't add or remove float properties
- 00:35:25 [myles_]
- TabAtkins: Those don't apply
- 00:36:10 [myles_]
- cbiesinger: in chrome it modifies the computed style, but per spec it shouldn't
- 00:36:20 [myles_]
- iank_: For us, the computed style of target float is none
- 00:37:58 [myles_]
- iank_: Firefox logs "left" and Safari logs "none"
- 00:38:12 [myles_]
- <silence>
- 00:38:42 [myles_]
- iank_: abspos modes of custom layout don't exist
- 00:38:47 [myles_]
- emilio: We could specify it
- 00:38:54 [myles_]
- iank_: in that case, we don't need special handling
- 00:39:03 [myles_]
- emilio: They just don't appear in teh custom layout stuff, like normal out of flow
- 00:39:08 [myles_]
- cbiesinger: What static position do they get?
- 00:39:36 [myles_]
- iank_: They're block children, so the padding inline block. Whatever the standard static position of an internal line box
- 00:39:50 [myles_]
- cbiesinger: If there's a custom algorithm, how does it know where the static position is?
- 00:39:57 [myles_]
- iank_: It's the static position of the marker inside the element
- 00:40:07 [myles_]
- emilio: I think it depends
- 00:40:25 [myles_]
- koji: It may be more comlicated when teh containing block is inline, and we compute merged boxes
- 00:40:33 [myles_]
- iank_: It should be fine ...?
- 00:41:20 [myles_]
- iank_: If you've got out-of-flow inside inline, that position is somewhere in the line box. For the purposes of layout, it's just positioning line boxes. It doesn't care about out-of-flow children. When we then handle out-of-flow as a postpass, they are handled naturally
- 00:41:43 [myles_]
- koji: Static position is fine. I was thinking about when the containing block is inline ancestor and we have right currently
- 00:42:07 [myles_]
- iank_: In that case, the out of flow layout parts would pick up where those open span and close span is
- 00:42:07 [myles_]
- iank_: it might be easy if we just do this
- 00:42:12 [myles_]
- iank_: I can't spell
- 00:42:33 [myles_]
- iank_: It crashes. We currently don't handle that.
- 00:42:34 [koji]
- s/right currently/`right: 0`/
- 00:43:02 [myles_]
- Rossen: Are we still working through this issue? I think we should move on.
- 00:43:03 [myles_]
- iank_: okay
- 00:43:28 [myles_]
- TabAtkins: Before the next topic, who put WebAssembly integration on the agenda?
- 00:43:36 [myles_]
- TabAtkins: Does anyone have anything we want to hit first?
- 00:43:45 [myles_]
- TabAtkins: Font enumeration? property registrations?
- 00:44:00 [TabAtkins]
- Topic: Scoping Property Registrations in Shadows
- 00:44:03 [TabAtkins]
- github: https://github.com/w3c/css-houdini-drafts/issues/939
- 00:44:07 [myles_]
- Topic: Scoping property registrations in the shadows
- 00:44:34 [TabAtkins]
- github: https://github.com/w3c/css-houdini-drafts/issues/939
- 00:44:37 [iank_]
- scribenick: iank_
- 00:45:19 [iank_]
- TabAtkins: Simon brought up, if we want prop registration scooped to shadow trees.
- 00:45:48 [iank_]
- TabAtkins: Best case an custom element will unregister a property, and reregister it.
- 00:46:06 [iank_]
- TabAtkins: There is a meta issue around things not being scoped in CSS.
- 00:46:38 [iank_]
- TabAtkins: 1) What happens when a property registered in the light dom, inherits into the shadow dom, and there is different property registrations.
- 00:47:12 [iank_]
- TabAtkins: I suspect that we can basically, it keeps around a synthesized property string, as it goes into the new thing, it can be reinterpreted.
- 00:47:26 [iank_]
- TabAtkins: This sounds similar if it wasn't registered.
- 00:47:41 [iank_]
- TabAtkins: If you do a size property, it'll probably be a <length> it both places.
- 00:47:57 [iank_]
- TabAtkins: You can code defensively, but resetting at the top of the shadow root.
- 00:48:18 [iank_]
- TabAtkins: If it crosses the boundary it just gets reinterpreted as a token stream.
- 00:48:31 [TabAtkins]
- s/but/by/
- 00:48:45 [iank_]
- heycam: A broader problem seems to be what .... there is no good way to partition these properties.
- 00:49:03 [iank_]
- heycam: If you have multiple registrations.
- 00:49:08 [iank_]
- TabAtkins: Nothing more specific.
- 00:49:31 [iank_]
- heycam: I could imagine 2 custom element authors, both coming up with a --theme property independently.
- 00:49:53 [iank_]
- heycam: No way to handle that these could be interpreted differently.
- 00:50:18 [iank_]
- TabAtkins: As long as the two components are siblings you could set it above the CEs.
- 00:50:33 [iank_]
- TabAtkins: If they are nested, the outer CE knows that it nested the child.
- 00:51:13 [iank_]
- iank_: Has CE scoping occured yet?
- 00:51:22 [iank_]
- masonfreed: Still not solved yet.
- 00:51:56 [iank_]
- heycam: If we expect component authors to use suitably named properties to avoid conflicts, then the solution you described sounds fine.
- 00:52:32 [iank_]
- heycam: 90% of CP usage I see, is setting the properties on the root.
- 00:53:26 [iank_]
- fremy: Another option would be to, have a map of token streams, and when you read it , it can switch based on the reading context.
- 00:53:57 [iank_]
- fremy: Its consistent within a property tree, downside if you have slots you can't reset these.
- 00:54:20 [iank_]
- fremy: We might want to ask people who are using CEs on how they use them.
- 00:55:36 [TabAtkins]
- problem case: Light-dom author sets a theming property expecting it to apply to whole page. Shadow-dom author uses colliding name in their shadow. Shadow version of the property is what the slotted content sees, not the light-author's intended light value.
- 00:56:13 [iank_]
- heycam: Can you describe other discussions?
- 00:56:13 [TabAtkins]
- https://github.com/w3c/csswg-drafts/issues/1995
- 00:56:16 [iank_]
- TabAtkins: Yes
- 00:56:28 [iank_]
- TabAtkins: discussion was about font-face but was about other things.
- 00:56:42 [iank_]
- TabAtkins: not just font-face, fill: url(#something), etc.
- 00:56:49 [iank_]
- TabAtkins: A lot of confusion.
- 00:57:11 [iank_]
- TabAtkins: People think that you just walk upwards, but this would be bad, as unreliably interpreted differently.
- 00:57:51 [iank_]
- TabAtkins: My idea - each value which has this context depedence, it keeps around a link to where it was declared. As its passed around contexts, it keeps a reference to what defined it.
- 00:58:09 [iank_]
- TabAtkins: The reference would be explicitly caught, and reflected in the TypedOM version.
- 00:58:46 [iank_]
- TabAtkins: It'll be Document, or ShadowTree, etc, could grab the value, and use it elsewhere.
- 00:59:10 [iank_]
- heycam: On font-face specifically not sure how this effects document.fonts
- 00:59:32 [iank_]
- TabAtkins: ShadowTree would have a tree.fonts, conceptually.
- 01:00:02 [iank_]
- TabAtkins: keyframes rules, etc would also be what was defined within your scope, but would still work if you interited a keyframe across a shadow root boundary.
- 01:00:21 [iank_]
- heycam: Does this match what fremy described?
- 01:00:24 [iank_]
- TabAtkins: Yes.
- 01:01:01 [iank_]
- TabAtkins: That would solve the problem which i minuted earlier. Keeping the simple keeping the value with a single reference. Complexity is a little worrying.
- 01:01:13 [iank_]
- smfr: Is any of this written down anywhere?
- 01:01:35 [iank_]
- TabAtkins: Only present within that issue thread. As nobody has said this is good.
- 01:01:42 [iank_]
- TabAtkins: <snark>
- 01:01:51 [iank_]
- smfr: I'll try and get our CSS folks to review it.
- 01:02:26 [iank_]
- emilio: I don't think @font-face works within a shadow tree.
- 01:02:43 [iank_]
- emilio: keyframes don't work, blink/ff do something different to webkit.
- 01:02:53 [iank_]
- TabAtkins: Yeah would like to get a consistent answer.
- 01:03:03 [emilio]
- s/don't work/don't work the same across browsers
- 01:03:43 [iank_]
- TabAtkins: What registration use when it is a Shadow Host. Light DOM sees it as a normal element, Shadow DOM sees it as a :root.
- 01:03:52 [iank_]
- TabAtkins: Which registration should it use?
- 01:03:56 [iank_]
- TabAtkins: Not sure.
- 01:04:30 [iank_]
- TabAtkins: 1) Uses the reg. of whereever that style came from, outer uses outer reg. for example.
- 01:04:57 [iank_]
- Good thing: styles always work, as long as they don't touch at the same time. But unpredictable for what TypedOM returns.
- 01:05:06 [iank_]
- fremy: But if you do what I said it can support both.
- 01:05:36 [iank_]
- TabAtkins: If we do the multiple scopes, we need to define how to get all the versions of the property.
- 01:05:50 [iank_]
- fremy: Yes - that's another question, how do you read the values.
- 01:06:06 [iank_]
- TabAtkins: None of my proposals have to worry about what context the script is in.
- 01:06:18 [iank_]
- TabAtkins: Big problem is what happens w/ typed om.
- 01:06:24 [iank_]
- fremy: I don't have a good idea for that.
- 01:07:17 [iank_]
- TabAtkins: 2) Always use the context which the element lives within. This means always get the Light DOM version. Means that you can never set the :host of the shadow DOM.
- 01:07:29 [iank_]
- plinss: That seems not good.
- 01:07:50 [iank_]
- TabAtkins: I agrree its not great, but simple and pretictable.
- 01:08:07 [iank_]
- TabAtkins: Not sure which one I want to do.
- 01:08:15 [iank_]
- TabAtkins: If anyone has opinions let me know.
- 01:08:28 [iank_]
- TabAtkins: As far as I can tell that is the major issue.
- 01:08:40 [iank_]
- TabAtkins: Lets get our browser folks about how this should work.
- 01:08:51 [iank_]
- TabAtkins: At some point I'll commit text about how this should work.
- 01:09:00 [iank_]
- heycam: What happens with constructable stylesheets.
- 01:09:13 [iank_]
- heycam: What happens to style elements which haven't been inserted within the point yet.
- 01:09:34 [iank_]
- heycam: ... e.g. you can access these from the TypedOM for these.
- 01:09:50 [iank_]
- emilio: This is at specified value time, and the grammer isn't applied yet.
- 01:10:03 [iank_]
- TabAtkins: ... yes - only at computed value time this is applied.
- 01:10:41 [iank_]
- TabAtkins: I'm good with this issue then, can move only the next one.
- 01:11:16 [iank_]
- fremy: Last thing you proposed, it'll use the Light DOM reg., the advantage is that you can always use both. If you are within the light tree, you can't pass information into the shadow tree.
- 01:11:42 [iank_]
- fremy: Component - wants to have a custom prop e.g. --grid-type
- 01:12:07 [iank_]
- TabAtkins: You can still set it, it won't get corrected until it hits the shadow tree.
- 01:12:44 [TabAtkins]
- Topic: perf concerns of custom properties
- 01:12:45 [TabAtkins]
- github: https://github.com/w3c/css-houdini-drafts/issues/940
- 01:13:29 [iank_]
- smfr: One if the issues w/ this being a JS api, is that there isn't a good time to register the properties.
- 01:13:53 [iank_]
- smfr: e.g. stylesheet loads, prop registered, need to recalc stylesheet potentially.
- 01:14:06 [iank_]
- smfr: Similar to style recalc thrashing.
- 01:14:21 [iank_]
- smfr: Has been a proposal for a declarative version of registered custom properties.
- 01:14:32 [heycam]
- q+
- 01:14:57 [iank_]
- TabAtkins: It seems like you have the same issues, e.g. if the properties come later in a sheet, or a later style sheet.
- 01:15:22 [heycam]
- q-
- 01:15:24 [iank_]
- smfr: B/c you only have to parse the properties once. And it'll come in a "batch."
- 01:15:40 [iank_]
- dino: You could imagine a bunch of component libs, which each register a custom properties.
- 01:15:50 [iank_]
- dino: If delcarative, they come all at once.
- 01:16:04 [iank_]
- TabAtkins: How is this different to JS setting this to something different each time?
- 01:16:11 [iank_]
- TabAtkins: You need to rerun all the style on the root.
- 01:16:22 [iank_]
- smfr: It depends how much work you need to do if the type changes.
- 01:16:32 [iank_]
- TabAtkins: If you have an untyped its still the same.
- 01:16:48 [iank_]
- TabAtkins: If its still the same, is there much of a concern still?
- 01:17:07 [iank_]
- smfr: We should try not to add new APIs let authors pull trigger for a performance cliff.
- 01:17:43 [iank_]
- TabAtkins: Would we get everything from the declarative appraoch, yes at the moment, but future levels, e.g. hooks, then no.
- 01:17:59 [iank_]
- smfr: Can we just to declar version atm?
- 01:18:46 [iank_]
- TabAtkins: As they are equiv. in power. But would be in favour if rewriting the spec to make the declarative version much more promiment.
- 01:19:16 [iank_]
- dino: In the spec if it calls out - most optimal way to declare all of them at top, then use them. And explain in the spec to do this.
- 01:19:33 [iank_]
- smfr: Also call out how to correctly use the JS api.
- 01:20:04 [iank_]
- majidvp: In JS api, you only need to do this if you trigger style reclac.
- 01:20:44 [iank_]
- emilio: Did agree that JS -reg properties, @property do not conflict. JS API won't throw.
- 01:20:55 [iank_]
- TabAtkins: That's in the pending edits.
- 01:21:09 [iank_]
- TabAtkins: JS stuff is on a separate layer.
- 01:21:16 [iank_]
- dino: What would happen? Ignored?
- 01:21:31 [iank_]
- TabAtkins: JS api wins. Treated as the "last" one.
- 01:22:03 [iank_]
- dino: If browser only supports JS version, nothing special.
- 01:22:49 [iank_]
- smfr: I have another thing related to animating untyped custom properties.
- 01:22:58 [smfr]
- https://codepen.io/smfr/pen/JjPerWw
- 01:23:02 [dlibby]
- dlibby has joined #houdini
- 01:23:39 [iank_]
- smfr: Question is - to do animation of untyped animated propeties, do you need to rerun the style-recalc each frame?
- 01:23:51 [iank_]
- TabAtkins: No, it flips 1/2 way through the animation.
- 01:24:01 [iank_]
- TabAtkins: All unreg. custom props are discreet.
- 01:24:12 [iank_]
- smfr: ok
- 01:24:48 [iank_]
- fremy: If you animate the custom property, and use it in another property which animates?
- 01:24:59 [iank_]
- emilio: Everyone is different (only FF gets it right?)
- 01:25:14 [iank_]
- TabAtkins: We discussed this years ago, there are like 16 options.
- 01:25:17 [iank_]
- dbaron: 6.
- 01:25:23 [iank_]
- TabAtkins: There were sub-options.
- 01:25:44 [iank_]
- majidvp: What happens when you reg. a type for that custom prop while animationing.
- 01:25:58 [iank_]
- TabAtkins: Just changes the value of the custom prop.
- 01:26:06 [iank_]
- TabAtkins: If that's unclear, happy to add somethign.
- 01:26:26 [iank_]
- heycam: Thats different to when you change font-size?
- 01:26:42 [iank_]
- TabAtkins: Yes - it changes the value of the property, e.g. from a token-stream to a <length>
- 01:27:05 [iank_]
- heycam: In web-anim is it possible to change the from value.
- 01:27:26 [iank_]
- TabAtkins: I believe it kicks off a new transition. Not entirely clear how this works.
- 01:27:54 [iank_]
- majidvp: web-anim for the duration of the animation, when you start the animtion the curve is computed, but transitions are different.
- 01:28:10 [iank_]
- TabAtkins: Sounds like it answers the relevant questions \o/
- 01:28:24 [iank_]
- smfr: Can we talk about the status?
- 01:28:40 [iank_]
- smfr: Hesitant to implement all the syntaxes.
- 01:28:49 [iank_]
- TabAtkins: Isn't that what we do right now?
- 01:29:02 [iank_]
- TabAtkins: A handful of primitive types, w/ + and *
- 01:29:07 [iank_]
- smfr: I thought it was more that that?
- 01:29:32 [iank_]
- TabAtkins: No there isn't the possibility for needing to decide what part of the syntax to match.
- 01:29:40 [iank_]
- TabAtkins: 3.1 describes all that you can do.
- 01:29:55 [iank_]
- TabAtkins: thing+ | other-thing+ etc,
- 01:30:24 [iank_]
- <br type="morning-tea" length="30m">
- 01:34:36 [cathiechen]
- cathiechen has joined #houdini
- 02:00:18 [satakagi_]
- satakagi_ has joined #houdini
- 02:06:08 [smfr]
- smfr has joined #houdini
- 02:06:29 [majidvp]
- github: https://github.com/w3c/css-houdini-drafts/issues/945
- 02:06:46 [Rossen_]
- Rossen_ has joined #houdini
- 02:06:53 [TabAtkins]
- github: https://github.com/w3c/css-houdini-drafts/issues/940
- 02:07:01 [TabAtkins]
- Topic: WebAssembly and Workers
- 02:07:05 [mattwoodrow]
- mattwoodrow has joined #houdini
- 02:07:13 [iank_]
- github: https://github.com/w3c/css-houdini-drafts/issues/945
- 02:07:17 [masonfreed]
- masonfreed has joined #houdini
- 02:07:26 [iank_]
- majidvp: This is a topic when boris looked at the animation worklet spec.
- 02:07:57 [iank_]
- majidvp: The concern is that most of the worklet specs, try to look at the class which is passed, and look at as if it was a JS object. E.g. access things w/ the prototype.
- 02:08:20 [iank_]
- majidvp: Doesn't sit will when the future when WASM can access these platform APIs. e.g. use IDL for these sections.
- 02:08:35 [iank_]
- majidvp: Issues there is no good way to check if something is a constructor.
- 02:08:44 [iank_]
- majidvp: I think tab was in agreement that we should do this.
- 02:08:57 [iank_]
- TabAtkins: The more stuff we do in WebIDL the better.
- 02:09:27 [dino]
- iank_: there have been issues on WebIDL in the past about exposing class constructors
- 02:09:32 [dino]
- iank_: is that in WebIDL yet?
- 02:09:36 [dino]
- heycam: i don't know
- 02:09:37 [iank_]
- heycam: I don't know.
- 02:09:53 [iank_]
- majidvp: Not sure yet.
- 02:10:06 [dlibby]
- dlibby has joined #houdini
- 02:10:11 [iank_]
- heycam: Having a webidl concept / type makes the most sense.
- 02:10:27 [iank_]
- iank_: what is web components doing?
- 02:10:39 [iank_]
- majidvp: Proposal is for them to also change their model.
- 02:11:02 [iank_]
- majidvp: Up to the web components folks to change it.
- 02:11:06 [heycam]
- https://github.com/heycam/webidl/issues/701
- 02:11:11 [iank_]
- Rossen: Curious to know if they were ahead of us.
- 02:11:23 [iank_]
- heycam: Dropped an issue disucssing the webidl feature.
- 02:12:10 [iank_]
- Rossen: Any objects to transfer over to webidl?
- 02:12:18 [iank_]
- RESOLVED: Transfer over to webidl.
- 02:12:38 [dbaron]
- iank_: to clarify, when WebIDL stuff is ready
- 02:13:03 [TabAtkins]
- Topic: Font Table Access API
- 02:13:07 [skk]
- skk has joined #houdini
- 02:13:17 [TabAtkins]
- github: https://github.com/inexorabletash/font-table-access/
- 02:14:10 [TabAtkins]
- github: https://github.com/w3c/css-houdini-drafts/issues/950
- 02:14:21 [iank_]
- cmp: I can start by given some info for the proposal for font table access.. current status is explainer and proposal stage, interested in HoudiniTF to give feedback at this stage. No facility to access information for fonts which is local to this system.
- 02:14:30 [pwnall]
- pwnall has joined #houdini
- 02:14:39 [iank_]
- cmp: No way to build an application to access these font tables. Only way to build a native app.
- 02:14:44 [pwnall]
- present+ Victor Costan (Google)
- 02:15:57 [jsbell]
- jsbell has joined #houdini
- 02:16:05 [jsbell]
- present+
- 02:16:15 [iank_]
- <discussion about blue light>
- 02:16:26 [iank_]
- cmp: <shows explainer>
- 02:16:51 [TabAtkins]
- explainer: https://github.com/inexorabletash/font-table-access/
- 02:16:59 [iank_]
- cmp: The shape of the API - has a permission request. Proposal to add a naviagator.permissions.request({name: 'local-fonts'})
- 02:17:25 [iank_]
- cmp: Then it adds a font enumeration API - e.g. navigaor.fonts.query()
- 02:17:46 [iank_]
- cmp: query() method returns an async iterator.
- 02:18:11 [iank_]
- cmp: Once you get the font you can query the types of tables, which are then represented as an array buffer.
- 02:18:17 [iank_]
- <see explainer>
- 02:18:47 [iank_]
- cmp: User might interact with a font-chooser to select which fonts are exposed.
- 02:19:06 [iank_]
- cmp: This is the shape of the API which we are considering. We'll send an Intent to Implement on chromestatus.com
- 02:19:16 [iank_]
- cmp: Can put those links into irc if useful.
- 02:19:26 [iank_]
- cmp: That is covering the proposal, at that point.
- 02:19:34 [iank_]
- cmp: Questions / comments?
- 02:20:01 [iank_]
- myles_: I think there is a few problems with this api, i think they fit into 2 cats.
- 02:20:10 [iank_]
- myles_: 1) Mechanical types
- 02:20:25 [iank_]
- myles_: on our platform we have a bunch of fonts, which are in AAT format.
- 02:20:49 [iank_]
- myles_: If we expect authors to implement their own font engines, folks wont use the AAT format correct.
- 02:21:03 [iank_]
- myles_: Similarly for emoji fonts are in a different format.
- 02:21:25 [iank_]
- myles_: We have custom information within the files, much of this is standardized, but some of it isn't.
- 02:21:47 [iank_]
- myles_: We expose this information through the CoreText API which exposes all this information which is normalized.
- 02:22:12 [iank_]
- myles_: Exposing this infromation as raw is not the way to expose this, better to expose different objects.
- 02:22:23 [iank_]
- cmp: A mix of mechanical & philosphical.
- 02:22:39 [iank_]
- cmp: Point well taken, e.g. divergiving font formats.
- 02:22:56 [iank_]
- astearns: It would also be nice to future proof this for future formats.
- 02:23:07 [jyasskin]
- jyasskin has left #houdini
- 02:23:21 [iank_]
- eae: Havne't been able to come up with a standard way to represent all the different formats.
- 02:23:41 [iank_]
- eae: I don't think its unreasonable for web developers who are using this to handle the different formats.
- 02:23:50 [iank_]
- heycam: What types of developers is this targetted at?
- 02:24:36 [iank_]
- eae: More complex apps which are doing typesetting, they bundle the fonts, and cross compile harfbuzz etc. And the web applications can't use local fonts, and these can't be bundled due to licensing reasons.
- 02:24:48 [iank_]
- myles_: Native apps don't have access to these?
- 02:24:51 [iank_]
- eae: They do?
- 02:24:58 [heycam]
- q?
- 02:25:07 [iank_]
- myles_: The API for the text system, is CoreText.
- 02:25:15 [iank_]
- eae: But you can always access the font files.
- 02:25:20 [iank_]
- myles_: But this isn't an API.
- 02:25:42 [iank_]
- heycam: Do you know why authors are cross compiling harfbuzz etc?
- 02:26:02 [iank_]
- eae: They want to get things like glyph outlines, and selectively apply kerning.
- 02:26:23 [iank_]
- myles_: Totally a viable problem, we should solve this, but not convinced that this is the right way to get about it.
- 02:26:29 [Rossen_]
- ack dbaron
- 02:26:29 [Zakim]
- dbaron, you wanted to ask about alternative entry points to the api
- 02:26:34 [iank_]
- dbaron: I wanted to raise a different issue.
- 02:26:43 [iank_]
- cmp: Philosphical point?
- 02:27:30 [iank_]
- dbaron: one other comment about this - the api as you've shown this, is tied into the font enumeration api, one of the issues, its not clear what the right permission model to get user concent.
- 02:27:43 [iank_]
- dbaron: one issue, is if there should be a different entry point.
- 02:28:11 [iank_]
- dbaron: Might be better to hook this up to something else.
- 02:28:37 [iank_]
- heycam: Eariler you said font-enum api would provide access via the FontFace object.
- 02:28:50 [iank_]
- TabAtkins: Yes if you have a webfont you can also access the table from those.
- 02:29:09 [iank_]
- cmp: Yes it is the existing FontFace object.
- 02:29:18 [iank_]
- dbaron: If thats the case this addresses my concern.
- 02:29:22 [Rossen_]
- q?
- 02:29:59 [iank_]
- myles_: Also worth pointing out, over the past 3 years, variable fonts have been implemented. Generally considered to be a good thing for web platform. If folks implement APIs to parsing font tables, this success wouldn't have been possible.
- 02:30:14 [iank_]
- eae: Thats fair, but we don't expect that the majority of websites would use.
- 02:30:40 [iank_]
- myles_: There is the set of websites that want outlines, and want to get outlines on installed fonts.
- 02:30:50 [iank_]
- myles_: I wouldn't be suprised if the intersection was very large.
- 02:31:03 [iank_]
- TabAtkins: I suspect it'll be design tools.
- 02:31:33 [iank_]
- myles_: But would want to render the same on each platform, but wouldn't want the local font?
- 02:31:53 [heycam]
- q+
- 02:31:55 [iank_]
- TabAtkins: But they might want to access the local fonts b/c we don't have licensing for these things.
- 02:32:09 [iank_]
- myles_: The set of websites who actually want this seems very small.
- 02:32:24 [iank_]
- TabAtkins: it exists on powerful design tools on desktop.
- 02:32:29 [iank_]
- myles_: Or they use webfonts.
- 02:32:52 [dbaron]
- I should be clear that I'm pretty sympathetic to Myles's concerns, both in terms of font format evolution and whether this is the right layer to be exposing.
- 02:32:52 [iank_]
- TabAtkins: But if someone have bought fonts under various licencing agreements which can't be redistributed.
- 02:34:07 [iank_]
- myles_: Talking to a group of people which make a successful web based design tool, and there is another solution to the licensing issue, e.g. could expose a subset of the font .
- 02:34:25 [iank_]
- myles_: Not saying this is the best solution, but there are other solutions for the licensing issu.e/
- 02:34:50 [pwnall]
- q+
- 02:34:56 [iank_]
- TabAtkins: If the way around licensing issue, is to expose only the parts, you also need an app to do that as well.
- 02:35:06 [iank_]
- TabAtkins: (and back at square one).
- 02:35:16 [Rossen_]
- q?
- 02:35:25 [Rossen_]
- ack heycam
- 02:35:28 [iank_]
- heycam: Eariler emil, was saying we've tried to come up with higher level apis and failed.
- 02:35:40 [iank_]
- heycam: would be good to see the list of requirements for these design tools.
- 02:35:58 [iank_]
- eae: Sure we'll try and share as must of these design explorations as possible.
- 02:36:51 [iank_]
- pwnall: We are also talking to a successful web design tool, this tool tells a user to install a local server to handle the local fonts on the system.
- 02:36:56 [Rossen_]
- q?
- 02:37:02 [pwnall]
- ack pwnall
- 02:37:11 [iank_]
- myles_: I wanted to ask another question.
- 02:37:39 [iank_]
- myles_: A few years ago - there was an API for the local font access API. This API feels similar to this API.
- 02:37:46 [myles_]
- https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/G-hC66MRTso/kfWDYhC_BAAJ
- 02:37:54 [iank_]
- myles_: Why do you think this will succeed when the other one didn't?
- 02:38:27 [iank_]
- myles_: In particular there are a few members from the chrome team which brought up issues with this api.
- 02:38:47 [iank_]
- myles_: if you don't have thoughts we can come back to this.
- 02:38:54 [iank_]
- eae: yeah no thoughts at this time.
- 02:39:15 [iank_]
- TabAtkins: There are differences, might have just been a less mature proposal.
- 02:39:27 [iank_]
- myles_: Those differences don't seem that important.
- 02:39:34 [jsbell]
- q?
- 02:39:39 [jsbell]
- q+
- 02:40:01 [iank_]
- cmp: Having reviewed the previous proposal, the table access was the big change/shift from the previous version. Font enum wasn't exposing the FontFace instance.
- 02:40:32 [jsbell]
- q-
- 02:40:39 [iank_]
- myles_: Not addressing the other questions raised here.
- 02:40:48 [iank_]
- myles_: There are also fingerprinting concerns.
- 02:41:13 [oyiptong]
- oyiptong has joined #houdini
- 02:41:19 [oyiptong]
- present+
- 02:41:22 [iank_]
- myles_: Also there is the philisophical question around this, it would all 100% of the text engine to be written in JS.
- 02:42:04 [iank_]
- myles_: Having a centralized place trying to get text to work correctly over many years, has worked better than a particular team making a particular usecase work.
- 02:42:10 [iank_]
- Rossen_: What is the particular ask?
- 02:42:22 [iank_]
- eae: We'll follow up on the good feedback.
- 02:42:31 [iank_]
- Rossen_: Lets go to the other propoal.
- 02:42:44 [mattwoodrow]
- mattwoodrow has joined #houdini
- 02:42:49 [TabAtkins]
- Topic: Local Font Enumeration
- 02:42:51 [TabAtkins]
- github: https://github.com/w3c/css-houdini-drafts/issues/951
- 02:43:30 [iank_]
- cmp: SImilar usecases, these web applications that we'd like to enable, would like to get a list of local fonts to present users a list of local fonts which are avail.
- 02:43:40 [iank_]
- cmp: Proposing a change to the font loading specification.
- 02:43:49 [iank_]
- <displays code on screen>
- 02:44:29 [TabAtkins]
- Reading again thru the old thread you linked, Myles, I find the major objection is about the usefulness of exposing binary data, given the necessity of porting a font-shaping engine to JS to do anything useful with it. There's a mention at the end that wasm should make this concern much less problematic, and I think time has shown this correct. ^_^
- 02:44:34 [iank_]
- cmp: Adds a FontFace.getMetadata() function.
- 02:44:53 [Rossen_]
- q?
- 02:45:13 [iank_]
- cmp: Again this is meant to be a font-chooser UX. E.g. allowing the user to access the local fonts, then allow access to the table.
- 02:45:23 [iank_]
- cmp: Also an Intent to Implment for this API.
- 02:45:40 [iank_]
- myles_: <discussion around minor code issue>
- 02:46:07 [iank_]
- heycam: navigator.fonts is a separate issue?
- 02:46:22 [iank_]
- cmp: navigaor.fonts is a FontFaceSet.
- 02:46:28 [iank_]
- heycam: Same as document.fonts?
- 02:46:32 [iank_]
- TabAtkins: No different.
- 02:46:40 [TabAtkins]
- s/No /No, /
- 02:46:55 [iank_]
- myles_: Can you state the usecase for this?
- 02:47:16 [TabAtkins]
- TabAtkins: document.fonts provides sync access to all the webfonts. This needs to give async access, for filesystem-enumeration reasons.
- 02:47:37 [iank_]
- cmp: Usecase for this is a web application would like to get a list of the locally installed fonts, the web application they shows a font picker, then the web application can access this font do things with it.
- 02:48:05 [iank_]
- myles_: Most document applications want to show the exactly the some thing? So what application are you thinking of?
- 02:48:28 [plinss]
- q+
- 02:48:30 [iank_]
- cmp: A design application for example. E.g. have a locally installed font that is under a license.
- 02:48:42 [iank_]
- TabAtkins: E.g. a company have purchase a particular font.
- 02:48:50 [iank_]
- TabAtkins: And want to use this consistently.
- 02:49:20 [iank_]
- myles_: We don't consider locally installed fonts for to web content.
- 02:49:22 [TabAtkins]
- TabAtkins: Or a company that can assume all the designers have access to a particular purchased font, and are just going to use it for local collab + printing.
- 02:49:29 [krit]
- q+
- 02:49:34 [iank_]
- myles_: Therefore would be able access via this api.
- 02:49:53 [iank_]
- s/would be/wouldn't be/
- 02:50:05 [Rossen_]
- q?
- 02:50:12 [heycam]
- q+
- 02:50:24 [iank_]
- myles_: In at least one of the 3 browsers, the issue would be solve that this API is trying to solve
- 02:50:44 [iank_]
- s/would be solve/wouldn't be sovled/
- 02:50:45 [Rossen_]
- ack plinss
- 02:50:52 [fremy]
- fremy has joined #houdini
- 02:51:04 [satakagi]
- satakagi has joined #houdini
- 02:51:04 [heycam]
- q-
- 02:51:16 [mattwoodrow]
- mattwoodrow has joined #houdini
- 02:51:25 [iank_]
- plinss: Rather than an api which enumerates all the fonts, expose an API which allows the browser to select a single font?
- 02:51:39 [iank_]
- TabAtkins: If that was the proposal would that reduce your concerns?
- 02:52:06 [Rossen_]
- q?
- 02:52:13 [iank_]
- myles_: Yes, but when fingerprinters run, they could enumerate over all the fonts which would provide a lot more entropy.
- 02:52:31 [plinss]
- s/browser to select/browser to display its own font picker and the user select/
- 02:52:57 [iank_]
- iank_: But its a behind a permission prompt?
- 02:53:16 [pwnall]
- q+
- 02:53:23 [iank_]
- myles_: I don't believe there is a set of words which would indicate informed consent.
- 02:53:31 [Rossen_]
- ack krit
- 02:53:32 [iank_]
- myles_: (for the permission prompt)
- 02:53:36 [TabAtkins]
- I agree, permission prompts are valuable, but limited.
- 02:54:04 [iank_]
- krit: What about a new UI element, if the font isn't available, would you get a notification that a particular font isn't available?
- 02:54:28 [iank_]
- krit: Would there be an API where an application could ask in a particular font is installed.
- 02:55:05 [iank_]
- heycam: In the font loading spec at the moment, if you call check() with a font which isn't available (e.g. not loaded, or not in installed local fonts) then it should throw.
- 02:55:43 [iank_]
- cmp: None of the implementations return the additional information.
- 02:55:53 [iank_]
- heycam: whether this API is a good idea is a separate question.
- 02:56:25 [iank_]
- krit: Have a document w/ text in it which used a separate font. The web application needs to identify this case.
- 02:56:49 [Rossen_]
- q?
- 02:56:56 [iank_]
- TabAtkins: On browsers which still expose a large set of local fonts via the font family. check() would still work. but on safari it wouldn't.
- 02:57:18 [iank_]
- myles_: We also know, iterating over all the fonts in a system is the wrong way to do it.
- 02:57:28 [Rossen_]
- ack pwnall
- 02:58:36 [iank_]
- pwnall: One usecase that I wanted to share, that wouldn't be solved w/ the picker in the UA. Web applications can design very complex pickers based on the usecase, e.g. the web application can filter based on what licsence types can be used (and should be available) for a particular project type.
- 02:58:44 [Rossen_]
- q?
- 02:58:55 [iank_]
- pwnall: There are usecases which are lost if the UA has to implement the picker.
- 02:59:12 [Rossen_]
- ack dbaron
- 02:59:12 [Zakim]
- dbaron, you wanted to raise one more issue about permission prompts
- 02:59:24 [iank_]
- dbaron: One other thought about permission prompt, has two purpsoes, to gain support, and to teach the user that this doesn't happen in other cases.
- 02:59:28 [satakagi_]
- satakagi_ has joined #houdini
- 03:00:05 [iank_]
- dbaron: E.g. the location permission, this idicates to the user that the location isn't exposed by default. Teaches the user about the expectations around privacy for the user.
- 03:00:20 [iank_]
- dbaron: Asks a question to the user which doesn't usually happen.
- 03:00:34 [iank_]
- dbaron: In this case, given how fonts work today, that is quite difficult.
- 03:00:35 [Rossen_]
- q?
- 03:00:57 [iank_]
- TabAtkins: If the UA provide the font picker , then we wouldn't need that picker.
- 03:01:14 [iank_]
- TabAtkins: How would the web application know about the license type.
- 03:01:15 [plinss]
- s/that picker/that permission/
- 03:01:54 [iank_]
- pwnall: The web application would scan font tables, e.g. woff has a licensing table to provide the ability to filter.
- 03:02:00 [dbaron]
- I wonder how many seconds (or minutes) said app would take to do that scanning of font tables to populate the UI!
- 03:02:16 [TabAtkins]
- ScribeNick: TabAtkins
- 03:02:28 [satakagi]
- satakagi has joined #houdini
- 03:02:58 [TabAtkins]
- dbaron: We've def seen in browser font stack impls, especially for the "users who have lots of fonts" cases, just setting up the font infra in the browser can sometimes be a serious perf problem.
- 03:03:12 [TabAtkins]
- dbaron: So anya pp doing what you just said, scanning all the fonts, there's a good risk of that taking seconds to minutes.
- 03:03:25 [jsbell]
- q+
- 03:03:38 [dbaron]
- s/anya pp/any app/
- 03:03:41 [TabAtkins]
- cmp: Yeah, good point. We're trying to see the effect in practice as we experiment.
- 03:03:54 [TabAtkins]
- myles_: Do you know of a native app that does this kind of license filtering? I'd like to play with it.
- 03:04:02 [TabAtkins]
- pwnall: I'll follow up with you.
- 03:04:08 [myles_]
- mmaxfield@apple.com
- 03:04:17 [TabAtkins]
- astearns: There are "design applications" that will do pre-flighting of fonts used in a doc as it's doing output.
- 03:04:49 [TabAtkins]
- astearns: As you're saving something, you can ahve a step that checks for fonts and ensures they're licensed.
- 03:05:10 [TabAtkins]
- TabAtkins: That use-case would be handled by the font-face tables access of UA-picked fonts, without needing full enumeration.
- 03:05:24 [TabAtkins]
- jsbell: I use GIMP, it takes forever to load, that's what tools do.
- 03:05:37 [TabAtkins]
- jsbell: I think it's presumptuous to say that we don't think that class of applications can be used on the web.
- 03:06:24 [TabAtkins]
- cmp: Thank you for the comments! We'll follow up, please ping me with additional comments.
- 04:03:03 [skk]
- skk has joined #houdini
- 04:06:48 [mattwoodrow]
- mattwoodrow has joined #houdini
- 04:21:35 [mattwoodrow]
- mattwoodrow has joined #houdini
- 04:29:54 [myles]
- myles has joined #houdini
- 04:32:00 [myles]
- myles has joined #houdini
- 04:41:00 [myles]
- myles has joined #houdini
- 04:43:59 [kzms2]
- kzms2 has joined #houdini
- 04:46:40 [skk]
- skk has joined #houdini
- 04:47:03 [rego]
- rego has joined #houdini
- 04:53:41 [myles]
- myles has joined #houdini
- 05:27:23 [Zakim]
- Zakim has left #houdini
- 05:52:56 [dino]
- dino has joined #houdini
- 06:54:27 [mattwoodrow]
- mattwoodrow has joined #houdini
- 07:19:50 [satakagi]
- satakagi has joined #houdini
- 09:15:07 [jsbell]
- jsbell has left #houdini
- 09:26:22 [Rossen]
- Rossen has joined #houdini
- 09:27:53 [leaverou]
- leaverou has joined #houdini
- 09:28:24 [plinss_]
- plinss_ has joined #houdini
- 10:52:23 [satakagi]
- satakagi has joined #houdini
- 11:10:21 [mattwoodrow]
- mattwoodrow has joined #houdini