22:15:30 <RRSAgent> RRSAgent has joined #houdini
22:15:30 <RRSAgent> logging to http://www.w3.org/2015/02/06-houdini-irc
22:15:45 <Zakim> Zakim has joined #houdini
22:16:03 <glazou> glazou has joined #houdini
22:16:09 <Rossen_SYD> zakim, this will be CSSHoudini
22:16:09 <Zakim> I do not see a conference matching that name scheduled within the next hour, Rossen_SYD
22:16:15 <glazou> glazou has changed the topic to: https://wiki.css-houdini.org/planning/sydney-2015
22:17:58 <Rossen_SYD> Meeting: CSS Houdini
22:19:28 <dbaron> dbaron has joined #houdini
22:20:21 <dino> dino has joined #houdini
22:22:02 <ChrisL> ChrisL has joined #houdini
22:22:32 <ChrisL> rrsagent, this meeting spans midnight
22:22:47 <ChrisL> zakim, remind us in 8 hours to go home
22:22:47 <Zakim> ok, ChrisL
22:24:41 <SimonSapin> SimonSapin has joined #houdini
22:26:15 <johanneswilm> johanneswilm has joined #houdini
22:29:37 <dino> zakim, remind us in 1 hour why we are here on a weekend
22:29:37 <Zakim> I don't understand the last part of that, dino; about what am I supposed to remind you?
22:30:16 <kwkbtr> kwkbtr has joined #houdini
22:30:22 <rbyers> rbyers has joined #houdini
22:30:26 <astearns> astearns has joined #houdini
22:30:31 <gregwhitworth> gregwhitworth has joined #houdini
22:30:40 <TabAtkins> TabAtkins has joined #houdini
22:30:47 <TabAtkins> ScribeNick: TabAtkins
22:30:51 <shane> dino, remind us in 8 hours to get some drinks
22:31:00 <ChrisL> Zakim End Of Life
22:31:04 <TabAtkins> Rossen_SYD: I've been getting a bunch of emails about HOudini, what's it mean, etc.
22:31:10 <ChrisL> http://www.w3.org/2015/07/zakim.html
22:31:12 <smfr> smfr has joined #houdini
22:31:29 <TabAtkins> Rossen_SYD: I have to recognize and give credit to bkardell for coming up with Houdini.
22:31:44 <TabAtkins> Rossen_SYD: The name comes from us wanting to get away from the magic of CSS, I think he described it.
22:31:50 <ChrisL> Houdini was famous for escaping from small boxes
22:32:33 <TabAtkins> Rossen_SYD: I think we should start with a round of intros, and instead of stating your name and affiliation, would be good to give a short intro about who you are, what your specialty is in the web platform, what your interests/strengths are, and an idea of what you think Houdini should or shouldn't be.
22:32:38 <xidorn> xidorn has joined #houdini
22:32:39 <ChrisL> ChrisL has joined #houdini
22:32:58 <murakami> murakami has joined #houdini
22:33:13 <TabAtkins> Rossen_SYD: I'm Rossen. With MS. Been working on IE for almost 8 years. My daily activies are about the layout and styling subsystems of Trident. Written most of the layout engine twice now.
22:33:27 <TabAtkins> Rossen_SYD: When I started we had one engine, was called HasLayout.  That is no longer.
22:33:42 <TabAtkins> Rossen_SYD: So I"m very familiar with anything to do with layout, at least how we've implemented it.
22:34:03 <TabAtkins> Rossen_SYD: I've also done a lot of modules, like line layout, flex layout, writing modes, etc. Anything with layout.
22:34:48 <TabAtkins> Rossen_SYD: For me, I think the programmability model of the web being tied to elements sucks, and the fact that you can't control what you see is something we can improve on.
22:35:13 <TabAtkins> Rossen_SYD: I'm also interested to see how we can better expose the ways we use to point to things (touch/gesture/etc events).
22:35:58 <TabAtkins> shane: I'm Shane Stephens of Google, working from Sydney on Blink.
22:36:11 <TabAtkins> shane: My team has been ramping up on responsibility for the style engine. WE've had a long-standing interest in style.
22:36:25 <TabAtkins> shane: I have interest in Houdini in three separate areas.
22:36:40 <TabAtkins> shane: 1 is the Extensible Web Manifesto, explaining the platform in terms of primitives.
22:36:48 <TabAtkins> shane: I really believe in that, a lot of other platforms have that, we don't.
22:37:08 <TabAtkins> shane: 2 is talking to product teams in Google and hearing their frsutrations with the web platform, especially when moving from Android or iOS.
22:37:24 <TabAtkins> shane: I think improving the customizability of style/layout can really provide value to people trying to build larger websites.
22:37:57 <TabAtkins> shane: 3 is, through previous work on Web Anim and other CSS things, one of the things we always try to do is polyfill the feature while we're talkinga bout it, it gives useful information on the feature.
22:38:06 <TabAtkins> shane: CSS is one area where polyfilling is really hard, and I think we can help with that.
22:38:25 <TabAtkins> xidorn: I'm Xidorn from Moz.
22:38:34 <TabAtkins> xidorn: I just joined Mox last quarter. I'm working on layout things.
22:38:47 <TabAtkins> dbaron: I'm David Baron from Moz. Been working on Gecko for a long time.
22:39:14 <TabAtkins> dbaron: The main thing I wanna see the TF work on is figuring out how to expose primitives os that developers can *do* a lot of the things that today have to happen in browser engines.
22:39:19 <TabAtkins> dbaron: So essentially polyfilling.
22:39:23 <TabAtkins> dbaron: And do them both correctly and efficiently.
22:39:31 <TabAtkins> dbaron: I think that when we do this it's worth thinkin gabout tradeoffs.
22:39:50 <TabAtkins> dbaron: There are a bunch of things related to user control and future compat, where there are something benefits to not exposing things, and we have to figure out where those tradeoffs are.
22:40:22 <TabAtkins> dbaron: Another area I wanna be careful with is that it's easy to define a set of low-levle primitives and build something else on top of those primitives, but it doesn't mean those *were* the primitives that existed before.
22:40:41 <TabAtkins> dbaron: I worry about defining a set of primitives that matches what one browser engine does and not another, and thus forces one engine to rewrite a lot of things.
22:41:06 <TabAtkins> dbaron: And also the other way - I worry about defining the set of primitives browsers do right now, and locking us out of changing in the future.
22:41:24 <TabAtkins> plinss: I'm Peter Linss from HP.  Also cochair of the TAG. This is actually a joint TF between CSS and the TAG.
22:41:39 <TabAtkins> plinss: The goal here is to add extensibility. CSS has been a big black box of magic since day one.
22:41:55 <TabAtkins> plinss: I echo all of dbaron's concerns, and I get it, but we need to work on this.
22:42:06 <TabAtkins> plinss: I hate form day one that the DOM APIs have conflated the doc and its display, and we need to fix it.
22:42:27 <TabAtkins> ChrisL: I"m Chris Lilley, working on several W3C groups (Fonts, SVG, CSS, TAG).
22:42:38 <TabAtkins> ChrisL: In SVG I was in an early attempt at extensibility, shadow-dom like.
22:42:53 <TabAtkins> ChrisL: So I'm aware of how things can fail, like beautiful-looking form controls that only work on one platform.
22:43:12 <TabAtkins> ChrisL: And how things can look good as long as you're using English, and break as soon as you use other characters.
22:43:29 <TabAtkins> ChrisL: I like what david said about not fossilizing a particular stage of webdev or a particular browser's internals.
22:44:00 <TabAtkins> glazou: I'm Daniel Glazman, owner of Disruptive Innovations, member of W3C, co-chair of CSS.
22:44:19 <TabAtkins> glazou: I've been involved with WYSIWYG editors for years. I'm probably the heaviest user of the CSSOM you could find.
22:44:29 <TabAtkins> glazou: I'm interested in Houdini because of things I"m missing in my life.
22:44:35 <SteveZ> SteveZ has joined #houdini
22:44:44 <TabAtkins> glazou: I'm looking at a 2002 doc I wrote about CSS Editor Objec tmodel, extending the parser/etc.
22:44:55 <TabAtkins> glazou: I miss it so much I had to write a new parser and OM for my editor.
22:44:58 <ChrisL> s/CSS, TAG/CSS. ex-TAG
22:45:10 <TabAtkins> glazou: I want access to the parser, to the box tree. I"m forced to polyfill all the time.
22:45:20 <TabAtkins> glazou: Polyfills are ugly hacks today, affecting performance and difficult to maintain.
22:45:40 <TabAtkins> glazou: Another thing I want to see fixed is things we dropped in the early days of CSSOM that weren't priority at the time.
22:45:50 <TabAtkins> glazou: Like having one document rendered differently in multiple windows.
22:46:08 <TabAtkins> glazou: It existed in a tool called Griff twenty years ago. It was in CSSOM, but nobody wanted to ipmlement it.
22:46:25 <TabAtkins> glazou: If we want the industry to move from BookMaster/SGML/etc markup to the web, we need things like this.
22:46:54 <TabAtkins> glazou: Another useful second-screen experience is mobile and television, for example. A new thing we hadn't thought of.
22:47:22 <TabAtkins> glazou: So I'm interesting in extending/opening up the parser and APIs. Giving access to what's internal right now, and should be exposed to web authors. This will drastically help me in my daily life.
22:47:43 <shane> ScribeNick: shane
22:48:01 <shane> TabAtkins: I'm tab, I've been working on the CSS for <a long time>, primarily writing specs.
22:48:27 <shane> TabAtkins: I'm interested in houdini because there's so much you can do on the rest of the web that you can't do in CSS, which means we only explore a tiny part of the space right now
22:48:45 <shane> TabAtkins: instead of polyfilling, we need to wait for vendors to spend N years getting everything done. Too slow.
22:48:56 <dino> EVERYONE GETS A LAYOUT SPEC!!!
22:49:05 <shane> TabAtkins: The only value in some of my specs is because you can't do them in JS
22:49:29 <shane> SimonSapin: I'm Simon Sapin from Mozilla. I work on a research project to try to get parallelism throughout the browser
22:49:29 <TabAtkins> SimonSapin: I'm Simon Sapin from Moz research. I work on Servo, a new browser engine that's a research engine for new techniques, particularly parallelism as much as possible in the browser.
22:49:37 <shane> ScribeNick: TabAtkins
22:49:38 <shane> :)
22:49:38 <TabAtkins> SimonSapin: So we do things internally a lot different from other browsers.
22:50:02 <TabAtkins> SimonSapin: So I'm here to make sure we don't accidentally lock things into the details of one browser, so Servo, and more generally parallel layout, can be compatible with this.
22:50:19 <TabAtkins> dino: I"m Dean from Apple. I'll mostly repeat everything David said.
22:50:51 <TabAtkins> dino: I'm not super sure we can get all the right people here to do this work, whatever it is.  Browser internals are horribly scary, adn only understood by a few people scattered around. Those people don't generally like traveling and talking to people.
22:51:13 <TabAtkins> dino: I don't want to get into a place where we come up with a new tree API that sits between DOM and our internal layout trees, just another level of abstraction.
22:51:36 <TabAtkins> dino: But I'm also interested in seeing a bunch of the failure points authors have run into getting fixes - querying layout, stuff with style, etc.
22:51:59 <TabAtkins> johanneswilm: I'm Johanness Wilm. I've been working as a JS dev for th epast 3 years on web-based editting and trying to get professional printing into the web.
22:52:14 <TabAtkins> johanneswilm: For both things, which I thought would be fairly general, I quickly ran into various browser problems.
22:52:25 <TabAtkins> johanneswilm: (Works for Vivliostyle)
22:52:54 <TabAtkins> johanneswilm: So that one cannot access many primitives directly as a JS developer has been a real concern, so one has to do so many tricks to get the information today, so that's what I'm here for.
22:53:22 <dino> Toru Kawakubo
22:53:52 <TabAtkins> Toru: I joined Vivliostyle a while ago, with Shinyu. We're trying to do typesetting, especially paged typesetting, int eh browser.
22:54:22 <TabAtkins> Toru: I've posted to the ML a bit about this.  I'm new to this area, so I'd like to hear a lot of your expert opinions and discuss what we can do to make javascript polyfills more powerful.
22:54:33 <TabAtkins> roc: I'm Robert O'Callahan, working on Moz for about 15 years.
22:54:46 <TabAtkins> roc: I've done layout, and a bunch more, graphics backend, media, compositor stuff, the whole renderer.
22:54:51 <TabAtkins> roc: I"m interested in most things.
22:55:05 <TabAtkins> roc: I'm not interested in implementing multiple presentations of one document (sorry, Daniel).
22:55:10 <bkardell_> bkardell_ has joined #houdini
22:55:29 <TabAtkins> roc: Not interested in explaining a lot of what we currently have in CSS in terms of new primitives. I think it's very hard, and we can get a lot of value out of this without having to do this.
22:55:51 <TabAtkins> Volick: I'm Ian from Google. I've spent most itme on compositor-driven effects, better scrolling, animation, etc.
22:56:10 <TabAtkins> Volick: I'm bummed out by how hard it is to coordinate the things you do in JS with these accelerated things; they're very janky.
22:56:18 <bkardell_> is there a line open?
22:56:30 <TabAtkins> Volick: So I'm very concerned with performant primitives that make it easy to fall into a pit of success.
22:56:49 <TabAtkins> Volick: I'm also very cognizant of not tying ourselves to current impls in browsers.
22:56:58 <shane> bkardell_: 10am
22:57:01 <TabAtkins> Volick: And of the tradeoff between richness and performance.
22:57:11 <shane> bkardell_: I don't think we have a bridge set up
22:57:16 <TabAtkins> rbyers: I'm Rick Byers for Google. I do stuff related to input for Blink.
22:57:17 <bkardell_> :(
22:57:42 <TabAtkins> rbyers: I've worked on other platforms before Google, and there are some things about the web I think are amazing, so I hate seeing other platforms take share away from the web for silly reasons.
22:57:42 <shane> bkardell_: we will break momentarily and try to set one up.
22:58:04 <TabAtkins> rbyers: My big concern is that I worry we've gotten into the mind that we don't have the same flexibility that other platforms have.
22:58:20 <TabAtkins> rbyers: I'm worried about native mobile platforms. Gotta take those day-to-day effects on their iPHones and make them work as well on the web.
22:58:31 <TabAtkins> rbyers: But we don't have the same aiblity to just throw stuff out and start over something new.
22:58:39 <TabAtkins> rbyers: We're collaborating, we're designing for 20 years here.
22:58:58 <TabAtkins> rbyers: So we have to be thoughtful, but it's also critical and urgent to fix some of th eshortcomings others have talked about.
22:59:27 <TabAtkins> rbyers: So I'm confident we can innovate and come up with primitives here. People work *so hard* to work around the limitations (FastBook, etc), and we can open things up for them and do wonderful things.
22:59:43 <TabAtkins> Shinyu: I'm the Shinyu Murakame, CEO of Vivliostyle.
22:59:58 <TabAtkins> s/Murakame/Murakami/
23:00:19 <TabAtkins> Shinyu: I was working on Antenna House, making the print formatter work on XSL and XSL-FO.
23:00:35 <TabAtkins> Shinyu: Been working on that since 1999, working on the AH layout engine.
23:00:50 <TabAtkins> Shinyu: Later, AH implemented CSS Paged Media based on the XSL-FO engine.
23:01:10 <TabAtkins> Shinyu: But the AH CSS formatter was very proprietary, with lots of vendor extensions, and not very compatible with web browsers.
23:01:41 <TabAtkins> Shinyu: I started Vivliostyle last year because I thought the future must be more open and an open-source web-browser typesetting engine is needed.
23:02:00 <TabAtkins> Shinyu: I found johanneswilm book.js library for making book layout and that inspired me very much.
23:02:19 <TabAtkins> Shinyu: I think that web browsers, we can make a very professional typesetting engine with web browsers.
23:02:28 <TabAtkins> Shinyu: I expect Houdini to make our work very easy.
23:02:43 <TabAtkins> gregwhitworth: I'm Greg Whitworth for Microsoft. I work with Rossen on layout.
23:02:54 <TabAtkins> gregwhitworth: I was a webdev. I ranted about IE, got asked to work on it.
23:02:55 <johanneswilm> note: I have not worked for Vivliostyle so far. All the stuff I did so far has been open source and financed by various groups, but not Vivliostyle. However, I'm excited to work for/with Vivliostyle henceforth to go further than where I got so far with BookJS/simplePagination.js .
23:03:07 <TabAtkins> gregwhitworth: My main focus is layout. Most importantly, as Blink and Gecko people can suggest, interop is huge to me.
23:03:29 <TabAtkins> gregwhitworth: So I'm excited about making some primitives that can help with producing interoperable things.
23:03:50 <TabAtkins> gregwhitworth: But there's a fine line between giving people options they need and drowning them in options. Don't want webdev to require a major engineering team to do interesting things.
23:04:05 <TabAtkins> szilles: I'm Steve Zilles, for Adobe. Been involved in CSS since its creation.
23:04:27 <TabAtkins> szilles: My interests are line layout and i18n. Both are hung up with a lakc of public driving them, but I suspect that with the right facilities the public would use them.
23:04:39 <TabAtkins> szilles: So I'm interesting in doing those kinds of layout thing in an extensible way.
23:05:00 <TabAtkins> szilles: Also, Adobe is a tool maker, not a browser company, so like Daniel I'm interested in being able to do better tooling.
23:05:17 <TabAtkins> szilles: I'm also interested in making sure we identify low-hanging fruit, rather than being caught on things that could take a lot of time and effort.
23:05:49 <TabAtkins> astearns: I'm Alan Stearns, also from Adobe.  Member of CSS for 3 years or so, and also DPIG, very interested in publishing-related things.
23:06:12 <TabAtkins> astearns: My team tried to develop some new features, and found it very difficult. I'm interesting in making that easier.  Particulary typographic effects in the browser.
23:06:45 <TabAtkins> astearns: I'd like to get the roadmap in place of what we want to do to make CSS extensible, but that roadmap needs to have small incremental steps along the way, letting us maybe change directions as we learn from each step.
23:07:11 <TabAtkins> iank___: I'm Ian Kilpatrick. I'm a SWE working on Blink. Transferred to Blink about 6 months ago, previous of Apps (Docs, Drive, Gmail).
23:07:44 <TabAtkins> iank___: Basically I wante dmore power as a webdev. >Worked on a bunch of internal frameworks; it was easy to extend other parts of th eplatform, like JS, but I always found mysefl frsutrated with CSS and layout.
23:08:03 <TabAtkins> iank___: So I'm interested in giving a bunch of pwoer to framework devs, Ember and React and such.
23:08:30 <TabAtkins> Rossen_SYD: Awesome. Thanks for those introductions, telling us your aspirations.
23:08:39 <TabAtkins> Rossen_SYD: In the interest of time, I'd like to quickly summarize.
23:08:55 <TabAtkins> Rossen_SYD: I think that obviously there is enough people with enough deep understanding to try and describe what we are after.
23:09:21 <TabAtkins> Rossen_SYD: For the rest of the day, we'll first take a break to fix the projectors and set up a telcon bridge.
23:09:35 <bkardell_> \o/
23:09:43 <TabAtkins> Rossen_SYD: After break, if anyone wants to present something they've been working on in relation to Houdini work, we'll open the floor for that.
23:10:15 <TabAtkins> Rossen_SYD: AFter that we'll figure out our concrete topics and start putting together a roadmap, like Alan suggested. That'll probably exhaust the day.
23:10:34 <TabAtkins> Rossen_SYD: Tomorrow we'll continue and start talking process, cadence, etc.
23:10:50 <TabAtkins> Rossen_SYD: I also echo Dean's concern about 5-day long CSS discussions, and I"ve got SVG right after that.
23:11:21 <TabAtkins> Rossen_SYD: This is a one-time event hopefully. We'll hold any Houdini meeting separately.
23:11:26 <TabAtkins> <br dur=15m>
23:29:55 <TabAtkins> Break duration has been extended.
23:35:09 <ChrisL> zakim, room for 3?
23:35:11 <Zakim> ok, ChrisL; conference Team_(houdini)23:35Z scheduled with code 26631 (CONF1) for 60 minutes until 0035Z
23:35:47 <ChrisL> +1 617 761 6200
23:36:06 <Zakim> Team_(houdini)23:35Z has now started
23:36:13 <Zakim> +BrianKardell
23:36:40 <ChrisL> hi Brian we are just dialling in
23:37:57 <bkardell_> ok
23:40:06 <Rossen_SYD> bkardell_ we're dialing in and will start shortly
23:50:22 <shane> bkardell_: falling back to hangouts
23:50:28 <bkardell_> lol ok
23:50:34 <bkardell_> bkardell on hangouts
23:50:38 <bkardell_> if you want to invite me
23:50:52 <shane> I think we're trying to hangout dial the bridge first
23:52:22 <Zakim> +??P1
23:53:07 <ChrisL> http://cdn.collider.com/wp-content/uploads/the-houdini-box.jpg
23:53:17 <kwkbtr> kwkbtr has joined #houdini
23:53:38 <ChrisL> zakim, who is here?
23:53:38 <Zakim> On the phone I see BrianKardell, ??P1
23:53:40 <Zakim> On IRC I see kwkbtr, bkardell_, SteveZ, ChrisL, xidorn, smfr, TabAtkins, gregwhitworth, astearns, rbyers, johanneswilm, SimonSapin, dbaron, glazou, Zakim, RRSAgent, Rossen_SYD,
23:53:40 <Zakim> ... CSSWG_LogBot, dstockwell, iank___, shane, plinss
23:53:52 <ChrisL> zakim, ??P1 is [Google]
23:53:52 <Zakim> +[Google]; got it
23:53:56 <shane> bkardell_: seriously. I tested all of this a couple of weeks ago and it worked fine then :(
23:54:36 <murakami> murakami has joined #houdini
23:54:51 <shane> ScribeNick: shane
23:55:00 <shane> Rossen_SYD: Who would like to present something?
23:55:06 <shane> ChrisL: Me, for about 10 minutes
23:55:15 <shane> glazou: me, for about 15 minutes
23:55:17 <gregwhitworth> Rossen: We have a couple presentations
23:55:19 <bkardell_> TabAtkins you should present the alias spec and I have the Hitch prollyfillish thing if you wanted to show it
23:55:27 <shane> iank___: me, for about 20-30 minutes
23:55:51 <shane> ScribeNick: gregwhitworth
23:56:09 <gregwhitworth> ChrisL: We recently did work around dropcaps and drop initials
23:56:41 <Rossen_SYD> Topic: ChrisL on dropcaps
23:56:46 <gregwhitworth> ChrisL: We've got these lines coming out of layout, and numbers from font metrics. We then do an equation on them
23:57:17 <gregwhitworth> ChrisL: We should be able to polyfill these, this would be a good test case for this as it was hard to standardize on
23:58:15 <gregwhitworth> ChrisL: You can ask the DOM for example, which fonts are on the DOM. It will give you a list, but it's your guess
23:58:28 <gregwhitworth> astearns: We had to do some hacks to get this information
23:58:38 <gregwhitworth> astearns: 1. What font is actually being used to display the text
23:59:01 <gregwhitworth> astearns: 2. Font metrics from that font, acent, decent...
23:59:12 <vollick> vollick has joined #houdini
23:59:18 <gregwhitworth> astearns: 3. Where the browser is drawing the dominant baseline
23:59:29 <gregwhitworth> astearns: Those are the 3 bits we needed
23:59:52 <gregwhitworth> astearns: That will be beneficial for all types of typographic things
23:59:57 <hober> hober has joined #houdini
00:00:30 <gregwhitworth> ChrisL: You may want a list of glyphs and those fonts
00:00:59 <gregwhitworth> astearns: It may make sense for a more simple API, you could make it so that you can dig into the API for more complex situations
00:01:11 <gregwhitworth> astearns: My thought is that you would ask the API for a certain range
00:01:25 <gregwhitworth> ChrisL: I'm thinking of mainly the first cap scenario
00:02:00 <gregwhitworth> astearns: In terms of small initial steps, we can come up with a font-metric API that does very little to begin with
00:02:12 <gregwhitworth> astearns: maybe just giving the dominant baseline position
00:02:24 <gregwhitworth> astearns: Then we could come back with things that we find more useful
00:02:44 <gregwhitworth> astearns: We maybe won't get to acent, and decent if it's not needed
00:02:55 <gregwhitworth> Rossen: What do you mean by dominant baseline
00:03:25 <gregwhitworth> rossen: You have the range, and then based on the font metrics you can determine the baseline
00:03:56 <gregwhitworth> rossen: When you have a complex scenario with different fonts, I'm finding it hard to make this a simple API
00:04:36 <gregwhitworth> SteveZ: You know what line your applying the glyphs to ultimately
00:04:59 <gregwhitworth> SteveZ: For example, if you have multiple characters and their not evenly spaced that's why we need to ask layout
00:05:44 <gregwhitworth> Roc: It sounds like you're wanting to expose the linebox, which sounds like you want to expose the box tree ultimately
00:05:49 <gregwhitworth> Roc: Is that accurate
00:06:23 <gregwhitworth> Roc: Gecko actually has a private API for the dev tools to expose the font used
00:06:43 <gregwhitworth> Roc: You actually need to be able to do layout based on any changes done
00:06:53 <gregwhitworth> Roc: I have two concerns
00:07:41 <gregwhitworth> Roc: We need two APIs for triggering layout
00:08:42 <gregwhitworth> Roc: And it needs to be able to do multiple iterations of layout since you'll be moving things
00:09:07 <gregwhitworth> astearns: I kept it very simple, it doesn't respond to layout, it assumes evenly spaced
00:10:22 <gregwhitworth> johanneswilm: I understand your worry, but web devs will only use this when necessary
00:10:34 <gregwhitworth> shane: I was going to say something similiar
00:11:05 <gregwhitworth> shane: This will allow authors to have that control instead of us making the decision for them
00:11:36 <gregwhitworth> ChrisL: The main people using this will be framework developers
00:12:10 <gregwhitworth> TabAtkins: This is a good functionality that should exist
00:12:19 <gregwhitworth> shane: We see this in animation libraries as well
00:12:23 <Rossen_SYD> bkardell_: can you hear anything?
00:12:36 <bkardell_> Rossen_SYD: yes
00:12:43 <bkardell_> depends on who is speaking
00:13:06 <gregwhitworth> ChrisL: We started off very simple, and this got very complicated
00:13:18 <gregwhitworth> dino: What do we do now?
00:13:30 <gregwhitworth> Rossen: Good question, let me reiterate the point of these
00:13:55 <gregwhitworth> rossen: These presentations help us see the use cases for us to going and start chewing on for the road map on technical discussions
00:14:34 <gregwhitworth> rossen: A simple scenario produced 30 minutes of technical hurdles, but this will help us define the purpose of Houdini
00:14:53 <bkardell_> drop caps work by adobe is expressed in css or through a lower level api only?
00:15:10 <gregwhitworth> glazou: These presentations are very important as these provide us with adequate use cases we need to design
00:15:25 <gregwhitworth> glazou: It also allows us to define priorities
00:15:38 <gregwhitworth> dino: Whose keeping track of these ideas
00:15:42 <gregwhitworth> shane: Rossen and I
00:15:48 <bkardell_> ?+
00:15:49 <gregwhitworth> rossen: This should be done by the CSSWG
00:15:52 <bkardell_> +?
00:16:07 <shane> s/by the/by the end of the/
00:16:07 <Rossen_SYD> Topic: glazou - needs for editing
00:16:21 <gregwhitworth> glazou: let me start with editing
00:16:36 <bkardell_> not at all
00:16:38 <gregwhitworth> glazou: These are problems that we started working on 15 years ago
00:16:58 <gregwhitworth> glazou: There are properties supported by some browsers and not by others
00:17:15 <gregwhitworth> glazou: What I mean by that is that for some browsers this info is stored by the CSSOM and not by others
00:17:23 <astearns> bkardell_: the drop caps work we did uses canvas hacks to approximate the data needed in some improvement to the APIs
00:17:42 <shane> astearns: is the source code publicly available?
00:17:44 <gregwhitworth> glazou: We really need a way to preserve all of the properties and their values, even if they aren't understood by the parser
00:18:01 <gregwhitworth> glazou: The second most important thing
00:18:13 <gregwhitworth> glazou: It's everywhere in my code, parsing values
00:18:23 <astearns> shane: https://github.com/adobe-webplatform/dropcap.js
00:18:33 <gregwhitworth> glazou: parsing 15px is trivial, but linear-gradient and animation values is complex
00:18:41 <gregwhitworth> glazou: We don't have an object model for that
00:18:45 <shane> astearns: thanks!
00:18:51 <dino> dino has joined #houdini
00:19:18 <bkardell_> astearns: so no parsing, but if you could have it sure would have been nice
00:19:29 <astearns> bkardell_: agreed
00:20:18 <Rossen_SYD> ping
00:20:24 <glazou> ping
00:20:46 <ChrisL> pong
00:21:06 <glazou> glazou: everything in a stylesheet should parseable from script at any time to retrieve an internal representation of it
00:21:13 <gregwhitworh> gregwhitworh has joined #houdini
00:21:17 <gregwhitworh> ping
00:21:23 <glazou> bkardell_: whenever you want, but around a few beers :-)
00:21:47 <gregwhitworh> rossen: To repeat my question, do you envision this as an object that is exposed through JS (similiar to supports)
00:21:50 <bkardell_> glazou: also extra download / cross origin worries are addressed by this
00:22:01 <gregwhitworh> rossen: just for my mental model css.parser
00:22:08 <gregwhitworh> glazou: Yes something like that
00:22:45 <gregwhitworh> glazou: Example: The selector is modified and you need to parse the selector and reconstruct it and apply it
00:22:58 <gregwhitworh> glazou: This is very complex for editors that recreating this in JS
00:23:00 <bkardell_> if it could normalize the url value or have a way to that would be super nice too
00:23:10 <gregwhitworh> glazou: It would be faster and interopable and work everyone
00:23:26 <Zakim> +??P2
00:23:37 <gregwhitworh> glazou: We're basically re-implementing something that the browser already knows and can do
00:24:03 <astearns> zakim, mute +??P2
00:24:03 <Zakim> sorry, astearns, I do not know which phone connection belongs to +??P2
00:24:04 <gregwhitworh> glazou: Another thing that we need
00:24:06 <Zakim> -[Google]
00:24:19 <bkardell_> no one on the line now boys and girls
00:24:27 <rbyers> brian, do you hear us?
00:24:30 <bkardell_> no
00:24:40 <bkardell_> unless you are all holding your breath
00:24:43 <dbaron> bkardell_, say something?
00:24:55 <bkardell_> I am
00:25:22 <gregwhitworh> glazou: Being able to synchornize the changes from the CSSOM and the layout effects
00:25:33 <gregwhitworh> I want to change multiple properties and not change layout until I tell it to
00:26:03 <gregwhitworh> ping
00:26:17 <gregwhitworh> rossen: This is not a new problem, it's a transactional layout
00:26:33 <gregwhitworh> Roc: Do you want just visual effects, or layout changes
00:26:42 <gregwhitworh> Roc: We don't change anything until the layout is finished
00:26:53 <gregwhitworh> glazou: Just the visual effects, which is what the user sees
00:27:16 <bkardell_> I can HEAR
00:27:27 <gregwhitworh> glazou: You want to setup a layout for your application, sometimes a partial set of these properties will create a mess on the page and user will be lost
00:27:28 <bkardell_> yes!!
00:27:32 <bkardell_> I can hear daniel
00:27:44 <gregwhitworh> glazou: When you set a fixed position, the object could be outside of the viewport
00:28:01 <gregwhitworh> glazou: I want to be able to say css.stopFlushing, etc
00:28:10 <dbaron> roc: Trying to understand what you want to happen instead.
00:28:16 <gregwhitworh> rossen: Let me try to reinterprate this, is it more transactional or batching
00:28:21 <gregwhitworh> glazou: I think it's batching
00:28:36 <TabAtkins> CSS.styleTransaction(function(){...}) // function is called sync, it's just used as an automatic open/close mechanism
00:28:46 <gregwhitworh> bkardell_ could the transaction be throttled
00:29:04 <bkardell_> so if you dont flush, after a certain time it would auto flush anyway
00:29:20 <gregwhitworh> rossen: This is getting more into the implementation, we want to keep them more in the inspirational/use-case
00:29:38 <gregwhitworh> SteveZ: I don't understand your difference it transaction and batching
00:29:50 <gregwhitworh> rossen: Transaction allows for multiple property changes
00:30:19 <bkardell_> this kind came up at the breakout session at edgeconf too
00:30:24 <bkardell_> was anyone in the room there?
00:30:28 <bkardell_> there were good ideas
00:31:02 <gregwhitworh> glazou: I'm resulting to javascript to fix the wholes
00:31:11 <gregwhitworh> s/wholes/holes
00:31:21 <bkardell_> s/resulting/resorting ?
00:31:28 <gregwhitworh> glazou: All the editors are doing this
00:32:05 <gregwhitworh> glazou: The second issue is regarding polyfills
00:32:08 <Rossen_SYD> Topic: glazou on polyfills
00:32:14 <gregwhitworh> glazou: writing a polyfill is about two things
00:32:25 <gregwhitworh> glazou: 1. extending the parser
00:32:41 <gregwhitworh> glazou: Inject an extension with appropraite selector grammar
00:32:59 <dbaron> dbaron has joined #houdini
00:33:16 <gregwhitworh> glazou: Psuedo element is very complicated as it is related to layout
00:33:28 <gregwhitworh> glazou: You need to be able to inject something
00:33:44 <gregwhitworh> glazou: It's a chicken or egg issue, how do you inject them so that layout sees them, etc
00:33:56 <bkardell_> it's not unlike custom elements - very similar
00:35:02 <gregwhitworth> gregwhitworth has joined #houdini
00:35:31 <gregwhitworth> glazou: If you're creating a new property, you want to see the old CSSOM as well as the new ones you've created. Only the polyfill knows
00:35:43 <gregwhitworth> glazou: so you need a polyfill for both execution and serialization
00:36:18 <gregwhitworth> glazou: Access to the box tree, creating new boxes, etc is what you need to do correct polyfills
00:36:32 <gregwhitworth> rossen: So if you were to consider this, what API would you extend to make this work
00:36:34 <bkardell_> q+
00:37:03 <gregwhitworth> glazou: Extend the list of pseudo classes so that it's a bool and provide it to JS
00:37:18 <gregwhitworth> glazou: Show that we care about extending the browser, and continue to iterate on it
00:37:41 <gregwhitworth> glazou: I don't think we can fix or even think of everything to fix from the beginning, it needs to evolve
00:38:09 <gregwhitworth> glazou: We've received requests from SASS and other library authors, so we need to give them the hooks they need
00:38:49 <gregwhitworth> bkardell_ I disagree with how you prioritize them
00:39:10 <gregwhitworth> s/I disagree/I don't disagree with
00:39:41 <gregwhitworth> bkardell_ The parser is important to everyone that wants to polyfill anything
00:39:51 <gregwhitworth> bkardell_ and there are some lower level things that will help
00:40:00 <bkardell_> The parser is important to anything that wants to polyfill at the language level
00:40:07 <bkardell_> but not necessarily at the functional level
00:40:11 <bkardell_> that is my point
00:40:28 <gregwhitworth> rossen: in summary, we can work on scoping its behavior and its needs
00:40:38 <bkardell_> they can be taken up in parallel, related but separe
00:40:43 <gregwhitworth> glazou: We have many live examples on the web for this, and help guide us
00:41:41 <shane> ScribeNick: shane
00:41:43 <iank___> https://wiki.css-houdini.org/explaining-css-layout
00:41:50 <shane> iank___: We put some stuff up on the wiki ^
00:41:53 <bkardell_> the newer hitch for example treats the language level as a preprocessor thing and that's still better
00:42:10 <shane> iank___: There's also a talk I did at blinkon in November which goes through some of the same stuff. Can link if people are interested
00:42:24 <shane> iank___: we've been thinking about this extensibility problem as a pipeline approach
00:42:26 <bkardell_> iank___: please do link
00:42:36 <shane> iank___: the first stage in this is custom properties
00:42:52 <ChrisL> rrsagent, here?
00:42:52 <RRSAgent> See http://www.w3.org/2015/02/06-houdini-irc#T00-42-52
00:43:09 <shane> iank___: example in strawperson - simple API that lets you register a property with a function that defines its effect
00:43:26 <TabAtkins> http://dev.w3.org/csswg/css-extensions
00:43:28 <shane> iank___: not wedded to this but we should let people define functional properties
00:43:36 <bkardell_> no sound?
00:43:44 <Rossen_SYD> Topic: IanK - The render pipepline
00:43:59 <iank___> http://dev.w3.org/csswg/css-extensions/
00:44:03 <shane> iank___: Tab has a document with other ways to extend the style engine too ^
00:44:25 <shane> iank___: In this there's ways to extend selectors, functions, @ rules, Tab might talk in more detail
00:44:43 <shane> iank___: so that's the style level. The next part, which we've touched on, is exposing things like the box tree and a measurement API
00:45:01 <shane> iank___: one thing that potentially could be useful e.g. to polyfill flexbox is being able to query boxes min/max content contributions.
00:45:12 <shane> iank___: working out intrinsic width/height/aspect ratio of images
00:45:28 <shane> iank___: lots of detailed sizing data in the engine that you can only get via osmosis, or not at all
00:45:52 <shane> iank___: also what roc was alluding to earlier today - how would we do a full layout API?
00:46:20 <shane> astearns: one tiny detail on custom properties and extending parsing syntax
00:46:46 <shane> astearns: francois mentioned on the mailing list that it's much more difficult for an author to add a new value to an existing property than to add a new property.
00:46:53 <shane> astearns: is this something we should solve?
00:46:58 <shane> astearns: or just rely on custom properties?
00:47:09 <shane> astearns: e.g. having my-display: grid might be sufficient to polyfill grid.
00:47:18 <bkardell_> 1 fallback seems sufficient to me
00:47:23 <bkardell_> we just have to define the right order
00:48:00 <shane> Rossen_SYD: re layout and layout extensibility. Our extensibility model is based on COM. The Browser Helper Objects (BHO) used to have something called layout behaviours. It was IE extensibility since IE4
00:48:16 <shane> Rossen_SYD: we killed it as soon as we could because we found out that people are fairly bad at writing and extending layout.
00:48:35 <shane> Rossen_SYD: in our case, the thing that was the highest motivator was that we made it synchronous rather than asynchronous. We should avoid that.
00:48:54 <shane> Rossen_SYD: Synchronous layout extensibility on the main thread will kill scenarios very quickly
00:49:07 <bkardell_> Rossen_SYD: I think what glazou was talking about that helps
00:49:34 <shane> roc: that seems weird to me. If you look at what Ian's written (which I agree with) you do want custom layout to behave like existing layout. You want custom layout to complete at the same time as the built-in stuff otherwise it's not a real polyfill. So it has to be synchronous
00:50:02 <shane> roc: in all our browsers, even servo, layout and js run on the same thread
00:50:10 <shane> roc: so sync doesn't make things more janky
00:50:42 <bkardell_> there are opportunities to offthread and rejoin I think
00:50:43 <shane> iank___: internally, we came to the conclusion that you need something running in the middle of layout computation, whether defined up-front with an EDSL or in JS
00:50:56 <shane> iank___: we were also toying with ideas like that the JS was in an isolated world (e.g. a worker)
00:51:13 <shane> iank___: might be able to have better guarantees about the DOM. Lots of tech discussions that we could possibly go into this afternoon
00:51:16 <shane> Rossen_SYD: Yes.
00:51:44 <shane> Rossen_SYD: I agree with the spirit of this. When we start discussing technical details we'll figure out how this can work. I believe we can still make things looser from a dependency point of view
00:52:07 <shane> Rossen_SYD: in some of the recent things we've been playing with we've been successful in detaching and running object model, layout and rendering (been parallel for 1 release already)
00:52:23 <shane> Rossen_SYD: so we don't block script or layout for rendering. Trying to do the same thing for layout. So far things look pretty good.
00:52:54 <shane> Rossen_SYD: as mentioned before the spirit here is that we don't want to disable the ability to do things in the platform just so we can expose things that script can use.
00:53:06 <shane> Rossen_SYD: but fundamentally want to be able to do something like this (???)
00:53:35 <shane> iank___: one other thing with layout - may not expose full range of CSS layout within custom layout. e.g. might not have the ability to deal with things like floats.
00:54:10 <shane> dino: can you give examples of what you mean by custom layout?
00:54:16 <bkardell_> GSS
00:54:45 <shane> iank___: two or three years ago we were speccing flexbox. Authors have wanted this for quite a while. Being able to do this in user land is extremely powerful (and things like grid too).
00:54:51 <TabAtkins> http://gridstylesheets.org/
00:55:02 <shane> iank___: another one - if we ever wanted to do a layout that is constraint based (like grid stylesheets)
00:55:07 <shane> iank___: how can we do that in user land?
00:55:21 <shane> iank___: I really like relative layout from android. How could we do this in user land?
00:55:41 <shane> dino: all the examples you gave are not really doing custom layout in the same way as the web is. I have concerns about this being performant.
00:55:58 <shane> dino: it's not JS performance per se that is going to be the problem, it's just that layout is tricky.
00:56:36 <shane> TabAtkins: we have some approaches that we think might work to make this performant, and we want to discuss in the group to make sure that the ideas could be used across browsers rather than just something that might work for us
00:56:54 <shane> iank___: I've written lots of custom layouts. How they work is horrific.
00:57:06 <bkardell_> right now there is a hot market in footguns is what tab is saying :_
00:57:14 <shane> iank___: often need to do things like collapse, do a DOM measure, inflate, do another measure.
00:57:34 <shane> glazou: at the moment the situation is far worse than _any_ API we can come up with
00:57:56 <shane> glazou: anything we can provide will make the situation orders of magnitude better. Even if we think there's a performance issue it's a huge win for authors.
00:58:21 <shane> dino: I agree with that, but there's a bigger set of users we need to worry about.
00:58:44 <shane> dino: they are the users. We've put a lot of effort into things like smooth scrolling - users don't care about custom layouts so much, they want their page to be fast.
00:59:17 <shane> dino: my general point is that developers obviously want this power and what they have now is terrible, but my fear is about making things worse
00:59:21 <bkardell_> dino: if people do it today, authors are taking resposibility for their custom stuff... making it extensible is not different, is it really?  not asking to add gss to the platform
00:59:31 <bkardell_> they have the power, that's the point
01:00:44 <shane> shane: yes but whether users care about custom layouts, authors are doing them. There's thousands out there. The techniques that are used have a performance impact across the platform, including scrolling. So we'll actually be making things better.
01:00:46 <bkardell_> I dont know if someone is talking, but I hear nothing
01:00:51 <bkardell_> nm
01:01:07 <SimonSapin> (bkardell_, minute taker catching up)
01:01:17 <shane> glazou: I hear both of you but I think we shouldn't confuse author's responsibilities and vendors responsibilities. This goes far beyond technical side and into marketing communications, etc.
01:01:48 <shane> glazou: but it's always the author's responsibility if they use a technique that slows the website down. There's nothing we can do about that. There are zillions of ways you can make your website suck.
01:02:04 <shane> glazou: I know this will impact the public image of your browser. But if we take that into account then we're not going to make progress.
01:02:22 <bkardell_> don't discount the possibility that the killer new feature comes in through this route as a cowpath
01:02:29 <shane> glazou: right now it's the author's responsibility if a site is slow or if it sucks. That isn't going to change because we add more APIs.
01:02:48 <shane> johanneswilm: again, just thinking about performance limits web apps to be really simple if you don't want them to slow on old computers.
01:03:18 <shane> johanneswilm: we're not stopping this now. People are doing this, despite the tricks they need to use. Things can't get slower if these tools are made available so we don't need to jump through loopholes.
01:03:46 <shane> dino: I guess I'm not against the idea of custom layout, especially Ian's example (the springy thing - measuring text offline efore animating to the right position).
01:03:55 <shane> dino: I think that's a bit different from implementing the CSS Grid model
01:04:07 <bkardell_> q+
01:04:14 <shane> iank___: you need to be able to do it inline in that example though. You need full participation of layout. So it's not that different.
01:04:38 <shane> iank___: I've mainly talked about box layout, not text layout. But we should also think about text layout.
01:05:17 <shane> bkardell_: should be able to organise things so you can shortcut and go through the native pathway if there's nothing custom, right?
01:05:26 <shane> bkardell_: so hopefully this will have no net effect on sites that don't use this
01:05:30 <shane> iank___: yes.
01:05:33 <glazou> name
01:05:44 <shane> iank___: So layout is hard
01:05:53 <shane> iank___: Then there's the painting aspect - the final layer of the pipeline
01:06:11 <shane> iank___: if people want e.g. screws on border corners, or something crazy, they should be able to paint that directly on the element if they want
01:06:31 <shane> iank___: e.g. in the past, border radiuses. When I was first starting out you needed to use a table to get these.
01:06:38 <shane> iank___: we should enable these types of use case too.
01:06:57 <shane> iank___: is painting a worthwhile problem?
01:07:03 <shane> dino: I've wanted this forever
01:07:34 <shane> iank___: needs some thought - e.g. drawing outside of bounds for things like box shadow, drawing in content layer
01:07:59 <shane> roc: do you want static content or animating content?
01:08:16 <shane> iank___: we'd want to do it on invalidation
01:08:23 <shane> roc: can you give an example?
01:08:39 <shane> iank___: e.g. if you have a my-border-radius and you animate that property, then the paint will animate
01:09:04 <shane> roc: but if a property isn't changing, then the display is static?
01:09:06 <shane> iank___: right.
01:09:56 <shane> Rossen_SYD: one of the things I wanted to mention here is that as we think about extending layout and the parser and all these things, it would be good if we approached this from the perspective of something that we can do right now versus a pipe dream
01:10:32 <bkardell_> it makes sense to keep trying to spell out a whole system even if pieces never get implemented or we need big "here be dragons" handwaving
01:10:51 <shane> Rossen_SYD: so one concrete example: Ian and Dean both mentioned that content measure is something we all have internally. We should be able to expose this on top of the current DOM today without going into super-crazy philosophical discussions
01:10:59 <bkardell_> *trying* just trying ;)
01:11:03 <shane> Rossen_SYD: (of how to implement a spiral layout)
01:11:11 <shane> Rossen_SYD: ultimately I think we'll strike a balance in the middle
01:11:46 <ChrisL> mouse tail layout http://www.maa.org/sites/default/files/images/upload_library/4/vol6/Growney/MouseTail.jpg
01:12:07 <shane> glazou: another thing that we need is CSS value. We need to be able to parse *any* value. Concretely: there was a polyfill for linear gradients. It's a function of arguments separated by commas. Each argument is pretty complex. We have no way of representing something like that if it's not already in the browser.
01:12:21 <bkardell_> can we get glazou to paste in his example if he is sharing
01:12:35 <ChrisL> http://www.maa.org/sites/default/files/images/upload_library/4/vol6/Growney/MathPoetry.html
01:13:58 <shane> glazou: in the OM right now, CSS Value completely sucks. Nobody uses it. We should get rid of it.
01:14:11 <shane> glazou: or have a new name for a new CSS Value, and get it right this time.
01:14:24 <shane> glazou: current one is useless and unused. Let's do it right.
01:14:58 <shane> SimonSapin: What if we had the ability from JS to pass things from any production rules. e.g. in the spec we have a thing that is either a linear gradient or radial gradient. What if we could pass just the color stop list.
01:15:10 <shane> glazou: yes. *all* the values we have in CSS. Including the infamous URL
01:15:32 <shane> glazou: it's pretty simple language actually. Should be able to achieve a representation of this in no time.
01:16:01 <shane> dino: question for Rossen. Were you suggesting we should prioritize the things we can do right now, or that we all know what those things are and should just do them?
01:16:08 <SteveZ> q+ to say want a CSS Linebox API
01:16:10 <shane> dino: and what do you mean by 'rgiht now'?
01:16:16 <bkardell_> q-
01:16:22 <shane> dino: e.g. we could probably all see a way to do painting right now.
01:16:35 <shane> Rossen_SYD: I didn't mean to suggest priority in terms of what we should spec or do
01:16:50 <shane> Rossen_SYD: I think it would be easier to start working on speccing and implementing things we can do right now.
01:17:02 <shane> Rossen_SYD: but I wouldn't push for implementing them *right now*
01:17:32 <shane> iank___: I think I've opened up enough rats nests for now
01:17:50 <bkardell_> Some things themselves can be speced and prolyfilled... a proposal for CSSValue for example
01:18:26 <shane> SteveZ: roc mentioned in passing. I'd like to ask for an explicit CSS Line Box interface, so you can ask how many lines a layed out thing has, and for each line ask for the dominant baseline and extent above and below.
01:18:27 <bkardell_> s/CSSValue/replacement for CSSValue
01:18:40 <shane> SteveZ: a read only interface. Would help with a lot of the things that we're doing.
01:18:49 <shane> Rossen_SYD: I think that ties in with the whole describing of the box tree.
01:18:57 <shane> Rossen_SYD: Definitely should do this.
01:19:10 <shane> SteveZ: needn't be a text box. Can have a line that consists entirely of images.
01:19:12 <shane> Rossen_SYD: line box.
01:19:22 <johanneswilm> +1 for line box exposing!
01:19:50 <astearns> ~70 minute break
01:19:59 <Zakim> -BrianKardell
01:20:35 <kwkbtr> kwkbtr has joined #houdini
01:24:59 <Zakim> disconnecting the lone participant, MeetingRoom, in Team_(houdini)23:35Z
01:25:02 <Zakim> Team_(houdini)23:35Z has ended
01:25:02 <Zakim> Attendees were BrianKardell, [Google], MeetingRoom
01:52:15 <xidorn> xidorn has joined #houdini
01:56:04 <dael> dael has joined #houdini
02:00:48 <ChrisL> ChrisL has joined #houdini
02:02:09 <johanneswilm> johanneswilm has joined #houdini
02:02:25 <Florian> Florian has joined #houdini
02:02:36 <kwkbtr> kwkbtr has joined #houdini
02:09:15 <dstockwell> dstockwell has joined #houdini
02:16:28 <SteveZ> SteveZ has joined #houdini
02:27:52 <Rossen_SYD> Rossen_SYD has joined #houdini
02:29:44 <Rossen_SYD> is there anyone on the channel that needs to dial in?
02:31:37 <dael> Not I. I'm just going to IRC lurk for a bit.
02:32:48 <ChrisL> rrsagent, here?
02:32:48 <RRSAgent> See http://www.w3.org/2015/02/06-houdini-irc#T02-32-48
02:32:52 <kwkbtr> kwkbtr has joined #houdini
02:35:26 <hitchjs> hitchjs has joined #houdini
02:35:42 <dbaron> dbaron has joined #houdini
02:35:49 <hitchjs> hitchjs is bkardell :-p
02:36:19 <gregwhitworth> gregwhitworth has joined #houdini
02:36:32 <murakami> murakami has joined #houdini
02:36:44 <Rossen_SYD> bkardell do you want to dial in?
02:37:01 <bkardell> yes I would love to but I lost the number when irc cloud failed
02:37:05 <bkardell> code?
02:37:48 <shans_> shans_ has joined #houdini
02:37:54 <ChrisL> zakim, room for 3?
02:37:56 <Zakim> ok, ChrisL; conference Team_(houdini)02:37Z scheduled with code 26631 (CONF1) for 60 minutes until 0337Z
02:38:22 <Zakim> Team_(houdini)02:37Z has now started
02:38:28 <Zakim> +??P1
02:38:29 <Zakim> + +1.519.880.aaaa
02:38:35 <dbaron> Zakim, ??P1 is MeetingRoom
02:38:35 <Zakim> +MeetingRoom; got it
02:38:53 <shans_> ScribeNick: shans_
02:38:53 <dbaron> Zakim, aaaa is bkardell
02:38:53 <Zakim> +bkardell; got it
02:39:22 <bkardell> wow the sound is so much better
02:39:24 <shans_> rbyers: I think scrolling extensibility is related to this area too
02:40:18 <rbyers> rbyers has joined #houdini
02:40:30 <shans_> rbyers: I'll just paste in a couple of links
02:40:34 <rbyers> https://docs.google.com/a/chromium.org/presentation/d/1P5LYe-jqC0mSFJoBDz8gfJZMDwj6aGeFYLx_AD6LHVU/edit#slide=id.g4119c536d_015
02:40:37 <rbyers> https://www.youtube.com/watch?v=L8aTuoQWI8A
02:40:44 <rbyers> https://docs.google.com/a/chromium.org/document/d/1VnvAqeWFG9JFZfgG5evBqrLGDZYRE5w6G5jEDORekPY/edit#heading=h.kd0gtwwz5bf9
02:41:21 <shans_> rbyers: This is a talk I gave at BlinkOn. Summary: native apps have lots of interesting scroll effects, want to be able to do this natively too.
02:41:42 <shans_> rbyers: most extreme example is pull-to-refresh.
02:41:54 <shans_> rbyers: working on a few primitives that might help
02:42:04 <shans_> rbyers: first thing is need some ability to synchronize with scrolling
02:42:11 <shans_> rbyers: e.g. if transforming something around the page
02:42:25 <shans_> rbyers: scroll-blocks-on is what we've exposed in canary.
02:42:43 <shans_> rbyers: every browser already has some notion of what scroll blocks on, it's good to expose that.
02:42:58 <rbyers> https://docs.google.com/a/chromium.org/document/d/1aOQRw76C0enLBd0mCG_-IM6bso7DxXwvqTiRWgNdTn8/edit
02:43:07 <shans_> rbyers: this property gives you a way to control htat
02:43:18 <shans_> rbyers: e.g. stop waiting for touch events
02:43:31 <shans_> rbyers: lots of potential concerns: Want to make sure we don't provide a footgun
02:43:36 <shans_> rbyers: still very experimental
02:43:59 <shans_> rbyers: don't want to do anything in isolation, hope we can talk about in this group
02:44:40 <shans_> rbyers: synchronizing with scrolling can be done two ways - either by forcing everything to happen on the main thread, or via extensible scrolling
02:44:50 <shans_> rbyers: also how do we explain things like scroll chaining
02:45:04 <shans_> rbyers: e.g. in pull-to-refresh, the spring needs to collapse before anything else scrolls
02:45:21 <shans_> rbyers: should be able to explain overflow scroll property and build it in JS
02:45:43 <shans_> rbyers: got a proposal called scroll customization that provides custom scroll and custom scroll-distribute methods to change how scrolling is implemented
02:45:54 <shans_> rbyers: super prototype, hoping others will be interested in talking about this topic
02:46:04 <shans_> rbyers: happy to give demos etc. if people want to talk more
02:46:41 <shans_> glazou: the topic that triggered the original discussions was the box tree. Haven't discussed that yet.
02:47:21 <shans_> astearns: during lunch we talked about the best venue for this discussion
02:47:32 <shans_> astearns: maybe the houdini list is better than the style list
02:47:49 <shans_> rbyers: I think that was a slightly different problem - threading - but it's related. We probably don't want to talk about threading here.
02:48:15 <shans_> plinss: with scrolling, in the early days of the gecko engine we had a choice of how to describe scrolling in terms of internal models
02:48:26 <shans_> plinss: internally had an anonymous box on the outside and another on the inside
02:48:38 <shans_> plinss: but are you moving the layout of these boxes around, or is it just something that happens at render time
02:48:55 <shans_> plinss: this is going to be an interesting one - there's lots of cases that potentially fall on both sides.
02:49:09 <shans_> plinss: this is going to be hard to standardise because of differences in implementation but I think we should
02:49:27 <shans_> plinss: if something is overflow visible and scrollable through script, and other things wrap around it live, then that needs to happen at layout
02:50:13 <shans_> rbyers: with the scroll customization primitives, first want to build something like overflow scroll, then with the box model primitives we're talking about should be able to meet some of these without adding extra to the platform
02:50:40 <shans_> ChrisL: from a user perspective, some things that look like scrolling aren't. e.g. tumblr model - things are actually being evicted from the top. But it looks like scrolling to the user.
02:51:16 <shans_> ChrisL: so decoupling gestures and presentation from backend implementation
02:51:31 <shans_> rbyers: want to decouple the intent from what that intent triggers. That's our thinking too.
02:51:42 <shans_> rbyers: infinite scrolling is a good example but can build it on top of scrolling
02:51:57 <shans_> rbyers: but e.g. what if I want to scroll through a spinning wheel and come back to where I started. Can't do that today.
02:52:08 <shans_> rbyers: should be able to implement a scroller that under the hood is a 3D rotate
02:52:17 <shans_> ChrisL: also can't do scrolling as nav mechanism.
02:53:12 <shans_> plinss: infinite scroll is a really good example of why we need the box tree. Sometimes infinite scrolling is just capturing the gesture. Sometimes it's lazy loading
02:53:40 <shans_> plinss: should be giving devs primitives to do these properly. Should e.g. be able to say that there are 10k items, 500px high, without them being explicitly in the DOM
02:53:52 <shans_> plinss: need to get to primitives that let these things happen without breaking everything else
02:54:54 <shans_> murakami: are things related to page views included in the agenda?
02:55:07 <shans_> Rossen_SYD: I don't think there's a fixed agenda, but we should definitely talk about that
02:55:18 <bkardell> No one has discussed isolation
02:55:43 <shans_> bkardell: one thing that I think is worth talking about is isolation
02:55:45 <vollick> vollick has joined #houdini
02:55:56 <shans_> bkardell: really dominated web-apps and www-style
02:56:12 <shans_> bkardell: what we have currently is almost impossible to manage in certain scenarios
02:56:27 <shans_> bkardell: developers really struggle with it. Worth discussing what the missing primitive is and where it belongs
02:56:46 <bkardell> https://briankardell.wordpress.com/2015/01/14/friendly-fire-the-fog-of-dom/
02:57:31 <shans_> Rossen_SYD: one more topic: haven't heard yet about how we deal with breaking, and what breaking means
02:57:42 <shans_> Rossen_SYD: line breaks, box breaks, page breaks (without defining pages)
02:58:00 <astearns> pagination requirements from digipub group: https://www.w3.org/dpub/IG/wiki/Pagination_Requirements
02:58:10 <shans_> Rossen_SYD: one of the ideas that I wanted to include as part of the next level of fragmentation is the ability to have named breaks
02:58:19 <shans_> Rossen_SYD: let people define their own types of breaking
02:58:39 <shans_> Rossen_SYD: e.g. I'm defining my own page element and want to know when something inside has reached a breaking boundary
02:58:44 <shans_> Rossen_SYD: then handle what happens
02:59:04 <shans_> Rossen_SYD: we currently have the names 'column', 'region', 'page' and the platform deals with them
02:59:15 <shans_> Rossen_SYD: no reason why the host shouldn't be able to define what the handling is
02:59:27 <shans_> Rossen_SYD: our implementation is pretty much the same and we use it for everything
02:59:41 <shans_> Rossen_SYD: it's the primitive we use for breaking layout between fragments
02:59:49 <shans_> astearns: can you describe a custom break type use case
02:59:51 <shans_> astearns: ?
02:59:52 <shans_> Rossen_SYD: yes.
03:00:07 <shans_> Rossen_SYD: Been getting lots of feedback from applications that do EPUB content presentation
03:00:19 <shans_> Rossen_SYD: it's really hard to start layout somewhere in the middle unless you control the content entirely
03:00:41 <shans_> Rossen_SYD: e.g. if I try to load the bible on an 8" device, chances are that there will be thousands of pages
03:00:57 <shans_> Rossen_SYD: If I want to resume reading in the middle, it's difficult to know how to do that without doing layout
03:01:35 <shans_> Rossen_SYD: having breaks and being able to do layout once for that size and font set lets us resume without necessarily having to chunk the content
03:01:35 <ChrisL> break-book break-chapter break-verse
03:01:41 <shans_> break-dance
03:01:51 <franremy> franremy has joined #houdini
03:01:55 <shans_> Rossen_SYD: I want named breaks because I'm sick of arguing about pages.
03:02:04 <shans_> Rossen_SYD: should be whatever you want to call a page.
03:02:14 <bkardell> q+
03:02:36 <shans_> Rossen_SYD: if I can create a pagination context that understands breaking 'foo', then I should be able to generate breaks in 'foo' from content and handle them in the 'foo' engine
03:02:41 <bkardell_> bkardell_ has joined #houdini
03:02:54 <ChrisL> ack bkar
03:03:05 <shans_> bkardell: would this have an impact on the URL?
03:03:14 <shans_> bkardell: how would you load a page from the middle outward?
03:03:32 <shans_> bkardell: is the bible a single HTML page in your example?
03:03:34 <shans_> Rossen_SYD: yes.
03:03:58 <shans_> bkardell: lots of ways the bible can be divided.
03:04:22 <shans_> bkardell: at some level this could potentially effect URLs - should it?
03:05:02 <shans_> johanneswilm: as I understand it, the entire bible is one HTML page. You load it but first the developer has already done a pagination run. So page 316 could immediately jump to the right place in the content.
03:05:16 <shans_> johanneswilm: so how would this work? Right now I'd count letters per page and store it somewhere on the page.
03:05:32 <glazou> q+
03:05:41 <shans_> johanneswilm: then I'd sum the first 315 pages, see how many letters, then jump to the exact point in the text
03:05:51 <shans_> johanneswilm: but how would you store these counts?
03:05:59 <bkardell> but I can share a link to Genesys chapter 1 vs 3 on the web - and that's important
03:06:09 <shans_> johanneswilm: should you have to display once? Or should this happen without ever having loaded
03:06:18 <shans_> Rossen_SYD: today we don't have a primitive that exposes the break record
03:06:48 <shans_> Rossen_SYD: usually a collection of all the elements and boxes that have been broken, + enough context to describe how much content was consumed and how much is remaining
03:07:17 <shans_> Rossen_SYD: without it being exposed you can't just resume generating page
03:07:21 <glazou> q-
03:08:38 <shans_> bkardell: So I can share a link to chapter 3. But if the URL doesn't change, how could you do that?
03:08:52 <shans_> bkardell: feels like this should be holistic
03:09:38 <shans_> Rossen_SYD: should still be able to find the position of a named element and resume layout from the nearest page break before that eement
03:09:39 <johanneswilm> +1 for allowing user defined breaktypes. Check this example of how it can currently be done: http://fiduswriter.github.io/simplePagination.js/simplePagination.html
03:10:10 <ChrisL> q+
03:10:14 <shans_> bkardell_: but I can't share that link if it doesn't have an affordance
03:11:29 <shans_> glazou: this isn't about sharing. Concrete example - you have a doc in your browser, you've scrolled, you close the tab, then reopen. You're in the same position. Everything had to be re-layed-out because that's the only way it can work right now. Rossen wants to optimize to layout from nearest break. Doesn't want to change anything.
03:11:56 <dbaron> What does this have to do with the agenda?
03:12:14 <shans_> bkardell: if that were a possibility I imagine we'd use it a lot more. Wondering if that can also be backed out so that there are URLs to each page.
03:12:35 <shans_> ChrisL: you do this with identifiers in the HTML, then declare there are page breaks
03:12:58 <bkardell> thank you, that's what I was asking for
03:13:01 <shans_> ChrisL: you don't share the page (different devices allocate differently to pages)
03:13:07 <glazou> q+
03:13:17 <glazou> Zakim, ack ChrisL
03:13:17 <Zakim> I see glazou on the speaker queue
03:13:24 <shans_> ChrisL: instead, it's so that if you go back to the device then you get the pages faster.
03:13:31 <shans_> ChrisL: but someone else might have different pagination
03:13:39 <shans_> glazou: why do you need user defined breakage?
03:13:59 <bkardell> dbaron: it just has to do with whether the idea loses an important quality of the web if you open that door
03:14:28 <bkardell> dbaron: I think it sounds like it doesnt necessarily, so not important
03:14:34 <astearns> q+ for an additional topic once this discussion ends
03:15:54 <shans_> Rossen_SYD: can only break on column, region or page right now. From app point of view, if creating own paginator and view then I want to declare which breaks I honor. (e.g. I handle article boundaries but don't paginate the articles)
03:16:15 <shans_> Rossen_SYD: so with use defined page breaks I can defined what article begin looks like and that I can break on article
03:16:21 <shans_> glazou: seems like regions are a solution here?
03:16:25 <shans_> Rossen_SYD: that's what we thought
03:16:36 <shans_> Rossen_SYD: but some cases are a little bit hard.
03:17:38 <shans_> ScribeNick: rbyers
03:17:42 <roc> roc has joined #houdini
03:17:55 <Rossen_SYD> Topic: Alan on Style Mutation Observer
03:17:57 <rbyers> Alan: want to discuss "style mutation observers"
03:18:19 <rbyers> Need to know when a style property changes
03:18:31 <rbyers> s/alan/astearns/
03:18:52 <rbyers> ChrisL: any selector would have an observer which triggers an event when what the selector matches changes?
03:18:56 <rbyers> astearns: Yes
03:19:08 <bkardell> jquery.live is essentially this
03:19:11 <rbyers> glazou: Selector matching observer or a property computed value changing observer
03:19:20 <rbyers> astearns: good question
03:19:36 <rbyers> astearns: New property - want to know what selectors it's being defined in.
03:19:36 <bkardell> http://api.jquery.com/delegate/
03:19:45 <rbyers> .. when prpoperty value changes
03:19:54 <rbyers> glazou: ok, so you need both
03:20:15 <rbyers> chrisl: Like DOM mutation, if nothing is watching there's no downside, right?
03:20:16 <bkardell> difference with jquery is it is for events
03:20:26 <rbyers> .. not doing anything doesn't cause any downside
03:20:39 <rbyers> glaxou: true except you still have to check the number of observers
03:20:55 <rbyers> s/glaxou/glazou/
03:21:13 <rbyers> dino: Why is your API just about selectors rather than detecting, for eg. computed style changes
03:21:27 <rbyers> .. I assumed "style mutation" could detect when style on an element had changed
03:21:56 <rbyers> astearns: Not sure what all needs to be tracked.  What selectors match seem to be the most important thing.
03:22:08 <rbyers> .. will happen much more often than the computed style changing
03:22:19 <rbyers> .. but maybe better to track the computed style changes per element
03:22:29 <bkardell> maybe you'd set it up like mutation observers - watch a selector and optionally only when the style changes
03:22:32 <Rossen_SYD> q?
03:22:43 <rbyers> glazou: you probably really want to know about the rule, not the selector
03:22:58 <rbyers> .. and you want to climb up the cascade
03:23:14 <rbyers> .. we suggested we add it to the OM a long long time ago.  It existed in Gecko.  I suggest we add it.
03:23:39 <rbyers> roc: if you're polyfilling a CSS property, what dino said is right.  When does a computed value change (including element added/removed from document)
03:23:49 <rbyers> .. want that notification for all elements
03:23:54 <rbyers> .. don't need to know anything about selectors
03:24:23 <rbyers> shans: I think webkit had a similar API for walking up the casecade.  Both WebKit and Mozilla had to remove it for security concerns.
03:24:32 <rbyers> .. not saying we shouldn't do it, but need to build awareness
03:24:39 <Rossen_SYD> q- astearns
03:25:04 <bkardell> I think you can build this on mutation observers today with just .filter and .matches right?  where is the security issue?
03:25:14 <rbyers> .. It was an API that gave you a set of style rules that matched a given element
03:25:19 <rbyers> roc: You don't need that
03:25:33 <rbyers> .. that's what people polyfilling CSS properties need
03:25:38 <rbyers> .. editors need other things
03:25:54 <rbyers> astearns: could this just be built on top of dom mutation observers?  triggers on computed style?
03:25:59 <rbyers> roc: no, not how you'd do it
03:26:10 <rbyers> shans: I used this once to polyfill CSS events
03:26:17 <rbyers> roc: that's different than CSS properties
03:26:34 <rbyers> shans: focusing on narrow use cases like user custom properties then you don't need it, but other cases do
03:26:41 <rbyers> glazou: I have a concrete example
03:26:49 <rbyers> .. editor, style property span on it
03:27:02 <rbyers> .. works whatever the style applied to the document - may be complex stylesheet
03:27:09 <rbyers> .. will try to find the deepest rule to modify
03:27:26 <bkardell> glazou devtools must essentially have this, right?
03:27:27 <rbyers> .. all the machinery is hidden to the user.  User just says "I want to set the font white here"
03:27:40 <rbyers> dino: why does that need to be web-facing?
03:27:49 <rbyers> .. the devtools API has this
03:27:58 <rbyers> .. could be standardized outside this group
03:28:09 <rbyers> glazou: IMHO it's extensibility of the style engine - so fits here
03:28:35 <rbyers> dino: need to understand what use cases we want to address.  roc and I are talking about very different use cases.
03:29:06 <glazou> q-
03:29:23 <bkardell> glazou are you essentially saying that you should be able to have an element and say "what rules am I matching right now?"
03:29:27 <rbyers> rossen_syd: any other topics?
03:29:46 <rbyers> rossen_syd: One topic not  put forward explicitly is the box tree.
03:29:53 <rbyers> .. one topic that lured me into all this
03:30:24 <Florian> Florian has joined #houdini
03:30:28 <rbyers> .. most of the topics discussed today would require deciding what the box tree is and what it's API surface should be, then tacking on additional behavior
03:30:34 <rbyers> .. but parser and style side is just as important
03:30:40 <bkardell> parser doesn't require box tree as far as I can tell, nor do custom pseudos?
03:30:48 <rbyers> chrisl: like css 2.0
03:31:01 <rbyers> .. where we said there should be a clear separation between the document tree and style tree
03:31:08 <rbyers> .. but one vendor had a single tree and blocked this
03:31:43 <rbyers> rossen_syd: yes, it's time to change
03:32:50 <rbyers> rossen_syd: box tree sounds like a fairly major piece that's worth discussing
03:33:00 <rbyers> .. good starting point
03:33:21 <rbyers> .. want to hear ideas for how we should expose the box tree, what APIs should look like, what hooks should we be giving
03:33:37 <bkardell> isn't it necessary to concretely define the box tree in an agreed upon way before you start talking about exposing it?
03:33:52 <rbyers> roc: think it's relatively easy to expose a read-only long-lived information about the box tree
03:33:59 <rbyers> .. need to define what it is, but mainly an editorial issue
03:34:10 <astearns> s/long-lived/non-live/
03:34:23 <rbyers> .. exact details of getting browsers to match those specs may be non-trivial
03:34:37 <rbyers> .. but exposing in a read-only way shouldn't be too hard for any of us.  needed for drawing borders correctly etc.
03:34:47 <rbyers> .. has to be a non-live API
03:34:52 <rbyers> .. snapshot of the current state in time
03:35:04 <rbyers> .. different engines don't have these boxes sitting around.  tracking changes will be really painful
03:35:34 <rbyers> ChrisL you still want people to change the box model, just not directly right?
03:35:53 <rbyers> roc: providing mutation should be a separate problem
03:36:09 <rbyers> ..  best to separate the boxes that are under the browser's layout control from those under developer's layout control
03:36:29 <rbyers> .. simplify things if you can't change normal text line boxes
03:36:35 <rbyers> .. but some boxes controlled by script
03:36:45 <rbyers> glazou: some polyfills don't create new boxes, but change existing ones
03:36:50 <rbyers> roc: which properties?
03:37:03 <rbyers> glazou: eg. controlling the borders property - multiple borders around an element
03:37:13 <rbyers> .. that impacts the width and everything of the element
03:37:30 <rbyers> roc: I don't think you should do that by taking a box and changing it's width - implications on rest of layout is very complex
03:37:38 <rbyers> .. there are different ways of doing that (eg. anonymous dom nodes)
03:37:48 <rbyers> glazou: but we don't control what people are doing with polyfills
03:37:59 <rbyers> roc: as long as we provide some way, we don't need to provide every way
03:38:28 <rbyers> plinss: we want to provide a way for polyfills to do all these things eventually
03:38:39 <rbyers> .. but I agree with roc is that we start with a read-only box tree API
03:38:45 <rbyers> .. we can add hooks later on
03:39:01 <rbyers> .. layout system can invoke hooks - 'how big do you want to be before I create the box tree'
03:39:08 <rbyers> roc: yes, exactly
03:39:22 <rbyers> plinss: separate processes - start with static
03:39:35 <rbyers> glazou: ok, yes I'm fine with that.  Wanted to make sure we're not saying we'll never act on the box tree
03:39:42 <rbyers> roc: right
03:40:04 <rbyers> glazou: we closed doors like this 15 years ago - end up discussing them far too late
03:40:32 <rbyers> plinss: we may say API surface will always be immutable, but we may provide other means
03:40:58 <rbyers> SteveZ: this first step is hard enough without trying to add mutation now.  But we need to think about how we might mutate in deciding what to expose.
03:41:11 <rbyers> Rossen_SYD: I'm having a hard time understanding "what is a box tree"
03:41:25 <rbyers> .. it sounds like we're talking about the same thing, but I guarantee we're not
03:41:52 <rbyers> .. text in CSS is intentionally vague
03:42:01 <rbyers> .. almost conveys nothing
03:42:07 <bkardell> +1 to begin defining the box tree
03:42:21 <rbyers> roc: I think that's mainly editorial
03:42:21 <bkardell> at least at a high level you gotta start spelling it out
03:42:35 <rbyers> .. if there's a specific question, people in the room can probably say the answer
03:42:39 <franremy> FWIW, I don't believe in mutating boxes directly either.
03:43:05 <rbyers> dbaron: Tab, fantasai and I would independently give the same answer
03:43:11 <dbaron> ... most of the time
03:43:42 <rbyers> roc: we have a sequence of fragments that are actually nothing like a box, but I don't think it's hard
03:43:50 <rbyers> .. if you give me DOM I think I can tell you what the box tree should be
03:44:00 <rbyers> Rossen_SYD: but I think implementations will be different
03:44:19 <rbyers> roc: Right, I know our implementation doesn't do exactly build the box tree, but I think we can agree on what the tree is
03:44:27 <franremy> I think there's some confusion here between 'boxes' (layout by-product) and 'renderable boxes' (which I call slots) - polyfills may need both for different purposes
03:44:43 <rbyers> Rossen_SYD: where anonymous boxes come into play I think we have different internal representation
03:44:45 <rbyers> roc: but they're in the spec
03:44:56 <rbyers> Rossen_SYD: so is table fixup, but go check interoperability
03:45:02 <rbyers> roc: but other browsers are buggy and ours is right
03:45:08 <rbyers> .. ;-)
03:45:40 <bkardell> if it is easily defined/mostly editorial how hard should it be to sketch it out with a little bit of handwaving over difficult bits here in sydney so that you can talk about what to expose
03:45:51 <rbyers> ChrisL: this is why it needs to be a snapshot API - can't go both directions
03:46:03 <rbyers> roc: ok, what do we actually need on these boxes
03:46:07 <rbyers> .. geometry, width, height
03:46:10 <rbyers> .. what else do people want?
03:46:14 <rbyers> shans: first and last baseline
03:46:36 <rbyers> dbaron: what created the box - what element it was for, maybe some specific type of anonymous box
03:46:42 <rbyers> Rossen_SYD: we need to be able to define the types of boxes
03:46:52 <rbyers> .. if I have the table box, it should be reasonable to ask for columns and rows
03:47:01 <rbyers> .. line boxes will have different properties
03:47:13 <rbyers> ChrisL: is it true that any given fragment has exactly one box parent
03:47:30 <rbyers> roc: a box generates multiple fragments
03:47:42 <rbyers> .. for any given fragement it'll have a parent fragment but it is generated by a box
03:47:50 <rbyers> ChrisL: Makes sense
03:48:16 <rbyers> astearns: do we add properties to these boxes in addition to width/height - things that went into determining, content min, max
03:48:25 <rbyers> roc: fragements have content, padding, border, outline rectangles
03:48:38 <rbyers> .. might want to expose intrinsic width
03:48:48 <rbyers> .. intrinsics as well as actuals
03:49:11 <rbyers> johanneswilm: content of a line box would be a range
03:49:11 <ChrisL> and they are not (necessarily) axis aligned
03:49:16 <rbyers> roc: Really good question
03:49:25 <rbyers> .. we need ranges whose end points can be in anonynous content
03:49:35 <rbyers> .. not good enough to just be a dom range, need something slightly better
03:49:42 <rbyers> .. but really good point that fragments are going to cover a range
03:49:53 <rbyers> astearns: may have multiple ranges if something within the range has been floated out of that line box
03:50:07 <rbyers> roc: you could look at it that way, or I think you could ignore that problem
03:50:14 <rbyers> .. line has a start and end in content in the dom
03:50:19 <rbyers> .. assume everyting in between is part of the line
03:50:44 <rbyers> astearns: depend on how much script you have to write to figure out all of those edge cases
03:50:52 <rbyers> .. might be simpler to have a list of ranges
03:50:54 <rbyers> roc: yes
03:51:11 <rbyers> .. one more thing - with regions you can have different styles for different strings
03:51:19 <rbyers> .. if we go this way, we'll want to expose the style for each fragment
03:51:20 <bkardell> oh can the list have real array methods? :)
03:51:32 <astearns> s/regions/fragments/
03:51:54 <rbyers> Rossen_SYD: any group who wants to start defining boxes?
03:51:57 <rbyers> .. I am
03:52:01 <rbyers> shans: me too
03:52:08 <rbyers> .. I don't have a lot of expertise, but have lots of interest
03:52:15 <rbyers> plinss: me too
03:52:24 <iank___> me too
03:52:38 <rbyers> Rossen_SYD: Think we've touched on most of the topics in the agenda
03:52:42 <rbyers> .. what about custom paint?
03:52:49 <rbyers> iank: I talked about this a bit
03:53:12 <rbyers> Rossen_SYD: time to collect topics and figure out scope
03:53:20 <rbyers> .. and who is interested in what
03:53:40 <rbyers> 10-15 min break - back at 3:05 sydney time
04:02:25 <franremy> [using the break to react on the interesting "DOM ranges won't work for anonymous content" comment from roc: I think coming up with something other than DOM ranges would delay things a lot; anonymous content is usually simple so we could reuse standard DOM Ranges for anonymous content by spanning the range over a 'detached' DOM element like <div::before>Chapter 1</div::before>; i.e. we create a detached DOM node
04:02:25 <franremy>  that matches anonymous content but isn't attached to the document (and wouldn't be live-updating); this should be sufficient to make the polyfills happy]
04:03:58 <dstockwell> dstockwell has joined #houdini
04:08:42 <bkardell> am I the only one remote?  man it's getting late here :-|
04:08:54 <bkardell> well.... me and franremy :)
04:12:05 <franremy> [bkardell I guess ^_^ In European time the meeting is almost entirely during bed time: from 23:00 to 6:30 -- I took a break between 0:30 and 4:00 to sleep a bit]
04:13:08 <Florian> I am only sort of attending while switching planes (in Japan now)
04:23:29 <kwkbtr> kwkbtr has joined #houdini
04:24:07 <shans_> shans_ has joined #houdini
04:24:31 <rbyers> Topic: Scope and proposed charter
04:24:43 <rbyers> shans_: Our attempt to rationalize various topics discussed today
04:25:02 <rbyers> Rossen_SYD: Want to agree on a charter, and then proposed a list of agenda items we can work on more actively
04:25:14 <murakami> murakami has joined #houdini
04:25:43 <Rossen_SYD> Query interfaces
04:25:46 <Rossen_SYD> Box Tree
04:25:53 <Rossen_SYD> 	4. Font Metrics
04:26:04 <Rossen_SYD> CSS Event model
04:26:12 <Rossen_SYD> CSSOM?
04:26:43 <Rossen_SYD> Modification interfaces
04:26:46 <rbyers> glazou: No-one in the world would say the CSSOM was well designed - we should improve it
04:26:51 <Rossen_SYD> CSS Parsing
04:27:04 <Rossen_SYD> Property and Value Extensions
04:27:11 <Rossen_SYD> Selector Extensions
04:27:20 <Rossen_SYD> Cascade and Inheritance Extensions
04:27:30 <Rossen_SYD> Input Extensions (scrolling, pointers etc.)
04:27:41 <Rossen_SYD> Layout Extensions (r/w extensions to the box tree)
04:27:51 <Rossen_SYD> Paint Extensions
04:27:56 <rbyers> ChrisL: By box tree you mean box and fragment tree, right?
04:28:00 <rbyers> shans_: Yes
04:28:05 <rbyers> glazou: Also a media query extensions
04:28:09 <rbyers> shans_: Yes, we'll ad it
04:28:11 <rbyers> s/ad/add/
04:28:21 <rbyers> shans_: This is the proposed scope - and this should become the charter
04:28:40 <rbyers> dbaron: Modification includes what you need to do new properties?
04:28:48 <rbyers> Rossen_SYD: property and value extentions should cover that
04:28:55 <rbyers> glazou: What are property / value extensions?
04:29:06 <rbyers> Rossen_SYD: What the areas we want to be read-only, what will be read-write?
04:29:15 <rbyers> .. read-only: box, fox, events, and object model
04:29:28 <rbyers> rbyers: What are the other input extensions?
04:29:35 <rbyers> Rossen_SYD: Basically what's involved around scrolling
04:29:44 <rbyers> .. that I'm initiating scroll
04:30:17 <rbyers> rbyers: fair to say it's scoped to scrolling?
04:30:37 <rbyers> Rossen_SYD: scrolling is why we put it here
04:30:45 <rbyers> .. don't see a need for more, but we might want to extend it
04:31:00 <rbyers> vollick: Does it include extending compositer driven scrolling?
04:31:16 <rbyers> shans_:   Don't see why it's out of scope
04:31:24 <rbyers> vollick: The threading question...
04:31:32 <rbyers> shans_: Scrolling is interesting - half in and half out of CSS
04:31:38 <rbyers> Rossen_SYD: But we shouldn't say no just because of that
04:31:40 <bkardell> is isolation in scope?
04:31:49 <rbyers> .. houdini TF is joint between CSS and TAG
04:31:52 <rbyers> .. TAG covers everything
04:31:57 <rbyers> .. so I wouldn't rule out threading
04:32:03 <bkardell> q+
04:32:22 <rbyers> shans_: Yes, isolation fits inside cascade and inheritance extensions
04:32:37 <Rossen_SYD> q- bkardell
04:32:45 <gregwhitworth> gregwhitworth has joined #houdini
04:32:48 <rbyers> shans_: any other questions / alterations?
04:32:56 <rbyers> zakim, who is noisy?
04:33:09 <rbyers> zakim are you there?
04:33:10 <Zakim> rbyers, listening for 13 seconds I heard sound from the following: bkardell (3%), MeetingRoom (22%)
04:33:45 <rbyers> ??: click on a link and jump to a target usually causes a hashchange, but not always -
04:33:47 <vollick> vollick has joined #houdini
04:33:52 <rbyers> Rossen_SYD: part of input extensions?
04:33:53 <dbaron> s/??/xidorn/
04:34:07 <rbyers> .. Named input because we want to keep it vague and wide open
04:34:18 <rbyers> .. any input that modifies CSS or other primitives we're covering
04:34:22 <rbyers> .. so that issue should be in scope
04:35:09 <rbyers> RESOLUTION: Accept proposed list of topics as scope and charter of houdini
04:35:43 <rbyers> Topic: Figure out agenda for rest of today and tomorrow
04:35:52 <rbyers> shans_: Suggestion is to start with box tree this afternoon
04:36:04 <rbyers> .. tomorrow property value extensions, css parsing, font metrics and input extensions
04:36:08 <bkardell> no sound on the call...
04:36:12 <rbyers> glazou: Who will write the charter and put it in the wiki?
04:36:21 <rbyers> ACTION: shans_ and Rossen_SYD to write charter and put it in the wiki
04:36:38 <rbyers> bkardell: can you talk brian?
04:36:42 <rbyers> .. we hear something from you
04:36:58 <dbaron> Zakim, who is noisy?
04:37:11 <bkardell> am talking
04:37:16 <Zakim> dbaron, listening for 10 seconds I heard sound from the following: bkardell (4%)
04:37:22 <glazou> bkardell: did you just say « zrzrzrzrzrzrzrzrzrzrzrzrzrzrz » ?
04:37:26 <glazou> :)
04:37:37 <bkardell> lol no
04:37:42 <dbaron> Zakim, who is noisy?
04:37:55 <Zakim> dbaron, listening for 10 seconds I heard sound from the following: bkardell (45%), MeetingRoom (9%)
04:38:00 <bkardell> lolol
04:38:03 <bkardell> I am muted now!
04:38:09 <bkardell> how could I be 45%
04:38:17 <glazou> Zakim, unmute bkardell
04:38:17 <Zakim> bkardell was not muted, glazou
04:38:20 <bkardell> I'll just follow on irc
04:38:23 <Zakim> -bkardell
04:38:24 <glazou> ok
04:38:44 <Zakim> -MeetingRoom
04:38:45 <Zakim> Team_(houdini)02:37Z has ended
04:38:45 <Zakim> Attendees were +1.519.880.aaaa, MeetingRoom, bkardell
04:39:03 <dbaron> Zakim, room for 3?
04:39:04 <Zakim> ok, dbaron; conference Team_(houdini)04:39Z scheduled with code 26631 (CONF1) for 60 minutes until 0539Z
04:39:15 <Zakim> Team_(houdini)04:39Z has now started
04:39:22 <Zakim> +??P0
04:39:26 <dbaron> Zakim, ??P0 is MeetingRoom
04:39:26 <Zakim> +MeetingRoom; got it
04:39:56 <rbyers> shans_: if we start with box tree, it's clear we need a box tree spec
04:40:14 <rbyers> .. we should resolve to create a box tree specification as a work item and select editors
04:40:44 <rbyers> TabAtkins: put me down for everything
04:41:10 <rbyers> ??: I'm interested in line layout
04:41:19 <rbyers> shans_: does that belong in box tree spec or another spec?
04:41:26 <dbaron> (was the initial set peterl, rossen, shans, then Tab for everything, then Ian K?)
04:41:32 <glazou> s/??/szilles
04:41:43 <rbyers> szilles: If the box tree is the result of layout, then it should be
04:41:49 <glazou> s/szilles/SteveZ
04:42:07 <rbyers> shans_: I'd expect editors to actively modify text
04:42:21 <rbyers> .. sounds like TabAtkins IanK Rossen_SYD plinss shans_
04:42:27 <rbyers> .. are editors of box tree spec
04:42:55 <rbyers> RESOLUTION: New document - box tree spec, with editors TabAtkins iank Rossen_SYD plinss shans
04:43:17 <rbyers> Topic: box tree spec
04:43:21 <rbyers> shans_: Let's work out what's in, what's out
04:43:47 <rbyers> no-one is listening on the call, right?  Let us know if you want us to use microphones again
04:44:14 <rbyers> dbaron: Part of the problem with the box tree spec is that some of it belongs in the main css specs
04:44:33 <rbyers> astearns: box ree spec won't say anything about what boxes are generated from what input - that belongs in CSS specs
04:44:39 <rbyers> .. but the API for accessing boxes
04:44:51 <rbyers> TabAtkins: generating boxes will be the job of custom layout - separate topic
04:44:57 <rbyers> shans_: and also standard layout - css specs
04:45:11 <rbyers> shans_: Would like to see descriptions of how boxes are generated based on CSS properties
04:45:21 <rbyers> .. maybe not normative, and maybe we can move to CSS spec later
04:45:31 <rbyers> .. but would like a single place that defines what a box is and how it's generated
04:45:41 <rbyers> .. doesn't have to be in the main text - informative attached to the spec
04:45:56 <rbyers> ChrisL: What's the point in having informative text saying how the boxes are generated?
04:46:13 <rbyers> .. seems like API spec describes how to get at it, but if that turns up holes in the CSS spec then we fix the CSS spec
04:46:27 <rbyers> shans_: without saying what generates boxes, box spec describes how to get something that doesn't exist
04:46:35 <rbyers> astearns: I can imagine examples
04:47:08 <rbyers> shans_: nailing down the behavior we expect is a big part of the work here
04:47:19 <rbyers> astearns: a lot of the information you're asking for is already in the CSS specs
04:47:37 <rbyers> astearns: if there are additional pieces, we should add them into the css specs
04:47:44 <rbyers> ChrisL: I'm not arguing there's not gaps
04:47:58 <rbyers> .. I'm sure there are, but the correct place to fix those are in the CSS spec
04:48:30 <rbyers> SteveZ: Said another way: interoperability concern - aught to be a consistent box tree result for a given CSS input
04:48:36 <rbyers> .. if not, CSS spec is vague
04:48:48 <rbyers> Rossen_SYD: we should be driving all these missing pieces back into the CSS spec
04:48:58 <rbyers> .. defining APIs on something that's ill defined is counter productive
04:49:14 <rbyers> .. This is exactly what I Was alluding to when I was asking what a box is
04:49:42 <franremy> (just want to point out the boxes being defined may depend on the layout mode; do line-boxes make sense for a grid? that's maybe why we want the spec to talk about concrete cases even if we have to actually define them in css after that)
04:49:45 <rbyers> plinss: The CSS specs have lots of examples of 'weasel wording' - "there's a box here"
04:50:12 <rbyers> .. every css spec that defines layout/display property should have a section that says: "here are the boxes as exposed via the box API"
04:50:27 <rbyers> .. meanwhile we may need to put those in the box tree spec temporarily
04:50:34 <rbyers> shans_: so the box tree spec should eventually be quite small
04:51:04 <rbyers> Rossen_SYD: so what API surface do we want in the spec?
04:51:16 <rbyers> .. eg. Rob suggested maybe there should be some geometry in there
04:51:25 <rbyers> TabAtkins: some are exposed roughly by getClientRects
04:51:31 <rbyers> .. gives you geometry
04:51:47 <rbyers> .. Toru (?) has a basical proposal on the mailing list
04:51:51 <rbyers> s/basical/basic/
04:52:30 <rbyers> ??: Is the API asynchronous?
04:52:35 <rbyers> dbaron: At what granularity?
04:52:46 <rbyers> s/??/SimonSapin/
04:53:22 <rbyers> roc: If we want to figure that out we need to take time to figure it out.  But it's orthogonal - any API will have that issue.
04:53:36 <murakami> s/(?)/kwkbtr/
04:53:53 <rbyers> TabAtkins: What's the problem with returning a promise?
04:54:07 <shans_> (toru's proposal: https://lists.w3.org/Archives/Public/public-houdini/2015Feb/0001.html)
04:54:08 <rbyers> roc: By the time you get your promise resolved, the information might be out of date
04:54:21 <rbyers> .. does it return new information, old information
04:54:26 <rbyers> .. what guarantees are we making.
04:54:35 <rbyers> .. as weak as "at some point between the call and result the layout information was this"
04:54:59 <rbyers> shans_: having the ability to request when it's ready rather than force synchronous layout is useful
04:55:01 <dbaron> (issue was that there could be multiple promises outstanding, and then one of them changes the dom... what happens to the others)
04:55:42 <rbyers> TabAtkins: it should be possible to define this - resolved in order, when resolved it reflects the state at that time
04:55:57 <rbyers> roc: but then have you solved the problem that you wanted to with an async api?
04:56:06 <rbyers> dbaron: If every promise runs layout again then you haven't solved the problem
04:56:15 <rbyers> .. it's the only reason people are thrashing layout today
04:56:29 <rbyers> TabAtkins: Ok, we should give better affordances around that
04:56:37 <rbyers> roc: Good question to ask - why do people thrash layout today?
04:56:50 <rbyers> .. one I've heard is people having to modify dom to get the information they way
04:56:52 <franremy> getClientRects/getBoxQuads/offsetWidth are synchronous; why go asynchronous for boxes?
04:57:01 <rbyers> .. we can avoid that by giving APIs to get the information they want without modifying the dom
04:57:04 <rbyers> .. are the other cases?
04:57:28 <rbyers> iank___: Large code base, multiple teams each registering global click event handlers
04:57:39 <rbyers> .. each of which is reading layout
04:57:46 <rbyers> .. they can't reason globally about what everyone else is doing
04:58:03 <rbyers> roc: but they don't need to fear - one peice won't change the parts of another
04:58:19 <franremy> roc: yep, I temporarily mutate the style to get "min-width, min-prefered-width, max-prefered-width, max-width"; an API would be there, I wouldn't need to
04:58:19 <rbyers> TabAtkins: when you don't have one code base it's hard to separate all the reads and writes
04:58:36 <rbyers> roc: that's a good argument for your promise-based approach
04:58:57 <rbyers> TabAtkins: it would make it less likely for one person to read/write back and forth
04:59:07 <rbyers> .. it's easier to code all your reads and writes together
04:59:22 <rbyers> rbyers has joined #houdini
04:59:32 <rbyers> roc: one approach is to return the results from the last animation frame
04:59:44 <rbyers> .. information gauranteed to be obsolete by one RAF frame
05:00:12 <rbyers> TabAtkins: all resolved at once with same information fed to them - all looking at the same world
05:00:34 <rbyers> .. read/writes won't interfere with eachother
05:00:50 <rbyers> dino: If you have large code base - multiple parts trying to do something.  do you have any guarantees over the order?
05:00:54 <rbyers> roc: order doesn't matter
05:01:05 <rbyers> .. everything will work as long as callbacks doesn't modify the dom in ways that affect other callbacks
05:01:13 <rbyers> .. if they do, there's no escape from layout trashing / incorrect results
05:01:20 <rbyers> shans_: you already needed to know the relative order
05:01:23 <rbyers> roc: rgith
05:01:29 <rbyers> s/rgith/right/
05:01:46 <rbyers> iank___: You might get frame glitches if it's a frame late
05:01:50 <rbyers> roc: we can do it in the same frame
05:01:58 <rbyers> TabAtkins: As long as you're in your frame budget it should be fine
05:02:14 <rbyers> .. we'll know what things we need to freeze - don't need to ship the entire world over
05:02:44 <rbyers> dino: If you had two things you'd be OK in the layout trashing case - you'll get accurate results
05:02:49 <rbyers> shans_: but second one needs to know it was second
05:03:06 <rbyers> shans_: writing values doesn't force a layout
05:03:10 <rbyers> dino: OK, I think I've convinced myself
05:03:17 <rbyers> shans_: you need to explicitly force a layout in the second one
05:03:36 <rbyers> .. forcing a layout explicitly will help teach developers about the cost
05:03:52 <rbyers> johanneswilm: when you look at the box tree you may change DOM / CSS
05:04:21 <rbyers> .. rather than use a promise wouldn't it be easier to require the developer to ensure things are stable
05:04:35 <rbyers> roc: that's how it works today, but we need to provide a way
05:04:49 <rbyers> dino: if we're returning the results of the last RAF setup, why async?
05:05:00 <rbyers> roc: you want to get the results at the next frame
05:05:11 <rbyers> .. you don't want previous frame because then you need to keep the old layout tree around
05:05:20 <rbyers> dino: Makes sense
05:05:42 <rbyers> shans_: so you're setting up a record of the requests - what boxes script wants information about
05:05:58 <rbyers> .. just after RAF you get those results
05:06:07 <rbyers> roc: It depends exactly when, but yes
05:06:29 <rbyers> johanneswilm: ??
05:06:38 <rbyers> iank___: You're getting at dom measurement API?
05:06:50 <rbyers> johanneswilm: if you don't want us to mess up the DOM afterwards
05:07:02 <rbyers> TabAtkins: It's not about not messing up the dom, it's just too easy to do things in a bad ordering
05:07:07 <rbyers> .. want it to be easier to get the order right
05:07:22 <franremy> Q: could we say instead that getBoxes() caches the result once generated for an element up to a rAF, except if the code explicitely asks element.forceLayout() or forces a layout by any other mean?
05:07:25 <rbyers> vollick: related to dom and layout trashing - are we interested in rationalizing stacking context and containing blocks?
05:07:44 <rbyers> .. so you can eg. escape z-index jail,
05:07:52 <rbyers> TabAtkins: Not sure if this is Houdini or CSS positioning
05:08:10 <rbyers> roc: you're asking for new CSS features to escape from transform, etc.
05:08:17 <rbyers> vollick: Yes.  Technical reasons it's very tricky
05:08:23 <rbyers> roc: I hope this is out of scope
05:08:34 <rbyers> shans_:  either firmly in scope here or in CSS WG
05:08:43 <rbyers> TabAtkins: in scope may mean "that's crazy, we won't do it"
05:08:57 <rbyers> shans_: could look at it as z-index as a css feature
05:09:09 <rbyers> .. or that z-index controls a primitive 'stacking order'
05:09:21 <rbyers> dbaron: not just stacking order but whole painting model
05:09:26 <rbyers> roc: let's not do that here
05:09:31 <johanneswilm> johanneswilm: boxtree will only work for elements that are part of the current DOM, which means that developers will need to stick stuff into the DOM, get the boxtree, then change the DOM again.
05:09:33 <rbyers> dbaron: I think it's in scope for css
05:09:56 <rbyers> roc: none of what we have here tries to change the way CSS paints stuff
05:09:58 <rbyers> .. we've got enough to do
05:10:06 <rbyers> plinss: doesn't mean we can't come back to it
05:10:32 <rbyers> plinss: We talked about this with scrolling - think about it terms of box modification or layout
05:11:20 <rbyers> iank___: what information to we want to expose?
05:11:28 <rbyers> TabAtkins: parent relationships, ..
05:11:48 <rbyers> .. for different types of boxes we might want eg. margin info
05:11:57 <rbyers> roc: it's very hard to work this out for yourself
05:12:02 <rbyers> .. when a box has been split
05:12:25 <rbyers> dbaron: for parent relationships are you talking in terms of boxes or fragments?
05:12:30 <rbyers> TabAtkins: boxes don't have parent child relationships
05:12:37 <rbyers> roc: Yes they do, but they don't have geometry
05:12:45 <rbyers> TabAtkins: when you're doing geometry you need fragments
05:12:54 <shans_> shans_ has joined #houdini
05:12:56 <rbyers> astearns: For boxes it makes to get list of ranges being displayed
05:13:08 <rbyers> TabAtkins: easier for foxes - line boxes need to go into character ranges
05:13:22 <rbyers> Rossen_SYD: does CSS describe inline context?
05:13:23 <shans_> s/foxes/boxes
05:13:24 <shans_> :)
05:13:32 <rbyers> .. what is inside of a line box
05:13:52 <rbyers> .. bunch of runs, inline element, position: inline, absolute position items, attached in a line but float out for floating context, etc.
05:14:01 <rbyers> .. a bunch of context inside the line box that isn't explicitly defined
05:14:05 <rbyers> .. could be quite useful
05:14:11 <rbyers> .. where is a break
05:14:21 <rbyers> TabAtkins: once you expose line boxes, the nature of the break becomes an obvious thing about it
05:14:26 <rbyers> Rossen_SYD: depends what we expose on the line box
05:14:30 <vollick> vollick has joined #houdini
05:14:44 <rbyers> .. if I have a bunch of stacked spans in completely different line boxes, is this part of my break?
05:14:52 <rbyers> .. we need to drive something back to CSS to specify inline context
05:14:56 <rbyers> .. then we can define what APIs we want
05:15:06 <rbyers> .. eg. we need a dominant baseline
05:15:12 <rbyers> .. what if we expose all the runs and you can compute it yourself?
05:15:29 <rbyers> .. that would be more powerful - could figure out where all the baselines are, inline elements, how we arrived at the baseline
05:16:00 <rbyers> TabAtkins: as a start we expose the root fragments.  each has a list of fragments inside of it, the range of the dom tree contained within it.
05:16:09 <rbyers> .. can go down to line boxes, which can contain inline boxes
05:16:35 <rbyers> TabAtkins: generated content is a first class citizen here
05:16:41 <rbyers> .. need a property way to describe where that's going
05:16:50 <rbyers> .. generated content can contain inline fragements
05:16:58 <rbyers> roc: one problem is how do you get acccess to just the information you want
05:17:17 <rbyers> .. without forcing the engine to take a snapshot of the entire subtree
05:17:20 <rbyers> TabAtkins: good question
05:17:27 <rbyers> .. maybe you could not have parent pointers?
05:17:36 <rbyers> .. you only see the requested box and below
05:17:44 <rbyers> roc: but you still have to snapshot that subree
05:18:01 <rbyers> TabAtkins: maybe options - descendants or not.  maybe a filter
05:18:09 <rbyers> .. ways to delcaratively limit what we want to expose
05:18:23 <rbyers> .. easily reveal only what we want so people can't query arbitrarily
05:18:29 <rbyers> johanneswilm: would it make sense to limit how far down you go?
05:18:38 <rbyers> .. eg. may be interested in an element and it's immediate children?
05:18:45 <rbyers> TabAtkins: yes, I think you should able to specify that
05:18:52 <franremy> roc: that's where we can divide the api into variants. maybe some "box" variant don't have child info.
05:18:53 <rbyers> .. at least 'this element', 'this element and all descendants'.
05:19:04 <rbyers> SteveZ: are anonymous boxes children
05:19:31 <rbyers> TabAtkins: the fragment generated by a a before pseudo is a child of one of the fragments of it's generating element.
05:19:34 <rbyers> .. just like being a first child in the dom
05:19:39 <rbyers> astearns: and table fixup?
05:19:43 <rbyers> TabAtkins: those would show up?
05:19:50 <rbyers> astearns: but not as a child of the table cell
05:19:54 <rbyers> TabAtkins: no, a parent
05:20:25 <rbyers> .. if you ask for the boxes of a table, you'll get the row group, captions, etc.
05:20:39 <rbyers> .. depends on the different box types
05:20:43 <rbyers> Rossen_SYD: In the display spec?
05:20:54 <rbyers> TabAtkins: that's where we decided to explain element vs. box vs. fragment, but haven't done that yet
05:21:03 <rbyers> Rossen_SYD: type of boxes seems like an element for that module
05:21:11 <rbyers> TabAtkins: need to rewrite display box module
05:23:47 <rbyers> dbaron: table heights are not interopable between engines
05:24:50 <rbyers> gregwhitworth: Any ideas on what the API would actually look like?
05:25:17 <rbyers> .. don't see what we're talking about getting uptake from most web developers - very cumbersome and not intuitive
05:25:22 <rbyers> Rossen_SYD: eg. what would a selector look like?
05:25:35 <rbyers> gregwhitworth: yes, hope I don't get a stack of a single tree - need to look inside of it to make sense of it
05:25:44 <rbyers> TabAtkins: we could give the type eg. flexbox
05:25:51 <rbyers> gregwhitworth: yes, to make it more intuitive
05:26:00 <rbyers> TabAtkins: the nature of the fragment can be exposed here
05:26:16 <rbyers> .. what class you're using in your render tree
05:26:21 <rbyers> Rossen_SYD: we haven't discussed accessibility at all
05:26:50 <rbyers> shans_: query apis just exposing information that already exists - may help accessibility
05:27:08 <rbyers> Rossen_SYD: if there's not good semantics in the nodes then it won't help
05:27:22 <rbyers> TabAtkins: a screen reader reading off the json structure returned by the API?
05:27:25 <rbyers> Rossen_SYD: it could
05:27:41 <rbyers> dbaron: We should talk about what the tree relationships in the API actually look like
05:27:52 <rbyers> .. if you have both boxes and fragments you want parent relationships over fragments
05:28:03 <rbyers> .. you might want to decide if it's a more array like or list like api for children
05:28:19 <rbyers> .. but issue that causes confusion for people working layout code:
05:28:25 <rbyers> .. continuations vs. siblings
05:28:31 <rbyers> .. not sure we should expose that to the web
05:29:07 <dbaron> interface CSSBoxFragment {
05:29:07 <dbaron>   Node node; // or element? -- what about text
05:29:07 <dbaron> 
05:29:07 <dbaron>   DOMString anonymousType; // empty string for normal??
05:29:07 <dbaron> 
05:29:08 <dbaron>   CSSBoxFragment parent;
05:29:10 <dbaron> 
05:29:12 <dbaron>   // Previous/next fragment of same box
05:29:14 <dbaron>   CSSBoxFragment prevFragment;
05:29:16 <dbaron>   CSSBoxFragment nextFragment;
05:29:18 <dbaron> 
05:29:20 <dbaron>   // Previous/next box, whether fragment of same box or not, as long
05:29:24 <dbaron>   // as they're children of the same parent.
05:29:26 <dbaron>   CSSBoxFragment prevSibling;
05:29:28 <dbaron>   CSSBoxFragment nextSibling;
05:29:30 <dbaron> 
05:29:32 <dbaron>   // access to children
05:29:34 <dbaron> 
05:29:36 <dbaron>   // geometry information
05:29:38 <dbaron> };
05:29:54 <rbyers> dbaron: if you do something like this, you have two different prev sibling / next sibling links with different semantics.  neither is a subset or superset of another.
05:31:47 <rbyers> dbaron: Given this example with lines break as I've drawn them [photo coming]
05:32:19 <rbyers> p has 4 child fragments - 2 in each line box
05:32:45 <rbyers> each red box is a fragment
05:32:51 <bkardell> hey guys, I've got nothing interesting to add to this and I'm dozing - I'll catch up and rejoin tomorrow.
05:33:03 <rbyers> we have two sets of things
05:33:13 <rbyers> children of different parents don't have nex/prev siblings
05:33:48 <rbyers> but prev fragment / next fragment links aren't just for siblings
05:34:12 <rbyers> asking someone to walk over the tree once they'll usually mess it up
05:34:24 <rbyers> .. you want to walk over all the boxes of an element
05:34:32 <rbyers> .. you need to use the next fragment links of the element only
05:34:42 <rbyers> .. look at the next child links but not the next fragment or you might double walk the tree
05:34:48 <rbyers> .. do we want to expose this to web developers?
05:34:53 <rbyers> gregwhitworth: we can expose what makes sense
05:34:56 <rbyers> .. you would do this internall
05:35:01 <rbyers> s/internall/internally/
05:35:10 <rbyers> dbaron: Then what do you want to expose?
05:35:31 <rbyers> SteveZ: there's different levels of developers - those that don't want to see this and those building higher level facilities that do want to
05:35:47 <rbyers> gregwhitworth: you can see both
05:36:26 <rbyers> johanneswilm: wouldn't this all be there if we simply had a line box, each with fragments
05:36:36 <rbyers> TabAtkins: would have a similar structure, but arranged by line boxes
05:36:44 <rbyers> dbaron: this just adds another set of boxes - doesn't change the linkage
05:36:53 <rbyers> TabAtkins: you want to be able to say "for this span, where are the rest of it's fragments"
05:37:27 <rbyers> dbaron: In Gecko we call the green links sibling links, the black ones are continuation links
05:37:35 <rbyers> shans_: what about an API that gives you various walks over the structure
05:37:41 <rbyers> .. we do the hard work of iterating them correctly
05:38:08 <rbyers> dbaron: you could provide an iterator that solves the 'hard to walk over the whole tree', but may still be confusing
05:38:24 <rbyers> plinss: we need to expose this in the low level API but we need to be careful what to call them to explain them rationally
05:38:27 <rbyers> .. not 'next sibling'
05:38:37 <rbyers> .. I'm sure we can come up with names that make it more obvious
05:38:45 <franremy> TabAtkins: it's maybe orthogonal though-- fragment.ranges[0].commonAncestor.getAllFragments()
05:38:48 <rbyers> .. and we can also expose iterators to make it easy
05:38:58 <rbyers> .. but we have to explain this - it's fundamental stuff, people will have to learn this
05:39:17 <rbyers> johanneswilm: I know we JS developers have historically not been seen as real developers - but we're not less intelligent than everyone else
05:39:24 <rbyers_> rbyers_ has joined #houdini
05:39:29 <rbyers> .. if we want to build good web apps that are as good as native apps, why shoudln't we have these things?
05:39:36 <rbyers> .. people will make libraries
05:39:49 <rbyers> plinss: To do hit testing you can just walk sibling relationship - don't care about parent/child
05:40:29 <plinss> s^parent/child^continuation^
05:40:33 <rbyers> TabAtkins: I think we can cast these in an easy to understand way
05:40:48 <rbyers> plinss: I think we'd be doing a disservice to try to expose this as different trees with similar APIs
05:41:10 <plinss> s/with similar/with simpler/
05:41:30 <TabAtkins> TabAtkins: I was thinking about something like what François wrote.
05:41:56 <rbyers> rbyers: example of this sort of API in native platforms?
05:42:00 <rbyers> TabAtkins: kind of, yes
05:42:15 <rbyers> .. eg. in android there are ways to get at some of this stuff but I don't know details
05:42:28 <rbyers> iank___: Android is simple with it's text
05:42:41 <rbyers> dino: I bet one of the more complicated ones is Adobe's API for text in flash
05:42:57 <rbyers> rbyers: but we should make an attempt to learn from other platforms here
05:43:33 <rbyers> dino: the iOS one (CoreText) isn't nearly as complicated as what we have
05:44:00 <Zakim> disconnecting the lone participant, MeetingRoom, in Team_(houdini)04:39Z
05:44:03 <Zakim> Team_(houdini)04:39Z has ended
05:44:03 <Zakim> Attendees were MeetingRoom
05:44:32 <rbyers_> rbyers_ has joined #houdini
05:44:42 <dbaron> I think it's worth considering what the API would look like without exposing fragments in the primary API, but exposing them in something secondary.
05:44:45 <rbyers> dino: In general on iOS we expose more details but nowhere near as complicated layout
05:45:26 <rbyers> dbaron: maybe if you exposed the fragments as something secondary
05:45:38 <rbyers> TabAtkins: eg. for a span you ask either one for all it's fragments
05:45:48 <rbyers> roc: that won't tell  you which fragments are children of which other ones
05:46:10 <rbyers> TabAtkins: you get the initial view, but if you walk down and ask for all your fragments you'll get an array of two spans
05:46:17 <rbyers> roc: those span fragments, will they have parent pointers?
05:46:22 <rbyers> TabAtkins: don't know, we'll figure it out
05:46:32 <rbyers> .. will have to review some use cases to figure out API shape
05:46:50 <rbyers> johanneswilm: but you will get down to what text is where
05:46:54 <rbyers> TabAtkins: yes, you'll need to
05:47:15 <rbyers> Rossen_SYD: other one we expose outside HTML is the rich text box
05:47:18 <rbyers> .. part of the .NET platform
05:47:25 <rbyers> .. not as much richness as HTML / CSS
05:47:26 <Rossen_SYD> https://msdn.microsoft.com/en-us/library/system.windows.forms.richtextbox_methods(v=vs.110).aspx
05:47:30 <rbyers> .. but has a decent amount of API surface
05:47:41 <astearns> flash text api: http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flashx/textLayout/elements/package-detail.html
05:48:03 <glazou> glazou has left #houdini
05:48:07 <rbyers> iank___: part of WPF?
05:48:09 <rbyers> Rossen_SYD: In .NET 4.5
05:48:16 <glazou> glazou has joined #houdini
05:48:56 <shans_> https://wiki.css-houdini.org/_media/img_20150207_163553.jpg <- dbaron's fragment madness diagram
05:49:44 <rbyers> Rossen_SYD: so do we want to go after a model that exposes everything?  Or a simpler one with iterators?
05:49:53 <rbyers> shans_: seems to be lots of support for expressing everything
05:49:58 <rbyers> .. but we should try to back up with use cases
05:50:08 <rbyers> SteveZ: if you expose everything, then people can write iterators
05:50:21 <rbyers> .. otherwise you lock out some views people would like to have
05:51:04 <rbyers> Rossen_SYD: valid argument this isn't easy to get right
05:51:11 <rbyers> SteveZ: so people will produce iterators that will do the right thing
05:51:21 <rbyers> TabAtkins: I think I can create something nice, I just need to review some use cases
05:51:38 <rbyers> ChrisL: it doesn't mean we have to give the entire tree at once
05:51:45 <rbyers> .. it just has to be available through traversal
05:51:59 <rbyers> shans_: if we can cover all of the information with a good set of iterators then it may solve the snapshot issue
05:52:04 <rbyers> .. for a really large tree
05:52:19 <rbyers> Rossen_SYD: if you get back an iterator, now you're blocking until the iterator is released
05:52:44 <rbyers> .. but if you get back a collection (with the promise based approach) then the engine can continue modifying the tree
05:52:52 <rbyers> shans_: a certain amount of work needs to be done to prepare the data
05:53:03 <rbyers> .. if you don't have a way to restrict what you ask for...
05:53:07 <rbyers> TabAtkins: yes, we're going to have a way
05:53:16 <rbyers> .. there's an async barrier, you ask for all the stuff you want
05:53:45 <rbyers> shans_: our filters need to be really good
05:53:48 <rbyers> TabAtkins: I have a decent idea for this
05:53:58 <rbyers> .. need to see how well it satisfies the various use cases
05:54:17 <rbyers> shans_: are there any other box tree related concepts people want to discuss?
05:54:26 <rbyers> TabAtkins: this is excluding text measurement?
05:54:27 <rbyers> shans_: yes
05:54:36 <rbyers> .. I think the box tree tells you about what's there
05:54:48 <shans_> s/shans_/Rossen_SYD
05:55:02 <shans_> wait
05:55:04 <shans_> not entirely
05:55:25 <rbyers> Rossen_SYD: you get the structure of the boxes.  Should the box module cover the properties of the boxes themselves, or just the structure?
05:55:45 <rbyers> .. given the different types of boxes we will have, putting them all in this spec will be harry
05:55:50 <rbyers> .. but I could see it going either way
05:56:04 <rbyers> .. certainly measure, geometry information
05:56:09 <rbyers> TabAtkins: fragments will link back to their elements
05:56:30 <rbyers> .. while there's not a perfect correspondence between box properties and element properties it'll be pretty close
05:56:41 <rbyers> .. but anonymous boxes don't have any elements to go back to
05:56:46 <franremy> btw, something interesting to mention here is getClientRects return visual position, not layout one
05:57:02 <rbyers> Rossen_SYD: so what do you do with all the structure for boxes not backed by dom
05:57:13 <rbyers> TabAtkins: yes, so lets look at the use cases and see what's needed there
05:57:25 <franremy> you can't know where a box is in the inline flow without unapplying transforms/relative pos; that's annoying
05:57:36 <rbyers> shans_: So should this be excluding or including measurement?
05:57:46 <rbyers> TabAtkins: I imagine most of the use cases want to know sizing information
05:58:04 <rbyers> iank___: there's sizing and their is measurement - what size would you be given this constraint
05:58:13 <rbyers> TabAtkins: right, so this is sizing only.   measurement is elsewhere.
05:58:37 <rbyers> Rossen_SYD: good part of measurement API is it doesn't depend on layout
05:58:48 <rbyers> Rossen_SYD: Anything from the SVG point of view?
05:59:09 <rbyers> ChrisL: 2 years ago I would have said no - don't use the box model.  But in svg 2 trying to reuse text to use the box model.  So yes.
05:59:25 <rbyers> .. but it's not really clear how we're doing it but I think this will help and I Expect to see the same sorts of things exposed
05:59:51 <rbyers> TabAtkins: if you put width on a text element you get line boxes out
05:59:57 <rbyers> .. but rest is probably 1:1
06:00:01 <rbyers> Rossen_SYD: not sure about use, marker, etc.
06:00:11 <rbyers> ChrisL: I need to look into it, but in principle we want to use the same thing
06:00:15 <rbyers> .. how useful it would be I'm not sure
06:00:42 <rbyers> roc: text on a path fragments are transformed - not rectilinear relationship.  don't think we want to expose arbitrary transforms
06:01:12 <rbyers> .. seems less complicated to expose what we had before doing the path transformation
06:01:16 <rbyers> ChrisL: yes that's fine
06:01:32 <rbyers> roc: we use the same engine for html and svg text - would be hard NOT to return the same information
06:01:54 <rbyers> .. would be nice to have a box and fragment for each SVG element
06:02:05 <rbyers> .. per spec it's not clear it has a box, but I think it should and in Gecko it does
06:02:13 <rbyers> ChrisL: so each element generates a box and each is absolutely positioned?
06:02:23 <rbyers> roc: essentially yes, SVG has it's own layout model
06:02:27 <rbyers> Rossen_SYD: pretty much the same as what we have in IE
06:02:35 <rbyers> ChrisL: Not clear what this gets you
06:02:49 <rbyers> roc: tools that highlight elements you hover over - working the same for HTML and SVG
06:02:54 <rbyers> .. eg. that's how our devtools work
06:02:56 <rbyers> ChrisL: makes sense
06:03:18 <rbyers> plinss: In Gecko does the box of an SVG element give you the bounding box?
06:03:25 <rbyers> roc: it's a little confusing, we'd need to spec it out
06:03:33 <rbyers> .. there's an idea of an SVG bounding box
06:03:50 <rbyers> .. in Gecko we the CSS border box is the SVG bounding box
06:03:57 <rbyers> ChrisL: SVG 2 is adding the second bounding box - decorating bounding box
06:04:05 <rbyers> roc: we have this for all our elements internally, not exposed
06:04:11 <rbyers> ChrisL: painting box can be bigger
06:04:30 <rbyers> TabAtkins: ...  background is fill, border is stroke
06:04:55 <rbyers> plinss: Box API should be extensible so SVG can extend it
06:05:07 <rbyers> TabAtkins: or we map to HTML
06:05:12 <rbyers> plinss: but what will they have in a few years?
06:06:16 <rbyers> TabAtkins: Gecko has a propritary border-colors property to specify multiple borders
06:07:28 <rbyers> Rossen_SYD: anything else related to box tree?
06:08:01 <rbyers> ??: About box tree measurement - physical and logical are both needed in box tree measurement API
06:08:25 <rbyers> .. defines block size and inline size.  such APIs should be defined for box tree
06:08:51 <rbyers> s/??/xidorn/
06:08:51 <astearns> s/??/murakami/
06:08:52 <johanneswilm> ^ murakami
06:09:04 <rbyers> s/xidorn/murakami/
06:09:44 <rbyers> Rossen_SYD: when you read back results in the box tree they're post layout.  So eg. for vertical text should we be talking about width/height and origin for logical or physical point of view.
06:10:01 <rbyers> .. I could see us mapping those back and forth fairly straight forward
06:10:20 <rbyers> TabAtkins: I don't have a strong opinion, but I don't think it's bad to just report x,y,w,h (physical)
06:10:47 <rbyers> Rossen_SYD: eg. I want width and height of vertical line so I can constraint it somehow
06:11:07 <rbyers> .. but now you're putting the burden back on me to figure out what it was
06:11:11 <rbyers> .. should we perhaps expose both?
06:11:23 <rbyers> .. eg. in Trident everything is logical
06:11:26 <rbyers> TabAtkins: ours too
06:11:33 <rbyers> shans_: I don't think we can just expose logical
06:11:45 <rbyers> Rossen_SYD: we'll probably have to expose both, just like CSS
06:11:51 <rbyers> gregwhitworth: I don't think more options are a bad thing
06:12:03 <rbyers> .. we just need to make the API intuitive - that'll be the hardest part
06:12:18 <rbyers> shans_: we'll have to be very careful about names
06:12:25 <rbyers> gregwhitworth: I truly hope there won't be a need for a library
06:12:33 <rbyers> .. there should be a simple way
06:12:50 <rbyers> .. so if physical is the easiest way for me to understand it, I should be able to get it
06:13:09 <rbyers> plinss: But extensible web manifesto says to expose the base primitives and let people make libraries
06:13:14 <rbyers> .. then we wait to see what libraries become popular
06:13:27 <rbyers> .. if we try to predict all the interesting usages and APIs we're going to take a long time and still get it wrong
06:13:42 <rbyers> .. let's do something simple and basic that people can build on top of, and see what people do
06:13:46 <rbyers> roc: yes
06:14:04 <rbyers> shans_: so logical vs. physical might be important because they are pieces of fundamental information
06:14:31 <rbyers> plinss: all the base information should be available.  but if I can compute all the logical dimensions from the physical plus style info then I don't have to expose them.
06:14:58 <rbyers> .. a common thing in these APIs is whether to use a parent-relative co-ordinate space or other origin
06:15:04 <rbyers> .. we end up converting back and forth
06:15:11 <rbyers> Rossen_SYD: do we expose used values or actual values or both?
06:15:16 <rbyers> .. pre-transform or post-transform
06:15:24 <rbyers> .. we obviously want the result of layout
06:15:32 <rbyers> .. but another layer of all the transforms applied on top of it
06:15:47 <rbyers> dbaron: don't like 'actual value' term
06:15:54 <rbyers> .. spec uses it but fails to define it
06:16:30 <rbyers> roc: One option is to ignore transforms for this box spec, return co-ordinates relative to something local.  eg. fragments for an element are relative to top-left of element's border box.
06:16:42 <rbyers> .. then use geometry APIs to compute relative to other elements
06:16:51 <rbyers> .. if we put transforms into here the API will be more cumbersome
06:17:00 <rbyers> shans_: yes, it's more consistent for transforms not to be part of this
06:17:11 <rbyers> roc: we've already spec'd out conversions of quads between any two elements
06:17:14 <rbyers> .. don't need to do that again
06:17:40 <franremy> and what about "position:relative;top:X;"?
06:17:48 <rbyers> xidorn: I'm concerned that some spec defines anonymous boxes but doesn't define the process to create it
06:18:03 <rbyers> Rossen_SYD: part of the box tree?
06:18:23 <franremy> because the 'inline' layout use the position without the 'top' being applied, yet people may expect to get position applied
06:18:25 <rbyers> shans_: We might need to update spec text for this
06:18:40 <rbyers> shans_: We should change spec text to say boxes are created for purposes of box tree API
06:18:52 <rbyers> plinss: CSS spec should be defining what boxes show up for the box tree API
06:18:58 <rbyers> shans_: doesn't mean engines need to store additional data
06:19:04 <rbyers> plinss: engine can always synthesize responses to the API
06:19:12 <rbyers> dino: they're going to have to anyway
06:19:25 <rbyers> Rossen_SYD: we've optimized the engine so there's nothing left
06:19:35 <rbyers> astearns: What about franremy's question?
06:19:45 <rbyers> Rossen_SYD: position: relative is something we compute during layout
06:19:52 <rbyers> .. it's reasonable to have it
06:20:01 <rbyers> .. if it's used value then it should be exposed
06:20:29 <rbyers> dbaron: I don't know that I'd draw the distinction based on used value or something else
06:20:42 <rbyers> Rossen_SYD: in your box tree, are you storing the relatively offset box position
06:20:46 <rbyers> dbaron: yes
06:20:48 <rbyers> Rossen_SYD: same for us
06:20:54 <rbyers> dbaron: I agree relative stuff should matter
06:21:01 <rbyers> .. just that 'used' isn't the distinction
06:21:13 <rbyers> s/used/used value/
06:21:42 <rbyers> Rossen_SYD: anything else we want to discuss?
06:21:50 <rbyers> shans_: probably more productive to start getting some spec text
06:22:24 <rbyers> Rossen_SYD: break for the day or move on to the next topic?
06:22:28 <rbyers> .. property and value extensions
06:22:32 <rbyers> iank___: that's probably quite big
06:22:42 <rbyers> roc: could we get more done by splitting in two?
06:22:47 <Zakim> ChrisL, you asked to be reminded at this time to go home
06:23:06 <rbyers> .. there's the style system then after you've computed style there's extending layout and painting
06:23:07 <franremy> I think Zakim solved the question for us
06:23:12 <rbyers> .. I'm really only interested in the latter
06:23:31 <rbyers> dino: how full is the CSS agenda?
06:23:47 <rbyers> roc: if not too many people are interested in both we could get more done
06:23:53 <rbyers> Rossen_SYD: people will gravitate to one or the other anyway
06:27:54 <rbyers> Rossen_SYD: adjurned for the day
06:32:58 <johanneswilm> johanneswilm has joined #houdini
06:42:33 <Zakim> Zakim has left #houdini
06:51:38 <shane> shane has joined #houdini
07:00:26 <johanneswilm> johanneswilm has joined #houdini
07:03:25 <vollick> vollick has joined #houdini
07:48:34 <kwkbtr> kwkbtr has joined #houdini
07:55:03 <kwkbtr_> kwkbtr_ has joined #houdini
07:56:29 <kwkbtr__> kwkbtr__ has joined #houdini
08:06:11 <Florian> Florian has joined #houdini
09:56:58 <shans_> shans_ has joined #houdini
10:00:00 <Rossen_SYD> Rossen_SYD has joined #houdini
10:08:55 <Rossen_SYD> Rossen_SYD has joined #houdini
10:26:32 <Rossen> Rossen has joined #houdini
10:42:44 <kwkbtr> kwkbtr has joined #houdini
11:32:03 <franremy> franremy has joined #houdini
12:05:35 <kwkbtr> kwkbtr has joined #houdini