00:09:52 RRSAgent has joined #houdini 00:09:52 logging to https://www.w3.org/2019/09/20-houdini-irc 00:09:52 present+ 00:09:54 present+ 00:10:04 mattwoodrow has joined #houdini 00:10:05 present+ 00:10:06 Agenda https://github.com/w3c/css-houdini-drafts/wiki/TPAC-2019 00:10:11 present+ 00:10:17 dino has joined #houdini 00:10:23 present+ 00:10:28 present+ 00:10:35 present+ 00:10:56 present+ 00:11:02 myles has joined #houdini 00:11:04 ScribeNick: myles 00:11:11 dino has changed the topic to: https://github.com/w3c/css-houdini-drafts/wiki/TPAC-2019 00:11:12 yigu has joined #houdini 00:11:14 present+ 00:11:16 Agenda: https://github.com/w3c/css-houdini-drafts/wiki/TPAC-2019 00:11:18 present+ myles 00:11:41 present+ 00:11:44 iank_: I have some demos! 00:12:02 Topic: Demo time 00:12:17 00:12:27 iank_: We got around to doing the line-by-line layout system. 00:12:45 present+ 00:13:03 iank_: This means we considered blockifying all the children. This is the issue, we blockify everything. Here are some demos. 00:13:26 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 iank_: it's pretty cool. 00:13:45 iank_: The next one is cool as well. 00:13:59 iank_: We did a quick line snapping 00:14:04 iank_: with koji 00:14:35 iank_: Instead of just pushing the line boxes down underneath one another, they's snapping ot a line grid 00:14:55 krit: Please select the text. 00:15:00 iank_: The selection is completely broken 00:15:13 iank_: The final cool one is: "initial two words" 00:15:34 iank_: it aligns the baseline of the first two words with the baseline of the third line of text 00:15:44 iank_: we're surprised about how powerful the line box API is. It's very flexible 00:15:48 Rossen: yaaaaaaay! 00:16:07 heycam: please show the code 00:16:12 iank_: Okay! The code is awful. 00:16:32 iank_: 00:16:56 iank_: All the demos are roughly 50 or 60 lines of code. 00:17:18 astearns: Is the grid just making sure the line height is a strict multiple? 00:17:29 iank_: It is. It's snapping the baselines to a multiple of 20px. 00:17:44 iank_: That's all, folks! 00:17:55 Topic: Inlinifying layout 00:17:57 myles: what's the name of the API that enables this? 00:17:59 github: https://github.com/w3c/css-houdini-drafts/issues/946 00:18:55 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 and that allows you to achieve all these effects 00:19:22 iank_: It's easy to do string-based layout when you blockify everything 00:19:39 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 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 heycam: Could those differences be exposed? 00:20:14 dlibby has joined #houdini 00:20:18 s/Could/Would/ 00:20:21 q+ 00:20:34 fremy has joined #houdini 00:21:00 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 has joined #houdini 00:21:19 smfr has joined #houdini 00:21:31 emilio: When you have a block inside inline, you have to split into multiple things. 00:21:39 iank_: The engines don't agree on various edge cases here. 00:21:53 present+ 00:21:57 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 emilio: That may be true 00:22:09 iank_: We didn't want to go down the rabbit hole by speccing everything 00:22:13 emilio: how do markers work? 00:22:17 iank_: 00:22:29 iank_: You don't get a separate item from a list item at the moment 00:22:32 TabAtkins: Because it's explicitly inline? 00:22:34 iank_: yes. 00:22:41 emilio: What about an outside marker? 00:22:51 iank_: I think that will get wrapped in an anonymous block. 00:23:22 Rossen: What is the issue in the proposal? 00:23:30 iank_: To remove child display "normal" for now, and instead just do inlinification 00:23:42 Rossen: That makes sense for flow layout, but it doesn't make sense for anything else 00:23:53 iank_: YOu have to nest your custom layouts to get things like this 00:24:11 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 Rossen: So this just sets your content to be inline rather than block? 00:24:19 iank_: yes. 00:24:49 cbiesinger: What happens to block children? DO tey become inline block? 00:24:50 iank_: yes 00:25:37 Rossen: In your example in the issue, the ABC followed by DEF ... 00:25:47 iank_: This would be represented as one child, with its children inline-ified 00:26:10 Rossen: Are you going to ignore ? 00:26:16 iank_: Yes, because it's ismpler. 00:26:19 Rossen: It makes no sense 00:26:29 s//the display-outside value of the div/ 00:26:30 iank_: It's the same as flexbox or grid blockifying. Just hte reverse. 00:26:41 Rossen: So how can display:block continue to be block? 00:26:51 iank_: You can't. You need two levels of custom layout. They must communicate internally 00:26:59 Rossen: That sounds complicated and unnecessary 00:27:02 iank_: It's simple to implement 00:27:27 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 iank_: It depends on the use case 00:27:35 Rossen: Use case is normal CSS 2.1 support 00:27:48 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 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 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 q? 00:28:56 majidvp: If we go wiht a simple model now, can we change the model later without breaking existing layouts? 00:29:22 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 dbaron: What layout capabilities do you have in inline content in this midel? 00:29:46 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 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 TabAtkins: Wouldn't that have a line break between "lorem ipsum"? 00:31:22 iank_: I have a non-breaking space between them 00:31:32 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 iank_: yes. 00:32:17 TabAtkins: Was this just an introduction, or do you want a resolution for this change? 00:32:25 TabAtkins: Proposed resolution: Remove 00:32:54 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_ has joined #houdini 00:33:59 ScribeNick: myles_ 00:34:16 masonfreed has joined #houdini 00:34:28 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 iank_: The float will switched to an intermediate line in this case, because we don't handle it 00:34:45 dino_ has joined #houdini 00:34:46 emilio: Do you also modify the computed style, or just layout box 00:34:55 iank_: The computed style, just like flex and grid 00:34:58 emilio: No. 00:35:12 TabAtkins: Flex and grid blockify at computed value time 00:35:19 emilio: They don't add or remove float properties 00:35:25 TabAtkins: Those don't apply 00:36:10 cbiesinger: in chrome it modifies the computed style, but per spec it shouldn't 00:36:20 iank_: For us, the computed style of target float is none 00:37:58 iank_: Firefox logs "left" and Safari logs "none" 00:38:12 00:38:42 iank_: abspos modes of custom layout don't exist 00:38:47 emilio: We could specify it 00:38:54 iank_: in that case, we don't need special handling 00:39:03 emilio: They just don't appear in teh custom layout stuff, like normal out of flow 00:39:08 cbiesinger: What static position do they get? 00:39:36 iank_: They're block children, so the padding inline block. Whatever the standard static position of an internal line box 00:39:50 cbiesinger: If there's a custom algorithm, how does it know where the static position is? 00:39:57 iank_: It's the static position of the marker inside the element 00:40:07 emilio: I think it depends 00:40:25 koji: It may be more comlicated when teh containing block is inline, and we compute merged boxes 00:40:33 iank_: It should be fine ...? 00:41:20 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 koji: Static position is fine. I was thinking about when the containing block is inline ancestor and we have right currently 00:42:07 iank_: In that case, the out of flow layout parts would pick up where those open span and close span is 00:42:07 iank_: it might be easy if we just do this 00:42:12 iank_: I can't spell 00:42:33 iank_: It crashes. We currently don't handle that. 00:42:34 s/right currently/`right: 0`/ 00:43:02 Rossen: Are we still working through this issue? I think we should move on. 00:43:03 iank_: okay 00:43:28 TabAtkins: Before the next topic, who put WebAssembly integration on the agenda? 00:43:36 TabAtkins: Does anyone have anything we want to hit first? 00:43:45 TabAtkins: Font enumeration? property registrations? 00:44:00 Topic: Scoping Property Registrations in Shadows 00:44:03 github: https://github.com/w3c/css-houdini-drafts/issues/939 00:44:07 Topic: Scoping property registrations in the shadows 00:44:34 github: https://github.com/w3c/css-houdini-drafts/issues/939 00:44:37 scribenick: iank_ 00:45:19 TabAtkins: Simon brought up, if we want prop registration scooped to shadow trees. 00:45:48 TabAtkins: Best case an custom element will unregister a property, and reregister it. 00:46:06 TabAtkins: There is a meta issue around things not being scoped in CSS. 00:46:38 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 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 TabAtkins: This sounds similar if it wasn't registered. 00:47:41 TabAtkins: If you do a size property, it'll probably be a it both places. 00:47:57 TabAtkins: You can code defensively, but resetting at the top of the shadow root. 00:48:18 TabAtkins: If it crosses the boundary it just gets reinterpreted as a token stream. 00:48:31 s/but/by/ 00:48:45 heycam: A broader problem seems to be what .... there is no good way to partition these properties. 00:49:03 heycam: If you have multiple registrations. 00:49:08 TabAtkins: Nothing more specific. 00:49:31 heycam: I could imagine 2 custom element authors, both coming up with a --theme property independently. 00:49:53 heycam: No way to handle that these could be interpreted differently. 00:50:18 TabAtkins: As long as the two components are siblings you could set it above the CEs. 00:50:33 TabAtkins: If they are nested, the outer CE knows that it nested the child. 00:51:13 iank_: Has CE scoping occured yet? 00:51:22 masonfreed: Still not solved yet. 00:51:56 heycam: If we expect component authors to use suitably named properties to avoid conflicts, then the solution you described sounds fine. 00:52:32 heycam: 90% of CP usage I see, is setting the properties on the root. 00:53:26 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 fremy: Its consistent within a property tree, downside if you have slots you can't reset these. 00:54:20 fremy: We might want to ask people who are using CEs on how they use them. 00:55:36 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 heycam: Can you describe other discussions? 00:56:13 https://github.com/w3c/csswg-drafts/issues/1995 00:56:16 TabAtkins: Yes 00:56:28 TabAtkins: discussion was about font-face but was about other things. 00:56:42 TabAtkins: not just font-face, fill: url(#something), etc. 00:56:49 TabAtkins: A lot of confusion. 00:57:11 TabAtkins: People think that you just walk upwards, but this would be bad, as unreliably interpreted differently. 00:57:51 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 TabAtkins: The reference would be explicitly caught, and reflected in the TypedOM version. 00:58:46 TabAtkins: It'll be Document, or ShadowTree, etc, could grab the value, and use it elsewhere. 00:59:10 heycam: On font-face specifically not sure how this effects document.fonts 00:59:32 TabAtkins: ShadowTree would have a tree.fonts, conceptually. 01:00:02 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 heycam: Does this match what fremy described? 01:00:24 TabAtkins: Yes. 01:01:01 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 smfr: Is any of this written down anywhere? 01:01:35 TabAtkins: Only present within that issue thread. As nobody has said this is good. 01:01:42 TabAtkins: 01:01:51 smfr: I'll try and get our CSS folks to review it. 01:02:26 emilio: I don't think @font-face works within a shadow tree. 01:02:43 emilio: keyframes don't work, blink/ff do something different to webkit. 01:02:53 TabAtkins: Yeah would like to get a consistent answer. 01:03:03 s/don't work/don't work the same across browsers 01:03:43 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 TabAtkins: Which registration should it use? 01:03:56 TabAtkins: Not sure. 01:04:30 TabAtkins: 1) Uses the reg. of whereever that style came from, outer uses outer reg. for example. 01:04:57 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 fremy: But if you do what I said it can support both. 01:05:36 TabAtkins: If we do the multiple scopes, we need to define how to get all the versions of the property. 01:05:50 fremy: Yes - that's another question, how do you read the values. 01:06:06 TabAtkins: None of my proposals have to worry about what context the script is in. 01:06:18 TabAtkins: Big problem is what happens w/ typed om. 01:06:24 fremy: I don't have a good idea for that. 01:07:17 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 plinss: That seems not good. 01:07:50 TabAtkins: I agrree its not great, but simple and pretictable. 01:08:07 TabAtkins: Not sure which one I want to do. 01:08:15 TabAtkins: If anyone has opinions let me know. 01:08:28 TabAtkins: As far as I can tell that is the major issue. 01:08:40 TabAtkins: Lets get our browser folks about how this should work. 01:08:51 TabAtkins: At some point I'll commit text about how this should work. 01:09:00 heycam: What happens with constructable stylesheets. 01:09:13 heycam: What happens to style elements which haven't been inserted within the point yet. 01:09:34 heycam: ... e.g. you can access these from the TypedOM for these. 01:09:50 emilio: This is at specified value time, and the grammer isn't applied yet. 01:10:03 TabAtkins: ... yes - only at computed value time this is applied. 01:10:41 TabAtkins: I'm good with this issue then, can move only the next one. 01:11:16 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 fremy: Component - wants to have a custom prop e.g. --grid-type 01:12:07 TabAtkins: You can still set it, it won't get corrected until it hits the shadow tree. 01:12:44 Topic: perf concerns of custom properties 01:12:45 github: https://github.com/w3c/css-houdini-drafts/issues/940 01:13:29 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 smfr: e.g. stylesheet loads, prop registered, need to recalc stylesheet potentially. 01:14:06 smfr: Similar to style recalc thrashing. 01:14:21 smfr: Has been a proposal for a declarative version of registered custom properties. 01:14:32 q+ 01:14:57 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 q- 01:15:24 smfr: B/c you only have to parse the properties once. And it'll come in a "batch." 01:15:40 dino: You could imagine a bunch of component libs, which each register a custom properties. 01:15:50 dino: If delcarative, they come all at once. 01:16:04 TabAtkins: How is this different to JS setting this to something different each time? 01:16:11 TabAtkins: You need to rerun all the style on the root. 01:16:22 smfr: It depends how much work you need to do if the type changes. 01:16:32 TabAtkins: If you have an untyped its still the same. 01:16:48 TabAtkins: If its still the same, is there much of a concern still? 01:17:07 smfr: We should try not to add new APIs let authors pull trigger for a performance cliff. 01:17:43 TabAtkins: Would we get everything from the declarative appraoch, yes at the moment, but future levels, e.g. hooks, then no. 01:17:59 smfr: Can we just to declar version atm? 01:18:46 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 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 smfr: Also call out how to correctly use the JS api. 01:20:04 majidvp: In JS api, you only need to do this if you trigger style reclac. 01:20:44 emilio: Did agree that JS -reg properties, @property do not conflict. JS API won't throw. 01:20:55 TabAtkins: That's in the pending edits. 01:21:09 TabAtkins: JS stuff is on a separate layer. 01:21:16 dino: What would happen? Ignored? 01:21:31 TabAtkins: JS api wins. Treated as the "last" one. 01:22:03 dino: If browser only supports JS version, nothing special. 01:22:49 smfr: I have another thing related to animating untyped custom properties. 01:22:58 https://codepen.io/smfr/pen/JjPerWw 01:23:02 dlibby has joined #houdini 01:23:39 smfr: Question is - to do animation of untyped animated propeties, do you need to rerun the style-recalc each frame? 01:23:51 TabAtkins: No, it flips 1/2 way through the animation. 01:24:01 TabAtkins: All unreg. custom props are discreet. 01:24:12 smfr: ok 01:24:48 fremy: If you animate the custom property, and use it in another property which animates? 01:24:59 emilio: Everyone is different (only FF gets it right?) 01:25:14 TabAtkins: We discussed this years ago, there are like 16 options. 01:25:17 dbaron: 6. 01:25:23 TabAtkins: There were sub-options. 01:25:44 majidvp: What happens when you reg. a type for that custom prop while animationing. 01:25:58 TabAtkins: Just changes the value of the custom prop. 01:26:06 TabAtkins: If that's unclear, happy to add somethign. 01:26:26 heycam: Thats different to when you change font-size? 01:26:42 TabAtkins: Yes - it changes the value of the property, e.g. from a token-stream to a 01:27:05 heycam: In web-anim is it possible to change the from value. 01:27:26 TabAtkins: I believe it kicks off a new transition. Not entirely clear how this works. 01:27:54 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 TabAtkins: Sounds like it answers the relevant questions \o/ 01:28:24 smfr: Can we talk about the status? 01:28:40 smfr: Hesitant to implement all the syntaxes. 01:28:49 TabAtkins: Isn't that what we do right now? 01:29:02 TabAtkins: A handful of primitive types, w/ + and * 01:29:07 smfr: I thought it was more that that? 01:29:32 TabAtkins: No there isn't the possibility for needing to decide what part of the syntax to match. 01:29:40 TabAtkins: 3.1 describes all that you can do. 01:29:55 TabAtkins: thing+ | other-thing+ etc, 01:30:24
01:34:36 cathiechen has joined #houdini 02:00:18 satakagi_ has joined #houdini 02:06:08 smfr has joined #houdini 02:06:29 github: https://github.com/w3c/css-houdini-drafts/issues/945 02:06:46 Rossen_ has joined #houdini 02:06:53 github: https://github.com/w3c/css-houdini-drafts/issues/940 02:07:01 Topic: WebAssembly and Workers 02:07:05 mattwoodrow has joined #houdini 02:07:13 github: https://github.com/w3c/css-houdini-drafts/issues/945 02:07:17 masonfreed has joined #houdini 02:07:26 majidvp: This is a topic when boris looked at the animation worklet spec. 02:07:57 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 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 majidvp: Issues there is no good way to check if something is a constructor. 02:08:44 majidvp: I think tab was in agreement that we should do this. 02:08:57 TabAtkins: The more stuff we do in WebIDL the better. 02:09:27 iank_: there have been issues on WebIDL in the past about exposing class constructors 02:09:32 iank_: is that in WebIDL yet? 02:09:36 heycam: i don't know 02:09:37 heycam: I don't know. 02:09:53 majidvp: Not sure yet. 02:10:06 dlibby has joined #houdini 02:10:11 heycam: Having a webidl concept / type makes the most sense. 02:10:27 iank_: what is web components doing? 02:10:39 majidvp: Proposal is for them to also change their model. 02:11:02 majidvp: Up to the web components folks to change it. 02:11:06 https://github.com/heycam/webidl/issues/701 02:11:11 Rossen: Curious to know if they were ahead of us. 02:11:23 heycam: Dropped an issue disucssing the webidl feature. 02:12:10 Rossen: Any objects to transfer over to webidl? 02:12:18 RESOLVED: Transfer over to webidl. 02:12:38 iank_: to clarify, when WebIDL stuff is ready 02:13:03 Topic: Font Table Access API 02:13:07 skk has joined #houdini 02:13:17 github: https://github.com/inexorabletash/font-table-access/ 02:14:10 github: https://github.com/w3c/css-houdini-drafts/issues/950 02:14:21 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 has joined #houdini 02:14:39 cmp: No way to build an application to access these font tables. Only way to build a native app. 02:14:44 present+ Victor Costan (Google) 02:15:57 jsbell has joined #houdini 02:16:05 present+ 02:16:15 02:16:26 cmp: 02:16:51 explainer: https://github.com/inexorabletash/font-table-access/ 02:16:59 cmp: The shape of the API - has a permission request. Proposal to add a naviagator.permissions.request({name: 'local-fonts'}) 02:17:25 cmp: Then it adds a font enumeration API - e.g. navigaor.fonts.query() 02:17:46 cmp: query() method returns an async iterator. 02:18:11 cmp: Once you get the font you can query the types of tables, which are then represented as an array buffer. 02:18:17 02:18:47 cmp: User might interact with a font-chooser to select which fonts are exposed. 02:19:06 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 cmp: Can put those links into irc if useful. 02:19:26 cmp: That is covering the proposal, at that point. 02:19:34 cmp: Questions / comments? 02:20:01 myles_: I think there is a few problems with this api, i think they fit into 2 cats. 02:20:10 myles_: 1) Mechanical types 02:20:25 myles_: on our platform we have a bunch of fonts, which are in AAT format. 02:20:49 myles_: If we expect authors to implement their own font engines, folks wont use the AAT format correct. 02:21:03 myles_: Similarly for emoji fonts are in a different format. 02:21:25 myles_: We have custom information within the files, much of this is standardized, but some of it isn't. 02:21:47 myles_: We expose this information through the CoreText API which exposes all this information which is normalized. 02:22:12 myles_: Exposing this infromation as raw is not the way to expose this, better to expose different objects. 02:22:23 cmp: A mix of mechanical & philosphical. 02:22:39 cmp: Point well taken, e.g. divergiving font formats. 02:22:56 astearns: It would also be nice to future proof this for future formats. 02:23:07 jyasskin has left #houdini 02:23:21 eae: Havne't been able to come up with a standard way to represent all the different formats. 02:23:41 eae: I don't think its unreasonable for web developers who are using this to handle the different formats. 02:23:50 heycam: What types of developers is this targetted at? 02:24:36 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 myles_: Native apps don't have access to these? 02:24:51 eae: They do? 02:24:58 q? 02:25:07 myles_: The API for the text system, is CoreText. 02:25:15 eae: But you can always access the font files. 02:25:20 myles_: But this isn't an API. 02:25:42 heycam: Do you know why authors are cross compiling harfbuzz etc? 02:26:02 eae: They want to get things like glyph outlines, and selectively apply kerning. 02:26:23 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 ack dbaron 02:26:29 dbaron, you wanted to ask about alternative entry points to the api 02:26:34 dbaron: I wanted to raise a different issue. 02:26:43 cmp: Philosphical point? 02:27:30 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 dbaron: one issue, is if there should be a different entry point. 02:28:11 dbaron: Might be better to hook this up to something else. 02:28:37 heycam: Eariler you said font-enum api would provide access via the FontFace object. 02:28:50 TabAtkins: Yes if you have a webfont you can also access the table from those. 02:29:09 cmp: Yes it is the existing FontFace object. 02:29:18 dbaron: If thats the case this addresses my concern. 02:29:22 q? 02:29:59 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 eae: Thats fair, but we don't expect that the majority of websites would use. 02:30:40 myles_: There is the set of websites that want outlines, and want to get outlines on installed fonts. 02:30:50 myles_: I wouldn't be suprised if the intersection was very large. 02:31:03 TabAtkins: I suspect it'll be design tools. 02:31:33 myles_: But would want to render the same on each platform, but wouldn't want the local font? 02:31:53 q+ 02:31:55 TabAtkins: But they might want to access the local fonts b/c we don't have licensing for these things. 02:32:09 myles_: The set of websites who actually want this seems very small. 02:32:24 TabAtkins: it exists on powerful design tools on desktop. 02:32:29 myles_: Or they use webfonts. 02:32:52 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 TabAtkins: But if someone have bought fonts under various licencing agreements which can't be redistributed. 02:34:07 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 myles_: Not saying this is the best solution, but there are other solutions for the licensing issu.e/ 02:34:50 q+ 02:34:56 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 TabAtkins: (and back at square one). 02:35:16 q? 02:35:25 ack heycam 02:35:28 heycam: Eariler emil, was saying we've tried to come up with higher level apis and failed. 02:35:40 heycam: would be good to see the list of requirements for these design tools. 02:35:58 eae: Sure we'll try and share as must of these design explorations as possible. 02:36:51 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 q? 02:37:02 ack pwnall 02:37:11 myles_: I wanted to ask another question. 02:37:39 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 https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/G-hC66MRTso/kfWDYhC_BAAJ 02:37:54 myles_: Why do you think this will succeed when the other one didn't? 02:38:27 myles_: In particular there are a few members from the chrome team which brought up issues with this api. 02:38:47 myles_: if you don't have thoughts we can come back to this. 02:38:54 eae: yeah no thoughts at this time. 02:39:15 TabAtkins: There are differences, might have just been a less mature proposal. 02:39:27 myles_: Those differences don't seem that important. 02:39:34 q? 02:39:39 q+ 02:40:01 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 q- 02:40:39 myles_: Not addressing the other questions raised here. 02:40:48 myles_: There are also fingerprinting concerns. 02:41:13 oyiptong has joined #houdini 02:41:19 present+ 02:41:22 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 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 Rossen_: What is the particular ask? 02:42:22 eae: We'll follow up on the good feedback. 02:42:31 Rossen_: Lets go to the other propoal. 02:42:44 mattwoodrow has joined #houdini 02:42:49 Topic: Local Font Enumeration 02:42:51 github: https://github.com/w3c/css-houdini-drafts/issues/951 02:43:30 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 cmp: Proposing a change to the font loading specification. 02:43:49 02:44:29 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 cmp: Adds a FontFace.getMetadata() function. 02:44:53 q? 02:45:13 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 cmp: Also an Intent to Implment for this API. 02:45:40 myles_: 02:46:07 heycam: navigator.fonts is a separate issue? 02:46:22 cmp: navigaor.fonts is a FontFaceSet. 02:46:28 heycam: Same as document.fonts? 02:46:32 TabAtkins: No different. 02:46:40 s/No /No, / 02:46:55 myles_: Can you state the usecase for this? 02:47:16 TabAtkins: document.fonts provides sync access to all the webfonts. This needs to give async access, for filesystem-enumeration reasons. 02:47:37 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 myles_: Most document applications want to show the exactly the some thing? So what application are you thinking of? 02:48:28 q+ 02:48:30 cmp: A design application for example. E.g. have a locally installed font that is under a license. 02:48:42 TabAtkins: E.g. a company have purchase a particular font. 02:48:50 TabAtkins: And want to use this consistently. 02:49:20 myles_: We don't consider locally installed fonts for to web content. 02:49:22 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 q+ 02:49:34 myles_: Therefore would be able access via this api. 02:49:53 s/would be/wouldn't be/ 02:50:05 q? 02:50:12 q+ 02:50:24 myles_: In at least one of the 3 browsers, the issue would be solve that this API is trying to solve 02:50:44 s/would be solve/wouldn't be sovled/ 02:50:45 ack plinss 02:50:52 fremy has joined #houdini 02:51:04 satakagi has joined #houdini 02:51:04 q- 02:51:16 mattwoodrow has joined #houdini 02:51:25 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 TabAtkins: If that was the proposal would that reduce your concerns? 02:52:06 q? 02:52:13 myles_: Yes, but when fingerprinters run, they could enumerate over all the fonts which would provide a lot more entropy. 02:52:31 s/browser to select/browser to display its own font picker and the user select/ 02:52:57 iank_: But its a behind a permission prompt? 02:53:16 q+ 02:53:23 myles_: I don't believe there is a set of words which would indicate informed consent. 02:53:31 ack krit 02:53:32 myles_: (for the permission prompt) 02:53:36 I agree, permission prompts are valuable, but limited. 02:54:04 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 krit: Would there be an API where an application could ask in a particular font is installed. 02:55:05 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 cmp: None of the implementations return the additional information. 02:55:53 heycam: whether this API is a good idea is a separate question. 02:56:25 krit: Have a document w/ text in it which used a separate font. The web application needs to identify this case. 02:56:49 q? 02:56:56 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 myles_: We also know, iterating over all the fonts in a system is the wrong way to do it. 02:57:28 ack pwnall 02:58:36 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 q? 02:58:55 pwnall: There are usecases which are lost if the UA has to implement the picker. 02:59:12 ack dbaron 02:59:12 dbaron, you wanted to raise one more issue about permission prompts 02:59:24 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_ has joined #houdini 03:00:05 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 dbaron: Asks a question to the user which doesn't usually happen. 03:00:34 dbaron: In this case, given how fonts work today, that is quite difficult. 03:00:35 q? 03:00:57 TabAtkins: If the UA provide the font picker , then we wouldn't need that picker. 03:01:14 TabAtkins: How would the web application know about the license type. 03:01:15 s/that picker/that permission/ 03:01:54 pwnall: The web application would scan font tables, e.g. woff has a licensing table to provide the ability to filter. 03:02:00 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 ScribeNick: TabAtkins 03:02:28 satakagi has joined #houdini 03:02:58 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 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 q+ 03:03:38 s/anya pp/any app/ 03:03:41 cmp: Yeah, good point. We're trying to see the effect in practice as we experiment. 03:03:54 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 pwnall: I'll follow up with you. 03:04:08 mmaxfield@apple.com 03:04:17 astearns: There are "design applications" that will do pre-flighting of fonts used in a doc as it's doing output. 03:04:49 astearns: As you're saving something, you can ahve a step that checks for fonts and ensures they're licensed. 03:05:10 TabAtkins: That use-case would be handled by the font-face tables access of UA-picked fonts, without needing full enumeration. 03:05:24 jsbell: I use GIMP, it takes forever to load, that's what tools do. 03:05:37 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 cmp: Thank you for the comments! We'll follow up, please ping me with additional comments. 04:03:03 skk has joined #houdini 04:06:48 mattwoodrow has joined #houdini 04:21:35 mattwoodrow has joined #houdini 04:29:54 myles has joined #houdini 04:32:00 myles has joined #houdini 04:41:00 myles has joined #houdini 04:43:59 kzms2 has joined #houdini 04:46:40 skk has joined #houdini 04:47:03 rego has joined #houdini 04:53:41 myles has joined #houdini 05:27:23 Zakim has left #houdini 05:52:56 dino has joined #houdini 06:54:27 mattwoodrow has joined #houdini 07:19:50 satakagi has joined #houdini 09:15:07 jsbell has left #houdini 09:26:22 Rossen has joined #houdini 09:27:53 leaverou has joined #houdini 09:28:24 plinss_ has joined #houdini 10:52:23 satakagi has joined #houdini 11:10:21 mattwoodrow has joined #houdini