07:14:24 RRSAgent has joined #houdini 07:14:24 logging to http://www.w3.org/2015/08/28-houdini-irc 07:14:35 Zakim has joined #houdini 07:14:58 ScribeNick: dael 07:15:06 rrsagent, make logs public 07:15:10 Florian has joined #houdini 07:15:29 zakim, remind us in 10 hours to go home 07:15:29 ok, plinss 07:15:55 Rossen: Welcome everyone. 07:16:02 Rossen: First thing is the agenda. 07:16:17 dbaron has joined #houdini 07:16:31 Rossen: So we have a couple of topics that will go as first thing. Is there any time restrictions or preferences from anyone here? 07:16:36 rossen: speak louder 07:16:38 smfr has changed the topic to: https://wiki.css-houdini.org/planning/paris-2015#proposed-agenda-topics 07:16:40 shane: WE had the jdaggett request. 07:16:47 Rossen: jdaggett what time is better for you? 07:16:50 franremy has joined #houdini 07:16:59 jdaggett: Discussions after 2 your time would be better. 07:17:22 jdaggett: I'll be here for around 2 hours and I can be on from how after 2pm your time. 07:17:33 Rossen: So we'll do font metric and line related in the afternoon. 07:17:39 Rossen: Other perf. for topics? 07:17:54 steveZ: No layout Sat afternoon 07:17:59 Rossen: Can we do it this morning? 07:18:03 several: yep 07:18:04 rossen: guessing "deadrange" is in there too 07:19:03 sorry, can we give a mike to rossen? 07:19:09 Rossen: We had the two items prep for this morning, scripts API which is one of the ians. iank. There was a topic elophent in the room. 07:19:12 ah, good good 07:19:30 s/elophent/elephant 07:19:47 present+ dauwhe 07:19:48 Present +dbaron 07:19:51 present+ astearns 07:19:53 present+ Peter Linss 07:19:56 Present+ Tab Atkins 07:19:56 present+ smfr 07:19:57 present+ Ian Kilpatrick 07:19:57 Present+ LiamQuin 07:19:59 present+ Florian 07:20:03 present+ jdaggett 07:20:04 Present+ Rick Byers 07:20:05 SteveZ has joined #houdini 07:20:07 present+ Elliott Sprehn 07:20:10 johanneswilm has joined #houdini 07:20:11 present+ SimonSapin 07:20:45 myles has joined #houdini 07:20:48 flackr has joined #houdini 07:20:48 zcorpan has joined #houdini 07:20:55 present+ Cameron McCormack 07:20:56 present+ gregwhitworth 07:20:57 present, Johannes Wilm, Vivliostyle 07:21:07 vollick has joined #houdini 07:21:10 present+ Rob Flack 07:21:11 Topic: Script API 07:21:14 present+ Simon Pieters, Opera Software 07:21:20 Bert has joined #houdini 07:21:27 http://bfgeek.com/css-houdini-drafts/css-script-api/Overview.html 07:21:31 present+ Dean Jackson (dino) 07:21:59 Present+ Bert Bos 07:22:02 iank: Basically we've been thinking a lot about how all the APis will work with script. One think we noticed early on is a lot of the APIs are very valuable. Take a hypothetical layout. 07:22:04 present Steve Zilles 07:22:32 iank: You could remover yourself during the middle of layout which would cause a lot of issues for at least us. So we needed a way to make the world sane for these APIs. 07:23:08 iank: Two options: run everything in the main exicution context and lock things down or create sep. exicution contexts the apis could run in. 07:23:59 iank: We didn't investigate locking down the path much because it ties you always to the main thread which isn't desirable if a UA wants to move all the custom paint code. Second is playing whack-a-mole with locking down. Does that match other thoughts? Other concerns? 07:24:23 Florian: I'm wondering if there is a generic ex. What you said about paint made a lot of sense, but when it's custom values I'm not sure the same apply. 07:24:27 iank: It would. 07:24:44 present+ Ian Vollick, Google. 07:24:51 shane: I think, one point is the concerns are less at style, but the same concerns to exist. 07:25:04 iank: I can't remember what but there was something we could do to break the style engine. 07:26:19 shane: The phase with the most potential with custom style. The advantage of building in a custom style enviroment...you get to work with more pieces of the style engine so the transitions engine will work for you. You get the step computations retained. You can make use of the type system, you get all this becuase you're embedded in the style engine. If you're in a main thread you'll have to do more of the work yourself. 07:26:42 shane: You can't be in a main style thread and expect to be invoked. So you don't get a chance to participate in those parts. 07:26:55 TabAtkins: And you can't expect to be called in the middle, you can screw everything up. 07:27:17 iank: A good test is if you're doing an apply style hook on an element and it will stay display: none, all bets are off. 07:27:19 Florian: Okay. 07:28:00 shane: The choice we have is being effectively part of the computation interface and having the ability to modify individual results or being a part of the thread and having access to the data, but having more restrictions. And not having the ability to participate as well. 07:28:47 iank: We thought some sort of sep exicution context was the way to go. The next question that came up was how many of the sep exic. context should we have. It would be nice to contrain the world in such a way that if you're doing custom layout you're constrained to yourself. 07:29:31 iank: This has severe implications for us and a few other UA and the exicution costs of expencinve. It would be 200kb for it and takes 1ms to spin up. We don't think we can get around the memory. 07:29:43 iank: This led us to think sep exic. per phase. 07:29:55 dino: All instances of that phase? 07:29:58 iank: Yeah. 07:30:08 dino: So if you're loading multi custom layours they all share. 07:30:55 iank: Yeah. This obv has consiquences for if you have a custom layout high on the tree and low on the tree it can't comm. If diff UA have diff painting behavior this could lead to UA dependant behavior if authors don't write thier functions in a way. 07:31:32 shane: We'd like to lock down script relations in a certain way and than UA could do what they want. It's hard to lock down JS like that. There's no way to do it and still have useful libraries. 07:31:45 present+ Rossen 07:32:01 shane: There was discussion yesterday about req browsers to maintain at least two contexts and to randomize them to force browsers not to have problems. 07:32:20 dino: So if you run a custom layout the prop is .5 that you'd end up in one event. 07:32:39 present+ Shane Stephens 07:32:44 esprehn: We kill agressively and it's worked well. 07:32:53 smfr: What is the lifetime of a context? 07:33:12 iank: Bascially we think, but want feedback, you can kill if you background a tab. 07:33:16 kwkbtr has joined #houdini 07:33:17 shane: That would be up to the UA. 07:33:37 flackr: If you apply the randomization, you're not promising any consitancy to the user. The UA could do what they want. 07:33:47 dino: What if they want persistance? 07:34:25 iank: There's two ideas there. First is to stash everything in your computed style object that goes down the tree. The other is to have an explicit API that's similar to the cache object. 07:34:44 shane: Already at this point if you want to use the JS library in this context it won't work on wifi 07:34:57 ChrisL has joined #houdini 07:34:59 s/on wifi/unmodified/ 07:35:20 shane: Our job here is to work out which set of things are the most powerful and what will we sacrifice and what won't we for this. It's a hard call. 07:35:32 iank: I thinkt he ideal doesn't exist, it's a whole bunch of trade offs 07:35:46 iank: Between what perf and API characteristics that we have, etc. 07:36:13 smfr: The spec doesn't address the UI workers case. Should there be a spec that covers all the cases? 07:36:38 iank: THis spec has empty exicution contexts and that would be an extention. I wrote this not thinking about compositor. 07:36:56 vollick: I thought the same thing looking at this where I hoped I could use it for the compositor. 07:37:55 iank: To the API in the spec, this is out of date. Also I can change the name from CSS work-up. Basically it's a standard dedicated to work on global with everything ripped out. You don't have UI specific things, you have the empty worked global scope. I think we want to get rid of the self attr too. 07:38:07 iank: We also don't want to import scipts as well. 07:38:20 s/CSS work-up/CSSWorker/ 07:38:21 s/work-up/worker/ 07:38:30 iank: It's empty global scope and for each type of worker it would extend this and insert the global API. 07:39:04 iank: We have to do a bunch of thinking about promises etc. HOw you load scripts into these workers, you get a ref. to this type of worker from the context. You can see in the ex you can import scripts into these contexts. 07:39:35 iank: Because of this we don't spec how many are running or where. So if the paint worker, we have 2 or 4 and they're on a different thread, that's fine. YOu could load them each time. 07:40:02 iank: We think when loading the scripts into these exicution contexts, we'd like it if we can wrap in an anon use-script mode so they're a little more locked down. 07:40:10 iank: And that's basically the API. 07:40:23 smfr: What is the use of it being an event target? ON global scope 07:40:38 iank: I think we want to remove that because you can't do anything with it. 07:40:50 smfr: And the CSS worker is that a target? 07:41:29 iank: You may want this...so initially I had import script as not returning a promise and it would throw. YOu may want this as an event target if an error was caused in the script. That's the only reason I can think of. 07:41:33 smfr: So it's error handling. 07:41:44 s/CSS worker is that a/CSS worker's/ 07:41:46 iank: Yeah. If we think we don't need it, fine. Similar to abstract worker. 07:42:01 iak 07:42:09 iank: Any other feedback? 07:42:16 iank: Is this the right approach? 07:42:32 dino: the API seems fine. It's missing when they're creating, which I guess is what we discuss. 07:42:45 iank: We need to lock down the lifetime. We want to leave it UA dependant. 07:43:05 TabAtkins: I suspect we want to put some guidance in. Something like killing or just to put a note in there. 07:43:18 Florian: Not only say you shouldn't guar persistancy, but you should screw it up. 07:43:30 dimI'm not interested in how you do things, not how you stop things. 07:43:56 shane: We do have an agenda item for that. I guess we should talk about what should be allowed. There's data that needs to be passed for an element. 07:44:00 s/dimI'm/dean: I'm/ 07:44:03 s/dimI'm/dino: I'm 07:44:22 dino: A paint operation might want to save to an offscreen canvas. There's lots of stuff to discuss there. 07:44:53 * question: How do we deal with name conflicts if they have to share the same context? Do we have something planned for namespacing, like to avoid conflicts between shared libraries but different versions? 07:44:55 shane: Maybe an important question si do we see a need for communication between diff elements on the page. WE can see in the pipeline for an element you have to pass data and indiv elements need to store data. 07:45:28 iank: We don't want elements to pass between because it allows us to do the validation. If you have communication and it leaves you in a bad state it doesn't know there's an error. 07:45:34 (to clarify my question, I meant in case multiple frameworks/scripts want to register a custom layout) 07:45:35 leaverou has joined #houdini 07:45:41 smfr: It seems the first thing people want to do req communication between elements. 07:45:41 franremy: Elephant in the room :) 07:45:52 shane: If we went outside the dom hierarcy it would work. 07:45:58 ojan: When do you want ocmmunication? 07:46:00 s/would/wouldn't/ 07:46:01 franremy: Name conflicts are only possible if you're trying to persist by writing to some global scope, which is difficult to do. 07:46:06 dino: Coordinated layout 07:46:16 smfr: You want sib grow the same size. 07:46:30 ojan: You want an arbitrary decendant to be the same size over here. 07:46:43 TabAtkins: You want multi tables to have their columns be the same width. 07:47:18 TabAtkins: Okay, so you argue people should wrap their code in a module and not expose anything. That's fair, thanks. 07:47:31 franremy: Nah, we plan to do that for you. 07:47:32 ojan: Our model has been providing primitives for what the platform is so nexttime we want to have a new layout mode we don't have to bake it into the browser. 07:47:35 Rossen: I agree. 07:47:51 franremy: Wrap the code in an anonymous "use strict;" function, so you lose easy access to the global. 07:47:54 smfr: You're dangling a carrot in front of web dev and it won't do what they want it to do, which is the tension 07:48:12 jet has joined #houdini 07:48:13 TabAtkins: great, question answered 07:48:24 iank: One API we could allow that would let invalidation work is before layout the ability to do a tree walk s you could set up a whole bunch of information and that would make invalidation work. 07:48:51 iank: The risk of that, the other risk with allowing arbitrary communication between phases, doing something between two threads is hard. 07:49:10 Florian: smfr can you comment on that because I think Servo has more experience on that. 07:49:19 s/smfr/simonsapin 07:49:57 iank: We're discussing what are the multi-threading impl if we allow arbitrary communication between the box tree in the middle of layout. 07:50:01 franremy: I think that loses "this", but you can still refer to say Number 07:50:22 franremy: and communicate through setting properties on that 07:51:02 heycam: Yeah, stashing on shared prototypes is still available, which is what the "randomize the contexts, reset them aggresively" is intended to address. 07:51:04 SimonSapin: The way it works now layout can work par. with script except during style competation because the layout has access to dom and we don't wnat to change what happens. Once style computation which incl constructing the tree, the script can walk on that tree and continue taking the dom. I suppose we could do somelayout on that layout tree. We would have to do something else to have the API accesses. 07:51:15 Florian: Is it a single thread doing layout in par? 07:51:26 SimonSapin:Many threads. 07:51:40 Florian: So arbitrary communication would cause sync problems? 07:52:04 SimonSapin: They're not completely arbitrary. Each of the children will need data. 07:52:22 Florian: Can we allow custom JS doing this to communicate between nodes? 07:53:07 SimonSapin: In custom layouts if we're accessing parts of the tree that would prevent layouts. We split into diff operatiosn such as compute the height of hte element which may include computing the height of the elem. And on each of these there are different restrictions on what you can access. 07:53:48 ojan: In terms of use cases, I've had a few in mind. One is impl something like flexbox or grid. The ccomplicated is doing a constraint based layout system. What I've beenpicutring is you own the whole thing so you do the constraint painting yourself. 07:54:11 Rossen: THat's one of the things I've been having a hard time wrapping my mind around. 07:54:37 smfr: I haven't looked at the CSS layout much and maybe I'm not thinking in the right terms, but I'm thinking as an author I want to do these cool things and this isn't right. 07:54:50 dino: This seems like an okay direction and lets discuss the spec. 07:55:37 SimonSapin: Maybe the API could allow communication when possible, but still have an adidtional case where you don't know anythingin the initial places. Only in the last version will you have access to all of your subtree. It's not going to be perfect. 07:56:18 I think the layout API could also work where a custom layout says which part of its subtree it's taking ownership of laying out (e.g., of just its children, or of a deeper subtree than that). 07:56:22 Rossen: I think this is a good thing to discuss in custom layout. I think we're starting to dive into what's required for layout. For the general PoV of restraining layout and communication, I think that what you've prop makes sense for me. 07:57:05 dbaron: I was saying, it seemslike the layout API could work in a way that the custom layout could take ownership of laying out a deeper sub tree or just its children. One is useful for grid, one for complexlayouts. 07:57:11 TabAtkins: It's something you have to opt into. 07:57:39 Florian: This is related to custom style computations where you may need access to your parents and if you do that changes the par opp you have access to. 07:57:51 shane: From what SimonSapin was saying, you haven't par. style. 07:57:57 SimonSapin: It's a top-down pass. 07:58:11 SimonSapin: Yes, it is parallel 07:58:11 Rossen: iank in your prototyping, have you had any reasons to share data? 07:58:30 iank: Not spec. but only because we've been building layouts in the web. One would build a stripped down flexbox. 07:59:36 iank: and compared it to native under the same conditions to look at the characteristics and see how performance. It didn't do too bad. It's a micro venture, but with a few perf tricks it was half as fast. Which for JS with no optimization that's pretty good. 07:59:43 Rossen: Anything elseon this topic? 07:59:52 iank: Do we need an ED and what to call it? 08:00:12 shane: We need a spec that talks about this, it's clear. Tihs spec that iank has provided, should we make it an ED? 08:00:25 Rossen: obj to adding it to the charter? 08:00:38 RESOLVED: add an ED for CSS Script API (name TBD) 08:01:00 dbaron: We may want to spend a few minutes discussing name. 08:01:08 dbaron: It may be good to pull API out. 08:01:12 iank: CSS script 08:01:13 tantek has joined #houdini 08:01:16 Florian: CSS workers 08:01:35 franremy: Do we have to have CSS in the name? 08:01:41 iank: Just call it script 08:01:47 HWorker 08:01:48 dbaron: isolated workers 08:01:53 https://wiki.css-houdini.org/planning/paris-2015?&#agenda 08:01:57 RESOLVED: name it Isolated Workers 08:02:17 Rossen: I just want to pull up the agenda quick. 08:03:06 Rossen: So we'll move on the gregwhitworth topic and then prioritization and passing data. 08:03:10 koji has joined #houdini 08:03:40 Rossen: Starting in a pipeline, we'll go through the afternoon topics and that should take us through the day. 08:03:59 smfr: I'd like to add a discussion about scrolling and UA workers 08:04:15 Rossen: There's a topic on saturday. 08:04:33 ojan: I'd roll that into async style. 08:04:48 Rossen: [goes over saturday] 08:04:56 SteveZ: Can we do pagination saturday morning? 08:05:16 Rossen: My thinking was if all the font stuff doesn't fill today, we'll pull it into the afternoon. If not we'll do sat morning. 08:05:23 Topic: Elephants in the room 08:06:36 gregwhitworth: This got added when we started on prop and values. We found a lot of what we're trying to accomplish ends up having to fight the pipeline. I wanted at a minimum to let people know that are following along to know what other large hurdles we have to see something that actually works. 08:07:25 gregwhitworth: For ex the perf issues we could see, not in a single custom layout, but if fruition is seen down the road and everything is being controlled you start to realize the mess. I'm not saying it will be realized and I'm thrilled iank is working on this. 08:08:12 gregwhitworth: Another example is parsers and values. If you have a layout library it's going to mess with it. Authors are starting to talk about it and I want to make everyone aware there are large elephant and small elepants and we need to mark them. 08:08:47 gregwhitworth: Google and us have talked about the perf hits, but I'm looking for a round table discussion about if anyone else has seen large issues we need to address so we're not just throwing useless APIs together. 08:09:11 dino: We have a significant fear that this is have a bad effect of what this could do to the web. People are complaiing about web perf. 08:09:31 dbaron: The flip is people are doing some of the things these APIs are for and they do them worse. 08:09:58 gregwhitworth: That was our concern and that's not the direction that we're heading. We're finding use cases and solving them instead of native APIs. 08:10:31 dino: The fear isn't the devs are currently trying to do things like htis, it's that web pages will import their bodyscripts that have 50 ad networks. It's not the good devs I'm worried about. 08:11:11 smfr: Peopl write a lot of bad JS. The browser engine can't optimize around the scripting hooks. Whichis contrast to declaritive where the browser can optimize. We're reluctant to expose new hooks without good reason. 08:11:30 vollick: We'll have to have some sort of admission control. Maybe we need to do it in other places then the async. 08:11:42 smfr: But if you abort the script the user has a bad expoereince. 08:12:20 ojan: The APIs are actually hard ot use. A neive user couldn't use them. It's because they're low level and the ergonomics aren't awesome. I don't nec view that as a bad thing. The people writing code will be framework authors. 08:12:37 smfr: Peple find stuff and use it and copy paste 08:13:19 ojan: Flexbox is my ex of what we have today doesn't work. It's full of these hook values and part of the reason is that one API had to solve every case and we didn't give people an out. The libraries don't have to address every case. 08:14:00 shane: The problem you're worried about, we have that already. I'm not sure we're widening the scope. Where you see ad networks that trash a webpage is the only ave they have is non performant. These people aren't stupid, they have no other choice. 08:14:13 dino: It's not that they're stupid, it's that they have to do a hack to get it done. 08:14:17 shane: They have no other way. 08:14:31 smfr: I don't think ad networks will write custom layout, but they'll use hooks. 08:14:42 shane: If you can only do layout with a layout hook they can't. 08:14:59 Houdini allows ads to hook into paint to be *absolutely sure* you see no content until every ad has been presented 08:15:53 ojan: I think this will be more useful once we've talked about the specs proposed. The thing that they dowhere they query all the positions, you can't do this will these APIs. I'm less concerned about an ad network distroying the whole page. Currently one ad network can do something to make the whole reasonable page fall over. These APIs you can only make your page horrible. 08:16:17 gregwhitworth: One of the elephants that we hit is collisions. How do we handle name spacing if they're all in various ways. 08:17:12 gregwhitworth: WE don't need this for 45 min, but I'm glad you have similar worries. But I always like to point to the flip and people are bipassing everything to feel like they're done something so I'm open to exporing it further. I'm open to continuing these conversations. I want it know this could end the web if we do it wrong. 08:18:00 dino: Flip boarding throws everything out to deal witht he prblem space. You don't have the anything goes of the web. We're not sayign don't look into it, but even if you're only doing layout, every time we add script it makes some things better and things we don't know about worse. 08:18:56 rbyers: I don't think I agree. I think we're catching up. The prob you're desc we need to tackle as browsers spec from houdini. Houdini adds complexity, but maybe we should discuss as broswer vendors how to deal with those problems. THere's low hanging fruit. 08:19:29 agenda+ Github issues topic from yesterday (context: see discussion in #css) 08:19:47 rbyers: There's a whole application monitoring industry for people to figure out what's going on in the wild. Maybe search index should take perf in account. Maybe there should be cues like frosting out the window when an app slows things down. There's tons to do, but it's orthogonal to houdini. 08:20:07 +1 to lea's GitHub suggestion, let's talk about this today or tomorrow in the context of Houdini. 08:20:20 ??: I think houdini makes this easier to check performance. This lays out script and boxes, they don't have hidden comlex costs. WE could lay out a heat name. 08:20:22 Rossen ^^^ 08:20:58 s/??/flackr 08:21:22 rbyers: So we should keep in mind these performance principals whenever we design something, CHrome jsut got a dev tool so you can tell CPU time per page. Maybe we can agree to let all performance be track back-able. Or all features are desgined with perf principles in mind. 08:21:48 smfr: What we do, you get nickled and dimed as you layout over elements. If people do custom layout you get that and you end with slow performance, but you can't blame one thing. 08:22:06 shane: Part of that is the depth of the trees people use. My hope is these apis will help slowt hat down. 08:22:35 TabAtkins: The two major android layouts are flat, but do complex layout that would require sign nesting in flexbox. Being exposed like houdini allows flatter doms. 08:23:12 shane: A native app with 100 widgets would be heavy weight for mobile, it's not uncommon to see them with 1000 or more. The layout we provide isn't what people want and so they're doing a lot of nesting. 08:23:15 Rossen, agenda+ using one source repo per spec, using github for issue tracking? 08:23:55 Rossen: That's also true for Zamo(?) as well for how the frameowkr works. YOu can hook on any callback. You have the primitive non-primitives like grid and you can operate the way they work. 08:24:00 s/zamo/XAML/ 08:24:13 s/CPU time per page/CPU time per origin/ 08:24:41 Rossen: From talking to some of the people who work on it, I was trying to cull their feedback on the perf. Surprisingly enough it was almost never layout, their frames weren't bound by custom layout. Most of their run time is impacted by things outside the box. 08:25:06 Rossen: Even with such an extremely open API platform, there's not a lot of evidence that people are shooting themselves in the foot. 08:25:36 Rossen: It's not clear that XAML devs are comparable to web dev, but you can have an open platform and be conformant as long as the code we write is reasonable. 08:26:29 tantek: Building culpability into the system as part of creating a feedback loop is the right approach. Any smart architecting, we'll get things wrong. If you build in that culpability of what's slowing things down, it enables at the UI level the frosting effects you mentioned 08:26:55 tantek: At that point we give the opp for broswers to surface to the user or give them options to kill that thing or block it. 08:27:07 s/conformant as long/performant as long/ 08:27:11 tantek: Responcible iteration is how you'll solve this. 08:28:12 rbyers: What I'm encouraged by is there's discussion about how performance relates to business metrics. The people making money on the web realize it's corilated with performance. If we design in a way that encourages it, the internet will take advantage of it. We failed on this before, I think we have a lot of catching up to do. 08:28:43 tantek: If there's culpability, that's great. 08:29:48 gregwhitworth: One other, while we're scoping I would love to take manigability into account. There is a website that I spent two days doing a bug fix because how they had desgined and nested and minified. Manigability for anyone viewing is rather important. We're adding more help, but the bugs we get will be more complex. 08:30:10 Rossen: Are you prop something actionable? 08:30:38 gregwhitworth: I dont' have an exact answer, but when we do this, I don't want to make it worse. We have source maps, maybe we could tie those in. So yes, it's slightly a rant. 08:30:44 correction: it was The Verge article, not Vox 08:30:48 Rossen: Anything else on this? 08:30:57 08:31:05 Florian has joined #houdini 08:31:21 this is the article I referenced: http://www.theverge.com/2015/7/20/9002721/the-mobile-web-sucks "The mobile web sucks " which ironically illustrates the problem of bad web development practices are what are making the mobile web suck. 08:32:12 Jeremy Keith's analysis/critique of said article: https://adactio.com/journal/9312 08:34:58 Jeffrey Zeldman's broader piece on the subject:http://www.zeldman.com/2015/07/29/publishing-versus-performance-our-struggle-for-the-soul-of-the-web/ "Publishing v. Performance—or, The Soul of the Web" 08:35:59 And even harsher critique of The Verg: http://blog.lmorchard.com/2015/07/22/the-verge-web-sucks/ 08:36:06 s/Verg/Verge 08:36:35 context: Vox Media publishes The Verge 08:47:21 vollick has joined #houdini 08:52:25 Rossen: Let's resume 08:52:29 smfr has joined #houdini 08:52:39 Topic: CSSOM 2 08:53:04 https://lists.w3.org/Archives/Public/public-houdini/2015Aug/0004.html 08:53:11 shane: We re-ordered to get more concrete topics first. 08:53:21 Florian has joined #houdini 08:54:00 A CSSOM that is actually using Objects 08:54:30 leaving now, back after 2pm :) 08:54:31 shane: This one is CSSOM2. A pretty way to desc is a typed cssom replacement a way to expose types of css to JS. We'd like to do this because in the exporations we've found to softest part of any custom pullout is comverting the strings out of css into typed representations and stuffing them back in the element. 08:54:49 shane: This e-mail is a rough API and I wanted to go over it. 08:55:19 Personally, I think TabAtkins’ proposal from a while ago is more elegant http://www.xanthir.com/b4UD0 though less complete, presumably 08:55:29 shane: The StylePropertyMap. The first to notice is this is almost map-like. There's get that gives you a start value and get-all that gives you all the values. 08:55:45 Mine *is* more elegant, but it's also impossible right now. This is a stopgap, rather than waiting for, in my estimation, 3+ years. 08:55:58 shane: The CSS WG has a tendancy to promote prop to list value and we don't want to do that. If we give you a get you can find out about just one prop. 08:56:05 SimonSapin: Do we do that for prop that were already lists? 08:56:12 TabAtkins: the parts of it that don't depend on value objects are also more elegant 08:56:16 shane: Yes. This would be anything. 08:56:28 dbaron: So when something is a list value you will only get the first with get? 08:56:30 shane: Correct. 08:56:47 shane: That's convienient because background is a list value, but 90% of the cases it's a single value. 08:57:04 leaverou: I'm much more in favor of a Map interface; it actually works with custom properties, for example. 08:57:08 I really like this re:list values, much better than making everything a sequence! 08:57:23 Florian: Thining to the editing TF, the presense of an API that can only give you first indicates that people don't care about getting more so the idea is give me an iterator so there's an idea of there's more to come. 08:57:30 leaverou: And it extends to MultiMap easily; my proposal did handle this problem, but in an imo clumsier way (the .l property) 08:57:33 s/making everything a sequence/handling everything like a collection and requiring [0] to get the first value/ 08:57:37 shane: That's not a bad idea. WE should think over that. THat's a good alt to fix this. 08:57:41 johanneswilm has joined #houdini 08:57:55 shane: append puts the new rule seq at the end of the previous. 08:58:15 shane: This gets complicated because it rep both style rules and computed value so this appends to the end of the start rule. 08:58:26 dbaron: For computed style? 08:58:31 shane: It poss does the same thing as set. 08:58:49 shane: Sorry, for inline style. computed style it does nothing. 08:59:16 shane: The e-mail I sent had computed and spec style sep, but we talked about rolling some of that up, but it may may sense to keep it. 08:59:30 SimonSapin: Does appead append a new value to a list value prop? 08:59:33 shane: Yes. 08:59:37 shane: No. 09:00:24 TabAtkins: Yes. When you append one, it put it at the end of the property. This is the multi-map interface that dom has forged for coring paramenters. WE have one weirdness with set taking a seq value and i'm not sure how to address that best. 09:00:40 shane: Do want to make get return an interator? 09:00:47 TabAtkins: I'd like to keep it to a map 09:00:53 SimonSapin: What about prop that aren't list? 09:01:19 TabAtkins: No op or throws. Going throwing to useful and no op than useful is both doable. 09:01:22 flackr: I pref throw 09:01:36 heycam: So do you have to spec append comma? 09:01:45 s/flackr/florian/ 09:01:53 esprehn: All list is using a comma, so doing an append adds a comma. 09:02:01 dbaron: We do have list values that don't have commas. 09:02:14 shane: The list instruction handles that for you. They're interally lists. 09:02:41 s/instruction/abstraction/ 09:03:04 shane: Another consideration is we can't just replace the existing access so we need a new attr to getting computed style map and a new on CSS style. Ths is a bit unfortinate having to have them side by side, but we can't think of a better way to do it. 09:03:23 smfr: Are there context where start prop map will be redone? 09:03:30 shane: Yep. WE'll factor those into a sub class. 09:03:37 TabAtkins: Fort he map like interface... 09:04:02 esprehn: Instead of having one style prop map it will go away and specify involkes a read/write. They're two traits. 09:04:14 Florian: Does the object reflect the change or do you get a new event? 09:04:23 MultiMapReadOnly and MultiMap I think 09:04:23 shane: The start prop map itself maybe. 09:04:40 shane: Every value that comes back is a subclass of start value so we can have the basic values everything. 09:05:12 did I hear that right? Element.style.margin -> Element.styleMap.getMargin ? 09:05:23 zcorpan: In CSSOM we introduced attr for getting cascade style and raw computed with is the real computed value, but they're css to CSS values. I dont think these are impl. WOuld it make more sense to spec these as the map? 09:05:28 TabAtkins: I think so. 09:05:30 Element.styleMap.get('margin') 09:05:37 thanks 09:05:55 esprehn: In favor of this appraoch it doens't require object stability. Get style may be analogis. When you touch the style prop we have to keep the element. 09:06:01 leaverou: Why use get margin? 09:06:23 TabAtkins: It looks like a map. The dashed camel case we use only works for CSS prop. 09:06:29 leaverou: WE can have trees that are anything. 09:06:42 TabAtkins: It's not nice to force two different access pattern. 09:07:07 leaverou: I think everybody does .foo because they're taught. It's better if they can do it like they do it in CSS. 09:07:25 TabAtkins: Maps in general are nice to pass in JS, but object value maps are clumsy in general. 09:07:39 leaverou: Could we use ES6 proxies to handle prop that don't exist? 09:08:06 TabAtkins: Technicaly we can, but that's not good. These make it confusing when you mix map keys and methods. .get gets you the dictionary keys and it's easy. 09:08:18 shane: We can't be a multi map if we expose in the other way. 09:08:34 leaverou: Having to type over and over is tedious. Will there behelpers to set multiple prop? 09:08:40 TabAtkins: I suspect htey will evolve. 09:08:53 shane: And you can continue using the old string map. 09:09:07 leaverou: ideally this shouldn't be promoting both. 09:09:13 esprehn: Authors should use this. 09:09:25 TabAtkins: the use of maps will get more ideomatic and easy with time. 09:09:40 leaverou: If we use get and set we should be able to call .set with an objective multi prop. 09:09:56 TabAtkins: I'd rather let the echosystem eveolve and we can see how the usage plays out. 09:10:15 s/echosystem/ecosystem/ 09:10:59 shane: So this is the base stuff. I've sketched out a number of sub classes. This is for properties like z-index. We know from animation use cases you need to be able set opacity that are not valid. 09:11:08 ChrisL: So your going for bounding and clipping? 09:11:13 shane: I think I could prefer that. 09:11:28 shane: So it's the question of where we do validation and do we want a sep type. 09:11:34 Florian: What do you pref? 09:11:54 shane: I'd prefer a single node of value and to in general reduce the # of types exposed and do late validation. 09:12:09 s/bounding/late, rather than early, bounding/ 09:12:15 shane: I'd say for numbers and maybe all types should clip. We should be consistant everywhere. 09:12:19 btw not sure if it's too early for bikeshedding, but I think element.styleMap is too verbose. Why not element.css? 09:12:34 iank: And these objects aren't live, it can get the validated version back. 09:12:48 smfr: It will make it hard to dev tools to warn when the author put in garbage. 09:12:55 ojan: You can't set with the wrong type. 09:13:02 smfr: But you can pass in a junk string. 09:13:09 leaverou: Yeah, .css is nice. Tho, I kinda want to reserve that for the eventual Value Object version. ^_^ 09:13:28 shane: Wehn you pass in a junk string, you don't get warned. You mgith find out if you read it back. I'd like to do better. Esp if those are used in a restricted enviroment. 09:13:35 Florian: So why do you pref clipping? 09:13:49 TabAtkins: it's better to design this API in a way that can accept value objects in the future than change it again to an entirely different one. This is ridiculous. From .style to .styleMap to .css?! 09:14:03 shane: There are other use cases where you don't want to clip. It will depend on...if you're setting an opacity that is a negative, that could be find. 09:14:11 flackr: But once assigned it has to be valid. 09:14:21 shane: That's the point we should clip, when you apply. 09:14:35 s/flackr/Florian 09:14:41 shane: The other one we sketched our was lengths 09:14:46 ojan: Do we want %? 09:15:03 TabAtkins: You can't not express % because they use them in the style sheets. 09:15:12 s/ojan/jet 09:15:40 TabAtkins: Often % is related to layout. We dont' want to do weird layer crossing. We much return a % if the length is a %. 09:15:47 Florian: % isn't a sub type of length. 09:15:53 TabAtkins: It is A sub type. 09:16:13 shane: Maybe we have sep types or we try and kee those together. These are all details. 09:16:32 heycam: This is sim to stuff we just worked out in SVG. One open issue that lead us to remove it is what to do with calc. 09:16:40 shane: Let me take you through it. 09:17:17 kwkbtr has joined #houdini 09:17:37 shane: This interface rep any kind of length. There's ismple lengths, a single value, length keywords, and calc expressions. If you go at this level you can work with any of the three. They will do the appropriate things. They'll throw if you try and use them on a lngth such as auto. 09:17:57 franremy: The length interface isn't enough for the values in the stlesheet. YOu cannot use vairables inside. 09:18:01 shane: Variables go higher. 09:18:20 TabAtkins: When you're using a vaiable, we don't even know you are in a calc 09:18:28 franremy: So we can't use disappearing? 09:18:35 TabAtkins: We need a diff object type. 09:18:43 franremy: So disappear is for the output? 09:18:59 TabAtkins: If you use l.stylemap.setwidth you can set it to a length or a token string. 09:19:06 franremy: Then you can't mix and match 09:19:19 TabAtkins: As much as you can do anything. It couldn't be diff thena prop with two types. 09:19:37 SimonSapin: The keywords accepted for length depend on prop. How will this work in snap path? 09:19:45 shane: It's something we need to decide. 09:19:51 TabAtkins: We should validate values on setting. 09:20:06 SimonSapin: You have em for length and a class hierarchy. How are they rep in JS? 09:20:14 TabAtkins: We need nice pretty constroctors. 09:20:34 Elaboration on "we don't know you're in a calc": 09:20:55 shane: The simple length sub class, if you want raw values you have to postulate it. That may not be the bes thting to do, but then you can read the value directly. Calc is a big dictionary of unit to value. 09:21:01 heycam: Are the objects live? 09:21:02 width: calc(1 + var(--two) + 3); 09:21:14 shane: No. This is another reason to use map rather than direct access. 09:21:20 heycam: That was a main problem with SVG. 09:21:41 Oh shoot, never mind, you can't do that - vars require the parens to be balanced. 09:21:59 SimonSapin: To explain more, in CSSOM we have this rule interface where objects can be more specific and to know which there is a type attr. In this case if I do width, how do I tell if that's simple or calc? 09:22:03 amtiskaw has joined #houdini 09:22:15 shane: When you have a super and sub class relationship, how do you carry that's it's a sub class. 09:22:36 TabAtkins: That's a prototype. YOu can query with .proto Instance of works as well. 09:22:47 SimonSapin: The type attr aren't needed? 09:22:50 TabAtkins: Yeah. 09:23:06 s/type attr/type attr in CSSOM/ 09:23:32 (CSSRule.type is one of the old-style "numeric enums" identifying what type of rule it is. That's stupid, because JS has `rule instanceof CSSFontFaceRule`, etc.) 09:23:50 s/carry/query/ 09:23:52 shane: That's pretty much all we have. There's lots of details missing. There is lots of things to do. If it makes sense to provide dictionary-like access. What I hoped to get out of presenting this is an indication for if we should do this and if this is a good direction. and if it's good I'd like an ED inside houdini repo 09:23:59 Rossen: Do you have all these in a spec? 09:24:06 shane: I don't, but I will if we want to proceed. 09:24:29 dbaron: It feels a lot like the existing CSSOM which we all hate. I'm not confident it fixes the thigns we don't like. 09:24:38 ojan: What don't you like? This fixes the thigns we don't like. 09:24:38 This API is way too verbose and reminds me of Java. E.g. we’ve turned el.style.foo into el.styleMap.get("foo") for reasons that most authors will not quite understand. Instead, they will just blame us for being verbose and "why can't these native APIs be as short and elegant as the libraries I use?" 09:24:47 TabAtkins: The things we don't like this ignores entirely. 09:25:15 dbaron: I think there were a few related things. One was that whenever we did something new it was hard to map that into the existing OM. This prob improves that a bit but not completely. 09:25:45 Florian: Now that you're baking % into length, if we later need to do 20hx + 2timble (?) it wouldn't work. 09:25:57 TabAtkins: When we add freqency we will bake that in. 09:26:50 dbaron: The other piece was how verbose it was to deal with the value objects. You want to manipulate the px value of the bg position and it's element.style.getpropertybackgroundposition.something else and another array and a getter and a px value getter. 09:26:54 el.styleMap.set('width', el.styleMap.get('width').add("5px")) 09:26:55 s/2timble/2timbl/ 09:27:03 Rather than el.css.get('width') += 5px 09:27:05 shane: If you're just using get it'll be .get.backgroundpotion.x and that's a value. 09:27:08 BogdanBrinza has joined #houdini 09:27:19 dbaron: TabAtkins had a prop for value objects that was less verbose. 09:27:36 TabAtkins: Those are insanely optimistically 2 years ago. 09:28:09 s/ago/out/ 09:28:21 TabAtkins: It'll still be somet ime before value objects and string parsing and serialsization is a major perf hit. Even though this is verbose, the hope is this is a stop-gap. It's not idea, I'd love ot just value objects, but we know strings are expencive and dumb. 09:28:53 ojan: To give context, in iank proptype of custom layout we hand waves a lot. His initial proptype was like 20x slower and the majority of that was parsing screens. 09:29:17 TabAtkins: Later in his impl he cheated, exposed the numbers directly, and that's when we got to 2x. 09:29:43 TabAtkins: Anything with transform animation is string parsing bound and that can be spead up. 09:30:07 esprehn: Since the ob are immutable, you can keep a transform value that you keep muting. You an jsut put in one value and call set again and again 09:30:19 s/immutable/not live/ 09:30:50 leaverou: What if when people uselength and calc they're treated as px? At least in JS it returns a number that can be used in any calc. If peopledon't call .px and they just add 5 to a length can it turn px? 09:31:19 TabAtkins: We can't return a number you can add to we return an object. yOu're sayign if we don't call px... 09:31:56 heycam: One major impediment of this is that there are a couple of cases with non-intutive results like if you use the not operator it's always false. There's a couple of cases so in SVG we thought it was too confusing. 09:32:40 leaverou: I agree this API is extreemely verbose. Authors will hate this. Why can't we desgin a more concise API or that does the reasonable thing in most cases. 09:32:54 TabAtkins: We have designed a good API, but it's not available until JS adds value objects. 09:33:12 TabAtkins: I'd be against adding a value of and pretend it's px because it's not predictable. 09:33:22 leaverou: In 90% of the cases people will use pixals. 09:33:25 shane: Is that true? 09:33:34 leaverou: Offset tall and offset width are px. 09:33:41 shane: They always do and they're not in this API 09:33:44 The worse example than the ! operator working on objects with a valueOf method is that doing a == of two objects with valueOf methods will check object identity, not compare the values. 09:33:49 leaverou: You use those in another API. 09:34:32 TabAtkins: You want people to write code that assumes you return a 10 when you get a number and it will trhow when you use 5em. It encourages brittle code. If you do auto it can't be pixal. They're the most common, but not overwhelmingly common. 09:34:49 shane: It's true of widths and lengths. The problem we have i hidden because computer is returning used. 09:34:52 franremy: Exactly. 09:34:59 Rossen: All the API you listed are only returning used style. 09:35:16 leaverou: So far it sounds like this will be used in computed. Will we have something else for used style? 09:35:24 shane: This is the computer style, not the resolved style. 09:35:34 s/computer/computed/ 09:35:34 dbaron: And there's prop in the CSSOM draft that sep. 09:35:45 s/sep/separate computed style and used style better/ 09:36:01 s/computer style/computed style/ 09:36:22 leaverou: If these values are used in computed style where you do have px you are able to resolve everything, but authors have to use .px. If we're going to replace this API, we're going to teach authors to use this until there's value objects and you'll have to learn something again in 3 years. 09:36:25 TabAtkins: Yes. 09:36:29 shane: It's an opt in. 09:36:30 s/pixal/pixel/ 09:36:52 leaverou: It will be evangilized as the new CSS OM. And if it's not good enough to replace .style then... 09:36:58 so we're back to dbaron's point, why bother? 09:37:16 s/evangilized/evangelized/ 09:37:31 dbaron: Witht he value API, we only have getters and not setters. If you want to do this, and we need to push this into CSS spec, every prop needs to spec how it maps to values so that we can introp impl getting and setting. 09:37:34 ojan: That sounds good to me. 09:37:45 dbaron: It sub increases compleity of impl. Prob a good thing. 09:37:52 ojan: INcreases complity of specing. 09:37:59 dbaron: We'll have to impl the setters which is new. 09:38:04 TabAtkins: Not computed style. 09:38:22 zcorpan has joined #houdini 09:38:24 BogdanBrinza has joined #houdini 09:38:46 heycam: I'm worried about author predicatability without them havign to look up the spec. With this talk about in this prop it auto to a length and so you can set it on a length but in this other it's just a keyword, I don't want to have to guess and set these values. 09:39:02 TabAtkins: You don't have predicability today. Whatever compleixty this gives you get today in strings. 09:39:19 heycam: I'm thining about spec. style 09:39:27 TabAtkins: That reflects as close as poss. to what you put in. 09:39:35 while a transitional API is unfortunate, getting a 10x performance increase seems to me to be worth the bother 09:39:36 heycam: Auto on this prop acts like a length. 09:39:41 shane: You can use auto string 09:40:01 TabAtkins: We can be more ergonoic about what text values you accept so when you pass a length auto we can pass it out. 09:40:24 dbaron: One more thing I don't like, how do you get and change the x offset of the text shadow. 09:40:37 TabAtkins: Complex objects theywill go one by one and figure out that it looks like. 09:40:50 dbaron: So you'll have a JS with a x and y and a z? 09:41:09 TabAtkins: Yes. We do tend to turn previous complex values into sub prop. All complex values become almost sub properties. 09:41:38 s/x and y and a z/color and x and y/ 09:42:40 leaverou: This might be too far from what we're discussing, but if we're going to replace this API eventually, let's think of whre CSSOM is giving trouble. It's a pain when you're manipulating colors because you have to parse yourself, it's a pain dealing with lengths. So since this is going to be a transitional PI, would it be easier if we jsut speced the few prop of the existing OM so you can have a few prop that jsut return the RGB of colors 09:43:01 leaverou: So there's something they can use until we get the new API. We don't have to give them a complete set of new properties. 09:43:08 dbaron: The thing you desc is value properties. 09:43:32 leaverou: They're retuning a dull string in the existing methods. I think it can have prop and still return a string given that the two strings... 09:43:50 TabAtkins: It can't We return primitive strings. People today depend on that empty strings are false. 09:43:53 leaverou: Oh, yes. 09:44:02 s/value properties/value objects/ 09:44:10 s/false/falsy 09:44:32 gregwhitworth: So is it so bad to spec with the value objects in mind and if people are able to spec this with that in mind you can say we'll take the impl cost of switching over. WE should be specing the desired behavior in par. 09:44:48 shane: The only reservation I have is relying on value objects of coming is a risk. 09:44:53 leaverou: Can't we push for it? 09:45:08 dino: Can't we push this? Why can't we make it happen sooner? 09:45:15 TabAtkins: We can push for faster, but it's a long push. 09:45:45 ojan: I think JS has bigger fish to fry like modules. Thought that push would be good for us it wouldn't be good for the web. 09:46:34 TabAtkins: There is an ergonomic cliff we fall off here. Value objects are a better UX but we can't depend on them happening fast enough since as our impl experience shows, this sort of thing is req for most of our APIs. 09:46:58 ojan: This isn't jsut houdini. This is when peopl try and do transform animations why spend a lot of time parsing and unparsing the string. 09:47:07 shane: I'd liek to explore making simple things easier. 09:47:31 shane: Do you think giving a px number simply and when it can't throws, would that be helpful? 09:47:37 leaverou: That would be terrible. 09:47:51 shane: We can't give you a px unless it's always a px or we through. 09:49:02 Rossen: We're tying to explain the pipeline and one of the things is value tied. it has a really good rep of what the specified value is. In our impl that value is used until it hits the cascade. We've internally computed them and it's a subset of four types. 09:49:34 Rossen: If I'm impl custom layouts and I'm working out of a style obj that's supposed to be rep the computed, I shouldn't see rem because to resolve that I have to do gymnastics. 09:49:43 shane: At that point rem is meaningless. 09:50:17 Rossen: If I take it further and start paint all I'm expecting after layout is pixel values. There's nothing else. That's why what leaverou is talking about,most of the authors are used to working out of the back end of the pipeline. 09:50:52 Rossen: My question is, I def like where this is going but why are we not trying to expose the reast of the length values. Why can't we have spec, computed and used length? 09:50:57 s/four types/four types: enum for auto etc, length in px, percent, and unknown 09:51:10 shane: We can. computed we have to set back into used. They need to be in the same hierarchy. 09:51:49 TabAtkins: One ergo improvement, in the common you'll to a .get and .set. WE can make that more ergo and make that less terrible. 09:51:57 shane: We should keep an eye out for ergo improvements. 09:52:04 TabAtkins: I suspect there's a lot of low hanging fruit. 09:52:23 Tab was describing an update method with a callback 09:52:25 s/terrible/terrible, with an update method that takes a callback that gets evaluated immediately 09:52:34 TabAtkins: Also, the generic length, that's important. In general you won't have to manually construct extra lengths. when you.get you can immediatly perform some math on it. 09:52:50 SimonSapin: If you call add with a string that contais 5px, if you do that you get the same problem with strings. 09:53:04 esprehn: I don't think we want to add that. It should be ugly to force the string parsing. 09:53:20 TabAtkins: We should still add the value. It also handles the I'm a calc now. 09:53:30 SimonSapin: Is it poss that calling a method changes the type? 09:53:33 TabAtkins: Yes. 09:53:38 shane: no, it returns a new object. 09:53:55 heycam: Why is that? 09:54:10 TabAtkins: You get, fiddle with it, and send it back in. If you want an explicit calc you do it piecemeal. 09:54:28 shane: dbaron given your reservations, what should we do? Proceed, edit and work through, sit with us and discuss? 09:54:39 dbaron: I'd lean toward proceeding, but I'm a little conflicted. 09:54:50 shane: We can bail later. 09:55:40 dbaron: I wanted to uderstand Rossen comment about computed values a little better. Were you desc something where you'd get diff value types in the leaves of the API or something more like what's in CSSOM now where there's diff getters on the element for the diff things. 09:55:49 Rossen: I was desc diff value types, how the diff styles. 09:56:44 Rossen: computerstyle.getwidth would only return type value which is computed style. So if you have spec style you'll get this. My desc was a hybrid of what's in CSSOM 1 with the type styles and off of those the values are also so you cannot mix and match. 09:56:49 For the purpose of minutes: we should probably have a .update() on the map too, which combines a get/set (though .update() is a Python dict method that's independently useful). 09:56:50 Rossen: At least that's how we handle. 09:57:14 shane: You have to go up to read a spec style. You need upward motion. 09:57:22 Rossen: You're only subsetting as you move forward. 09:57:38 var w = el.styleMap.get("width"); w.px += 10; // would this work, or would it also require a .set()? 09:57:38 dbaron: I like that, it has a bunch of advantages. It's also more complex which makes me hesitant. 09:57:39 el.specifiedStyle.set('width', el.computedStyle.get('width').add(5, 'px')) is terrible, but... 09:57:49 ojan: I'd like to see this in a dsicussion of where we'd expose these. 09:57:57 el.specifiedStyle.update('width', x=>x.add(5,'px')) is better 09:58:04 Rossen: In custom layout I'd want to be working out of a computed style. 09:58:18 Well, there's that computed/specified split, which we'll have to work with. Hmmmmmmmmm 09:58:19 TabAtkins: honestly, both are extremely verbose 09:58:25 shane: An API that lets you set rems what the agent will be required. 09:58:31 leaverou: Oh, sure, but again, *there's no way to fix that* until Value Objects. 09:58:33 Rossen: Is everyone okay placing htis is a draft? 09:58:42 leaverou: Can someone look at TabAtkins examples in IRC? 09:58:57 TabAtkins: We know theya re verbose. WE can't fix it yet. 09:59:04 tantek: Is this a higher performance API? 09:59:05 Eventually: el.specifiedStyle.get('width') += 5px; 09:59:08 plinss: Higher. 09:59:15 tantek: In terms of introducing it to dev. 09:59:24 esprehn: We expect it to be wrapped in libraries. 09:59:30 tantek: I agree with leaverou concerns. 09:59:44 shane: If I choose between verbosity and performance.... 09:59:47 TabAtkins: no, that would be el.style.set(el.specifiedStyle.get('width') + 5px) 09:59:58 Verbosity is the number #1 anti-pattern in the DOM 10:00:09 franremy: Nah, += will invoke .set() 10:00:19 Not sure I understand why we can't do el.specifiedStyle.get('width').px += 10; without value objects. Are these length objects immudable? 10:00:20 Rossen: There's one more thing that needs to be said, keeping focus on what we're trying to expose with houdini, verbosity might be needed here. We want to attract the right level of dev who are writing middle term libaries. 10:00:24 s/immudable/immutable/ 10:00:31 tantek: Verbosity makes more copy paste. 10:00:58 TabAtkins: When less verbosity is only payable with large perf drops it's not worth it. We're trying, we can't do it. 10:01:10 TabAtkins: We parse as fast as we can today. 10:01:28 tantek: You can assume that all the browsers have been working to improve parsing string performance for 10 years. 10:01:28 Also the above example with the current API is: el.style.width = parseInt(getComputedStyle(el).width) + 5 + 'px'; 10:01:45 And hope that it is pixels 10:01:45 tantek: Another verbose syntax is not without its down side to the platform. 10:02:02 TabAtkins: This is a stop gap which we're not happy with but that we consider nec to do other things. 10:02:21 tantek: Then I suggest you advertise as high perfoamnce only. 10:02:37 esprehn: I don't see whyJQuery wasn't going to take this. It's one like for JQuery. 10:02:57 TabAtkins: I'm doubtful this could work. That would mean overriding the ".get(...) =" operator on the map, such that it can track an assignement to a value get from it; that looks far fetched to me. Did I miss something? 10:03:01 tantek: I don't thinkt hat framing would stop the JQuery people from trying to do that. And the nice thing is they can experiment with less verbose. 10:03:14 iank: And that example (for today's code) is only *that* "simple" because 'width' is a trivial little property. Adding 5px to a shadow blur is no more complex in the Object code, but *way* more complex in the String code. 10:03:15 astearns: I question the utility of framing something as high perf to reduce usage. 10:03:21 shane: I don't have a problem framing it as high perf. 10:03:32 ChrisL: And the other branding was this is temporary and good luck with that. 10:03:46 TabAtkins: We'll replace it, but we will have to keep supporting it. We'll be paying that cost forever. 10:03:56 esprehn: It's not clear this will be temporary. 10:04:22 ojan: We have to do this work for both versions. All of dbaron concerns would apply to value objects, it's jsut that the ergonomic approve. 10:04:29 tantek: Not just typing, but debugging. 10:05:08 ChrisL: I like the approach of using object and numberical values rather than messing around with strings. I'm slightly concerned about increases in verbosity and I remember people hated that about the SVG DOM. 10:05:32 s/numberical/numerical/ 10:05:46 zcorpan has joined #houdini 10:06:14 ChrisL: Another time we didn't stringify there was people that found sign improvement and that was on mobile. The issue was spending 90% of your time parsing strings. I like your idea of maps. Having to say get and set, people are going to react and say why do we have to say that. 10:06:33 shane: If we do .thingIwant people will also react negatively if it doesn't work. 10:06:50 ChrisL: We've got this thingthat depends on a number, but we're stuck. 10:06:57 Florian: I'm concerned about this massive bikeshedding. 10:07:19 TabAtkins: This will be sombody going through every prop to write them down. A few things will need to be resolved. 10:07:38 leaverou: If you had proper propities, if you set it to an number it's a pixel. 10:07:49 shane: Style.color.red +=15 That can't work. 10:07:49 s/that depends on a number/ that is a number and unit, so can't be treated like a simple number/ 10:07:55 TabAtkins: Not now. 10:08:00 leaverou: So why? 10:08:10 shane: You're not setting othe object back intot he interface. 10:08:25 shane: Youc an mutate but it doesn't set it in. Whe you use a map objects aren't love objects. 10:08:33 TabAtkins: When you pull it's no longer connected. 10:08:38 leaverou: Andt aht's performance? 10:08:44 ojan: Perf and impl complxity. 10:08:56 shane: And SVG stepped away from that. 10:09:08 heycam: It's caused security bugs. It's hard when you have 3 levels of live objects. 10:09:31 I think part of the key with framing is to point out this is API is "higher performance" but wordier (and thus more awkward code). Be intentionally upfront about the self-deprecation. 10:09:34 leaverou: Having an API that's perf optimized is great, but having one that's for usability is also great. 10:09:48 shane: That's a fair point. the perf is the high priority. 10:09:58 esprehn: I think usability is also subkjective. 10:10:09 leaverou: It is when you're undefined. It's not reactJS devs. 10:10:17 esprehn: It is. We should give them something they can use. 10:10:27 leaverou: I thought this was the same target group as CSSOM. 10:10:31 agreed, who is the target group? 10:10:45 shane: I think this is not for entry level devs. This is for people with perf issues using strings. 10:11:06 leaverou: I think that'st he fundimental misunderstanding. This is for authors that have the issues with the parsing. 10:11:20 Florian: This is coming through houdini and htat's for people trying to replace grid and that's not beginners. 10:11:36 shane: The best for beginners is wait for the the value API. 10:11:49 tantek: I think we need to be upfront about that framing. 10:12:18 tantek: As to the UX being subjected, I think we've got enough data of people pref the sucenct syntax there's data about simplicity. 10:12:39 esprehn: The reach devs are saying what we desgined are wrong. before and after, they want intel dom diffing. 10:12:50 TabAtkins: Like .closest which is a JQuery idiom. 10:13:18 dbaron: It sounds like you're arguing because we fixed one UX problem and they have a diff on the first isn't a UX problem 10:13:28 s/UX/usability/ (twice) 10:13:41 TabAtkins: Going too far in let's make this super conveient as possible, that's super subjective. 10:14:11 shane: usability is undeliably important. I think if we frame this appropriatly tantek you're okay going forward? 10:14:16 s/replace grid/replace grid layout/ 10:14:18 tantek: Yeah. I don't see another choice. 10:14:32 dbaron: I don't want to agree now that we'll have a 3rd CSSOM for usability. 10:14:42 TabAtkins: In the future it would be an independant decision. 10:14:47 dbaron: We should worry about usbaility. 10:15:04 plinss: My concern...we don't know what value objects will be, but can they fit in this API? 10:15:12 leaverou: one improvement we can make is CSS.px(10), you could do var px = CSS.px; then just write px(10) 10:15:12 shane: I'd like to investigate fitting them in. 10:15:23 leaverou: lots more sugar can be added 10:15:31 TabAtkins: Mutation is a problem, other than that it fits well. Worst case we'll have a different getter. 10:15:40 plinss: I want to make sure we take that into account at this layer. 10:15:49 TabAtkins: Worse case we'll have a third par. that's very close. 10:15:57 shane: I'm happy to explicitly design for that. 10:16:09 TabAtkins: Designing this with the idea that value objects will happen is good. 10:16:39 Florian: So if we're going to use it for value objects we shoudl desgin with usability in mind, but we should keep the perfm in mind for this. 10:17:09 ojan: We came up witht he most uabie thing, we had all these discussions. We rec. it's not wonderful, but we haven't come upw tih anything else. 10:17:29 Rossen: So I think we still need a resolution as to if we ED this or if they work more. 10:17:37 Rossen: Obj on having this as an ED? 10:17:45 Florian: I think we have to iterate, but the principle is good. 10:18:02 tantek: I don't obj I jsut request that the issues be placed in line. 10:18:09 TabAtkins: It's important tog et ahead of PR on this. 10:18:17 shane: I'll work with TabAtkins to get this out ASAP. 10:18:25 Rossen: Title and editors? 10:18:35 be upfront about why it's verbose as it is 10:18:40 TabAtkins: CSS-Typed-OM 10:18:50 leaverou: Code examples in ED? 10:18:51 TabAtkins: Yep. 10:18:55 Rossen: Editors? 10:18:59 TabAtkins: Me and shane? 10:19:12 gregwhitworth: I'd like to stay in the loop. 10:19:41 RESOLVED: ED for CSS-Typed-OM with gregwhitworth esprehn TabAtkins and shane as editors. 10:20:25 @doctype cssom PUBLIC "-//W3C//DTD CSSOM 1.0 Performant//EN"; 10:20:37 return at 1:15pm 10:20:49 (paris time) 11:05:26 shane: https://gist.github.com/anonymous/6738a42eba01838145f0 11:05:36 SimonSapin: thanks! 11:08:38 astearns: help is on the way 11:12:51 zcorpan has joined #houdini 11:12:54 johanneswilm has joined #houdini 11:17:25 smfr has joined #houdini 11:21:31 Topic: properties and values 11:21:54 Rossen: Before we do that, we wanted to take a quick show of hands of who is interested in dinner. 11:23:41 shane: I added it. 11:24:35 shane: shane We have an ED which is on the web. There has been some discussion, I was wondering if we were thinking of FPWD on this or if we need more thinking. 11:24:35 Florian has joined #houdini 11:24:36 present+ tantek 11:24:42 https://drafts.css-houdini.org/css-properties-values-api/ 11:24:44 shane: Do you want me to go through the spec? 11:24:45 https://drafts.css-houdini.org/css-properties-values-api/ 11:24:49 Rossen: Yeah. 11:26:14 shane: The main point is to start to explain parts of style computation. When we put this together what we wanted to do is come up witht he min things we could expose to add power. First is giving custom prop a type which let them participate in animation. THe second is if we provided a post layout hook we could let them influence the native properites so they can effect the changes to the visual display 11:27:13 Florian: The apply hook is very useful, but to do the kind of computed value adjustmenents that native properties do. It seems to me that thay may be an abuse of it since computed time isn't when you effect layout. In some cases you can do it, but the primary goal of this hook should do computed value and computed time, not layout 11:27:45 shane: It could be a compute hook which is a single prop or an apply hook. We have ex at the style level where prop effect other prop. This shouldn't be for layout. 11:28:07 Florian: Having a computed that works on a single prop isn't as interesting. This is important for being for computed value time. 11:28:36 franremy has joined #houdini 11:29:02 Florian: The single hook isn't powerful enough. We need to be able to have a hook that works cross prop is important. But it shouldn't be for elayout. Just because I can influence the width of the computed doesn't mean it should effect layout. 11:30:01 shane: That's the general idea. There's lots of specifics. one important point is these apply hooks would apply in these described contexts, rather then the main thread. YOu want the respond to relevant changes, not run at every relayout. You have to be spec what the hook is sensitive to. 11:31:01 shane: We had some ideas about how to deal with multi apply hooks wanting to chang ethe same output prop. IN CSS if you have multi prop that do apply the layout, we can reason which comes first, etc. We don't have that ability when we open this to third party authors. The initial design is only one apply hook could write to each prop, but that's too restricted. 11:31:50 shane: The advantage is you know straight away two hooks could conflict and you can warn the author. Instead we need to do it at the time they do conflict. But the very common case of wanting two prop that effect the same element in different places can work. 11:32:10 Florian: There'st he same problem of having one hook effect a prop and another use it as a input. 11:32:28 shane: For this version we'd want to prevent chains. We could add that as an advanced feature later if there's need. 11:32:44 Florian: I think we make sure we don't design them so we can't chain later. 11:33:18 shane: We're left with pretty basic, you register with aname and a syntax string. It's just what we see in specs right now. 11:33:38 heycam: You might want to use the style since the rest of the CSS values syntax uses style. 11:33:40 shane: Yep. 11:34:23 shane: You do that, you spec if it inherits. You spec the initial value. You get syntax error if the initial value doesn't match the syntax or if you don't match the custom prop name production. That's registration of custom prop. There's an unregistered. 11:34:47 shane: You need to spec your apply hook which is when your custom prop is set or changed on an element. It's registered in the context, not on the main thread. 11:34:56 TabAtkins: The def of changed is the same as transitions. 11:35:35 shane: Inputs are all computed values and would use that sytnax, as are the outputs. In terms of ordering this happens after transitions. I sent an e-mail to the list about why. 11:36:25 TabAtkins: In particular, if you're using the syntax varient, not *, but the transitionable ones, then with they syntax information we can write transitions on custom properties and then you want to be able to react to the changes on the custom properties. 11:36:49 shane: The analysis I sent to the list is reasonably detailed. Unless we think of other cases we need to support, this is pretty conclusive. 11:37:12 TabAtkins: There are reasons to run before transitions, but they're less useful. We might want to consider in the future. 11:38:06 shane: A simple side point is you can use this to opt in or out of inheritcance and you can use this for type information so this can be useful for properties. 11:38:26 heycam: I was worried a common thing with transforms, running your apply hook every frame will force it to the main thread. 11:38:34 gregwhitworth: That's one of the elephants. 11:38:54 astearns: In the ex the input prop uses * notation to grab a bunch of prop. Is it worth adding the input prop are *? 11:39:06 shane: I don't think so. This was us being lazy on the ex. 11:39:29 TabAtkins: We have use cases for arbitarily properties with custom names, but that's not a v1 feature. 11:39:43 shane: We think this is tightly restricted. It opens new capabilities. 11:40:44 ojan: This gets at what dino and smfr were getting at about what can you do in your hook. If you look at the apply functions, the only output is the field you put on the output style. You can't get anything out of the worker beyond that so you can't get something crazy out. 11:41:00 dino: Do I remember the previous version of the spec was a sandwich between side by side elements? 11:41:08 shane: We removed that because we didn't think we could do this. 11:41:12 dino: Good, we didn't either. 11:41:39 ojan: The element passed to the apply isn't in the normal dom sense, it's in the style sense. 11:41:46 TabAtkins: It's a very restricted bag of information. 11:41:55 ojan: We're not adding output style to the main frame. 11:42:00 shane: It's an element proxy. 11:42:12 flackr: It doesn't include ancestors or children or a whole bunch of things. 11:42:19 ojan: It only has input and output style. 11:42:26 shane: At some point we might add parent style. 11:42:41 dino: In the apply hook it says reading computed styles in element property? 11:43:31 shane: That's correct. It happens after computation so it reads in already computed values. If you have multiple apply hooks they're running par. They don't chain. You do the computation, you compute the apply hooks, if they don't conflict you have a new set of values. 11:43:45 Florian: With that model to be able to do chaining you'd need a different chainable apply 11:43:55 shane: I think it's important to opt-in to chain 11:44:08 gregwhitworth: The author wnats to chain though? 11:44:15 shane: The author has to be able to say it, yes. 11:44:34 gregwhitworth: We're hoping the 1% of authors apply this and you give them these two libraries and apply hooks. 11:44:56 TabAtkins: It's like the JQuery and the $ We need to make it easy for libraries to say never mind, this is the one I wanted. 11:45:03 Florian: This is the only concern I have on the spec. 11:45:13 shane: I think it's a great idea to get an example in there. 11:45:18 s/this is the one I wanted/here's the apply hook I was going to use, go ahead and sequence it yourself/ 11:46:02 franremy: From all the specs this is the one I have the most concerns about. The reason why is I don't see using this. It doesn't solve any problem with a solution you can use. You can't fix CSS Grid, I've yet to see an example beside creating an animation. 11:46:35 shane: The two ex in the spec. [pulls up spec] this is a full fidelity polyfill of translate. 11:46:54 shane: One not in the spec, I want a prop that lets me lighten colors by 10% You can do this as a prop as you wish. 11:47:06 shane: This spec is also an enabler of all the things we wish to do in the future. 11:47:22 franremy: This doesn't go far enough in any direction to be useful. WE can't do this like short hand prop. 11:47:37 TabAtkins: They're resolved at a much earlier stage. Handling short hands will be in the future. 11:48:02 franremy: When I look at the spec every time I have a great use case I'm told it's an extension to the spec. I'm worried this will become the most complicated spec. 11:48:34 shane: There's two things missing. One will not end up the spec. Short hands don't belong here, they should be spec. THe computed value hook should be here and isn't. 11:48:54 franremy: I'm afriad this is specific to one use case. You could give me this in broswers and it doesn't solve any problem I have. 11:49:44 TabAtkins: Taht's highly unlikely. You could polyfill most of the prop side of flexbox. That's what you need to enable a lot of these things. We don't want you to be forced to only get custom layout in JS. There are limitations, but this is the most useful first place to insert ourselves into. 11:49:55 shane: And it has a multiplictive effect when pairs with others. 11:50:03 dauwhe: Yes, definitely. 11:50:18 franremy: I see the point of combining with CSS painting. but if you want to move futher this isn't sufficent for, layout. 11:50:24 shane: You would use the layout spec. 11:50:37 TabAtkins: I would love an example of why this plus layout is missing to reimpl flexbox. 11:50:55 franremy: You don't get shorthands and you don't get computation rule and it's difficult for transition block. 11:51:34 TabAtkins: If you ignore shorthands, those are all nice single value prop that fit into the model you have. You should be able to transition a --flexbasis no problem and have the layout hook take advantage of that. 11:51:43 TabAtkins: We can't solve everything at one. 11:51:51 dauwhe: @--page, rather. 11:52:05 franremy: I have the impression this spec is trying to say we can't solve all the letters, so lets start with a, c, and d. 11:52:20 shane: You can operate without shorthands, but you can't do flexbox without this. 11:52:47 franremy: You say it's simple, I have a css polyfill for css grid. We are talking about making things better so it's not better than what exists that's not the point. 11:53:13 flackr: The CSS WG produces immediatly useful things. This group provides primitives. 11:53:28 s/flackr/florian 11:53:43 Florian: When you don't have enough primitives, you need to have enough to be able to combine them. 11:54:00 franremy: There are other ways to solve this problem that solve other problems. 11:54:43 jdaggett has joined #houdini 11:55:25 ojan: To answer smfr and dino about what do you do in an apply hoot, the eq code is the style adjuster in Blink. There's code that takes the if you're pos abs make a block. If you add a new position like prop you want to do that. If you want to code yourself to that block if your flexbox. It's not common for most libraries but you need it for most usec ases. 11:55:34 s/hoot/hook/ 11:55:35 Rossen: It's needed when you're applying cascade. 11:56:03 johanneswilm: Can I use this if I need to invent a new prop and I have 10 stylesheets that override and I want to know what this ends up at the end? 11:56:10 shane: There's no communication out. 11:56:50 johanneswilm: What say I invent something new and I have 10 stylesheets that override each other. If I apply 55 diff values in diff style sheets, if I don't want the JS to go through to figure out which one, this should help me? 11:57:14 TabAtkins: Yes. All of that merging together happens earlier than cascade. BY the time we get to the apply hook it's done and gone. 11:57:24 gregwhitworth: Can you add an issue to draw a diagram? 11:57:25 TabAtkins: yeah. 11:57:36 dbaron: You couldn't impl a flexbox that doesn't take a simple syntax. 11:57:53 TabAtkins: Yeah. most prop are fine. If you ignore shorthands, I think they all work. 11:58:01 q+ 11:58:03 TabAtkins: I think every non-shorthand is a single value. 11:58:06 q+ 11:58:09 ojan: It's just the flex shorthand. 11:58:25 dbaron: Still not being able to validate syntax that isn't those 6 things is limiting. 11:58:47 TabAtkins: We're limiting because they syntax is easy to create invalid options. Our ability is to provide guar. unambig. 11:59:13 TabAtkins: In the future we might be able to proide a method to figure out hte ambiguity and we'll add that. 11:59:22 dbaron: You don't even allow validation of set keywords. 11:59:34 TabAtkins: We do. The second to last one is arbitary items. 11:59:41 dbaron: What about 7 particular idents. 11:59:58 TabAtkins: That's what it's for. It's just like a CSS syntax definition. 12:00:08 dbaron: It feels a little off to not allow code to validate. 12:00:39 TabAtkins: I suspect we want to do that at handle shorthand stage. Right now the main purpose is to allow transitions to work. once we get shorthands we need less arbitrary syntax. 12:00:52 shane: And I hope we can allow the syntax strings to take a function 12:01:39 Florian: To answer franremy point, I think it's tempting to try and make useful things, if we're not modeling along the way browsers work we end up with a model that's not exposing the syntax of the browser, but we won't be able to expose that if we don't start there. 12:02:15 franremy: We cannot even provide more information that the API is not of use. It doesn't make sense. We can provide it as a spec, but it's not going to help most people. We can ship something, but it's not useful 12:03:11 TabAtkins: From what we can tell and the examples we've worked through, the apply hook is rather useful for doing a lot of things. Maybe not in an optimal way, but in a useful way. If we're wrong and we can add more we'll fell in the holes. That you think this level everything is more or less useless, I think it's wrong. 12:03:36 franremy: I understand the point, I just don't think it's going to add much. 12:03:47 dino: I agree.I think it's limited utility until we add other specs. 12:04:03 TabAtkins: Oh yes. this is the maximum usful of the things and provides a lot of power. 12:04:36 s/the syntax of the browser/the internal model of the browser/ 12:04:37 heycam: About the apply hook, the outputs are computed values and ultimately you need to asign them to the output values, what happens when you assign 12em. 12:04:49 shane: It would throw an error and we need to wkr through that. 12:04:57 TabAtkins: We have the information nec to resolve. 12:05:07 esprehn: You're assigning more prop, we can resolve once. 12:05:28 TabAtkins: You take the single track at computed, you break off, loop around, and put it back in. THat's the mental model. 12:05:48 heycam: If you effect, say, font size, what happens to other prop univolved in input and output 12:05:56 TabAtkins: I think that's when we do the recomputation. 12:06:09 shane: We don't do that. It makes the font size that was use to determine it. 12:06:18 TabAtkins: By the tie you hit the first computer they're pixels. 12:06:20 bkardell_ has joined #houdini 12:06:27 heycam: I think you have to store post and pre font size. 12:06:38 q+ 12:06:44 esprehn: You have to do that already because the values that you get...two apply hooks cannot communicate. 12:07:00 heycam: So you have to recompute any prop with font-size:reletive if you effect the font size. 12:07:02 vollick has joined #houdini 12:07:31 esprehn: This seems like we should discuss futher. It might be benifitial to say you can't. We will let you resolve to a pixel value and you do it yoruself. 12:07:53 heycam: For the kids of prop we're alreayd tweeking at apply value, we want to be careful to desc what happens if you effect oneof those. 12:08:27 TabAtkins: We have two ideas. 1) you think of all the fixup you do as an apply hook that the broswer sequences after whatever the user applies. WE may want it to run before so you see the same world beforehand. 12:08:39 TabAtkins: The very least we need one. 12:09:07 dbaron: I don't think this works with our impl. We hook interprop dependencies in a chached structed with in cached struct. 12:09:32 TabAtkins: So the cannonization at computed stage happens easly enough you have to expose those before the apply hook seems some 12:09:34 dbaron: For some. 12:09:48 TabAtkins: For use they can all be done later, but if we need a list or spec that everything runs twice we can do that. 12:10:01 q+ 12:10:11 TabAtkins: If everything runs twice you're fine and it works for us because we can do whenever. If I'm understanding right. 12:10:37 dbaron: What about things like other lengths in em depending on font size. So if you change the font size, is that saying you'll go back and computer the lengths? 12:11:19 TabAtkins: That was heycam secdon question and that we need to go back and work it through. There's two options and we can decide which one is better and performant. 12:11:32 ChrisL: Didn't we say this morning you only want things only in pixels? 12:11:41 TabAtkins: This is later on. This is the middle of value computation 12:12:03 franremy: If we say you can only have pixel in the end you still have an issue where you have custom prop. 12:12:23 TabAtkins: Like var prop? We have to work it out. It may be the presence of var means we have to do our computation first. 12:12:26 s/only want/don't only want/ 12:12:36 franremy: I believ the best stage is after specified. 12:12:44 TabAtkins: That doesn't let you do responded transition. 12:13:15 franremy: That's not ture. in a lot of cases you know which transition will run and you can use a transition that's already running. 12:13:20 ack Florian 12:13:50 Florian: This is a bit on a topic earlier, how slow can we allow this to run if the apply hook is a ddos that takes forever. Can we have a provision to let the broswer fallback? 12:14:27 TabAtkins: If you have accidently too slow code, maybe? We'd have to decide what that means if you don't set any value and it passes through unchanged. It's something we should jsut pay attention to. 12:14:43 Florian: The problem of being too slow is common, but the solution might be individual. 12:14:55 ack ojan 12:14:56 TabAtkins: I agree. There's a problem we should pay attention to even if we jsut rec UA mitigation 12:16:19 ojan: two things. I view this spec sim to scripting. Its value in itself is min but it's requied for everything else we're doing. It's not a spec we could integrate elsewhere, though. OTher is I feel dbaron point about exicuting code to do validation got glossed over. I view what's in the spec as the min we can ship that has mos tof the value. Ever script hook we add involves a lot of discussion so I lean toward we can ship the first without script codes. 12:16:39 ojan: It's naturally easy to assume that you can pass one and I think we'll add it, but I don't think the first needs it. 12:16:50 TabAtkins: We will need shorthands eventually and that ties well into that stage. 12:17:13 dbaron: This weird flow here on the white board where you comp twice, it doesn't feel like it's exposing browser internal. 12:17:44 esprehn: Internat to a broswer you can't...so border can't change font size. There's a constraint with how you repeat style. 12:18:26 TabAtkins: I don't know if we want to expose that. I don't want to go through and map forever for the same reason we don't let the var apply to normal prop, this would require the same. I'd rather things become inconsistant if you screw up 12:18:30 q? 12:18:59 heycam: I'd start to worry about the order you run things then. So lets say you have some prop not effected by apply hooks. You've got one that effects em values and another that willr esolve. 12:19:07 esprehn: There's no chaining. 12:19:19 TabAtkins: The em have disappeared by the time you get to the apply hook. 12:19:41 Florian: By the time we have chainable we need to make sure we can apply them. You can have a loop. 12:20:09 can we give Tab a mic? 12:20:19 TabAtkins: Once you're chaining you're not writing into the same data structure. Chaining would have input intermediate, output and each would see the intermediate and write it. No apply hook care writing into the computation of a native property. 12:21:06 Florian: So if we wanted to expose exactly how it works it would be exposing the engine and the code where authors tell each other what to do. You're creating a two stage thing that's not already there. You can't be a part of the broswer chain, you have to let that run and run your own. 12:21:10 TabAtkins: The alt. isn't doable. 12:21:33 heycam: I'm worred that introducing native chains to css would create breakages. 12:21:35 TabAtkins: Yeah. 12:22:00 TabAtkins: The browser can do aribitary things, not beause magic powers, but because they have one apply hook. 12:22:02 s/introducing/introducing new/ 12:22:14 for example, extend an existing property with a new length value that can be in em units 12:22:24 esprehn: So let's put apply hooks as at-risk. The property still has a lot of useful pieces. 12:22:43 shane: If we can't get thgouht these issues we drop. 12:23:03 hehe 12:23:14 Rossen: Are you planning to add...I saw you're looking for FPWD. Spec looks a little dry, quite empty.It's jsut ideas on paper. 12:23:24 Rossen: Also I think there's need for better examples. 12:23:39 TabAtkins: Sure. And we need to comb through the minutes and add the dozen or so issues. 12:23:54 shane: Perhaps the best thing to do is for us to do that over the next week and send the result to the list. 12:24:04 TabAtkins: In the mean time, this as a ED of houdini? 12:24:07 shane: It already is. 12:24:09 TabAtkins: nvm 12:24:18 Rossen: Is that it on this? 12:24:24 shane: Unless there's other questions 12:24:34 Topic: Generized Cascading Sheets 12:24:51 https://lists.w3.org/Archives/Public/public-houdini/2015Jul/0003.html 12:25:24 leaverou: In the past 15 years we've seen many lang come up with sim syntax to CSS. same grammer and cascading and these can be unrelated to styling. I've included a few examples. 12:26:05 leaverou: As you can see many are unrelated to CSS so my prop was to make something, this is a placeholder name, something that lets us sep the style from the cascading sheets and create a generalize language that people can hook onto. 12:27:01 leaverou: A sort of generalized lang framework so more people can make lang based on the CSs syntax to make it easier to show what classes and pseudos they accept. A lot of thi is being done in houdini, but in the context of extending CSS> It's also useful for these other lang and right now they have to use a CSS parser and that's not ideal. 12:27:47 leaverou: It would be easier for people to write tools and be easier to define future languages, like Caas. WE can also have more interested parties working on this because it's a language frameowrk. Event he selectors language would be accessibile. 12:28:05 leaverou: I think that's the general idea, what do you guys think? 12:28:26 SimonSapin: To note selectors are in the css. Also css syntax spec is fairly seperate. 12:28:34 leaverou: This seperation is happening, but it's centered around css 12:28:42 SimonSapin: Given that what else is needed. 12:29:24 leaverou: Something that defines what else is acceptable in the language, like wht @rules are acceptable. Right now they can use a parser and it drops things that CSS doesn't understand. They're not first class web languages, they're leecing off CSS 12:30:39 ChrisL: We're trying to provide extensibility points nad browsers and I see this helping both. If you want to extend one phase you should be able to do that. The thing about discarding all the prop you know is a problem for CSS where you don't want to discard properties you don't understand. This is a smlal amount of effort to slightly generalize the parsing API it would be useful for many languages and reduces the pressure on this group to standarize. 12:30:55 ChrisL: People come to the group and ask us to build things and when we have this we can say no you can build them. 12:31:07 SimonSapin: I agree with everything you said. What steps can we take in that direction 12:31:15 -> http://www.w3.org/Style/2014/css-charter Our charter has since a long time presented syntax, cascading/inheritance and rendering as three independent topics the WG can work on. 12:32:03 leaverou: We should decide what the integration should be. Do these cascade? Do they need to? How would we define the syntax? The CSS values part of it, do we need that? Selectors and syntax would be in GSS, but what else would be, that's not clearly defined. 12:32:12 q+ 12:32:16 q+ 12:32:31 text/sass+gcs 12:32:41 leaverou: We could discuss what hte syntax would be. THe way I picture this is something with its own mime type so you could have like text.gss list JSONLD is LSON + LD 12:33:07 TabAtkins: The puzzle you have is several parts. Let's expose what the browser does to turn charaters into CSSOM. There's parse as selectors and apply as cascade. 12:33:24 leaverou: Will the lang have OM? We don't want them to mess witht he CSS OM. Do we give them an OM? 12:34:37 TabAtkins: Directly exposing the CSS parser so you don't have to pull in a JS impl of what the broswer is doing, prob reasonable. In our code if we see somethingt hats' a selector we do some reordering and pull something out to hand to JS. I'm not sure what FF does. In so far as if you take text and you parse it into CSS, what's the fidelity? 12:34:45 heycam: You lose things like universal combinator. 12:34:56 esprehn: I think we can remove the parser manging. 12:35:13 leaverou: Perhaps sep lang could hook up sep code even as a part of a GSS parser. 12:35:18 s/combinator/selector/ 12:35:34 TabAtkins: The parser part seems reasonable. If you look at my parse CSS i've added something about that. 12:35:51 leaverou: It's extensibility for authros and browsers. What is Caas was impl by broswers? 12:36:16 TabAtkins: The non generic of our css parser was a problem recently when I thougt we could impl caas and now we can't. 12:36:22 plinss: We agreed to expose the CSS parser. 12:36:23 s/Caas/CAS/ 12:36:40 esprehn: Exposing the parser is reasonable. The cascade isn't as reasonable because it's not very generic. 12:37:05 gregwhitworth: I can see you're using the parser we expose through the API and whatever your doc tree looks like and you'd have your own impl. 12:37:22 leaverou: If there's some way to get the specificity of a css selector it would be easy to get it yoruself. 12:37:41 TabAtkins: If we can say parse this a selector for me and exposing the specificity directly is fine. 12:37:52 SimonSapin: With matches they don't have specificty by themselevs. 12:38:47 leaverou: A part of this discussion is framing many things we're doing differently for more interest. There's alreadypeople writing their own language when they could be using something like CSS. I've seen weird syntax that would be better if they looked like CSS, but 'cause they can't use generalized syntax it doesn't. 12:38:58 TabAtkins: Same experience here. 12:39:08 leaverou: And they don't look at CSS specs because they're not doing style. 12:39:14 SimonSapin: Why can't they use a syntax like CSS 12:39:21 q? 12:39:36 Florian: They could if they fully understand, but because they don't they get close. If they could hook in they could. 12:40:14 leaverou: Imaginge if MS had something that's sort of like SVG, but it's not quite the same as it. It's like trying to desc a left by how it differs from the siblings. 12:41:00 gregwhitworth: Let's say an author wanted to do theming based on CSS, you're talking in a much more generic form. It seems like you're want the parser, not the whole engine. I'm wondering the feasbility of this outside embedding the entire engine. 12:41:22 Would it be fair to say what we are exposing is the GCS parser and that CSS uses the GCS parser and as of today has 0 deltas? 12:41:34 leaverou: It's a good qustion as to if it's in scope for houdini. Most of our work is CSS API and this is a different alnaguage. That's the first thing we should do, discuss if this is in scope. 12:41:50 TabAtkins: Exposing the parser is in the charter. We need to write it up, still. 12:42:24 TabAtkins: There's one part of what I've heard that we haven't addressed and that is automatically getting a parser in there to style type= CAS and get CAS in there. 12:42:55 leaverou: Like browsers have an XML parser, I imaging it would be similar. 12:43:27 Florian: Things early in the pipeline like the parser we will expose. Thing sin the later stage when we're trying to expose the primitives your looking to expose the general. 12:43:43 q 12:43:50 q? 12:44:07 leaverou: Part is branding. People that aren't interested in CSS won't care and they won't use it. This is not just a technical thing, this is how branding works. If you frame it as something people aren't interested in it won't succeed. 12:44:09 can we pass the mic? 12:44:10 ack dauwhe 12:44:34 BogdanBrinza has joined #houdini 12:44:51 dauwhe: I've been looking at the tree transform thing and it's very similar to something we use to prepare comment. If someone gave me 1mil and I decided to implement that, does houdini have what we need. That's anther way to get to if this is a houdini level request. 12:45:17 leaverou: I've heard many CSS WG people say the future of transformation si a CSS language. I think something like this is around the corner. 12:45:59 Florian: I think there's multi levels. selectors aren't branded CSS, syntax I think is. There's a diff of branding specs and having generalized impl of broswers. 12:46:00 s/the tree transform thing/Daniel Glazman's Simple Tree Transform Sheets/ 12:46:08 q? 12:46:21 TabAtkins: If we focus on parsing, let's do that. WE have most of the spec of that we need to just apply certain schemea. 12:46:29 TabAtkins: Selectors are exposed in DOM 12:46:50 leaverou: I imagine we'll come up with syntax of what's allowed. Would it be poss to have parameters for cascading? 12:47:42 TabAtkins: Exposing the cascade would be something completely new. The parser is exposing something we're doing. All of our cascades are too tied into CSS specific application. It's a matter of defining a new feature. Cascading is easy enough and niche enough it won't pass the benefit test. 12:47:56 dauwhe: I think I could do the STS thing with the existing cascade. 12:48:08 TabAtkins: If you're willing to use custom prop in CSS, sure. 12:48:23 ack bkardell_ 12:49:18 bkardell_: I don't know at this point how much I'll add...I agree that the branding is important and maybe what we're doing is saying that thing down there is more valuble than just beign a css parser given that it needs to parser more than css. If we called it gss parser and css is in the family and the thing it gives you back is a rougher thing than cssom is 12:49:51 bkardell_: As we desc these things our goal is to describe thing in the appropriate layers. At diff layers we have extensibility points and the closer you get to where css is at at some point it's css. 12:49:53 TabAtkins: Yeah 12:49:55 Florian: Yeah. 12:49:57 +1 12:50:31 bkardell_: I don't know if it's helpful, btu I like saying the thing we're desc is not the css parser, its a general parser of css-type things and trying to layer it so it's poss to wedge most of those ideas in there in ways that are flexible. 12:50:37 q- 12:51:07 TabAtkins: I doubt it's useful to rename the css syntax spec, but I agree conceptually. It can be frames like selectors and MQ as lan independant. We'll expose how to parse with that. If there anything else we need to talk about? 12:51:33 franremy: The main thing is to have a few samples of what is gss and what is not. Examples of what it's a gss-like so people can test if their lang is gss complient. 12:51:41 leaverou: WE should also bikeshed the name. 12:51:52 Rossen: Is that it? 12:52:24 GCS = Generalized Cascading Sheets, but we don't actually include the cascade, so it's a bad name 12:53:01 Rossen: We'll take a short break and then do the font stuff for jdaggett. 12:53:01 Florian: Good point, Perhaps Generalized Declaration Sheets? Generalized Property Sheets? 12:53:20 12:53:35 oh Generalized Property Sheets produces a great GPS which wont be confusing at all! :) 12:54:07 NCNSS (non-cascaded non-style sheets) 12:54:29 extensible stylesheets - XSS... that couldn't possibly have a branding problem :) 12:55:29 LIST - Lea Inspired Sheet Thingr 12:56:11 Lea-Inspired Sheet of Properties - LISP 12:56:43 Lists Including Some Properties 12:57:51 you could have a lang with just @rules and descriptors 12:57:58 so I'd rather if property was not in the name 12:58:32 declaration perhaps? [Generalized | eXtensible ] Declaration Sheets? 12:58:49 what if we tried not to use an initialism and just called it something people would be subliminally drawn to, like "Gelato" :-p 13:00:26 bkardell_: that's too cool for standards :P 13:03:04 How about just Rules And Declararations - that would be RAD... this way we'd be guaranteed have a rad output 13:13:25 dauwhe has joined #houdini 13:18:59 Topic: Font metrics, lineboxes, and their interaction 13:19:56 ChrisL: There are several topics about font metrics API. What metrics d you want? Do you want what's int he font, waht the browser returned? In the units the font uses, in pixels? And in some cases you're better off with lineboxes. First thing is to discuss that. 13:20:25 ChrisL: Most likely thing you want is the baseline. 13:20:31 Rossen: Should we diagram? 13:20:35 ChrisL: Yeah. 13:21:48 ChrisL: Before I go into this, the overall sketch of how I picutre this working, you point to something in a document and say what font is used. What font is actually being used because it can be several options. And you get that data back and do a polyfill. 13:22:23 ChrisL: Simpliest is you pass a selector and get that back, but it's not good enough. That's the point of the deadrange. That's another topic, but that's what I mean by point. 13:22:54 ChrisL: You decide you're using language in script x and lang in script y and you decide you want to pull it one language down. Or you want to do drop caps and we don't have it. 13:23:38 astearns: Simpliest I know of is in flexbox you can align flex items by first baseline. I don't know of a way to do that with information given in APIs. So being able to polyfill that first baseline alignment and adjusting where the boxes are. 13:23:48 smfr: So the UA does first layout and you come and fix it. 13:23:58 Florian: And when you point, you don't mean coordinates. 13:24:05 ChrisL: Point in the source tree. 13:24:23 ChrisL: It's more that you're hidden in some way and you'll reveal once you've calc. 13:25:04 ChrisL: one thing you'll want to know if where is the baseline you'll decide to align this on. This is a common case wehre you have an image and want to align. You've also got x height in latin fonts, people have expressed that desire. 13:25:34 ChrisL: And the other is you want to know what the actual font is, some of which is metrics, some of which it is not. 13:25:51 q+ 13:25:54 ChrisL: Do I need more diagrams for what we're going for? some of ths is low hanging and easy to expose. 13:26:13 astearns: For example the font being used and the dominant baseline in the line box, they seem to be to be fairly different things. 13:26:32 ChrisL: Does anyone in the room see this as interesting? 13:26:48 Rossen: It's not use that should be finding this interesting, it's the use cases that should be telling us. 13:26:53 astearns: I can list more use cases. 13:27:10 Rossen: Are we finding this interesting, yes, the req. should be based on use cases. 13:27:25 ChrisL: Mathematical layout is something people want to do, certainly. 13:27:52 astearns: I've seen the upset reaction from people trying to do font setting in sophisticated ways. 13:28:19 ChrisL: They're tryign to make assumptions that I want to use this font and I hard code and if doesn't work because that's not the font used. 13:28:56 first baseline offset, baseline grids, initial-letter, aligning anything to typographic measures 13:29:25 liam: There's tonnes of use cases and we should do those on list. Being able to align things, when we look at things like page floats, howcome did some examples and having sucessfully present to usenet, his page floats would be rejected because they didn't line up exactly witht he cap height and the like and you can't do that right now. 13:29:26 q+ 13:30:11 liam: If you're doing custom layouts which is reasonable in houdini, you need access to positions as well as sizes. Just guessing or hard wiring the line height doesn't work if there's a pseudo script. This isn't as simple as it might sound. 13:30:17 jdaggett: Yes. 13:30:46 s/pseudo script/superscript/ 13:31:09 smfr: I'm a little confused about this fits into layout. Every time the UA lays out the line you have to run script to fix this up. Unless this is a part of custom layout it would be nice to get this fixed up before the user sees it. 13:32:43 jdaggett: I guess, I def agree that there are a lot of use cases for a lot of this information, however I think the danger here is if we take tha ttitude of we'll just take a set of end us cases and try and gin up artifical data structures that provide the info for those use cases we'll produce something that's a big mess. That we're producing artifical data structures is also a problem. 13:33:13 q+ 13:33:27 Chris did not say "the font *for the line*" 13:34:05 jdaggett: When you have a text frame there are step. Segmentation of the data and script structure for the font, when ChrisL says the font there isn't jsut hte font. IN what astearns has posted to the list there information that the first line information is the font. You have to distinguish the putputs of these different phases. YOu have to let them cleanly tweek what they want to and not get mixed up. 13:34:28 ChrisL: At no point has anyone said this is for the whole line. This is the first character or first glyph. 13:34:38 ack smfr 13:34:51 ack jdaggett 13:35:11 jdaggett: My problem is I think you need to look at text rendering, break down the primitives and see in where in these step si there information you need to get out. In a lot of use cases you find things like font selection is important to expose. 13:35:42 ack astearns 13:36:09 astearns: I agree that we need to explore that stack of things that happen and hook intot he right place. But we also have the fragment API that is giving things like position, width, height that are the results of the layout prop we want to hook into. THere's a place in those results to give some of the information that script layout need to get at the right information. 13:36:22 Rossen: Suppose all these APIs are read only, would that make you easier? 13:37:26 jdaggett: No. If you look on the list you'll find astearns prop for font metrics and it's a mixture of line metrics and per font metrics. You need to define these are metrics with a font in general, these are metrics att he glyph level, there are the line. I think you have to split these out so it's clear what you're exposing. Your mixing up elements setting priitives. It creastes extra work for a UA. 13:37:54 astearns: I do agree that not having them all bundled in the same interface is useful. Setting the attr values so you know where they're comnign from is good 13:38:35 ChrisL: I'm generally agreeing with you. Being able to iterate through the segments would be nice. And I take your point on per font instead of per glyph metrics. I understand your point about different levels and keeping them sep. 13:38:52 q+ 13:39:05 jdaggett: I don't think we should proceed from use case. We should proceed from here's the model, here are the use cases, here is how we can expose thes eintellegently. 13:39:45 here's the set of primitives needed for displaying text: 13:39:46 1. text analysis and segmentation: Unicode operations on text 13:39:47 2. font selection: mapping of text to set of 's 13:39:49 3. text shaping: map ==> positions> 13:39:52 4. font data access: ==> binary table blob 13:39:53 5. line placement: ==> set of lineboxes with 13:39:54 adjusted positions 13:39:55 6. path extraction: glyph ids ==> path data 13:40:01 SteveZ: Basically want I wanted to say is I'm also interested in the line layout aspect of the problem and it's very much related to this kind of thing. I'm assuming it would be part, but I don't know so I wanted to put in that that should be a part of the case. 13:40:27 SteveZ: You want to have line breaking as a piece. It's not per say part of the font, but it's very much involved as a part of the process. 13:41:23 jdaggett: I think there are a lot of use cases people talk about and they take different parts of the problem. I just dumped in what I put on the list about hte different primitives. I don't think so many people are interested in doing shaping. I think what people want to do is the line breaking on this. Given these are the glyphs and the advances, how will I break lines. 13:41:44 jdaggett: So how do we provide the information and how do I feed this back into whatever system has been set up? 13:41:55 q? 13:42:00 ack flackr 13:42:04 ack Florian 13:42:17 Florian: I want to go in jdaggett direction and related this to the convo with franremy earlier with the tension of trying to do things good for use cases and trying to expose the underlying model. 13:42:48 Florian: Fewer people have an underlying model of the font pipeline in this room, but I think we should be taking the same approach. 13:43:00 Rossen: Also it differs between impl. 13:43:12 q+ 13:43:40 [ "the font" - http://www.holoweb.net/~liam/download/font.html has a base character and an acute accent in different fonts in é ] 13:43:46 Florian: In general I'm agreeing with you jdaggett. We also do need to look at the use cases to figure out which underlying concepts are work exposing because it could be with the use cases some people won't care about parts of the underlying model. 13:43:55 ack esprehn 13:43:55 q+ 13:44:25 esprehn: Just to direct the discussion, it would be nice to talk about this in the terms of the houdini model. I think we should prhase this where if we le tyou hook into the line layout, what should we expose and what would be useful. 13:44:50 chrisl: I think the fix up after the fact was janky. I think hooking in is what you want to do. 13:44:56 ack jdaggett 13:45:32 jdaggett: I was going to say is one way we can short cut is provide and API that gives access to the tables of the font. For math layout that's the sanest thing, the level of detail needed for those people is far beyond. 13:46:11 astearns: That sounded crazy to jdaggett of a few months ago when I mentioned it. Having the raw data to do math layout that aligns with any content the browser itself is laying out means you have to align to all the regular layout. 13:46:26 jdaggett: For math out you have to be able to say this box in the box tree, this script manages. 13:46:41 astearns: Even when you have complete control over the box, you might want to align with other boxes. 13:47:06 chrisl: It is a fairly simple thing that people have been asking for. Expose two base lines andline them up. 13:47:41 jdaggett: I don't want to get deep into supporting someone's math layout. It's more efficent for you to create a set of scripts that understand math tables and we can provide the services to allow you to coordinate where that is. 13:48:01 astearns: And in order to do that coordination, when you expose the line boxes or fragments, you also need to give at least the dominant base line. 13:48:15 jdaggett: My point is more we don't want to spend a lot of time making API for math layout. 13:48:17 q? 13:48:42 jdaggett: We want to have a simple thing where we say you make the math tabelsa and we'll help you coordinate where that lines up. 13:48:58 astearns: shane you were talking about the hooks you would need to do your own line layout earlier? 13:49:03 shane: A form of custom layout. 13:49:10 Rossen: But the general area is custom layout. 13:49:22 shane: And you want to leverage the broswers ability to give you line boxes. 13:49:36 Rossen: And in this context is where all of this will become relevent. 13:50:25 iank: Tomorrow with layout we could talk about how line layout works briefly and for a first level of the spec what is the bare min we could ship with that API and be useful. We won't be able to spec everything in the first level, so what is the bare minimum 13:51:12 Rossen: Andto refocus the convo here, because it's still about font snad font metrics. Since last F2F you said you would go and spec all the things you are requirired in terms of font and line metrics. Do we have anything written up in terms of what we're referring to? 13:51:52 astearns: A minimum set of things, not all. We shoul dhave a min set that fit reality and show where the data is coming from and allow for extensions and hooks that might be needed in the future, but start with something as small as possible so we don't get into a morass. 13:52:07 astearns: So far all I've got is the e-mail exchanges, but we can take those and this convo... 13:52:28 chrisl: At some point it became clear we needed more conversation here. You clearly need both. 13:53:05 ojan: Can I prop as a part of custom layout we have a really barely baked custom layout that we can present and maybe we could figure out how this and that work together. 13:53:42 ChrisL has joined #houdini 13:54:10 s/chrisl/ChrisL/ 13:54:21 Rossen: chris, do you feel you've had enough discussion on this topic? You have some other topics today. It seems this is a good and useful discussion after we discuss layout. If you're okay we can pull the custom layout topic now and go from there. 13:55:07 Rossen: And then we'll swap pagination to tomorrow. If sounds like the current topic are going in tangents because there are two sets of assumptions. 13:55:23 Topic: Custom layouts 13:55:30 mic? 13:55:56 iank: I wanted to get one thing out of the way for box layout, but we can do line layout. 13:56:53 iank: one thing this is very much box layout, but I wanted to start a discussion on what is a min viable set of features we can do for an algo. I sent this to the list in the hope that people would read it and come up with suggestions. 13:57:55 iank: Basically what we'd like to do if do what flex and grid do for a lot of it. So remove all the complexity of intruding floats and collapising margins. Blockify all the children as well. If we move to where you can layout children we'll need a flag later. You can't reorder the dom tree like flex. 13:58:24 Rossen: So if I want a custom layout myself with a float layout with line around I cant do it? 13:58:31 TabAtkins: You do it yourself with -- something. 13:58:48 Rossen: modeling all custom layout types after there are specific layout types is more restrictive. 13:59:15 johanneswilm has joined #houdini 13:59:43 TabAtkins: It works for 1/3 of the CSS layout and also tables. And a number of other layout systems are comfortable in these. A bunch can be done, you can't do block layout. For simplistic v1 making sure we can optimize, this should be suffienct for a lot of use cases. 14:00:21 iank: your direct children and not all the way down the tree is another initial constraint. 14:00:29 iank: I also missed abspos is metricly handled. 14:00:39 Rossen: So sim to floats? 14:00:53 iank: If you abspos a child of a custom layout, it works on flex. 14:01:56 Rossen: If I want to create a custom layout which handles all the first level children which also includes all the abspos items...I may not have control over the prop of the children, but I still want to process and layout them in a uniform way. I should be able to position and size. THe abspos becomes transparent is loss for me. 14:02:33 ojan: I pictured this what wewould have a sep phase for position. So there's a sep call back for when you do poisition. That didn't seem nec for v1. 14:02:47 Florian: If we're thinking of the abspos children of the grid that you put in the slot, you need v2? 14:03:00 Rossen: So if I impl grid I have to position abspos on thegrid. 14:03:17 Rossen: I think the limitation you have is somewhat artificial for the abspos 14:03:33 Florian: For abspos you don't need full control if you can give it custom containing block. 14:03:39 dbaron: can you zoom the camera out to the room? 14:03:42 ojan: You need some API and at the moment there isn't one. 14:04:00 Rossen: If you're at the level where an abspos icon is positioned you should be able to. 14:04:12 ojan: I don't think it's too hard to extend, we wanted to jsut stay focused. 14:04:22 TabAtkins: I think we should by default treat them as out of flow. 14:04:35 plinss: There's aspects of abspos where you need to know where this hit. 14:04:47 plinss: The custom layout should know where to place this. 14:05:30 TabAtkins: Static pos is det. byt he parent of the abspos element. If you havea custom layout container with an abspos child, that container sets it's static pos. We can be simple for now with 0,0 or we can extend later. We can drop an issue now. 14:05:55 dbaron: It seems like there are three different things. 14:06:16 dbaron: Taking over static pos of something that's abspos means ignoring it and placing the other children which is different. 14:06:34 ojan: I think forcing things to be static pos is reasonable, but I worry authors will be immediatly unhappy with it. 14:07:07 Rossen: Layout is about positining and sizing. I"m going to position however I want. When we're givign someone else the layout, we're giving them all the problem space. 14:07:10 ojan: I'm sold. 14:07:38 dbaron: The flip side is in our own engine we used to do that and we didn't get abspos right for most things until we switched to where abspos as applied to everything at a general level. 14:07:42 TabAtkins: I agree. 14:08:11 Florian: I don'tthink we should take over abspos. We may want to be abspos aware. You may want to layout within and let the normal browser take over. 14:08:15 ojan: Grandshild? 14:08:39 Rossen: Once I do layout on the child, one of the return thigns is a collection of what I found that you should layout for me. You have one more item you have to layou t. 14:08:49 ojan: But why do the positin static thing at all. 14:09:25 Rossen: This is the way it works in our impl. You layout an itema and they give you back a bag of thigns that was found somewhere else in the tree and you have to decide do I take care of this or do I move this up. 14:09:49 Rossen: As part of when you discover the abspos, you have to figure out the static position and set it up. 14:09:55 Rossen: I think we're going on a tanget. 14:10:03 ojan: This is an open issue and we need to work on it. 14:10:13 liam: The interaction between this and fragments? 14:10:49 TabAtkins: Flexboxa nd grid turn off everything that could cause fragementation. It's not explicitly clear about it and we should generalize the language a bit more. 14:10:55 liam: It's a big limitation, but it's fine. 14:11:04 iank: Other initial thoughts so far? 14:11:59 iank: What we're thinking for that basic API for this, and this is writting in the doc somewhere, is have a class like API with three calls. Third is do your layout call where you go past a whole bunch of constraints and then you can traverse down your children. 14:12:18 iank: Things like if you are responsible for your children or they for you is osmething we haven't figured out. 14:13:35 https://docs.google.com/document/d/1nYeyLuhFf_Y5No11rsMcAQBFbKcPNQW0DQHV1G4r4uI/edit#heading=h.gycgwg8x982t 14:14:36 dael_ has joined #houdini 14:14:51 iank: This is an example of the layout. 14:15:02 ojan: This isn't the polished end result. This is pseudo code. 14:15:08 iank: This is your current layout mode. 14:15:16 Rossen: So given a fragment.... 14:15:30 iank: This is you basically. 'node' could be 'this' 14:15:54 iank: This is where things get more vague is layout. What we have in this version of the API, you get past a bag on constraints. 14:16:26 iank: You could mention a world where you want a width constraint where flexbox has fixed you to a size. You can set constraints so saying you must be this wdith or up to this width. 14:16:40 iank: In this version the child will resolve its own height from the constraints. 14:17:22 ojan: To clarify, the thing we're picturing is you pass in everything that is an input to layout and everything that comes out is an output and you don't have access to anything else. 14:17:33 ojan: Among the inputs would be your list of children. 14:18:05 ojan: Presumibly with positioning your list of positioning dependents would come out. 14:18:22 plinss: So that implies that all layout of the children would happen in the same marker. 14:18:56 ojan: Correct. We considered a promise-based API and it was 20x slower. Some of that could be improved, but I doubt all of it. I think promised based is too expensive. 14:19:14 plinss: If you have children and they can't lay out in paralell... 14:19:25 iank: There is a version I considered where you give a list of children to layout now. 14:19:37 plinss: It doesn't have to be a promise per child. 14:19:51 shane: Doesn't ahve to be a promise at all. It could sit and wait until the layout is done. 14:20:15 plinss: If you're claling each child's layout in a loop, if you're telling the first child to wait you're going to block. 14:20:55 Rossen: Your point is valid. That you're with such API you're restricting sync layout. So getting children ready out of order will make for tricky layout. You can't position block c before you have a and b. 14:21:18 plinss: But that's how layout has worked for the last 10 years, I'm talk about the next 10 years. 14:21:31 plinss: One person at least is working on parallel layout. 14:22:23 plinss: When we started this we don't want to bake the existing algo into these APIs. I accept that when you want to layout a custom block you have to let the children layout. et's explore tweaking. Instead of calling individual children, here's an opporunity to layout all my children, I'll wait until they're all done. 14:22:53 SimonSapin: The reason this algo has to be sequention is this function is responsible for layouts on the children and doing recursion. 14:24:04 SimonSapin: If we remove the responsibility from the enige. Before and after would be two different callback. So if you do sequentially, I'm starting to have this, you have the poss. to do something here. Once you have the children you can do something after. That's sequential and can be rewritten. After we're done with one node we can all the children and the parent together and once they're done we do the second callback 14:24:26 TabAtkins: So take this exact also and in the line that says child.layout you can split that into two. 14:24:40 ojan: We considered this but it doesn't work for some layout algo. Flexbox needs to do two pass. 14:25:07 Rossen: You still could. YOu have to reset the context for the children and lay them out again and you get a new set of results. You may want another pass. 14:25:31 plinss: IN that scenario you may want to avoid if two differen guys are passing over the chidlren we don't do four passes. 14:25:45 astearns: And if you want to do flexbox with this you have to give the position of the first dom. baseline. 14:25:49 dbaron: How does servo do it? 14:26:12 SimonSapin: I'm not sure we do it yet. Everything we do is one pass and we have different callbacks. 14:26:45 TabAtkins: We know how to pause a function and resume it later. They're called generators. The functionaly exists. We can say layout children is a functionality you can invoke. 14:26:49 esprehn: Generators are agist 14:26:55 TabAtkins: This is a top level function 14:27:01 esprehn: It's a member of the layout class 14:27:07 TabAtkins: It's directly called by the OS 14:27:28 TabAtkins: The question is do we need to limit the number of children are layed out. 14:27:36 shane: Why don't we do both and let the author choose. 14:28:05 TabAtkins: We would want to make sure the ergonomics are such that laying out all your children all at once is the obvious thing to do. 14:28:26 Rossen: In this context, can you jump to line layout? I'm afraid jdaggett Is past his bed time. 14:28:38 iank: This is less baked. 14:29:10 https://docs.google.com/document/d/1htU9IM1aJGl2_mFFSg0_2P_wvBEPeHLU424RzyhiOsE/edit?usp=sharing 14:30:47 iank: The core of this is you've got linebox and it how its bounds and baselines which can be bikeshedded. Ignore the promises for a second. Basically you have a you can say to your content okay, give me a line box up to a point where it will break. So it can be give me a line box for the next word or next script boundry. 14:30:55 iank: Or element boundry. 14:31:16 iank: Given your layout mode and the type of breaks, you can find a list of breaks. You can then split them upinto line boxes. 14:31:58 iank: It's measureRange and it's got your children. ON your layout you can render a linebox. 14:32:03 esprehn: This will all get better names. 14:32:17 iank: Render is place, effectively. 14:32:36 iank: Once you've grabbed your line box, you modify the bounds and place it. 14:32:45 shane: We need to split the top-left from the height. 14:33:11 ojan: The core is there's a measure function that takes a wdith, does the segmentation, and you get back boxes taht could have the font metric apis 14:34:19 astearns: I just added a comment to the first bit. YOu want to change hanging baseline to dominant baseline. The rest you have to define whre you're getting those values because a line doesn't have a sing ascent. Are you giving a first one for the fist glyph, a max for the line. All those things you need to define where they come from. If that's just he definition or encoded, I'm not sure. 14:34:29 can't hear... 14:36:01 shane: What's important here is not the set of font metrics, this is a place holder until we ask experts. You're measuring text into a box for a brower. All you can say is how wide the box is and that sort of thing, you get a box back and you can place it or throw it out. It gives you enough power to do similar content to what's out there as well as all kinds of interesting things. 14:36:20 Rossen: In your examples, where are the boxes generated? 14:37:27 Rossen: One of the things line layout does is it takes, lets assume the input is a some kind of text, it will have to generate a whole bunch of boxes becides figure out where it goes. Is the only hook you're invisioning is the only thing I want you to do is position the next thign witht he box you're giving me. 14:37:43 Rossen: Or do you have access to a subset of dom with all the prop and ou decide how to generate the box. 14:38:00 iank: In this API we were invisioning that you're just laying out text. We're not doing splitting of boxes. It's jsut text. 14:38:08 ojan: Inclduing inlines as well. 14:38:33 ojan: The first version ages ago way plain text but that was not useful 14:38:43 shane: You can't do plain ltext because you need to do inline blocks. 14:38:49 ojan: That's what I was saying 14:39:25 astearns: You have a to do saying you have to have a range. So you give a width and the broswer gives you a linebox that tells you waht would fit, can you say here's a linebox what fits? 14:39:42 ojan: THe expert isn't here, but I think he was picturing something you could do iteritively. 14:39:55 q+ 14:40:34 Rossen: Let's forget about text. We're working with generating boxes that are fragemented. Instead of arranging blocks one after another, all I have is divs. I have to split at some point and I want to split a div into two boxes. Explain how that works 14:40:54 ojan: I don't have a good explination and I was hoping for your input. In Blink codebase line layout and box are different. 14:41:24 Rossen: I'm asking you to provoke the convo, in our case our boxes if they're for inline or blocks or whateevr are always done in the same way. THe result of layout is a box. 14:41:34 ojan: I want to have this convo, I think it would result in a better API. 14:41:38 q? 14:41:44 q? 14:42:02 jdaggett, dbaron was waiting before you 14:42:15 esprehn: I agree. We thought about this in terms of our impl in terms of disjointed layout. It seems like instead of blockifying the children you could do fragementation-like. We should have taht discussion. 14:42:37 Rossen: kk 14:43:18 dbaron: A few things we need out of this API. One thing is you need, if you take a range and try and build a linebox, you first want to know how tall. That was part of the process of deciding if you want to reject that placement. You tried placing a line at a width, it has a height, it intersects, you try again. 14:44:09 dbaron: Another thing you need to know is about what is in the line block. If you're doing things like floats or margin notes attached to things in the line block, you need ot know what it's attached to. So if you have margin notes you wantt o attach off to the side...maybe that's not this API. 14:44:19 Rossen: Even abspos items attached to the lines. 14:44:27 SteveZ: You're assuming an anchor of some kind. 14:44:45 dbaron: That was what I wanted to point out. I'll have more comments when there's more details 14:44:46 ack jdagg 14:45:23 jdaggett: A quick point. I don't think you should assume text layout works in an interative fashion. That's how they commonly work, but that's not the ideal. There's algo tht take a whole paragraph. 14:45:41 Rossen: Yes. We don't want to prevent that and I don't think this would. I think we're trying to set he framing of how to think about it. 14:46:02 astearns: So you get a box and you place or reject and that would preclude getting a bunch of boxes and accept or preclude. 14:46:20 Rossen: That was one suggestion, but I don't htink we're at a point where we can see it's clearly better. 14:47:18 Rossen: Let's run witht he assumption that custom layout has happened and we do have the linebox. I know this is getting late for jdaggett and there are a whole bunch of things we should talk on this and perhaps we can have a breakout, but I want to move back to the people who wanted to talk about all the prop that the linebox would how now that you have it somehow. 14:47:45 Topic: font metrics, lineboxes, and thier interations. 14:47:52 MozParis has joined #houdini 14:48:43 astearns: You have a start of things that you might want to say about a line blox that could effect its positioning. ONce it creates a line box you need to place it somewhere. What's here with a dom. baseline with ascent and descent it's the start of the information you need. jdaggett do you think this is the approp. place to put these? 14:49:17 astearns: It seems to me once you have a linebox you have the dominant baseline and you need to know where it is in the height of the box to know where to place it when you're doing baseline grid 14:49:50 astearns: Or if you wanted to impl a varient system that edalt with lines going top of cap to top of cap you mgiht need cap height over the line box to determine where to place relative to the other. 14:50:02 Florian: What is the cap height of the linebox rather than the glyph? 14:50:06 astearns: That's a good question. 14:50:52 jdaggett: This is the piont I was making on the list we need to sep metrics that are defined by the line and metrics that are constants in a given font. Looking at the perspective of the line there are a bunch of metrics assocaitaed with a give font and for the line you have an overall metric. 14:51:32 astearns: To proceed at this level we should ensure that the linebox has a prototype level. I don't know if for the first iteration we need more than dom. baseline. 14:51:40 SteveZ: You want to know which baseline is the dom. one. 14:51:45 astearns: That's more important. 14:51:57 ChrisL: Which was was used and how it came across that is more important. 14:52:14 SteveZ: If you're doing initial caps from non latin languages you need more information than that. 14:53:04 astearns: We need to have, we should start with a min set of typographic measures that make sense but leave things open for extensions. I think baseline grid should be level 1. I don't think a different letting system is. 14:53:10 jdaggett: What do you mean? 14:53:21 s/letting/leading/ 14:54:12 astearns: Roman scripts everywhere outside the web deals with stacking differently and non Roman do on the web. I think that aligning the dominant baseline should be a requirment but leading is a futher future requirement. 14:54:50 esprehn: This seems reasonable, it seems like we need to get a bunch of people together in a breakout to build something. We use to have linebox grid. I think webkit still has it. I think it's a useful thing to have. 14:55:07 jdaggett: It feels weird to talk about baseline grid as v1 when it seems like you can't do much in a single line. 14:55:33 esprehn: I don't think we'll know what we can do in v1 until we try. This is so rough we can't tell. We should set out with some goals and try. 14:55:46 jdaggett: We need a sketch out model and decide what will be exposed in v1 first. 14:55:56 astearns: Line breaking is part of the model. We're trying to spec that one piece. 14:56:35 Rossen: And before you hav line box you won't have dom. baseline. We are going to spec in a logical way so they're useful once they come up. I'm not looking to expose alphbetical baseline on something you can't even get. 14:56:44 jdaggett: It seems like a dumbed down model. 14:56:55 Rossen: Which is prob okay for the people giong to use it at first. 14:56:58 jdaggett: I'm skeptical. 14:57:54 Rossen: Let's be realistic. The people who want to work on our code bases work on our code bases. We don't want to expose every since thing. In here we are trying to sketch a model which is an intersection of all these impl but is useful for peple that will use the dumb down objects as something better than what's out there today. 14:58:26 Rossen: I think we sympathize with your concerns and the other impl have just as much concerns because that's work for us, so I think the overall feedback is we hear you. 14:58:49 jdaggett: I think we really need to think about underlying models of the processes we're trying to expose before we say we want to support baseline grids. 14:59:37 TabAtkins: jdaggett doesn't want this to be one of those solely use case driven designs where we figure out here's the one use case and we solved that. but we like having leading use cases that are moderatly complex that show we have some useful things. 14:59:44 astearns: The leading use case is the start. 14:59:46 q+ 15:00:29 TabAtkins: Without a leading use case it's very easy to design something that it could have been very easy to fix. But once you have that leading use case we can figure out ways to make everything consistant. Baseline grids seems to be right about the level of complexity for v1. 15:00:36 Florian: But the goal of v1 is not that. 15:01:03 TabAtkins: Re-impl flexbox is a leading use case for v1. WE can get to a well known point that is useful. 15:01:38 Florian: For CSS we have a well doc, well understood for what's going on. I don't think we have the same level of understanding for the font pipeline and having a high level overview of that would be helpful. 15:01:46 TabAtkins: This doesn't need to be strictly useful. 15:01:56 heycam: Can I try restrating jdaggett concern? 15:02:15 s/strictly useful/strictly ordered; this isn't a waterfall design process, it's back and forth/ 15:02:36 heycam: What I'm hearing is there's an existing model for how glyphs have their metrics and if we don't writing down what their model is there's a chance we'll expose things that aren't consistant with the actual underlying model. 15:02:36 s/to design something/to design something worthless/ 15:02:42 jdaggett: Yeah. That's what I was saying. 15:03:19 SteveZ: For clarification. I agree whatever we produce ought to be impl in terms of those underlying primitives, but the user might not need those and we may present a simplified model. Is that okay? 15:03:37 jdaggett: NO. You're creating an aritifical model and that's something you'll have to support forever. 15:03:58 SteveZ: I was saying that I want to simplify the model that the user saw and not give him all the details at a lower level. It has to be consistant. 15:04:55 jdaggett: Desc and exposing the primitives are two sep things. We have to first define the primitives. To be able to get this type of info that you want you need to have information from this specific object. Then you can talk about how will we present this. A lot of what I'm hearing is people take stuff associated with a line and say it's with a font. 15:05:08 Rossen: Is this something that you want to contribute to and propose that kind of model? 15:05:21 jdaggett: I posted something on the list and dumped it into ICR. I can flesh it out more. 15:05:43 Rossen: That's useful. By the tiem you get to user expose those you may decide it's too much info and we shouldn't expose all these things. 15:05:51 jdaggett: You have to understand the model to know what ot expose. 15:06:31 Florian: I've seen dbaron make a presentation about how a layout engine works, we need something similar for the font layout model. Having that is something I would like to udnerstand. If it's video, slideshow, text, that's irrelivant. 15:07:22 Rossen: It sounds like there needs to be more work done on further defining the model. Going back to the current topic, is there anything else we want to discuss or should we take that after we have more knowledge. I'm looking at ChrisL and astearns and jdaggett 15:07:28 SteveZ: I think it's ready to go offline. 15:07:48 Rossen: So jdaggett I think this is going to be all for font and lineboxes. The next this on the agenda is the deadrange. 15:07:58 jdaggett: What is that? 15:08:07 I was referring to this presentation (or its variants): https://www.youtube.com/watch?v=a2_6bGNZ7bA I'd like to see something similar for the font level of things 15:08:21 Rossen: It's there to discuss what it is. It's supposed ot be quick. 15:09:27 Dinner: L’arbre à Canelle, 57 passage des Panoramas, 7pm 15:10:24 ScribeNick: TabAtkins 15:10:39 ChrisL: In the prev discussion, there was a mention of "need a range here". How's that used? 15:10:51 ojan: IT's half-baked. You say what range you want... 15:11:06 ChrisL: Oh so you don't declare ranges yourself, you set up the linebox and it tells you what range fits in there? 15:11:10 ojan: Maybe. Half-baked 15:11:20 Line 4 metro closure: http://www.ratp.fr/fr/ratp/v_133187/metro-ligne-4-interruption-partielle-de-trafic-du-27-au-30-aout-2015/ 15:11:23 ChrisL: There was a description of a lighter-weight thing-- 15:11:50 esprehn: The Range in this has nothing to do with DOMRange. This is in a separate scripting context, and this RAnge is a disjoint concept, unrelated. 15:11:56 esprehn: The spec says "DOMRange", it's just wrong. 15:12:03 ChrisL: Ah, ok. 15:12:13 ChrisL: People didn't like DOMRange. 15:12:24 ChrisL: We informally called the new thing "DeadRange", because it's not live. 15:12:36 ChrisL: I want more clarity in how people saw DeadRanges being produced. 15:12:56 esprehn: In our example, the measurement API returns metrics about spans. The breaking API returns boundaries. 15:13:12 esprehn: So if you wanted the size of the first letter, you'd set up a DeadRange and ask about it. Dont' think that's decribed in this doc. 15:13:43 ChrisL: There's some complications with, for example, bidi. Don't want to have to iterate by chars to know font - prefer larger "block" structure in the line. 15:13:48 jdaggett: That's what impls typically do. 15:13:59 jdaggett: You end up with a single-font span 15:14:13 ChrisL: So when that font matching happens, can it change the segmentation? 15:14:32 jdaggett: In general no. There's some complication with variation selectors, but it's not that important. 15:14:44 esprehn: I don't think we go backwards either. 15:14:59 esprehn: In this API, for first letter, you'd explicitly break off the first letter before calling the breaking API. 15:15:06 ChrisL: So the segmentation isn't done autoamtically there. 15:15:11 esprehn: Correct, you'd insert breaking points. 15:15:21 ChrisL: So is there an idea for how to control that? 15:15:32 esprehn: Don't think there's anything that describes it yet. Interested in fleshing it out with interested parties. 15:15:50 jdaggett: If you really want to expose per-glyph info, it shoudln't be done at a higher level. You should get primitives for the character runs. 15:16:03 ChrisL: Yeah, I wanted per-font level, but the per-glyph is secondary out of that. 15:16:23 jdaggett: What you need for line-breaking is the advance info, which is there in the font level. 15:16:36 ChrisL: Yeah, and Bruce was talking about balanced fit text. 15:16:51 jdaggett: That requires an API that lets you take an arbitrary set of glyphs spans, and put them into a linebox. 15:16:55 ChrisL: Right. 15:17:08 ChrisL: I think the major confusion was that it had nothing to do with DOMRange. 15:17:19 Topic: Buildling blocks for pagination 15:17:59 q+ 15:18:04 dauwhe: AS I mentioned earlier in CSS, the pub community has hopes that if brwoser aren't natively implementing pagination, that they'd at least have hooks to let them implement it themselves. 15:18:10 dauwhe: This is a big major use-case for them. 15:18:16 q- 15:18:28 dauwhe: And getting fragment information (look at an element, determine what fragment it's in) is also important, for page numbers, indexes, etc. 15:18:52 did someone ack me? I cant hear 15:18:53 dauwhe: That's all. 15:19:02 you'll be next 15:19:11 Q 15:19:25 johanneswilm: AS someone who's implemented that stuff in JS, the most important info is "if I have text, where will the linebreak happen?". If I have that in a way that I don't have to draw it and measure it and take it back out again, that will help a lot. 15:19:30 q+ 15:20:06 johanneswilm: Both line breaks and the height of the lines - hacks today use multicol to separate things into a "one page" chunk, then manually breaks it in the DOM at that point. 15:20:09 johanneswilm: Not cheap. 15:20:36 TabAtkins: I think both of those are the v1 features we're hoping to expose 15:20:37 TabAtkins: I think both of those are the v1 features we want to expose. 15:20:55 bkardell_: I dunno how Apple does this, but since we talked about building blocks of pagination... 15:21:07 https://elements.polymer-project.org/elements/iron-pages 15:21:08 bkardell_: I'm wondering where that falls in fragmenting visible bits that are pagelike 15:21:23 bkardell_: For example, Polymer has concept of "pages", for making tabs or such 15:21:30 bkardell_: The "page", then different subviews. 15:21:37 bkardell_: Would our building blocks satisfy that? 15:21:40 q- 15:21:47 nikos has joined #houdini 15:22:11 Rossen: I'm hoping that if we expose enough in the box tree, in terms of boxes and fragment breaks, we'll never have to talk about pagination again. 15:22:28 Rossen: It's the application devs who'll deal with it. 15:23:01 Rossen: These are strong words, and we're far from it, but in a world where we have a box tree, and each box has a fragment break which is self descriptive, with custom layout you'll figure out how the fragment will continue to the next fragmentainer. 15:23:35 Rossen: To further your point about "don't forget about the foudnation", the underlying statement is "don't forget to add fragment breaks everywhere", and let the application deal with it. 15:23:48 Florian: Having these in combo with the "ground" element (top-level) lets the browser deal with it too. 15:23:57 SteveZ: What Rossen said. 15:24:32 SteveZ: One other piece - the keeping of flows and positions in them, which is a piece of the fragment, is very important. More than just boxes, it's measuring where you are in streams of content. 15:24:51 Rossen: Right, every fragment is self-descriptive. It's in some fragmentainer, has a position and size, and a ref to what follows next. 15:24:57 Rossen: You decide what happens to the next fragment. 15:25:14 ack 15:25:20 Rossen: If I decide to switch to page 400 of War and Peace, I dont' need to diplay the previous 399. 15:25:35 Rossen: And Regions is basically boxes with fragment breaks. 15:25:53 Rossen: When you're able to create fragments yourself, you don't need them. 15:26:46 johanneswilm: [asks about where in the presented spec these were] 15:26:56 TabAtkins: Not in the spec yet, we just talked about them; it's too early now. 15:27:57 Topic: Spec management 15:28:13 ScribeNick: dael 15:28:20 Rossen: Let's start with which wiki 15:29:31 q+ 15:29:36 shane: We can continue to use the wiki on the csshoudini.org which until recently was member only for writing, though anyone could read. The other option is to move to the wiki gon github. I kind of prefer that. The specs are tehre and we're lodging issues there. The only thing not there would be meeting planning. So I wanted to sugest we open the wiki on github 15:30:07 plinss: we opened it recently. We can set the access to any level we want to. Personally I think there's value to owning own data. 15:30:19 TabAtkins: Only arguement I have for github is better wiki syntax. 15:30:35 ojan: We have the concrete thing of people not being able to figure out how to add to the wiki, but they know github. 15:30:48 Rossen: As long as meeting planning is priavte. 15:30:51 ack SteveZ 15:31:39 ChrisL: What I would like is not to have things spread all over so tht I have to spend a lot of time looking for things. Wikis are bad for that because they're bad for dfinding changes. But as long as it's all in the same place it's fine. As long as it doesn't include people spamming and the like. 15:31:56 shane: Our issues list is on github and we can link directly too issues. 15:32:15 tantek: It sounds like you're saying as long as someone keeps the sidewalks clean you're okayw ith anyone on the web. 15:32:47 ChrisL: I've seen a much of wikis that were well mantained and then had to close down for the spam. BUt as long as it works I don't care and being able to auto link is good. 15:33:02 Florian: Should we ever change our mind we can export out? 15:33:05 SimonSapin: Yes. 15:33:18 Rossen: To be clear we are keepign the wiki for meeting planning. 15:33:41 plinss: I'm sort of opposed to that. I don't want to have n wikis. I don't care where, but I just want one. 15:33:54 TabAtkins: What's the reason for putting it on a wiki? It's publicly viewable. 15:34:01 Florian: Security by obscrity. 15:34:33 Rossen: The prop is we find a way to restrict the planning section to memebers only, can we move to github wiki. 15:35:05 TabAtkins: I don't understand what's wrong with the public having editing. Anyone outside the group editing the planning is a spammer and we treat it that way. 15:35:30 plinss: So you need to action someone to move the data from the wiki. 15:35:38 shane: plinss you need to unlock the wiki. 15:35:53 plinss: and you'll move the wiki over? 15:35:55 shane: Yeah. 15:36:12 q? 15:36:36 plinss: The only access control is people with push access. There's no fine grain control over the wiki. 15:36:50 TabAtkins: Worst case we create a sep repo for houdini planning. 15:37:01 SimonSapin: Where are we doing issue tracking? 15:37:04 Rossen: Next topic. 15:37:42 bkardell_: If you type in the main domain you redirect to wiki.etc. If we're doing wiki can we use a central page and do a nicer what this is? 15:37:51 TabAtkins: Sounds like you want to design it. 15:37:53 bkardell_: nope. 15:38:09 dauwhe: The messaging about the project is important. 15:38:28 gregwhitworth: shane and I had talked about writing language for the project. 15:38:40 ChrisL has joined #houdini 15:38:46 Rossen: There's an action for us to write the roadmap and tht wiki would be the best place to do it. 15:39:18 Topic: issue tracking mailing list vs github 15:40:03 Florian: In the CSS WG which has a longer history, everyting goes through the mailing list. This is the only place to discuss things. An alternative approach is they all must be in github issues and gets forwarded to the ML and you don't discuss in the ML. 15:40:36 g+ 15:40:42 q+ 15:40:57 Florian: So are we in a github centric or a ML centric world. If you can get your github issues via e-mail and reply to the e-mail, you can close things when they're done and you can find the thigns that aren't closed yet. This is also useful in long discussions. 15:41:09 TabAtkins: It also prevent thread breaking. 15:41:22 ack bkardell_ 15:41:27 q- 15:41:59 johanneswilm: one thing related that I saw in CSS WG e-mail solution vs github, if things are old in the ML that thing may be lost and you have to go through the mail archive. But on github it's easy to see what's open. 15:42:21 Florian: IN the mail load there are ways around that. you can download the archieve which is osmething I did recently for CSS UI. It's not plesent. 15:42:27 ack ojan 15:42:42 ojan: You said you'd be opposed to just on github? Is that becaseu everyone needs to see every issue or you want to? 15:42:48 Florian: I want to see and I want offline cpaability. 15:43:09 ojan: You can subscribe to notifications for the whole repo. We don't have to mandate they go to the list. 15:43:31 TabAtkins: The reason why using hte ML is halfway when you set notifications you get e-mails on every message. 15:43:38 SimonSapin: If you watch the repo you get everything. 15:43:46 astearns: Is there a way to get the archive. 15:43:48 plinss: No. 15:43:59 astearns: That's why it should all go to the ML. 15:44:07 TabAtkins: Thread starts seems more useful. 15:44:58 dbaron: The otherp poos if you have a second ML. The more general thing, the everything goes to www-style makes it hard to manage reading it. When trying to deal with editing transitions I have to show I replied and I'm dumping crap in. 15:45:29 ojan: That's why I was putting it in there. This whole publish HTML falls into a point where people are ignoring them. I was supportive of the www-style concept, but it's not working in practice. 15:45:41 TabAtkins: That's why the dom solution of just send notifications of a new thread works. 15:45:58 dbaron: There are issues I sent to www-style where that's a waste because only me and the editor care. 15:46:21 ojan: If you can about that you can set that up on the github and people can subscribe to the mailing list. 15:46:31 Florian: The existing ML, what do we deal with? 15:46:39 ojan: There are discussions you want a ML for. 15:47:13 dbaron: There are issues you want the whole group to be aware of. it's worth raising those to the ML to say these are things you want to pay attention to. We can use that when we think it is important. 15:47:26 greg: and you only get the notifications for the things you're editing. 15:48:02 SimonSapin: Question on what you said. In that case where you want to see something, do you post it on github issues and you post it to the ML or do yo just on github? 15:48:24 dbaron: Depends on what you want to do. If you say hey I made this massive change or something needs to be discussed. 15:48:40 TabAtkins: We can set up a github bot that sets up a tag and auto forwards to the ML 15:48:54 dbaron: That has the danger of not enough context. WE might want a notification as to why. 15:49:08 TabAtkins: We play with the simpliest. Everything on github issues and you e-mail the list if you want. 15:49:29 Florian: We then have an additional ML that gets everything on github for accessibility and usability? 15:49:38 TabAtkins: I'm happy to make a public houdini issues mailing list. 15:50:15 Florian: I'm worried if you just do github by default, when you're new you can't start be gettign a sense of everything and filter. When you sub to www-style you notice htings. 15:50:33 TabAtkins: It's onboarding new memeber appropraitely and making sure information is easily and widely displayed. 15:50:50 dauwhe: The firehose is not the optimal onboarding. 15:50:57 Florian: It was for me, but i'll admit I'm odd 15:51:44 TabAtkins: So CSS Houdini strat is you open and discuss issues on github If you need something to have wide notice you send an e-mail and we set up a mailing list with the thread. 15:52:00 franremy: Maybe we have something that says what threads are getting more attention? 15:52:06 TabAtkins: If there are robots, let's do that. 15:52:15 Florian: Also this is a good experiment for the CSS WG. 15:52:31 Florian: So if we move to that model I can set up github to mail me about everything? 15:52:34 TabAtkins: Yes. 15:52:39 johanneswilm has joined #houdini 15:52:41 TabAtkins: You can subscribe to the whole thing. 15:53:41 TabAtkins: All houdini discussion by default takes place on github issues. We mail to the public ML whenwe have good reason to req. the whole group to look at something. We set up an issues mailing list that gets the start of each issue. WE explore more robots for better notifications 15:54:04 dbaron: Using it with a single repo means I get all the notifications. 15:54:24 Bert: Can you open issues by e-mail? 15:54:28 TabAtkins: I'm pretty sure you can. 15:54:40 Bert: Okay. 15:55:07 Bert: I want to know what I sent and my e-mail client is very good at remembering what I did. 15:55:21 Rossen: Object? 15:55:30 SimonSapin: Github doesn't support that. 15:55:33 TabAtkins: We can set up a bot. 15:55:45 Rossen: Any objections? 15:55:49 RESOLVED: All houdini discussion by default takes place on github issues. We mail to the public ML whenwe have good reason to req. the whole group to look at something. We set up an issues mailing list that gets the start of each issue. WE explore more robots for better notifications 15:56:02 TabAtkins: One repo for houdini instead of one per spec. 15:56:34 TabAtkins: I understand the arguements for one per spec. It means you can watch what you want to, but you can't firehose. And it's clumsier if you try and do wide editing. 15:56:54 greg: You can do a w3c team and you're auto subscribed. If you're an editor you would auto sign up for those. 15:57:07 hober: We're a part of the W3C org. 15:57:20 TabAtkins: But we don't want every w3c. But the functionality is there. 15:57:23 shane: We can make a team. 15:57:44 Florian: If we do this, setting up a new spec, how do you sync that to the server that serves the rendered spec? 15:57:51 I find splitting the repo for issue tracking somewhat sad, since I think a single repo is better from a VCS perspective, but github's issue tracking really encourages smaller repos. 15:58:08 TabAtkins: There are various ways. There's nice command line tools. It's as easy as a git init. 15:58:23 Florian: I mean, the server where you read the spec. 15:58:40 Florian: It can't sjut do ls in the repo. It needs to query github about new repos. 15:58:53 TabAtkins: We can bot it or those steps are infrequent and not hard to doc. 15:59:19 gregwhitworth has joined #houdini 15:59:21 plinss: It's work on my end. That server only serves a single repo so I would need to change that to aggrigate multi repos. 16:00:05 plinss: It's going to be work to set that up. I guess it's in the github API, but I don't know how it will tell a houdini repo. We're also operating under the w3c org. 16:00:18 SimonSapin: W3c has a few hundred repo. Is it useful to havea smaller org? 16:00:23 plinss: One tag we ahve our own. 16:00:32 TabAtkins: And it would mean we have a useful front page for it. 16:00:55 plinss: so we'll have to move everything over. We'll want to make sure we don't break. 16:01:03 TabAtkins: no one should do direct github links. 16:01:03 s/One tag/In the TAG/ 16:01:31 Florian: Another down side is we do move text from one spec to another. That would be lost if we do sep. repos. Personally the down sides are higher. 16:01:33 q+ 16:01:56 TabAtkins: But we have easier history to walk through for each individual spec. Well, through the github API it's find. 16:02:15 TabAtkins: We'll lose some history. I don't consider it a huge deal. 16:02:35 dbaron: I'm okay with trying to keep one bit repo. It's better from VCS. Issue tracking encourages multi. 16:02:51 q? 16:03:03 q- 16:03:03 shane: The issue tracking we can label each issue and that lets you filter. That does mean as SimonSapin said it makes it easier to have an issue across multi specs. 16:03:12 (was going to talk about labels) 16:03:19 SimonSapin: One problem is only org members can set the issue labels 16:03:28 Florian: It means random people filing issues aren't taggin. 16:03:37 TabAtkins: Or the bot has to turn subject lines into labels. 16:03:46 SimonSapin: But multi repos we get that for free. 16:03:58 dbaron: A bot could pull the url out and flag it. 16:04:15 TabAtkins: Lets stick with one repo for now and if it's annoying we can split. 16:04:30 shane: I think a lot of extrnal issues will be I want to do x or y. 16:04:46 SimonSapin: The rush project has a lot of bots. 16:04:54 plinss: He has example bots. 16:05:01 plinss: I have a bot on my server. 16:05:04 s/rush/rust 16:05:32 plinss: I created the CSS houdini team, but I don't have a list of everyone's github ID. 16:05:42 SimonSapin: So have we decided on one repo 16:05:44 Florian: Yes, one. 16:06:19 Rossen: adjourned. 16:06:24 Dinner: L’arbre à Canelle, 57 passage des Panoramas, 7pm 16:07:09 Florian has joined #houdini 16:29:24 johanneswilm has joined #houdini 16:50:53 Florian has joined #houdini 16:57:01 zcorpan has joined #houdini 17:15:29 plinss, you asked to be reminded at this time to go home 19:31:39 zcorpan has joined #houdini 20:14:51 liam has joined #houdini 20:19:21 franremy has joined #houdini 21:40:51 dauwhe has joined #houdini 21:46:45 dauwhe_ has joined #houdini 22:01:10 dauwhe has joined #houdini 22:14:37 johanneswilm has joined #houdini 22:16:03 tantek has joined #houdini 22:23:14 dbaron has joined #houdini 22:39:50 zcorpan has joined #houdini 23:10:59 johanneswilm has joined #houdini