22:08:24 RRSAgent has joined #houdini 22:08:24 logging to http://www.w3.org/2015/02/07-houdini-irc 22:08:29 RRSAgent, make logs public 22:08:35 RRSAgent, this meeting spans midnight 22:08:42 Zakim has joined #houdini 22:08:47 Zakim, remind us in 9 hours to go home 22:08:47 ok, dbaron 22:09:31 xidorn has joined #houdini 22:09:50 dino has joined #houdini 22:10:07 SteveZ has joined #houdini 22:11:42 Zakim, room for 10 22:11:42 I don't understand 'room for 10', rbyers 22:12:19 Zakim, room for 3? 22:12:20 ok, rbyers; conference Team_(houdini)22:12Z scheduled with code 26631 (CONF1) for 60 minutes until 2312Z 22:13:35 Team_(houdini)22:12Z has now started 22:13:42 +??P0 22:13:44 -??P0 22:13:45 Zakim, ??P0 is MeetingRoom 22:13:46 Team_(houdini)22:12Z has ended 22:13:46 Attendees were 22:13:46 sorry, dbaron, I do not recognize a party named '??P0' 22:14:04 Zakim, room for 3? 22:14:04 dbaron, an adhoc conference was scheduled here less than 2 minutes ago 22:14:33 Team_(houdini)22:12Z has now started 22:14:33 shans_ has joined #houdini 22:14:40 +??P0 22:14:41 Zakim, ??P0 is MeetingRoom 22:14:41 +MeetingRoom; got it 22:15:15 gregwhitworth has joined #houdini 22:15:37 krit has joined #houdini 22:15:47 ChrisL has joined #houdini 22:16:05 roc has joined #houdini 22:16:35 Rossen: yesterday we had introductions. Today we get to do magic tricks 22:17:04 Rossen: introducing Dirk, Elliot and Jet 22:17:34 Elliot: introduces himself 22:17:38 Dirk: introduces himself 22:17:45 (Elliot Sprehn, Dirk Schultze, Jet Villegas) 22:17:45 Jet: introduces himself 22:17:52 esprehn_ has joined #houdini 22:17:54 ScribeNick: roc 22:18:06 Rossen: start with parsing 22:18:32 Rossen: recap: we did agree on a scope and charter for the WG .... pretty much anything goes at this point? 22:18:39 Dirk: when does the CSSWG join Houdini? 22:18:56 dbaron has joined #houdini 22:19:24 Rossen: yesterday we discussed boxtree. Agreed on an initial set of editors. Resolution to start working on a draft. Shane checked in the first version of a draft 22:19:27 Shane: not much in there 22:19:53 Rossen: that went well yesterday. Let's figure out the set of people interested in extending the CSS parser and figure out the scope of that module 22:20:01 Rossen: Daniel, please start 22:20:08 Daniel goes to whiteboard 22:20:35 Daniel: Currently people do quirky things with regexps and homemade parsers that are partial and have lots of problems and bugs with character sets and everything 22:20:55 Daniel: it feels wrong to reimplement when the browser has a parser 22:21:23 Daniel: concrete example: my own tool. I all the time have to parse selectors, rules, values, unknown properties, complete stylesheets 22:21:38 jet has joined #houdini 22:21:39 Daniel: can't use browser to preserve unknown properties and values 22:21:52 Daniel: complex backgrounds and gradients are the worst. 22:22:09 Daniel: often have to parse, modify one single value, and regenerate 22:22:18 Daniel: Need a CSS.parser API 22:22:57 roc: so this is about exposing the parser, not extending the parser? 22:23:00 Daniel: right 22:23:51 SteveZilles: 2 things: callback on error; send a string to the parser with some context information and get back some table or something 22:24:10 Daniel: need to expose structures for selectors, values etc 22:24:38 Daniel: CSSOM exists for values but it's bad. Selectors are not exposed at all 22:24:55 Daniel: these things are built into every browser and we should be able to use that 22:25:27 Daniel: writes "CSS.parser; internal representation" ... "Selectors; updated CSSValue" 22:25:47 Daniel: a lot of complex values like gradients are not exposed through CSSValue 22:25:54 accessing one color of a color stop is a real pain 22:26:34 Daniel: a few bits we miss from the OM... a CSSText attribute on rules, but not stylesheets. Another paint 22:26:38 Rossen: a very common ask 22:27:07 Daniel: if you tweak one style rule and you want to reserialize everything, you cannot do that by querying the CSSText on the stylesheet. Rendering engine has all the machinery but we can't get it 22:27:18 Daniel: writes "OM consistency" 22:27:35 Jet: would you expect CSS variables to be evaluated before parsing or after? 22:27:57 Daniel: we can even forbid variables if you like 22:28:10 Daniel: restrictions on this are perfectly understandable and acceptable 22:28:32 PeterLinss: I would not expect variables to resolved at this point 22:28:38 Tab: at parse time they're just a list of tokens 22:29:04 Simon: maybe extrapolating variables could be a separate step from parsing 22:29:07 Daniel: sure 22:29:29 Daniel: Steve, I agree about the callbacks. That's a very good idea 22:29:52 Daniel: you can understand it in different ways. You want a callback on errors, or when somethings unrecognized in the OM 22:29:55 present: Elliott Sprehn (Google), Steve Zilles (Adobe), Greg Whitworth (Microsoft), Murakami Shinyu (Vivliostyle ), Rick Byers (Google), Ian Kilpatrick (Google), Kawakubo Toru (Vivliostyle), Alan Stearns (Adobe), Dean Jackson (Apple), Johannes Wilm (Vivliostyle), David Barron (Mozilla), Xidorn Quan (Mozilla), Tab Atkins (Google), Daniel Glazman (Disruptive 22:29:55 Innovations), Chris Lilley (W3C), Peter Linns (HP), Simon Sapin (Mozilla), Dirk Schulze (Adobe), Robert Ocallahan (Mozilla), Jet Villegas (Mozilla), Shane Stephens (Google), Rossen Attanasov (Microsoft) 22:30:20 Daniel: I know that throwing away unrecognized stuff is a useful restriction in browsers, but it's a problem for editors 22:30:46 ChrisLilley: could parse everything, optionally stores everything, and then optionally throws away everything it doesn't understand 22:30:59 bkardell_ has joined #houdini 22:31:02 ChrisLilley: seems cleaner to mark things as dirty and then throw them out 22:31:13 Daniel: like syntax highlighters. 22:31:18 sorry I am late.. is there a line open? 22:31:32 Tab: CSS syntax does no validation. expects a later phase to throw things away 22:31:44 bkardell, yes we're on the call but we haven't been using mics 22:31:59 but we can star using mics if you want to dial in 22:32:08 Rossen: either use the parser as an evaluator, or use it to parse the current style sheet? 22:32:24 bkardell, code is 26631 22:32:24 +??P1 22:32:38 Daniel: what is interesting to me (just my projects) is getting the parsed representation of what I pass as an argument: stylesheet, rule, declaration or value 22:32:53 Daniel: then tweak one single token and reserialize it 22:33:11 Shane: is performance an issue here? sounds a bit slow. is this going to impact browser's evaluate paths? 22:33:25 Daniel: don't we have exactly the same problem as queryselector? 22:33:38 (Brian joins the phone call) 22:33:38 Zakim, ??P1 is bkardell 22:33:38 +bkardell; got it 22:33:51 Daniel: querySelector has the same issue 22:34:03 Rossen: so does @supports 22:34:32 Shane: if you take an entire stylesheet, tweak and reserialize it might not perform well 22:34:54 Daniel: non-issue because you're in an editor where performance is less of an issue because the user hit the save button or did an action with an input event 22:35:30 Daniel: only case where it's an issue is when you're in an animation editor and you change a stop, but we're already doing it with good performance in JS 22:35:45 so not an issue with native code 22:36:01 shane: just exposing a JS implementation with Web Animations can avoid string conversion cost 22:36:09 shane: should we do this? 22:36:13 Daniel: sure 22:36:34 Tab: react.js bypassing CSS, would be helped by ability to throw a CSS object at the DOM 22:36:43 Tab: and style an element 22:36:51 Daniel: a few other areas: CSS extensions to the parser 22:37:14 Daniel: being able to declare a new pseudoclass, a new combinator, whatever 22:37:34 Daniel: a few things in the OM would like to see fixed: all the insertion methods rely on indexes, this is seriously broken 22:37:42 Daniel: need to insert a rule before/after a given rule 22:38:08 Daniel: check many Websites doing editing, all computing the indexes of rules all the time 22:38:18 Daniel: feels like 1995 22:38:44 Daniel: how do we do this given the current OM? 22:39:05 Improving existing seems unlikely 22:39:06 Daniel: given compat issues? do we need another one? can we improve this one? 22:39:32 I am with daniel here, proposed this myself 3-4 years back 22:39:46 Tab: have ideas, depend on value objects in JS, hopefully they'll show up soon 22:40:12 Daniel: points at Selectors/CSS Values 22:40:16 Rossen: those are next on the agenda 22:40:34 Daniel: selectors are not too complicated. There will be discussions about making them performant 22:41:26 Daniel: Perfectly willing to edit a proposal. I can dedicate a lot of time to that. I will dogfood it, I miss it 22:41:47 RickByers: all sounds super exciting. TAG wants us to not just make CSS extensible, but explain it 22:42:14 RickByers: can't write an alternate CSS parser 22:42:19 Tab: you can fetch, parse, reserialize 22:42:41 Daniel: I had STTS ... a CSS-like language 22:42:51 Daniel: these properties change the tree 22:43:23 RickByers: would this parser API help with that? 22:43:26 Daniel: yes 22:43:44 Rossen: sorry, but where's the *ordered* agenda for today to be found? can't stay for the whole thing, would like to schedule my sleep time? 22:43:47 we have to decide whether to return just a set of tokens or more than that? 22:44:03 Daniel: if I can only get partial things I'll live with that 22:44:19 Daniel: some areas of the browser are considered to be moved from CSS to JS 22:44:35 Daniel: seriously discussed moving all editing from C++ to JS 22:45:09 Daniel: In Gecko most HTML editing rules could be exported to JS 22:45:34 Dirk: you already mentioned the parser might return tokens? is there a way it could return an OM? 22:46:01 Daniel: the problem is for selectors. their parsing is a bit peculiar 22:46:02 rework has something, not great, but not bad either 22:46:11 it's not so much OM, almost like AST 22:46:19 Daniel: dealing with only tokens is complex. You need heuristics to figure out selectors 22:46:25 Daniel: I'd love to have access to both 22:46:46 PeterLinss: should have a low level API to return tokens, and a parser that consumes tokens 22:46:58 esprima might be a good corollary 22:47:09 Daniel: my code is like that 22:47:26 Dirk: CSS syntax already specifies tokenizer? 22:47:27 Tab: yes 22:47:35 Peter: just need to expose it 22:47:37 franremy: updated here: https://wiki.css-houdini.org/planning/sydney-2015?&#actual-agenda 22:47:42 Daniel: can be an iterator on strings 22:48:01 franremy: I expect this and values to take the morning 22:48:03 Daniel: who's willing to work on a spec? 22:48:07 Tab raises hand 22:48:39 Elliot: all engines have tokenizers, but some engines may not build a tree structure (cites V8 as example) 22:48:51 Zakim, q- 22:48:51 I see Tab on the speaker queue 22:48:54 q- 22:48:58 Hm. 22:49:04 ack 22:49:07 Daniel: this is something extra that we'll build 22:49:07 zakim, ack 22:49:07 I don't understand 'ack', TabAtkins 22:49:11 Elliot: just for editors? 22:49:14 Daniel: no, Webapps 22:49:42 Daniel: you will never inject what you've parsed into the engine. It's made for consumption by apps 22:50:01 shane: Thanks; I'll try to stay till 2am (noon); I'm interested in everything, but I have to make a choice ^_^ 22:50:02 dino: you're not talking about extending the parser, just getting access to what it's done 22:50:08 Daniel: I'm interested in both 22:50:23 dbaron: I'm having trouble understanding what this API's like 22:50:39 dbaron: parsing depends on context. What's generic between a token stream and an object model? 22:50:49 zakim, q- Tab 22:50:49 I see no one on the speaker queue 22:50:49 dbaron: the parser has custom logic to convert from tokens to OM that's context sensitive? 22:51:13 dbaron: you could build a tree that corresponds to the OM, but if you put enough information in the tree to validate that it's correct syntax, you're back to a token stream 22:51:33 dbaron: validating gradient syntax requires checking parens, commas, spaces 22:51:54 TabAtkins: the current output of the parsing stage is a function object with a token stream argument 22:52:04 TabAtkins: you are *so queued* 22:52:06 dbaron: a hierarchical token stream? 22:52:13 Tab: yes. Function and block structure and that's it 22:52:26 dbaron: not a whole lot else there 22:53:20 Daniel: return value could be a function with a comma-separated list of values, each stop a space-separated list of values, each a list of one color and one percentage 22:53:44 Daniel: I'm open to anything 22:54:01 TabAtkins: good idea to expose parser/tokenizer 22:54:08 TabAtkins: exact shape can be discussed 22:54:28 Rossen: we have Daniel and Tab so far. Simon, are you interested? 22:54:35 I am interested 22:54:37 Daniel: you gave me good feedback 22:54:43 Simon: definitely interested in reviewing 22:55:09 Brian: Esprima is a similar thing 22:55:22 Brian: rework has a nice thing, halfway between AST and OM 22:55:22 ReworkCSS 22:55:48 Daniel: is extensions to the parser now> 22:55:53 Rossen: yes 22:56:36 Daniel: first thing that comes to mind is psuedoclasses 22:56:57 Daniel: you need very little context, it replies with just a boolean, so it's quite easily extensible 22:57:05 we didn't capture Tab's resolution btw 22:57:08 Daniel: tab wants a declarative way 22:57:12 TabAtkins: I want both 22:57:28 Daniel: would prefer a link between a JS function and a CSS declaration 22:57:33 Daniel: actionscripts 22:57:47 Daniel: wanted to preserve the ability to disable JS and CSS. Seems so long ago 22:58:19 Daniel: so easy to write function foo() of one argument that returns bool 22:58:28 TabAtkins: current proposal is just an alias 22:58:44 most custom selectors like JQuery can be declarative 22:58:58 Daniel: I don't think we need two solutions 22:59:10 dbaron: are you talking about a way to add/rmeove elements from a set 22:59:16 TabAtkins: a way to turn one selector into another in JS 22:59:38 TabAtkins: I'm lying about that 22:59:39 s/about a way/about a function that takes an element and returns a boolean or about a way/ 22:59:42 TabAtkins: the current approach is aboolean function 22:59:54 TabAtkins: a base selector to limit which elements are applicable 22:59:58 TabAtkins: run that function on a bunch of elements 23:00:07 TabAtkins: do some caching stuff there 23:00:34 roc: you don't want to run user JS that accesses the DOM during selector matching. 23:00:42 roc: not just performance; safety issues 23:01:03 Zakim: q+ 23:01:20 Zakim, q+ 23:01:20 I see shane on the speaker queue 23:01:22 TabAtkins: polyfill works OK 23:01:33 roc: browser might want to selector matching when it's not safe to run user JS 23:01:47 s/polyfill/HitchJS polyfill/ 23:01:49 https://www.irccloud.com/pastebin/WtJrSusx 23:01:57 shane: I was just going to say there might be other ways of doing script for custom selectors 23:02:08 shane: that wouldn't require you to run JS inside selector matching 23:02:12 shane: might need a pre-match call 23:02:22 Zakim, q- 23:02:22 I see no one on the speaker queue 23:02:34 Elliot: if you're just adding an element to a set, how is this different to a class? 23:02:50 dbaron: mostly not, it might be that something doesn't want to expose that set to other parts of code? 23:03:05 TabAtkins: simple declarative is better than a class, it handles mutations for you 23:03:26 shane: the set changes 23:03:42 Elliot: when would this be useful? 23:03:51 TabAtkins: jquery has custom pseudoclasses that it accepts 23:03:55 TabAtkins: :heading 23:03:57 TabAtkins: :input 23:04:11 TabAtkins: these simple things are really useful 23:04:26 we did an examination of this, jquery had like more than a dozen, most of which are simple aliases 23:04:26 TabAtkins: Brian's being working on this in Hitch 23:05:01 Daniel: good for prototyping polyfilling 23:05:13 custom things are better for standards in a lot of cases too - prototype your solution, let's use and evaulate it 23:05:23 dino: wanted to reemphasize what Roc said: running JS code for selector matching will be a perf hit 23:05:28 dino: prefer declarative way 23:05:53 Elliot: we have a sophisticated invalidation system. We potentially will ahve to invalidate all custom selectors 23:06:09 (something to think about: if selectors are extensible, there's a huge conflict risk -- jQuery first tries to give a selector to the native engine, we may have conflicting meaning for selectors) 23:06:17 TabAtkins: with the current API shape, we have a base selector to tell you what it cares about 23:06:47 TabAtkins: we'll see if it's good enough 23:07:27 Daniel: extending parser is in Tab's specs. Where are extensions physically in the stylesheets? always before everything? 23:07:36 Daniel: need JS API to achieve the same thing 23:07:56 Daniel: need to discuss interactions with variables 23:08:19 Rossen: everything should be on the table 23:09:06 TabAtkins: informal namespacing works pretty well 23:09:39 TabAtkins: we can introduce namespaces later if we need to 23:10:03 Rossen: anything more? 23:10:09 Daniel: one special beast: pseudoelements 23:10:34 Daniel/Simon: definition of pseudoelements is the issue 23:10:54 Rossen: anything more for the parser discussion? 23:11:00 re TabAtkins: so, with "--" prefix to avoid conflict with native and not like jQuery, right? 23:11:16 Yeah. 23:11:42 ok, that was my concern; 23:11:42 dino: could do a lot of parser extensions through declarative API --- CSS variables-like aliasing/psuedoclasses 23:11:56 dino: possibly not what Daniel needs 23:12:06 Daniel: not just for myself only 23:12:45 Rossen: resolution: who are the final editors? Daniel, Tab, Shane 23:12:51 Rossen: any objections? 23:13:23 Resolved: Tab, Shane and Daniel to start work on CSS Parser 23:13:34 correction 23:13:45 Resolved: Tab, Shane, Daniel and Brian to start work on CSS Parser document 23:14:02 might be good to call it "CSS Parser API" to make it a little more distinct from CSS Syntax... 23:14:32 dbaron +1 23:15:45 Florian has joined #houdini 23:40:46 Ojan Vafai is now here 23:40:49 (Google) 23:40:55 Rossen: next topic: property and value extensions 23:41:10 TabAtkins: Custom Properties spec optimizes for variable setters 23:41:30 TabAtkins: Need a Variables level 2 to help us with custom properties ... specify initial value, inheriting, animation behavior 23:41:47 TabAtkins: Elliot and Ojan have put thought into custom properties being used to drive layout and other thigns 23:42:05 murakami has joined #houdini 23:42:44 dbaron has joined #houdini 23:44:06 esprehn: current shape: 23:44:13 johanneswilm has joined #houdini 23:45:07 esprehn: writes "registerProperty({ name : "width", syntax : CSSLengthSyntax" ... syntax a function that takes a token stream and returns an object 23:45:43 esprehn: "inherit: boolean; iniitalValue: new Length(0);" 23:45:55 esprehn: Tab wants object types here, they don't exist yet 23:46:18 Daniel: in syntax line, your function returns an object, but your initial value is only a length? 23:46:34 Ojan: syntax function needs to return an object an object of type Length 23:46:45 esprehn: "invalidation: Paint, Layout, Style, none" 23:46:51 s/object types/JS Value Objects/ 23:46:59 esprehn: probably just make initial value a string 23:47:12 TabAtkins: thx 23:47:36 esprehn: Layout makes sense for custom layout, Paint could be like Color, style means recompute style 23:47:49 TabAtkins: lets the engine know what kinds of things to update 23:47:55 Dirk: how to handle animations 23:48:24 Dirk: cannot define custom types? 23:48:26 shane: yes you can 23:48:46 esprehn: "type: CSSLengthType" 23:49:01 Earlier sketch for a better CSSOM API, based on Value Objects: http://www.xanthir.com/b4UD0 23:49:04 Ojan: layout just means "changes size and position" 23:49:07 I presented this to the CSSWG last year. 23:49:23 esprehn: writes "invalidation: geometry, paint, none" 23:49:57 esprehn: there's AnimatedType, e.g. LegnthAnimatedType. There's a resolve, which takes values and returns a fixed value, something the engine understands 23:50:07 esprehn: AnimatedType has an invalidate() 23:50:26 just keep invalidating and we'll come around and get a different value 23:50:52 shane: can just use Web Animations 23:51:05 esprehn: ok as long as output type is something Web animations understands 23:51:26 shane: interpolation is hard, we should leverage Web Animations 23:51:34 expose an interpolator for each type 23:52:11 Dirk: the function is supposed to register new properties. Or to register properties already defined? 23:52:17 esprehn: register new properties. 23:52:28 esprehn: writes "name: x-width" 23:52:41 esprehn: e.g. a width that always divides by 2 23:53:02 Dirk: if you create custom properties, will they have -- at the beginning? 23:53:04 TabAtkins: yes 23:53:12 esprehn: writes "--width" 23:53:26 esprehn: when is it safe to run script? Uses a separate Realm 23:53:47 esprehn: ES6 realms. Separate scripting context. register properties inside of them. Can call in when it's normally unsafe to run script 23:54:09 dino: when do you do that? Does registering a property reparse everything? 23:54:35 esprehn: we don't discard them. Or we could make sure you have to register before 23:54:41 dino: what if you want to override? 23:54:48 esprehn: I think it would be extremely powerful 23:54:57 dino: we don't provide that currently 23:55:04 quick note: realms are deferred to ES7 :( 23:55:28 esprehn: people will want to add new things to existing properties 23:55:56 PeterLinss: people may want to extend length so you don't have to override everything that takes a length 23:56:06 esprehn: can compose existing types together 23:56:26 esprehn: only complication not resolved is how to do invalidation. Need to tell the engine when to reevaluate these properties 23:56:28 dino: i think we should address the case where the dev wants to extend the browser support for an existing property. 23:56:55 esprehn: need invalidateProp(name) API . if the inputs change, you need to be able to invalidate all the uses of the property 23:57:23 shane: lengths can expressed as 15em. When does that get computed? 23:57:43 esprehn: "syntax" is the parsing phase. "type" is the resolution phase 23:57:48 shane: can you specify custom types 23:58:04 esprehn: yes, there are builtin types and you can specify a custom type 23:58:17 shane: CSS has notions of type unioning and subclassing. Can you capture that? 23:58:45 esprehn: a Syntax function can return a different type every time 23:59:03 esprehn: e.g. you could return strings or lengths and handle those 23:59:24 shane: your syntax function has to return whatever type is appropriate for each union possibility 00:00:00 esprehn: you could do "union(length, string,...)" 00:00:24 esprehn: the syntax is a function that consumes a token stream and emits type objects 00:01:05 TabAtkins: need some way to extend basic parsing functions, e.g. to introduce a new fx unit that's a type of length. everything that's a length can accept it now 00:01:14 TabAtkins: custom values will be another bit of extension to make this super usable 00:01:46 (shane takes photo) 00:02:16 esprehn: you can extend this pattern for things like custom @rules ... registerCustomAtRule ... parses a token stream and gives the body to a rule parser that parses out the rules 00:02:36 TabAtkins: I'd like to create CSS syntax for SVG and just parse it out of the stylesheet. 00:02:40 dino: let's do that anyone 00:02:50 dino: anyway 00:03:00 TabAtkins: convert SVG into CSS compatible syntax 00:03:08 roc: ewwww 00:03:14 esprehn: just want to do strings 00:03:31 esprehn: this design is nice, you can compose syntaxes and length values 00:03:48 esprehn: expect custom properties level 2 to roughly look like this 00:04:05 TabAtkins: thanks Elliott 00:04:09 Rossen: who's going to work on that? 00:04:28 Rossen: Property part. 00:04:34 shane: makes sense to split into two specs? 00:04:40 Rossen: probably. 00:04:41 TabAtkins: probably 00:04:54 Rossen: who other than shane and Tab? 00:05:01 Daniel: like to be a little bit involved 00:05:03 Greg: me 00:05:27 Rossen: Elliott, Greg, Tab, Daniel, Shane ... pretty well covered 00:05:41 Rossen: Resolution. Anyone object to starting work on CSS properties? 00:05:43 no 00:05:47 Resolved 00:05:56 Rossen: next topic: value extensions 00:06:10 Rossen: Tab? 00:06:14 TabAtkins: vague ideas 00:06:47 Daniel: Many ways to see the result of parsing a value --- a stream of tokens , a hierarchy of tokens, a parsedobject? 00:07:03 Daniel: what kind of descriptors can extend the value space? 00:07:21 Daniel: either an ID coming from the registered property, or an ID coming from a parser looking, extending the value space 00:07:37 Daniel: if the new property is a CSS length, provide its syntax 00:07:48 Daniel: if the final computed value has to be computed from a specified value, you need a function somewhere 00:08:17 Daniel: do we want to extend existing properties? how do we extend a property that was registered from JS? 00:08:34 Daniel: say you wanted to add something to the width property? Do you want to do that or add your own width property? 00:08:59 roc: adding something to the width property composes better 00:09:08 Daniel: yes 00:09:35 Daniel: this will impact the way we extend values (pointing at property extension on board) 00:09:45 Daniel: notions of properties and values cannot live separately 00:10:10 Rossen: anyone have a different opinion? 00:10:16 Rossen: will it help to have them together? 00:10:18 Daniel: yes 00:10:24 A question that's worth asking: should css provide elegant solution taken alone, or should it provide acceptable solutions made elegant by a pre-processor 00:10:27 Daniel: things on the whiteboard right now will be reused 00:10:53 Daniel: two documents will be synced, the editors will probably be the same 00:11:08 dbaron: with value extensions, if someone adds a new type of length value, how do you deal with invalidation? 00:11:21 dbaron: a lot of what's interesting about new length values is that they're derived from other different things 00:11:26 I'm not sure how we can add new values to width that wouldn't be aliases if JS can't intervene at layout time to compute to an understood value 00:11:27 dbaron: something would have to drive it 00:11:41 Daniel: are you extending a type of value, or are you extending a type of value? 00:11:52 Daniel: new length unit is different from adding "red" to width 00:12:10 TabAtkins: with regards to units, we'd have a similar "invalidateUnit()"function 00:12:25 TabAtkins: monitor, detect changes, call invalidate, the engine will find out where it's used and redoi it 00:12:43 Rossen: if we add a "gm" type, size of g letter in your font. how would that work? 00:12:56 re TabAtkins: 'em' is local, not global 00:12:57 TabAtkins: that's especially hard because we don't know the font 00:13:10 TabAtkins: monitor for font changes, figure out when that would be different 00:13:19 TabAtkins: types that would change based on where in the tree you are. Requires more thought 00:13:30 TabAtkins: custom types for vw/vh would be easier, same across the page 00:13:39 TabAtkins: tree-based ones have complexity we haven't thought through 00:13:51 shane: not just based on tree, but based on other style values 00:14:04 shane: avoid chaining custom style computations to support this kind of thing 00:14:08 shane: would be nice to avoid it 00:14:38 TabAtkins: extending value space for existing properties 00:14:53 TabAtkins: register yourself for "display": handle things yourself and turn it into a new display 00:15:03 TabAtkins: registering new units sounds OK 00:15:30 Daniel: adding new units could be level 2 00:15:31 I don't want to seem overly negative, but it seems we're going into a too deep space here 00:15:44 franremy: WE MUST GO DEEPER 00:16:00 It's easier to use custom properties and your own JS to override the style 00:16:15 Daniel: we don't close the door, but some things will take more time than others 00:16:41 esprehn: consulted our implement, specify dependencies and reevaluate when font changes 00:17:07 You write "width: 2gm", your preprocessor emit "--width: 2gm" and your client script handles the invalidation work and emits "width: Xpx" for affected elements 00:17:15 esprehn: besides just units, you want functions like calc() 00:17:29 I don't think it's "the" option, just an easier path forward 00:17:39 esprehn: otherwise people will use bitfields to encode functions 00:17:49 TabAtkins: I've given it some though but needs more ideas 00:18:15 Rossen: anything else? 00:18:34 ... We may reconsider better api once we know what devs need and do use (except if you believe we have that experience already) 00:18:46 Rossen: any objection to adding "Values" to the CSS properties module? 00:18:50 no objections 00:18:57 franremy: That doesn't compose great. 00:19:06 Resolved: New spec will be "CSS properties and values extensions" (same set of authors as previous resolution) 00:19:30 Rossen: next set of topics: font metrics, input extensions 00:19:50 rbyers: I can do that 00:19:55 shane: would be better to wait for Ian 00:20:04 rbyers: let's wait 00:20:10 Rossen: OK, font metrics 00:20:20 re TabAtkins: I don't think so; at least I'm pretty sure it would if we define a CSS Parsing API. But, ok. 00:20:35 Rossen: looking at notes, put forward by Alan and Steve 00:20:40 Rossen: and Chris 00:20:53 Rossen: rehash motivation and example of dropcaps 00:21:25 astearns: we don't know what font is being used 00:21:38 astearns: proposal I've heard is to add something to the Range object that gives you the first used font 00:21:43 for any particular range 00:21:53 if you're not concerned with what each glyph is 00:22:01 franremy: What I mean is, if two things want to define width extensions... 00:22:04 range for the first one, make assumptions for there 00:22:13 if you want, you can get all the information you want 00:22:39 ChrisL: is there never a case where a single character maps to two glyphs from different fonts 00:22:51 esprehn: yes 00:22:53 roc: no 00:23:10 roc: comibning chaaracters are different chars 00:23:20 roc: Indic characters are separate characters 00:23:34 astearns: even if there's a situation where a glyph is composed from different fonts, we can still choose the first 00:23:45 ChrisL: OK thanks 00:23:54 esprehn: don't want to extend the range API 00:24:12 esprehn: Ranges make the whole engine slow 00:24:18 esprehn: you want some read-only representation 00:24:25 esprehn: design something new that's not live 00:24:50 johanneswilm: how does this interact with font loading? at all? 00:24:53 TabAtkins: I don't think nso 00:25:05 astearns: for a font, I want metrics for that font 00:25:23 astearns: the font loading API could return the same object, with metrics 00:25:53 ChrisL: consider a stylesheet with has a font stack, need to load a font off the Web, will be slow. Suppose I'm using a fallback font meanwhile. At that point, someone calls the new API. what do they get? 00:26:06 astearns: would hope you get the current answer 00:26:10 re TabAtkins: no, I would just move coordination on "--width" to user land; when we understand what frameworks do for coordination, then we try to write a standard; I think we go backwards here because we design without any realword experience (we can continue this on public-houdini if you prefer) 00:26:15 astearns: later you get the new answer 00:26:16 I agree with astearns 00:26:31 i agree with dbaron 00:27:00 astearns: does the idea of using same font object for font loading and this new API make sense? 00:27:02 TabAtkins: yes 00:27:22 TabAtkins: needs extension to local fonts, there's an issue in the spec for that 00:27:45 astearns: I do understand the rationale for DeadRange, I'm not sure the displayed font is sufficient justification for it 00:28:10 Ojan, esprehn: discourage anyone from creating a range 00:28:28 astearns: for fragment tree, return a list of ranges that a fragment displays. So let's not do that 00:28:53 SteveZ: call it FreeRange not deadRange 00:29:02 q+ on concerns with dead Ranges 00:29:16 SteveZ: another use is, if I want pseudoelements by looking at what's inside, I'd like to look at different ranges 00:29:33 SteveZ: a number of examples where we parse the content when generating pseudoelements 00:30:00 esprehn: Range has to be compatible in restricting ways. With something new we can express pseudoelements. We can't change what Range does 00:30:28 esprehn: IE had a different range object that had a lot of useful stuff. select line, select word. 00:30:34 Rossen: we still have it ... for the record 00:30:54 fantasai has joined #houdini 00:30:58 ping 00:30:59 dbaron: I think when we have issues with live vs dead objects, there are disadvantages of both 00:31:09 dbaron: dead objects need copying 00:31:25 dbaron: an API that didn't give you an object wouldn't have either problem 00:31:42 dbaron: a live object you need to keep it live over time 00:31:48 dbaron: a dead object must copy everything you might need over time 00:32:15 esprehn: you'll need a similar circus for objects passed into custom paint/custom layout 00:32:32 -bkardell 00:32:32 esprehn: neuter objects when a call returns 00:33:29 Rossen: we're off topic of fonts and designing FreeRanges 00:33:46 Rossen: should we design FreeRanges? 00:34:23 SteveZ: David's comment is critical. The issue isn't whether it's dead or alive, but how long the reference persists and when you can throw away the information 00:34:34 SteveZ: Elliott's suggestion of transaction-based is useful 00:34:49 astearns: should this be in fragment tree scope? 00:34:53 hmm kicked me off, wont let me call back in 00:35:02 Rossen: I think so 00:35:06 try rejoining after lunch? 00:35:17 Rossen: I'm not sure. Could also be its own module 00:35:27 astearns: the fragment tree will likely need to use it 00:35:36 astearns: being able to access generated content 00:35:47 Rossen: I wouldn't disagree 00:36:04 Rossen: let's come back to Font metrics 00:37:03 astearns: the font loading API returns a font object, and the font-getting API returns it, and this object should have some font metrics --- cap height, baselines 00:37:31 astearns: really useful for scripts that position things based on font information 00:37:32 disconnecting the lone participant, MeetingRoom, in Team_(houdini)22:12Z 00:37:35 Team_(houdini)22:12Z has ended 00:37:35 Attendees were MeetingRoom, bkardell 00:37:54 astearns: should we try to be reasonably complete? 00:38:10 TabAtkins: we know what CSS needs today. Go for that basic list. 00:38:24 (fwiw, I finally found the glyph image I was looking for in the past when discussing text & font measurements: https://i-msdn.sec.s-msft.com/dynimg/IC520421.png) 00:38:32 SteveZ: the only thing that's hard is ascender, descender 00:38:40 ChrisL: not hard. Just get in line if you don't want typographic ascender/descender 00:38:54 franremy: Niiiice 00:38:55 SteveZ: all the definitions have some particular use 00:39:26 Rossen: does that matter? 00:39:30 SteveZ: yes 00:39:37 Rossen: first font will have ascend and descent 00:39:49 font.ascender.osx.yosemite 00:40:00 astearns: the font object just gives you some input data for lineboxes. Doesn't give you everything 00:40:12 astearns: might need to add information to line boxes themslves 00:40:20 Rossen: keep lineboxes and font metrics separate 00:40:24 astearns: agree 00:40:35 Rossen: line boxes have multiple boxes and fonts 00:40:43 Rossen: font objects have just one font 00:41:01 SteveZ: four definitions of ascender/descender values, per font. Different values depending on when fonts overflow embox etc 00:41:25 dbaron: our font code does some fun things to figure which values to use, trying different tables. Not very interoperable 00:41:36 dbaron: try to define it in a way that allows such variation 00:41:43 http://www.w3.org/TR/2008/REC-CSS2-20080411/fonts.html#ascent 00:41:44 SteveZ: fine. Just a warning that it's a pitfall 00:42:00 SteveZ: you need ascender/descender as well as baselines 00:42:11 astearns: spec has to say how you get these in these odd font situations 00:42:49 esprehn: should discuss custom layout. Information needed by line-grid snapping etc 00:43:26 chrisL: not just drop caps 00:43:28 esprehn: drop caps sounds like custom layout 00:43:39 SteveZ: waiting for custom layout for drop caps is not desirable 00:44:14 astearns: I need the cap height to set the size 00:44:20 Dirk: font metrics are also necessary for canvas 00:44:41 esprehn: canvas has measureText already 00:44:45 roc: not much information 00:44:50 SteveZ: typographers are fussy 00:45:12 ChrisL: calling for volutneers 00:45:14 TabAtkins: not me 00:45:16 ChrisL: me 00:45:19 Rossen: we'll get there 00:45:28 What information is missing from https://developer.mozilla.org/en-US/docs/Web/API/TextMetrics ? 00:45:28 SteveZ: information is not always available 00:45:53 Rossen: anything else? 00:46:05 ChrisL: want to get this going so we can get feedback at type conferences 00:46:32 Rossen: who's interested in working on this? 00:46:39 Rossen: besides Chris and Alan? 00:46:43 Rossen: SteveZ 00:47:01 Rossen: Resolution: start working on font metrics unless objection 00:47:03 no objections 00:47:17 Rossen: Resolved: SteveZ, Alan and ChrisL will work on Font Metrics Extensions module 00:47:46 astearns: one thing to go in fragment tree spec. When we expose line boxes, line box needs to tell script where it's placing the dominant baseline 00:47:49 ojan has joined #houdini 00:48:27 SteveZ: needs to expose line box baseline even if there's nothing there 00:48:52 Rossen: box tree editors will ensure that 00:49:00 Rossen: let's break for lunch 00:50:02
00:50:58 have a good lunch 01:09:51 florian has joined #houdini 01:20:38 florian has joined #houdini 01:36:02 florian has joined #houdini 01:37:57 kwkbtr has joined #houdini 01:49:17 johanneswilm has joined #houdini 02:01:22 bkardell_: are you still on the phone? 02:01:30 no 02:01:39 ok 02:01:40 I got booted and then it wouldnt acceptt he code 02:01:48 are you guys ready to start again? 02:02:10 CONF1 right? 02:02:36 Zakim, room for 3? 02:02:37 ok, dbaron; conference Team_(houdini)02:02Z scheduled with code 26631 (CONF1) for 60 minutes until 0302Z 02:02:47 ScribeNick: jet 02:02:47 scribenick: jet 02:02:48 murakami has joined #houdini 02:03:29 shane: dinner plans 02:03:49 26631 "this passcode is not valid" 02:04:44 bkardell, give me a sec 02:05:13 no worries 02:05:54 Team_(houdini)02:02Z has now started 02:06:01 +bkardell 02:06:15 florian has joined #houdini 02:06:20 brian, can you hear Rossen? 02:06:21 Rossen: PM agenda: 02:06:31 +??P1 02:06:35 Rossen: custom paint, custom layout 02:06:46 Zakim, ??P1 is MeetingRoom 02:06:46 +MeetingRoom; got it 02:06:54 Rossen: input extensions, async, threading, process 02:07:07 Ian: whiteboard 02:07:08 Zakim, who is here 02:07:08 rbyers, you need to end that query with '?' 02:07:11 Zakim, who is here? 02:07:11 On the phone I see bkardell, MeetingRoom 02:07:13 On IRC I see florian, murakami, johanneswilm, kwkbtr, ojan, fantasai, dbaron, bkardell_, jet, esprehn, roc, ChrisL, krit, SteveZ, dino, xidorn, Zakim, RRSAgent, glazou, Rossen, 02:07:13 ... vollick, shane, rbyers, dstockwell, hober, TabAtkins, astearns, SimonSapin, CSSWG_LogBot, iank___, plinss 02:07:27 rbyers, much better to ask "who is on the phone?" than "who is here?", since you don't get the extra IRC list 02:07:33 custom paint https://c1.staticflickr.com/9/8061/8206144541_4843dd6445.jpg 02:07:42 Ian: custom paint assumes invalidation eg. custom properties 02:07:58 Topic: Custom Paint 02:08:12 iank___: properties that invalidae paint (not layout) should have paint callbacks 02:08:20 iank___: with custom context to be safe 02:08:35 iank___: to not leave layout in an inconsistent state 02:08:52 iank___: roughly have 3 areas to override: 02:08:57 1. on BG layer 02:09:00 2. on content 02:09:10 3. on outline (potentially) 02:09:13 Zakim, who is noisy? 02:09:25 rbyers, listening for 11 seconds I heard sound from the following: bkardell (64%), MeetingRoom (36%) 02:09:32 dean: does this include children? 02:09:36 iank___: no sure 02:09:37 hmm.. I am muted 02:09:55 Zakim, mute bkardell_ 02:09:55 sorry, bkardell_, I do not know which phone connection belongs to bkardell_ 02:10:01 Zakim, mute bkardell 02:10:01 bkardell should now be muted 02:10:10 bkardell, did you just mute the room? 02:10:11 roc: there's an argument to be able to modify paint for your children, eg. for effects 02:10:24 roc: we should constrain scope 02:10:37 iank___: we should constrain to just your paint (not children) 02:10:44 bkardell, I was testing my hypothesis that Zakim has the names inverted 02:10:51 rbeyers - did I? someone asked who was noisy, it said me but my phone was muted 02:11:08 there's no sound now though :) 02:11:17 bkardell, ok then I Was right. 02:11:18 iank___: eg. in a function(ctx, style) get a canvas context and style info 02:11:21 Zakim, unmute bkardell 02:11:21 bkardell should no longer be muted 02:11:29 Zakim, bkardell is confused 02:11:29 +confused; got it 02:11:36 iank___: ctx.clipPath = path 02:11:36 LOL 02:11:44 Zakim, MeetingRoom is bkardell 02:11:44 +bkardell; got it 02:11:46 iank___: ctx.paint(self) 02:11:54 Zakim, confused is MeetingRoom 02:11:54 +MeetingRoom; got it 02:12:14 dschulze: can we cover the diferent paint phases? 02:12:34 iank___: most effects are covered, per canvas 02:12:49 iank___: or just use the background layer depending on how fine-grained 02:13:07 dirke: what are the use cases for custom paint 02:13:20 iank___: eg. Google material design 02:13:36 iank___: draw custom shadows on buttons 02:13:49 iank___: currently we add DOM nodes to get this effect 02:14:01 dirke: why do that? Chrome can already draw a canvas element as a BG 02:14:21 iank___: demo on screen 02:14:38 http://www.polymer-project.org/components/paper-button/demo.html 02:14:50 iank___: we can't do this easily with DOM elements today, and need script for that 02:15:10 iank___: when first designed, button effects had gradients 02:15:28 dean: you already have the context, should be able to set what you want, eg. WebVR 02:15:44 dean: need to know the backing store to cover the element and effect 02:16:03 dean: needs more knobs on the API 02:16:18 esprehn: currently read-only API no backing store 02:16:39 dean: may need to be able to get readback (eg from WebGL) 02:16:53 iank___: eg, for getting 3D canvas 02:17:03 dean: don't limit to 2D API 02:17:16 dean: might need a retained model like SVG 02:17:41 dean: can do similar effects with SVG as input to custom paint 02:18:11 esprehn: with 2D canvas you can address a lot of use cases 02:18:21 esprehn: we can do 3D and displayList later 02:18:44 iank___: initially, specify 2D context, leave it open for later 02:19:08 dirk: how is it diffrent from BG canvas feature? 02:19:28 iank___: problems with webkit BG canvas 02:19:38 iank___: can't use the default canvas 02:20:04 roc: don't want to introduce new rendering, just modify existing parts 02:20:31 esprehn: want to call in before and after paint 02:21:04 esprehn: shows physics effect on whiteboard 02:21:27 iank___: you need a known width/height before use for canvas 02:21:32 SimonSapin: glazou proposed this in 1923 02:21:40 iank___: with proposed API you can get dimensions at paint time 02:22:08 glazou: :) <3 02:22:10 iank___: say width is animating, you can do effects without synchronous layout flush 02:22:56 roc: you can apply an effect, draw yourself but if content is complicated, layerization gets messed up 02:23:31 roc: eg. video on the background, call drawSelf( ) draws the button and video, but now layer decisions get comlicated 02:24:00 esprehn: you'll need to opt into staying on top or below other content to force layerization 02:24:24 roc: if clipping, you need to wrap your content with different options 02:24:40 esprehn: you need some way to push a clippath or opaity layer 02:24:45 s/opacity 02:25:06 esprehn: probably want a surface area that's closer to a traditional drawing API 02:25:15 esprehn: or use a display list 02:25:59 dirk: are the 3 context options combineable? 02:26:10 iank___: no, one per paint phase 02:26:33 iank___: depending on what's useful for authors 02:26:57 dean: if you'e doing something with video, compositor handles video paint 02:27:21 dirk: can we handle certain phases first? 02:27:37 roc: how important is it to modify content now? 02:27:49 esprehn: can't mask to arbitrary shapes 02:27:59 roc: you can do it with SVG masks 02:28:16 esprehn: can't do it without layout flush 02:28:27 roc: which use case? 02:28:55 esprehn: want to mask descendents based on current size 02:29:17 esprehn: to scale the effect as size changes 02:30:00 roc: is that OK to lag? Concern is trying to apply custom effects to the contents of an element that aren't acessible easily 02:30:25 dean: with video, you'd get a lag unless we do compositor tricks 02:30:38 roc: ramps up the complexity for edge cases 02:30:51 esprehn: just for clippath? 02:31:20 roc: you can get into very complicated states with multiple transforms, or not draw at all, or call drawSelf() twice 02:31:40 iank___: drawSelf is constrained before() or after() only 02:31:57 roc: complexity is added by masks, etc. 02:32:25 shane: seems pretty standard to invoke custom behavior before or after a bult-in context 02:32:32 s\built-in 02:32:53 esprehn: add clippath, opacity, transforms with API 02:33:23 dean: 3D API's allow hooks into different pahses of the rendering 02:33:42 iank___: mangle with a limited subset within API 02:33:56 dean: does this happen before filters and xforms? 02:34:15 shane: filters should apply 02:34:26 dirk: filters affect all operations 02:34:59 dean: you won't be able to override a CSS clippath with custom paint 02:35:06 iank___: that should be fine 02:35:27 shane: why can't we exose clippath? 02:35:47 dean: you shouldn't be able to modify the clippath passed into you 02:36:04 shane: you can modify local clippaths 02:36:43 dean: I'm worried about restrictions per context 02:36:56 dean: to avoid touching the backing store 02:37:13 shane: we can add other contexts later 02:37:36 roc: what kinds of restrictions we want in the JS environment? 02:37:54 iank___: initially, just get the context, read the style, get the fragment size 02:38:05 roc: do you have persistent global state between paints? 02:38:16 iank___: the style object passes in state 02:39:13 esprehn: the features are coupled with custom CSS properties (eg. to cover animated physics based on buttonDown) 02:39:24 esprehn: whiteboard 02:39:38 iank___: state comes from style 02:39:53 roc: won't need to count paints without global state 02:40:03 roc: how to send/receive messages? 02:40:09 iank___: via the style object 02:40:29 dean: how about images? 02:40:45 iank___: use an arrayBuffer with the image data 02:41:07 roc: use transferables/structured clones in the API 02:41:29 dean: what's in the style object? 02:41:46 iank___: either all computed style or just what relates to paint 02:42:07 iank___: author can specify which properties they want 02:42:37 esprehn: you should use the current geometry, not supplied sizes 02:43:00 it would be good to sketch out the process / relationships of what we are talking about (all of them I mean) 02:43:14 roc: need to have access to custom and built-in styles, might be good to share custom paint and custom layout features 02:43:26 esprehn: except that not all layout causes paint 02:43:38 q+ 02:43:42 dean: you can specify what you want to invalidate paint 02:43:55 dean: looks a lot like CSS shaders 02:44:45 dean: are you allowed to control how long it should take to paint? 02:45:34 bkardell_: it would be good to list what happens from parse to layout to paint and show how to plug into the API 02:45:54 esprehn: specifications are intertwined 02:46:11 +1 02:46:19 esprehn: first, a spec on the JS execution (in limited context) 02:46:32 esprehn: then specs on the layout and paint 02:46:50 dirk: how do you prevent pixel leakage? 02:47:19 roc: how to prevent timing attacks? 02:47:29 dean: limit out drawSelf()? 02:47:48 esprehn: webGL makes sense above or behind content 02:48:07 dirk: allow limited access to GL pixel data 02:48:34 roc: rendering to GL surfaces will be high overhead 02:48:53 dean: more worried about perf issues from usage 02:49:15 Rossen: any concerns re: SVG? 02:49:34 dirk: we don't have z-ordered paint phases in SVG (yet) 02:49:50 ChrisL: canvas is expected to work with SVG 02:50:04 florian has joined #houdini 02:50:27 dirk: SVG should be able to work as well 02:51:58 Rossen: resolution: shane, iank___ to work on Custom Paint proposal 02:52:24 CSS Painting 02:52:54 rbyers: do we need an uber spec? 02:53:06 rbyers: at least a note 02:53:30 Rossen: next topic: Custom Layout 02:53:52 shane: dinner at 6 02:54:49 shane: Custom Layout callbacks like for paint 02:55:08 shane: to read pieces of computed style that's targeted for Layout 02:55:19 shane: will depend on fragment tree spec 02:55:25 shane: filter the computed style to the pieces that are relevant for Layout 02:55:36 shane: API needs to create such fragments 02:56:04 dbaron: you want this to be separate from normal layout 02:56:16 dbaron: with some new display type to invoke it 02:56:30 dbaron: callbacks layout its children 02:56:33 dbaron that's mostly what we discussed at edge 02:56:44 seems good 02:56:48 TabAtkins: new display:--whatever would work 02:57:24 dbaron: mixing custom and builtin layout gets complex. new display type should avoid that 02:57:35 shane: restrictions should make this more implementable 02:58:03 Rossen: declaring an element to have custom layout should take over builtin layout 02:58:17 dbaron: descendants that use builtin layouts should be OK 02:58:46 dbaron: but don't let that happen with eg. table descendants that make anonymous boxes 02:59:25 roc: fragmentation? do we need to support braking, etc? 02:59:29 shane: yes 02:59:37 just that using a different 'display' value is useful because we have anonymous box construction rules that deal with things like avoiding invalid combinations like a display:table-row child of something arbitrary 03:00:06 TabAtkins: need to support printing, etc. 03:00:32 roc: interoperable fragmentation/breaking API will be hard 03:00:58 shane: we can make that call later 03:01:18 plinss: provide for breaking, doing so later may get harder to add 03:01:47 SteveZ: use case for breaking: eg. MathML and text 03:02:18 roc: We could have a simpler API that doesn't provide for breaking and a more complex API that does; that mightbe better for authors anyway. 03:02:45 plinss: break this out into smaller phases 03:03:21 plinss: don't put everything in one call 03:03:39 plinss: eg., have a phase for sizing 03:03:54 shane: don't make engine-specific assumptions 03:04:21 Rossen: how do you prevent hangs? infinite loops? 03:04:59 Rossen: custom layouts often create cycles 03:05:23 Rossen: how to prevent that? 03:05:48 Rossen: can't keep it to one iteration. eg 13 levels of recursion? 03:06:31 iank___: constrain things within phases? 03:07:54 roc: are we OK with constraining to basic CSS (intrinsic width, computed width, height calculations from children, etc.) 03:08:11 seems ok - at least for now seems ok 03:08:29 Rossen: flexbox and grid already exceed the basic CSS box calculation 03:09:03 q+ 03:09:13 q- 03:09:18 Rossen: shouldn't create cycles, but flexbox gets that way easily with custom layouts 03:09:22 Florian_ has joined #houdini 03:09:45 Rossen: treat custom layout as fixed size? 03:10:25 there's no sound - is there discussion off mic or did I get dropped again? 03:10:43 iank___: API will be used by framework developers 03:10:57 Some discussion is off-mic. 03:11:10 roc: we need to prevent lockups even from iframe usage 03:11:20 roc: eg. facebook like buttons 03:13:02 Rossen: resolution: greg, iank___ TabAtkins, shane, Rossen, roc to start work on Custom CSS Layout 03:13:13 dean: need use cases before API discussions 03:13:52 15 minute break 03:14:56 RESOLVED: shane, iank___ start work on Custom Paint Module 03:16:23 RESOLVED: greg, iank___, TabAtkins, shane, roc, Rossen start work on CSS Layout Module 03:17:22 s/start work on Custom Paint Modules/start work on CSS Paint Module/ 03:18:44 RESOLVED: SteveZ, Alan and ChrisL start work on Font Metrics Extensions module 03:23:30
03:36:13 johanneswilm has joined #houdini 03:37:28 next topic: input extensions 03:37:49 rbyers: on-screen demo 03:42:37 rbyers: following up on TPAC discussions 03:42:49 rbyers: these are all experiments 03:43:18 rbyers: motivation is to enable native app scroll effects 03:43:46 rbyers: enabling customization to tweak scroll effects 03:44:16 rbyers: currently have to extend input events to reimplement scrolling 03:44:40 eg.