IRC log of houdini on 2015-02-07

Timestamps are in UTC.

22:08:24 [RRSAgent]
RRSAgent has joined #houdini
22:08:24 [RRSAgent]
logging to http://www.w3.org/2015/02/07-houdini-irc
22:08:29 [dbaron]
RRSAgent, make logs public
22:08:35 [dbaron]
RRSAgent, this meeting spans midnight
22:08:42 [Zakim]
Zakim has joined #houdini
22:08:47 [dbaron]
Zakim, remind us in 9 hours to go home
22:08:47 [Zakim]
ok, dbaron
22:09:31 [xidorn]
xidorn has joined #houdini
22:09:50 [dino]
dino has joined #houdini
22:10:07 [SteveZ]
SteveZ has joined #houdini
22:11:42 [rbyers]
Zakim, room for 10
22:11:42 [Zakim]
I don't understand 'room for 10', rbyers
22:12:19 [rbyers]
Zakim, room for 3?
22:12:20 [Zakim]
ok, rbyers; conference Team_(houdini)22:12Z scheduled with code 26631 (CONF1) for 60 minutes until 2312Z
22:13:35 [Zakim]
Team_(houdini)22:12Z has now started
22:13:42 [Zakim]
+??P0
22:13:44 [Zakim]
-??P0
22:13:45 [dbaron]
Zakim, ??P0 is MeetingRoom
22:13:46 [Zakim]
Team_(houdini)22:12Z has ended
22:13:46 [Zakim]
Attendees were
22:13:46 [Zakim]
sorry, dbaron, I do not recognize a party named '??P0'
22:14:04 [dbaron]
Zakim, room for 3?
22:14:04 [Zakim]
dbaron, an adhoc conference was scheduled here less than 2 minutes ago
22:14:33 [Zakim]
Team_(houdini)22:12Z has now started
22:14:33 [shans_]
shans_ has joined #houdini
22:14:40 [Zakim]
+??P0
22:14:41 [dbaron]
Zakim, ??P0 is MeetingRoom
22:14:41 [Zakim]
+MeetingRoom; got it
22:15:15 [gregwhitworth]
gregwhitworth has joined #houdini
22:15:37 [krit]
krit has joined #houdini
22:15:47 [ChrisL]
ChrisL has joined #houdini
22:16:05 [roc]
roc has joined #houdini
22:16:35 [roc]
Rossen: yesterday we had introductions. Today we get to do magic tricks
22:17:04 [roc]
Rossen: introducing Dirk, Elliot and Jet
22:17:34 [roc]
Elliot: introduces himself
22:17:38 [roc]
Dirk: introduces himself
22:17:45 [dbaron]
(Elliot Sprehn, Dirk Schultze, Jet Villegas)
22:17:45 [roc]
Jet: introduces himself
22:17:52 [esprehn_]
esprehn_ has joined #houdini
22:17:54 [dbaron]
ScribeNick: roc
22:18:06 [roc]
Rossen: start with parsing
22:18:32 [roc]
Rossen: recap: we did agree on a scope and charter for the WG .... pretty much anything goes at this point?
22:18:39 [roc]
Dirk: when does the CSSWG join Houdini?
22:18:56 [dbaron]
dbaron has joined #houdini
22:19:24 [roc]
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 [roc]
Shane: not much in there
22:19:53 [roc]
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 [roc]
Rossen: Daniel, please start
22:20:08 [roc]
Daniel goes to whiteboard
22:20:35 [roc]
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 [roc]
Daniel: it feels wrong to reimplement when the browser has a parser
22:21:23 [roc]
Daniel: concrete example: my own tool. I all the time have to parse selectors, rules, values, unknown properties, complete stylesheets
22:21:38 [jet]
jet has joined #houdini
22:21:39 [roc]
Daniel: can't use browser to preserve unknown properties and values
22:21:52 [roc]
Daniel: complex backgrounds and gradients are the worst.
22:22:09 [roc]
Daniel: often have to parse, modify one single value, and regenerate
22:22:18 [roc]
Daniel: Need a CSS.parser API
22:22:57 [roc]
roc: so this is about exposing the parser, not extending the parser?
22:23:00 [roc]
Daniel: right
22:23:51 [roc]
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 [roc]
Daniel: need to expose structures for selectors, values etc
22:24:38 [roc]
Daniel: CSSOM exists for values but it's bad. Selectors are not exposed at all
22:24:55 [roc]
Daniel: these things are built into every browser and we should be able to use that
22:25:27 [roc]
Daniel: writes "CSS.parser; internal representation" ... "Selectors; updated CSSValue"
22:25:47 [roc]
Daniel: a lot of complex values like gradients are not exposed through CSSValue
22:25:54 [roc]
accessing one color of a color stop is a real pain
22:26:34 [roc]
Daniel: a few bits we miss from the OM... a CSSText attribute on rules, but not stylesheets. Another paint
22:26:38 [roc]
Rossen: a very common ask
22:27:07 [roc]
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 [roc]
Daniel: writes "OM consistency"
22:27:35 [roc]
Jet: would you expect CSS variables to be evaluated before parsing or after?
22:27:57 [roc]
Daniel: we can even forbid variables if you like
22:28:10 [roc]
Daniel: restrictions on this are perfectly understandable and acceptable
22:28:32 [roc]
PeterLinss: I would not expect variables to resolved at this point
22:28:38 [roc]
Tab: at parse time they're just a list of tokens
22:29:04 [roc]
Simon: maybe extrapolating variables could be a separate step from parsing
22:29:07 [roc]
Daniel: sure
22:29:29 [roc]
Daniel: Steve, I agree about the callbacks. That's a very good idea
22:29:52 [roc]
Daniel: you can understand it in different ways. You want a callback on errors, or when somethings unrecognized in the OM
22:29:55 [shane]
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 [shane]
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 [roc]
Daniel: I know that throwing away unrecognized stuff is a useful restriction in browsers, but it's a problem for editors
22:30:46 [roc]
ChrisLilley: could parse everything, optionally stores everything, and then optionally throws away everything it doesn't understand
22:30:59 [bkardell_]
bkardell_ has joined #houdini
22:31:02 [roc]
ChrisLilley: seems cleaner to mark things as dirty and then throw them out
22:31:13 [roc]
Daniel: like syntax highlighters.
22:31:18 [bkardell_]
sorry I am late.. is there a line open?
22:31:32 [roc]
Tab: CSS syntax does no validation. expects a later phase to throw things away
22:31:44 [rbyers]
bkardell, yes we're on the call but we haven't been using mics
22:31:59 [rbyers]
but we can star using mics if you want to dial in
22:32:08 [roc]
Rossen: either use the parser as an evaluator, or use it to parse the current style sheet?
22:32:24 [rbyers]
bkardell, code is 26631
22:32:24 [Zakim]
+??P1
22:32:38 [roc]
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 [roc]
Daniel: then tweak one single token and reserialize it
22:33:11 [roc]
Shane: is performance an issue here? sounds a bit slow. is this going to impact browser's evaluate paths?
22:33:25 [roc]
Daniel: don't we have exactly the same problem as queryselector?
22:33:38 [roc]
(Brian joins the phone call)
22:33:38 [dbaron]
Zakim, ??P1 is bkardell
22:33:38 [Zakim]
+bkardell; got it
22:33:51 [roc]
Daniel: querySelector has the same issue
22:34:03 [roc]
Rossen: so does @supports
22:34:32 [roc]
Shane: if you take an entire stylesheet, tweak and reserialize it might not perform well
22:34:54 [roc]
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 [roc]
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 [roc]
so not an issue with native code
22:36:01 [roc]
shane: just exposing a JS implementation with Web Animations can avoid string conversion cost
22:36:09 [roc]
shane: should we do this?
22:36:13 [roc]
Daniel: sure
22:36:34 [roc]
Tab: react.js bypassing CSS, would be helped by ability to throw a CSS object at the DOM
22:36:43 [roc]
Tab: and style an element
22:36:51 [roc]
Daniel: a few other areas: CSS extensions to the parser
22:37:14 [roc]
Daniel: being able to declare a new pseudoclass, a new combinator, whatever
22:37:34 [roc]
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 [roc]
Daniel: need to insert a rule before/after a given rule
22:38:08 [roc]
Daniel: check many Websites doing editing, all computing the indexes of rules all the time
22:38:18 [roc]
Daniel: feels like 1995
22:38:44 [roc]
Daniel: how do we do this given the current OM?
22:39:05 [bkardell_]
Improving existing seems unlikely
22:39:06 [roc]
Daniel: given compat issues? do we need another one? can we improve this one?
22:39:32 [bkardell_]
I am with daniel here, proposed this myself 3-4 years back
22:39:46 [roc]
Tab: have ideas, depend on value objects in JS, hopefully they'll show up soon
22:40:12 [roc]
Daniel: points at Selectors/CSS Values
22:40:16 [roc]
Rossen: those are next on the agenda
22:40:34 [roc]
Daniel: selectors are not too complicated. There will be discussions about making them performant
22:41:26 [roc]
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 [roc]
RickByers: all sounds super exciting. TAG wants us to not just make CSS extensible, but explain it
22:42:14 [roc]
RickByers: can't write an alternate CSS parser
22:42:19 [roc]
Tab: you can fetch, parse, reserialize
22:42:41 [roc]
Daniel: I had STTS ... a CSS-like language
22:42:51 [roc]
Daniel: these properties change the tree
22:43:23 [roc]
RickByers: would this parser API help with that?
22:43:26 [roc]
Daniel: yes
22:43:44 [franremy]
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 [roc]
we have to decide whether to return just a set of tokens or more than that?
22:44:03 [roc]
Daniel: if I can only get partial things I'll live with that
22:44:19 [roc]
Daniel: some areas of the browser are considered to be moved from CSS to JS
22:44:35 [roc]
Daniel: seriously discussed moving all editing from C++ to JS
22:45:09 [roc]
Daniel: In Gecko most HTML editing rules could be exported to JS
22:45:34 [roc]
Dirk: you already mentioned the parser might return tokens? is there a way it could return an OM?
22:46:01 [roc]
Daniel: the problem is for selectors. their parsing is a bit peculiar
22:46:02 [bkardell_]
rework has something, not great, but not bad either
22:46:11 [bkardell_]
it's not so much OM, almost like AST
22:46:19 [roc]
Daniel: dealing with only tokens is complex. You need heuristics to figure out selectors
22:46:25 [roc]
Daniel: I'd love to have access to both
22:46:46 [roc]
PeterLinss: should have a low level API to return tokens, and a parser that consumes tokens
22:46:58 [bkardell_]
esprima might be a good corollary
22:47:09 [roc]
Daniel: my code is like that
22:47:26 [roc]
Dirk: CSS syntax already specifies tokenizer?
22:47:27 [roc]
Tab: yes
22:47:35 [roc]
Peter: just need to expose it
22:47:37 [shane]
franremy: updated here: https://wiki.css-houdini.org/planning/sydney-2015?&#actual-agenda
22:47:42 [roc]
Daniel: can be an iterator on strings
22:48:01 [shane]
franremy: I expect this and values to take the morning
22:48:03 [roc]
Daniel: who's willing to work on a spec?
22:48:07 [roc]
Tab raises hand
22:48:39 [roc]
Elliot: all engines have tokenizers, but some engines may not build a tree structure (cites V8 as example)
22:48:51 [TabAtkins]
Zakim, q-
22:48:51 [Zakim]
I see Tab on the speaker queue
22:48:54 [TabAtkins]
q-
22:48:58 [TabAtkins]
Hm.
22:49:04 [TabAtkins]
ack
22:49:07 [roc]
Daniel: this is something extra that we'll build
22:49:07 [TabAtkins]
zakim, ack
22:49:07 [Zakim]
I don't understand 'ack', TabAtkins
22:49:11 [roc]
Elliot: just for editors?
22:49:14 [roc]
Daniel: no, Webapps
22:49:42 [roc]
Daniel: you will never inject what you've parsed into the engine. It's made for consumption by apps
22:50:01 [franremy]
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 [roc]
dino: you're not talking about extending the parser, just getting access to what it's done
22:50:08 [roc]
Daniel: I'm interested in both
22:50:23 [roc]
dbaron: I'm having trouble understanding what this API's like
22:50:39 [roc]
dbaron: parsing depends on context. What's generic between a token stream and an object model?
22:50:49 [plinss]
zakim, q- Tab
22:50:49 [Zakim]
I see no one on the speaker queue
22:50:49 [roc]
dbaron: the parser has custom logic to convert from tokens to OM that's context sensitive?
22:51:13 [roc]
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 [roc]
dbaron: validating gradient syntax requires checking parens, commas, spaces
22:51:54 [roc]
TabAtkins: the current output of the parsing stage is a function object with a token stream argument
22:52:04 [shane]
TabAtkins: you are *so queued*
22:52:06 [roc]
dbaron: a hierarchical token stream?
22:52:13 [roc]
Tab: yes. Function and block structure and that's it
22:52:26 [roc]
dbaron: not a whole lot else there
22:53:20 [roc]
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 [roc]
Daniel: I'm open to anything
22:54:01 [roc]
TabAtkins: good idea to expose parser/tokenizer
22:54:08 [roc]
TabAtkins: exact shape can be discussed
22:54:28 [roc]
Rossen: we have Daniel and Tab so far. Simon, are you interested?
22:54:35 [bkardell_]
I am interested
22:54:37 [roc]
Daniel: you gave me good feedback
22:54:43 [roc]
Simon: definitely interested in reviewing
22:55:09 [roc]
Brian: Esprima is a similar thing
22:55:22 [roc]
Brian: rework has a nice thing, halfway between AST and OM
22:55:22 [TabAtkins]
ReworkCSS
22:55:48 [roc]
Daniel: is extensions to the parser now>
22:55:53 [roc]
Rossen: yes
22:56:36 [roc]
Daniel: first thing that comes to mind is psuedoclasses
22:56:57 [roc]
Daniel: you need very little context, it replies with just a boolean, so it's quite easily extensible
22:57:05 [shane]
we didn't capture Tab's resolution btw
22:57:08 [roc]
Daniel: tab wants a declarative way
22:57:12 [roc]
TabAtkins: I want both
22:57:28 [roc]
Daniel: would prefer a link between a JS function and a CSS declaration
22:57:33 [roc]
Daniel: actionscripts
22:57:47 [roc]
Daniel: wanted to preserve the ability to disable JS and CSS. Seems so long ago
22:58:19 [roc]
Daniel: so easy to write function foo() of one argument that returns bool
22:58:28 [roc]
TabAtkins: current proposal is just an alias
22:58:44 [roc]
most custom selectors like JQuery can be declarative
22:58:58 [roc]
Daniel: I don't think we need two solutions
22:59:10 [roc]
dbaron: are you talking about a way to add/rmeove elements from a set
22:59:16 [roc]
TabAtkins: a way to turn one selector into another in JS
22:59:38 [roc]
TabAtkins: I'm lying about that
22:59:39 [dbaron]
s/about a way/about a function that takes an element and returns a boolean or about a way/
22:59:42 [roc]
TabAtkins: the current approach is aboolean function
22:59:54 [roc]
TabAtkins: a base selector to limit which elements are applicable
22:59:58 [roc]
TabAtkins: run that function on a bunch of elements
23:00:07 [roc]
TabAtkins: do some caching stuff there
23:00:34 [dbaron]
roc: you don't want to run user JS that accesses the DOM during selector matching.
23:00:42 [dbaron]
roc: not just performance; safety issues
23:01:03 [shane]
Zakim: q+
23:01:20 [shane]
Zakim, q+
23:01:20 [Zakim]
I see shane on the speaker queue
23:01:22 [roc]
TabAtkins: polyfill works OK
23:01:33 [roc]
roc: browser might want to selector matching when it's not safe to run user JS
23:01:47 [astearns]
s/polyfill/HitchJS polyfill/
23:01:49 [bkardell_]
https://www.irccloud.com/pastebin/WtJrSusx
23:01:57 [roc]
shane: I was just going to say there might be other ways of doing script for custom selectors
23:02:08 [roc]
shane: that wouldn't require you to run JS inside selector matching
23:02:12 [roc]
shane: might need a pre-match call
23:02:22 [shane]
Zakim, q-
23:02:22 [Zakim]
I see no one on the speaker queue
23:02:34 [roc]
Elliot: if you're just adding an element to a set, how is this different to a class?
23:02:50 [roc]
dbaron: mostly not, it might be that something doesn't want to expose that set to other parts of code?
23:03:05 [roc]
TabAtkins: simple declarative is better than a class, it handles mutations for you
23:03:26 [roc]
shane: the set changes
23:03:42 [roc]
Elliot: when would this be useful?
23:03:51 [roc]
TabAtkins: jquery has custom pseudoclasses that it accepts
23:03:55 [roc]
TabAtkins: :heading
23:03:57 [roc]
TabAtkins: :input
23:04:11 [roc]
TabAtkins: these simple things are really useful
23:04:26 [bkardell_]
we did an examination of this, jquery had like more than a dozen, most of which are simple aliases
23:04:26 [roc]
TabAtkins: Brian's being working on this in Hitch
23:05:01 [roc]
Daniel: good for prototyping polyfilling
23:05:13 [bkardell_]
custom things are better for standards in a lot of cases too - prototype your solution, let's use and evaulate it
23:05:23 [roc]
dino: wanted to reemphasize what Roc said: running JS code for selector matching will be a perf hit
23:05:28 [roc]
dino: prefer declarative way
23:05:53 [roc]
Elliot: we have a sophisticated invalidation system. We potentially will ahve to invalidate all custom selectors
23:06:09 [franremy]
(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 [roc]
TabAtkins: with the current API shape, we have a base selector to tell you what it cares about
23:06:47 [roc]
TabAtkins: we'll see if it's good enough
23:07:27 [roc]
Daniel: extending parser is in Tab's specs. Where are extensions physically in the stylesheets? always before everything?
23:07:36 [roc]
Daniel: need JS API to achieve the same thing
23:07:56 [roc]
Daniel: need to discuss interactions with variables
23:08:19 [roc]
Rossen: everything should be on the table
23:09:06 [roc]
TabAtkins: informal namespacing works pretty well
23:09:39 [roc]
TabAtkins: we can introduce namespaces later if we need to
23:10:03 [roc]
Rossen: anything more?
23:10:09 [roc]
Daniel: one special beast: pseudoelements
23:10:34 [roc]
Daniel/Simon: definition of pseudoelements is the issue
23:10:54 [roc]
Rossen: anything more for the parser discussion?
23:11:00 [franremy]
re TabAtkins: so, with "--" prefix to avoid conflict with native and not like jQuery, right?
23:11:16 [TabAtkins]
Yeah.
23:11:42 [franremy]
ok, that was my concern;
23:11:42 [roc]
dino: could do a lot of parser extensions through declarative API --- CSS variables-like aliasing/psuedoclasses
23:11:56 [roc]
dino: possibly not what Daniel needs
23:12:06 [roc]
Daniel: not just for myself only
23:12:45 [roc]
Rossen: resolution: who are the final editors? Daniel, Tab, Shane
23:12:51 [roc]
Rossen: any objections?
23:13:23 [roc]
Resolved: Tab, Shane and Daniel to start work on CSS Parser
23:13:34 [roc]
correction
23:13:45 [roc]
Resolved: Tab, Shane, Daniel and Brian to start work on CSS Parser document
23:14:02 [dbaron]
might be good to call it "CSS Parser API" to make it a little more distinct from CSS Syntax...
23:14:32 [SimonSapin]
dbaron +1
23:15:45 [Florian]
Florian has joined #houdini
23:40:46 [esprehn_]
Ojan Vafai is now here
23:40:49 [esprehn_]
(Google)
23:40:55 [roc]
Rossen: next topic: property and value extensions
23:41:10 [roc]
TabAtkins: Custom Properties spec optimizes for variable setters
23:41:30 [roc]
TabAtkins: Need a Variables level 2 to help us with custom properties ... specify initial value, inheriting, animation behavior
23:41:47 [roc]
TabAtkins: Elliot and Ojan have put thought into custom properties being used to drive layout and other thigns
23:42:05 [murakami]
murakami has joined #houdini
23:42:44 [dbaron]
dbaron has joined #houdini
23:44:06 [roc]
esprehn: current shape:
23:44:13 [johanneswilm]
johanneswilm has joined #houdini
23:45:07 [roc]
esprehn: writes "registerProperty({ name : "width", syntax : CSSLengthSyntax" ... syntax a function that takes a token stream and returns an object
23:45:43 [roc]
esprehn: "inherit: boolean; iniitalValue: new Length(0);"
23:45:55 [roc]
esprehn: Tab wants object types here, they don't exist yet
23:46:18 [roc]
Daniel: in syntax line, your function returns an object, but your initial value is only a length?
23:46:34 [roc]
Ojan: syntax function needs to return an object an object of type Length
23:46:45 [roc]
esprehn: "invalidation: Paint, Layout, Style, none"
23:46:51 [TabAtkins]
s/object types/JS Value Objects/
23:46:59 [roc]
esprehn: probably just make initial value a string
23:47:12 [roc]
TabAtkins: thx
23:47:36 [roc]
esprehn: Layout makes sense for custom layout, Paint could be like Color, style means recompute style
23:47:49 [roc]
TabAtkins: lets the engine know what kinds of things to update
23:47:55 [roc]
Dirk: how to handle animations
23:48:24 [roc]
Dirk: cannot define custom types?
23:48:26 [roc]
shane: yes you can
23:48:46 [roc]
esprehn: "type: CSSLengthType"
23:49:01 [TabAtkins]
Earlier sketch for a better CSSOM API, based on Value Objects: http://www.xanthir.com/b4UD0
23:49:04 [roc]
Ojan: layout just means "changes size and position"
23:49:07 [TabAtkins]
I presented this to the CSSWG last year.
23:49:23 [roc]
esprehn: writes "invalidation: geometry, paint, none"
23:49:57 [roc]
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 [roc]
esprehn: AnimatedType has an invalidate()
23:50:26 [roc]
just keep invalidating and we'll come around and get a different value
23:50:52 [roc]
shane: can just use Web Animations
23:51:05 [roc]
esprehn: ok as long as output type is something Web animations understands
23:51:26 [roc]
shane: interpolation is hard, we should leverage Web Animations
23:51:34 [roc]
expose an interpolator for each type
23:52:11 [roc]
Dirk: the function is supposed to register new properties. Or to register properties already defined?
23:52:17 [roc]
esprehn: register new properties.
23:52:28 [roc]
esprehn: writes "name: x-width"
23:52:41 [roc]
esprehn: e.g. a width that always divides by 2
23:53:02 [roc]
Dirk: if you create custom properties, will they have -- at the beginning?
23:53:04 [roc]
TabAtkins: yes
23:53:12 [roc]
esprehn: writes "--width"
23:53:26 [roc]
esprehn: when is it safe to run script? Uses a separate Realm
23:53:47 [roc]
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 [roc]
dino: when do you do that? Does registering a property reparse everything?
23:54:35 [roc]
esprehn: we don't discard them. Or we could make sure you have to register before
23:54:41 [roc]
dino: what if you want to override?
23:54:48 [roc]
esprehn: I think it would be extremely powerful
23:54:57 [roc]
dino: we don't provide that currently
23:55:04 [shane]
quick note: realms are deferred to ES7 :(
23:55:28 [roc]
esprehn: people will want to add new things to existing properties
23:55:56 [roc]
PeterLinss: people may want to extend length so you don't have to override everything that takes a length
23:56:06 [roc]
esprehn: can compose existing types together
23:56:26 [roc]
esprehn: only complication not resolved is how to do invalidation. Need to tell the engine when to reevaluate these properties
23:56:28 [dino]
dino: i think we should address the case where the dev wants to extend the browser support for an existing property.
23:56:55 [roc]
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 [roc]
shane: lengths can expressed as 15em. When does that get computed?
23:57:43 [roc]
esprehn: "syntax" is the parsing phase. "type" is the resolution phase
23:57:48 [roc]
shane: can you specify custom types
23:58:04 [roc]
esprehn: yes, there are builtin types and you can specify a custom type
23:58:17 [roc]
shane: CSS has notions of type unioning and subclassing. Can you capture that?
23:58:45 [roc]
esprehn: a Syntax function can return a different type every time
23:59:03 [roc]
esprehn: e.g. you could return strings or lengths and handle those
23:59:24 [roc]
shane: your syntax function has to return whatever type is appropriate for each union possibility
00:00:00 [roc]
esprehn: you could do "union(length, string,...)"
00:00:24 [roc]
esprehn: the syntax is a function that consumes a token stream and emits type objects
00:01:05 [roc]
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 [roc]
TabAtkins: custom values will be another bit of extension to make this super usable
00:01:46 [roc]
(shane takes photo)
00:02:16 [roc]
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 [roc]
TabAtkins: I'd like to create CSS syntax for SVG and just parse it out of the stylesheet.
00:02:40 [roc]
dino: let's do that anyone
00:02:50 [roc]
dino: anyway
00:03:00 [roc]
TabAtkins: convert SVG into CSS compatible syntax
00:03:08 [roc]
roc: ewwww
00:03:14 [roc]
esprehn: just want to do strings
00:03:31 [roc]
esprehn: this design is nice, you can compose syntaxes and length values
00:03:48 [roc]
esprehn: expect custom properties level 2 to roughly look like this
00:04:05 [roc]
TabAtkins: thanks Elliott
00:04:09 [roc]
Rossen: who's going to work on that?
00:04:28 [roc]
Rossen: Property part.
00:04:34 [roc]
shane: makes sense to split into two specs?
00:04:40 [roc]
Rossen: probably.
00:04:41 [roc]
TabAtkins: probably
00:04:54 [roc]
Rossen: who other than shane and Tab?
00:05:01 [roc]
Daniel: like to be a little bit involved
00:05:03 [roc]
Greg: me
00:05:27 [roc]
Rossen: Elliott, Greg, Tab, Daniel, Shane ... pretty well covered
00:05:41 [roc]
Rossen: Resolution. Anyone object to starting work on CSS properties?
00:05:43 [roc]
no
00:05:47 [roc]
Resolved
00:05:56 [roc]
Rossen: next topic: value extensions
00:06:10 [roc]
Rossen: Tab?
00:06:14 [roc]
TabAtkins: vague ideas
00:06:47 [roc]
Daniel: Many ways to see the result of parsing a value --- a stream of tokens , a hierarchy of tokens, a parsedobject?
00:07:03 [roc]
Daniel: what kind of descriptors can extend the value space?
00:07:21 [roc]
Daniel: either an ID coming from the registered property, or an ID coming from a parser looking, extending the value space
00:07:37 [roc]
Daniel: if the new property is a CSS length, provide its syntax
00:07:48 [roc]
Daniel: if the final computed value has to be computed from a specified value, you need a function somewhere
00:08:17 [roc]
Daniel: do we want to extend existing properties? how do we extend a property that was registered from JS?
00:08:34 [roc]
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]
roc: adding something to the width property composes better
00:09:08 [roc]
Daniel: yes
00:09:35 [roc]
Daniel: this will impact the way we extend values (pointing at property extension on board)
00:09:45 [roc]
Daniel: notions of properties and values cannot live separately
00:10:10 [roc]
Rossen: anyone have a different opinion?
00:10:16 [roc]
Rossen: will it help to have them together?
00:10:18 [roc]
Daniel: yes
00:10:24 [franremy]
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 [roc]
Daniel: things on the whiteboard right now will be reused
00:10:53 [roc]
Daniel: two documents will be synced, the editors will probably be the same
00:11:08 [roc]
dbaron: with value extensions, if someone adds a new type of length value, how do you deal with invalidation?
00:11:21 [roc]
dbaron: a lot of what's interesting about new length values is that they're derived from other different things
00:11:26 [franremy]
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 [roc]
dbaron: something would have to drive it
00:11:41 [roc]
Daniel: are you extending a type of value, or are you extending a type of value?
00:11:52 [roc]
Daniel: new length unit is different from adding "red" to width
00:12:10 [roc]
TabAtkins: with regards to units, we'd have a similar "invalidateUnit()"function
00:12:25 [roc]
TabAtkins: monitor, detect changes, call invalidate, the engine will find out where it's used and redoi it
00:12:43 [roc]
Rossen: if we add a "gm" type, size of g letter in your font. how would that work?
00:12:56 [franremy]
re TabAtkins: 'em' is local, not global
00:12:57 [roc]
TabAtkins: that's especially hard because we don't know the font
00:13:10 [roc]
TabAtkins: monitor for font changes, figure out when that would be different
00:13:19 [roc]
TabAtkins: types that would change based on where in the tree you are. Requires more thought
00:13:30 [roc]
TabAtkins: custom types for vw/vh would be easier, same across the page
00:13:39 [roc]
TabAtkins: tree-based ones have complexity we haven't thought through
00:13:51 [roc]
shane: not just based on tree, but based on other style values
00:14:04 [roc]
shane: avoid chaining custom style computations to support this kind of thing
00:14:08 [roc]
shane: would be nice to avoid it
00:14:38 [roc]
TabAtkins: extending value space for existing properties
00:14:53 [roc]
TabAtkins: register yourself for "display": handle things yourself and turn it into a new display
00:15:03 [roc]
TabAtkins: registering new units sounds OK
00:15:30 [roc]
Daniel: adding new units could be level 2
00:15:31 [franremy]
I don't want to seem overly negative, but it seems we're going into a too deep space here
00:15:44 [TabAtkins]
franremy: WE MUST GO DEEPER
00:16:00 [franremy]
It's easier to use custom properties and your own JS to override the style
00:16:15 [roc]
Daniel: we don't close the door, but some things will take more time than others
00:16:41 [roc]
esprehn: consulted our implement, specify dependencies and reevaluate when font changes
00:17:07 [franremy]
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 [roc]
esprehn: besides just units, you want functions like calc()
00:17:29 [franremy]
I don't think it's "the" option, just an easier path forward
00:17:39 [roc]
esprehn: otherwise people will use bitfields to encode functions
00:17:49 [roc]
TabAtkins: I've given it some though but needs more ideas
00:18:15 [roc]
Rossen: anything else?
00:18:34 [franremy]
... 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 [roc]
Rossen: any objection to adding "Values" to the CSS properties module?
00:18:50 [roc]
no objections
00:18:57 [TabAtkins]
franremy: That doesn't compose great.
00:19:06 [roc]
Resolved: New spec will be "CSS properties and values extensions" (same set of authors as previous resolution)
00:19:30 [roc]
Rossen: next set of topics: font metrics, input extensions
00:19:50 [roc]
rbyers: I can do that
00:19:55 [roc]
shane: would be better to wait for Ian
00:20:04 [roc]
rbyers: let's wait
00:20:10 [roc]
Rossen: OK, font metrics
00:20:20 [franremy]
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 [roc]
Rossen: looking at notes, put forward by Alan and Steve
00:20:40 [roc]
Rossen: and Chris
00:20:53 [roc]
Rossen: rehash motivation and example of dropcaps
00:21:25 [roc]
astearns: we don't know what font is being used
00:21:38 [roc]
astearns: proposal I've heard is to add something to the Range object that gives you the first used font
00:21:43 [roc]
for any particular range
00:21:53 [roc]
if you're not concerned with what each glyph is
00:22:01 [TabAtkins]
franremy: What I mean is, if two things want to define width extensions...
00:22:04 [roc]
range for the first one, make assumptions for there
00:22:13 [roc]
if you want, you can get all the information you want
00:22:39 [roc]
ChrisL: is there never a case where a single character maps to two glyphs from different fonts
00:22:51 [roc]
esprehn: yes
00:22:53 [roc]
roc: no
00:23:10 [roc]
roc: comibning chaaracters are different chars
00:23:20 [roc]
roc: Indic characters are separate characters
00:23:34 [roc]
astearns: even if there's a situation where a glyph is composed from different fonts, we can still choose the first
00:23:45 [roc]
ChrisL: OK thanks
00:23:54 [roc]
esprehn: don't want to extend the range API
00:24:12 [roc]
esprehn: Ranges make the whole engine slow
00:24:18 [roc]
esprehn: you want some read-only representation
00:24:25 [roc]
esprehn: design something new that's not live
00:24:50 [roc]
johanneswilm: how does this interact with font loading? at all?
00:24:53 [roc]
TabAtkins: I don't think nso
00:25:05 [roc]
astearns: for a font, I want metrics for that font
00:25:23 [roc]
astearns: the font loading API could return the same object, with metrics
00:25:53 [roc]
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 [roc]
astearns: would hope you get the current answer
00:26:10 [franremy]
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 [roc]
astearns: later you get the new answer
00:26:16 [dbaron]
I agree with astearns
00:26:31 [dino]
i agree with dbaron
00:27:00 [roc]
astearns: does the idea of using same font object for font loading and this new API make sense?
00:27:02 [roc]
TabAtkins: yes
00:27:22 [roc]
TabAtkins: needs extension to local fonts, there's an issue in the spec for that
00:27:45 [roc]
astearns: I do understand the rationale for DeadRange, I'm not sure the displayed font is sufficient justification for it
00:28:10 [roc]
Ojan, esprehn: discourage anyone from creating a range
00:28:28 [roc]
astearns: for fragment tree, return a list of ranges that a fragment displays. So let's not do that
00:28:53 [roc]
SteveZ: call it FreeRange not deadRange
00:29:02 [dbaron]
q+ on concerns with dead Ranges
00:29:16 [roc]
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 [roc]
SteveZ: a number of examples where we parse the content when generating pseudoelements
00:30:00 [roc]
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 [roc]
esprehn: IE had a different range object that had a lot of useful stuff. select line, select word.
00:30:34 [roc]
Rossen: we still have it ... for the record
00:30:54 [fantasai]
fantasai has joined #houdini
00:30:58 [fantasai]
ping
00:30:59 [roc]
dbaron: I think when we have issues with live vs dead objects, there are disadvantages of both
00:31:09 [roc]
dbaron: dead objects need copying
00:31:25 [roc]
dbaron: an API that didn't give you an object wouldn't have either problem
00:31:42 [roc]
dbaron: a live object you need to keep it live over time
00:31:48 [roc]
dbaron: a dead object must copy everything you might need over time
00:32:15 [roc]
esprehn: you'll need a similar circus for objects passed into custom paint/custom layout
00:32:32 [Zakim]
-bkardell
00:32:32 [roc]
esprehn: neuter objects when a call returns
00:33:29 [roc]
Rossen: we're off topic of fonts and designing FreeRanges
00:33:46 [roc]
Rossen: should we design FreeRanges?
00:34:23 [roc]
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 [roc]
SteveZ: Elliott's suggestion of transaction-based is useful
00:34:49 [roc]
astearns: should this be in fragment tree scope?
00:34:53 [bkardell_]
hmm kicked me off, wont let me call back in
00:35:02 [roc]
Rossen: I think so
00:35:06 [bkardell_]
try rejoining after lunch?
00:35:17 [roc]
Rossen: I'm not sure. Could also be its own module
00:35:27 [roc]
astearns: the fragment tree will likely need to use it
00:35:36 [roc]
astearns: being able to access generated content
00:35:47 [roc]
Rossen: I wouldn't disagree
00:36:04 [roc]
Rossen: let's come back to Font metrics
00:37:03 [roc]
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 [roc]
astearns: really useful for scripts that position things based on font information
00:37:32 [Zakim]
disconnecting the lone participant, MeetingRoom, in Team_(houdini)22:12Z
00:37:35 [Zakim]
Team_(houdini)22:12Z has ended
00:37:35 [Zakim]
Attendees were MeetingRoom, bkardell
00:37:54 [roc]
astearns: should we try to be reasonably complete?
00:38:10 [roc]
TabAtkins: we know what CSS needs today. Go for that basic list.
00:38:24 [franremy]
(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 [roc]
SteveZ: the only thing that's hard is ascender, descender
00:38:40 [roc]
ChrisL: not hard. Just get in line if you don't want typographic ascender/descender
00:38:54 [TabAtkins]
franremy: Niiiice
00:38:55 [roc]
SteveZ: all the definitions have some particular use
00:39:26 [roc]
Rossen: does that matter?
00:39:30 [roc]
SteveZ: yes
00:39:37 [roc]
Rossen: first font will have ascend and descent
00:39:49 [ChrisL]
font.ascender.osx.yosemite
00:40:00 [roc]
astearns: the font object just gives you some input data for lineboxes. Doesn't give you everything
00:40:12 [roc]
astearns: might need to add information to line boxes themslves
00:40:20 [roc]
Rossen: keep lineboxes and font metrics separate
00:40:24 [roc]
astearns: agree
00:40:35 [roc]
Rossen: line boxes have multiple boxes and fonts
00:40:43 [roc]
Rossen: font objects have just one font
00:41:01 [roc]
SteveZ: four definitions of ascender/descender values, per font. Different values depending on when fonts overflow embox etc
00:41:25 [roc]
dbaron: our font code does some fun things to figure which values to use, trying different tables. Not very interoperable
00:41:36 [roc]
dbaron: try to define it in a way that allows such variation
00:41:43 [ChrisL]
http://www.w3.org/TR/2008/REC-CSS2-20080411/fonts.html#ascent
00:41:44 [roc]
SteveZ: fine. Just a warning that it's a pitfall
00:42:00 [roc]
SteveZ: you need ascender/descender as well as baselines
00:42:11 [roc]
astearns: spec has to say how you get these in these odd font situations
00:42:49 [roc]
esprehn: should discuss custom layout. Information needed by line-grid snapping etc
00:43:26 [roc]
chrisL: not just drop caps
00:43:28 [roc]
esprehn: drop caps sounds like custom layout
00:43:39 [roc]
SteveZ: waiting for custom layout for drop caps is not desirable
00:44:14 [roc]
astearns: I need the cap height to set the size
00:44:20 [roc]
Dirk: font metrics are also necessary for canvas
00:44:41 [roc]
esprehn: canvas has measureText already
00:44:45 [roc]
roc: not much information
00:44:50 [roc]
SteveZ: typographers are fussy
00:45:12 [roc]
ChrisL: calling for volutneers
00:45:14 [roc]
TabAtkins: not me
00:45:16 [roc]
ChrisL: me
00:45:19 [roc]
Rossen: we'll get there
00:45:28 [esprehn]
What information is missing from https://developer.mozilla.org/en-US/docs/Web/API/TextMetrics ?
00:45:28 [roc]
SteveZ: information is not always available
00:45:53 [roc]
Rossen: anything else?
00:46:05 [roc]
ChrisL: want to get this going so we can get feedback at type conferences
00:46:32 [roc]
Rossen: who's interested in working on this?
00:46:39 [roc]
Rossen: besides Chris and Alan?
00:46:43 [roc]
Rossen: SteveZ
00:47:01 [roc]
Rossen: Resolution: start working on font metrics unless objection
00:47:03 [roc]
no objections
00:47:17 [roc]
Rossen: Resolved: SteveZ, Alan and ChrisL will work on Font Metrics Extensions module
00:47:46 [roc]
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]
ojan has joined #houdini
00:48:27 [roc]
SteveZ: needs to expose line box baseline even if there's nothing there
00:48:52 [roc]
Rossen: box tree editors will ensure that
00:49:00 [roc]
Rossen: let's break for lunch
00:50:02 [TabAtkins]
<br type=lunch dur=indefinite>
00:50:58 [franremy]
have a good lunch
01:09:51 [florian]
florian has joined #houdini
01:20:38 [florian]
florian has joined #houdini
01:36:02 [florian]
florian has joined #houdini
01:37:57 [kwkbtr]
kwkbtr has joined #houdini
01:49:17 [johanneswilm]
johanneswilm has joined #houdini
02:01:22 [Rossen]
bkardell_: are you still on the phone?
02:01:30 [bkardell_]
no
02:01:39 [Rossen]
ok
02:01:40 [bkardell_]
I got booted and then it wouldnt acceptt he code
02:01:48 [bkardell_]
are you guys ready to start again?
02:02:10 [bkardell_]
CONF1 right?
02:02:36 [dbaron]
Zakim, room for 3?
02:02:37 [Zakim]
ok, dbaron; conference Team_(houdini)02:02Z scheduled with code 26631 (CONF1) for 60 minutes until 0302Z
02:02:47 [dbaron]
ScribeNick: jet
02:02:47 [jet]
scribenick: jet
02:02:48 [murakami]
murakami has joined #houdini
02:03:29 [jet]
shane: dinner plans
02:03:49 [bkardell_]
26631 "this passcode is not valid"
02:04:44 [rbyers]
bkardell, give me a sec
02:05:13 [bkardell_]
no worries
02:05:54 [Zakim]
Team_(houdini)02:02Z has now started
02:06:01 [Zakim]
+bkardell
02:06:15 [florian]
florian has joined #houdini
02:06:20 [rbyers]
brian, can you hear Rossen?
02:06:21 [jet]
Rossen: PM agenda:
02:06:31 [Zakim]
+??P1
02:06:35 [jet]
Rossen: custom paint, custom layout
02:06:46 [dbaron]
Zakim, ??P1 is MeetingRoom
02:06:46 [Zakim]
+MeetingRoom; got it
02:06:54 [jet]
Rossen: input extensions, async, threading, process
02:07:07 [jet]
Ian: whiteboard
02:07:08 [rbyers]
Zakim, who is here
02:07:08 [Zakim]
rbyers, you need to end that query with '?'
02:07:11 [rbyers]
Zakim, who is here?
02:07:11 [Zakim]
On the phone I see bkardell, MeetingRoom
02:07:13 [Zakim]
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 [Zakim]
... vollick, shane, rbyers, dstockwell, hober, TabAtkins, astearns, SimonSapin, CSSWG_LogBot, iank___, plinss
02:07:27 [dbaron]
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 [ChrisL]
custom paint https://c1.staticflickr.com/9/8061/8206144541_4843dd6445.jpg
02:07:42 [jet]
Ian: custom paint assumes invalidation eg. custom properties
02:07:58 [Rossen]
Topic: Custom Paint
02:08:12 [jet]
iank___: properties that invalidae paint (not layout) should have paint callbacks
02:08:20 [jet]
iank___: with custom context to be safe
02:08:35 [jet]
iank___: to not leave layout in an inconsistent state
02:08:52 [jet]
iank___: roughly have 3 areas to override:
02:08:57 [jet]
1. on BG layer
02:09:00 [jet]
2. on content
02:09:10 [jet]
3. on outline (potentially)
02:09:13 [rbyers]
Zakim, who is noisy?
02:09:25 [Zakim]
rbyers, listening for 11 seconds I heard sound from the following: bkardell (64%), MeetingRoom (36%)
02:09:32 [jet]
dean: does this include children?
02:09:36 [jet]
iank___: no sure
02:09:37 [bkardell_]
hmm.. I am muted
02:09:55 [bkardell_]
Zakim, mute bkardell_
02:09:55 [Zakim]
sorry, bkardell_, I do not know which phone connection belongs to bkardell_
02:10:01 [bkardell_]
Zakim, mute bkardell
02:10:01 [Zakim]
bkardell should now be muted
02:10:10 [rbyers]
bkardell, did you just mute the room?
02:10:11 [jet]
roc: there's an argument to be able to modify paint for your children, eg. for effects
02:10:24 [jet]
roc: we should constrain scope
02:10:37 [jet]
iank___: we should constrain to just your paint (not children)
02:10:44 [rbyers]
bkardell, I was testing my hypothesis that Zakim has the names inverted
02:10:51 [bkardell_]
rbeyers - did I? someone asked who was noisy, it said me but my phone was muted
02:11:08 [bkardell_]
there's no sound now though :)
02:11:17 [rbyers]
bkardell, ok then I Was right.
02:11:18 [jet]
iank___: eg. in a function(ctx, style) get a canvas context and style info
02:11:21 [rbyers]
Zakim, unmute bkardell
02:11:21 [Zakim]
bkardell should no longer be muted
02:11:29 [rbyers]
Zakim, bkardell is confused
02:11:29 [Zakim]
+confused; got it
02:11:36 [jet]
iank___: ctx.clipPath = path
02:11:36 [bkardell_]
LOL
02:11:44 [rbyers]
Zakim, MeetingRoom is bkardell
02:11:44 [Zakim]
+bkardell; got it
02:11:46 [jet]
iank___: ctx.paint(self)
02:11:54 [rbyers]
Zakim, confused is MeetingRoom
02:11:54 [Zakim]
+MeetingRoom; got it
02:12:14 [jet]
dschulze: can we cover the diferent paint phases?
02:12:34 [jet]
iank___: most effects are covered, per canvas
02:12:49 [jet]
iank___: or just use the background layer depending on how fine-grained
02:13:07 [jet]
dirke: what are the use cases for custom paint
02:13:20 [jet]
iank___: eg. Google material design
02:13:36 [jet]
iank___: draw custom shadows on buttons
02:13:49 [jet]
iank___: currently we add DOM nodes to get this effect
02:14:01 [jet]
dirke: why do that? Chrome can already draw a canvas element as a BG
02:14:21 [jet]
iank___: demo on screen
02:14:38 [iank___]
http://www.polymer-project.org/components/paper-button/demo.html
02:14:50 [jet]
iank___: we can't do this easily with DOM elements today, and need script for that
02:15:10 [jet]
iank___: when first designed, button effects had gradients
02:15:28 [jet]
dean: you already have the context, should be able to set what you want, eg. WebVR
02:15:44 [jet]
dean: need to know the backing store to cover the element and effect
02:16:03 [jet]
dean: needs more knobs on the API
02:16:18 [jet]
esprehn: currently read-only API no backing store
02:16:39 [jet]
dean: may need to be able to get readback (eg from WebGL)
02:16:53 [jet]
iank___: eg, for getting 3D canvas
02:17:03 [jet]
dean: don't limit to 2D API
02:17:16 [jet]
dean: might need a retained model like SVG
02:17:41 [jet]
dean: can do similar effects with SVG as input to custom paint
02:18:11 [jet]
esprehn: with 2D canvas you can address a lot of use cases
02:18:21 [jet]
esprehn: we can do 3D and displayList later
02:18:44 [jet]
iank___: initially, specify 2D context, leave it open for later
02:19:08 [jet]
dirk: how is it diffrent from BG canvas feature?
02:19:28 [jet]
iank___: problems with webkit BG canvas
02:19:38 [jet]
iank___: can't use the default canvas
02:20:04 [jet]
roc: don't want to introduce new rendering, just modify existing parts
02:20:31 [jet]
esprehn: want to call in before and after paint
02:21:04 [jet]
esprehn: shows physics effect on whiteboard
02:21:27 [jet]
iank___: you need a known width/height before use for canvas
02:21:32 [bkardell_]
SimonSapin: glazou proposed this in 1923
02:21:40 [jet]
iank___: with proposed API you can get dimensions at paint time
02:22:08 [bkardell_]
glazou: :) <3
02:22:10 [jet]
iank___: say width is animating, you can do effects without synchronous layout flush
02:22:56 [jet]
roc: you can apply an effect, draw yourself but if content is complicated, layerization gets messed up
02:23:31 [jet]
roc: eg. video on the background, call drawSelf( ) draws the button and video, but now layer decisions get comlicated
02:24:00 [jet]
esprehn: you'll need to opt into staying on top or below other content to force layerization
02:24:24 [jet]
roc: if clipping, you need to wrap your content with different options
02:24:40 [jet]
esprehn: you need some way to push a clippath or opaity layer
02:24:45 [jet]
s/opacity
02:25:06 [jet]
esprehn: probably want a surface area that's closer to a traditional drawing API
02:25:15 [jet]
esprehn: or use a display list
02:25:59 [jet]
dirk: are the 3 context options combineable?
02:26:10 [jet]
iank___: no, one per paint phase
02:26:33 [jet]
iank___: depending on what's useful for authors
02:26:57 [jet]
dean: if you'e doing something with video, compositor handles video paint
02:27:21 [jet]
dirk: can we handle certain phases first?
02:27:37 [jet]
roc: how important is it to modify content now?
02:27:49 [jet]
esprehn: can't mask to arbitrary shapes
02:27:59 [jet]
roc: you can do it with SVG masks
02:28:16 [jet]
esprehn: can't do it without layout flush
02:28:27 [jet]
roc: which use case?
02:28:55 [jet]
esprehn: want to mask descendents based on current size
02:29:17 [jet]
esprehn: to scale the effect as size changes
02:30:00 [jet]
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 [jet]
dean: with video, you'd get a lag unless we do compositor tricks
02:30:38 [jet]
roc: ramps up the complexity for edge cases
02:30:51 [jet]
esprehn: just for clippath?
02:31:20 [jet]
roc: you can get into very complicated states with multiple transforms, or not draw at all, or call drawSelf() twice
02:31:40 [jet]
iank___: drawSelf is constrained before() or after() only
02:31:57 [jet]
roc: complexity is added by masks, etc.
02:32:25 [jet]
shane: seems pretty standard to invoke custom behavior before or after a bult-in context
02:32:32 [jet]
s\built-in
02:32:53 [jet]
esprehn: add clippath, opacity, transforms with API
02:33:23 [jet]
dean: 3D API's allow hooks into different pahses of the rendering
02:33:42 [jet]
iank___: mangle with a limited subset within API
02:33:56 [jet]
dean: does this happen before filters and xforms?
02:34:15 [jet]
shane: filters should apply
02:34:26 [jet]
dirk: filters affect all operations
02:34:59 [jet]
dean: you won't be able to override a CSS clippath with custom paint
02:35:06 [jet]
iank___: that should be fine
02:35:27 [jet]
shane: why can't we exose clippath?
02:35:47 [jet]
dean: you shouldn't be able to modify the clippath passed into you
02:36:04 [jet]
shane: you can modify local clippaths
02:36:43 [jet]
dean: I'm worried about restrictions per context
02:36:56 [jet]
dean: to avoid touching the backing store
02:37:13 [jet]
shane: we can add other contexts later
02:37:36 [jet]
roc: what kinds of restrictions we want in the JS environment?
02:37:54 [jet]
iank___: initially, just get the context, read the style, get the fragment size
02:38:05 [jet]
roc: do you have persistent global state between paints?
02:38:16 [jet]
iank___: the style object passes in state
02:39:13 [jet]
esprehn: the features are coupled with custom CSS properties (eg. to cover animated physics based on buttonDown)
02:39:24 [jet]
esprehn: whiteboard
02:39:38 [jet]
iank___: state comes from style
02:39:53 [jet]
roc: won't need to count paints without global state
02:40:03 [jet]
roc: how to send/receive messages?
02:40:09 [jet]
iank___: via the style object
02:40:29 [jet]
dean: how about images?
02:40:45 [jet]
iank___: use an arrayBuffer with the image data
02:41:07 [jet]
roc: use transferables/structured clones in the API
02:41:29 [jet]
dean: what's in the style object?
02:41:46 [jet]
iank___: either all computed style or just what relates to paint
02:42:07 [jet]
iank___: author can specify which properties they want
02:42:37 [jet]
esprehn: you should use the current geometry, not supplied sizes
02:43:00 [bkardell_]
it would be good to sketch out the process / relationships of what we are talking about (all of them I mean)
02:43:14 [jet]
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 [jet]
esprehn: except that not all layout causes paint
02:43:38 [bkardell_]
q+
02:43:42 [jet]
dean: you can specify what you want to invalidate paint
02:43:55 [jet]
dean: looks a lot like CSS shaders
02:44:45 [jet]
dean: are you allowed to control how long it should take to paint?
02:45:34 [jet]
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 [jet]
esprehn: specifications are intertwined
02:46:11 [bkardell_]
+1
02:46:19 [jet]
esprehn: first, a spec on the JS execution (in limited context)
02:46:32 [jet]
esprehn: then specs on the layout and paint
02:46:50 [jet]
dirk: how do you prevent pixel leakage?
02:47:19 [jet]
roc: how to prevent timing attacks?
02:47:29 [jet]
dean: limit out drawSelf()?
02:47:48 [jet]
esprehn: webGL makes sense above or behind content
02:48:07 [jet]
dirk: allow limited access to GL pixel data
02:48:34 [jet]
roc: rendering to GL surfaces will be high overhead
02:48:53 [jet]
dean: more worried about perf issues from usage
02:49:15 [jet]
Rossen: any concerns re: SVG?
02:49:34 [jet]
dirk: we don't have z-ordered paint phases in SVG (yet)
02:49:50 [jet]
ChrisL: canvas is expected to work with SVG
02:50:04 [florian]
florian has joined #houdini
02:50:27 [jet]
dirk: SVG should be able to work as well
02:51:58 [jet]
Rossen: resolution: shane, iank___ to work on Custom Paint proposal
02:52:24 [jet]
CSS Painting
02:52:54 [jet]
rbyers: do we need an uber spec?
02:53:06 [bkardell_]
rbyers: at least a note
02:53:30 [jet]
Rossen: next topic: Custom Layout
02:53:52 [jet]
shane: dinner at 6
02:54:49 [jet]
shane: Custom Layout callbacks like for paint
02:55:08 [jet]
shane: to read pieces of computed style that's targeted for Layout
02:55:19 [jet]
shane: will depend on fragment tree spec
02:55:25 [dbaron]
shane: filter the computed style to the pieces that are relevant for Layout
02:55:36 [jet]
shane: API needs to create such fragments
02:56:04 [jet]
dbaron: you want this to be separate from normal layout
02:56:16 [jet]
dbaron: with some new display type to invoke it
02:56:30 [jet]
dbaron: callbacks layout its children
02:56:33 [bkardell_]
dbaron that's mostly what we discussed at edge
02:56:44 [bkardell_]
seems good
02:56:48 [jet]
TabAtkins: new display:--whatever would work
02:57:24 [jet]
dbaron: mixing custom and builtin layout gets complex. new display type should avoid that
02:57:35 [jet]
shane: restrictions should make this more implementable
02:58:03 [jet]
Rossen: declaring an element to have custom layout should take over builtin layout
02:58:17 [jet]
dbaron: descendants that use builtin layouts should be OK
02:58:46 [jet]
dbaron: but don't let that happen with eg. table descendants that make anonymous boxes
02:59:25 [jet]
roc: fragmentation? do we need to support braking, etc?
02:59:29 [jet]
shane: yes
02:59:37 [dbaron]
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 [jet]
TabAtkins: need to support printing, etc.
03:00:32 [jet]
roc: interoperable fragmentation/breaking API will be hard
03:00:58 [jet]
shane: we can make that call later
03:01:18 [jet]
plinss: provide for breaking, doing so later may get harder to add
03:01:47 [jet]
SteveZ: use case for breaking: eg. MathML and text
03:02:18 [dbaron]
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 [jet]
plinss: break this out into smaller phases
03:03:21 [jet]
plinss: don't put everything in one call
03:03:39 [jet]
plinss: eg., have a phase for sizing
03:03:54 [jet]
shane: don't make engine-specific assumptions
03:04:21 [jet]
Rossen: how do you prevent hangs? infinite loops?
03:04:59 [jet]
Rossen: custom layouts often create cycles
03:05:23 [jet]
Rossen: how to prevent that?
03:05:48 [jet]
Rossen: can't keep it to one iteration. eg 13 levels of recursion?
03:06:31 [jet]
iank___: constrain things within phases?
03:07:54 [jet]
roc: are we OK with constraining to basic CSS (intrinsic width, computed width, height calculations from children, etc.)
03:08:11 [bkardell_]
seems ok - at least for now seems ok
03:08:29 [jet]
Rossen: flexbox and grid already exceed the basic CSS box calculation
03:09:03 [bkardell_]
q+
03:09:13 [bkardell_]
q-
03:09:18 [jet]
Rossen: shouldn't create cycles, but flexbox gets that way easily with custom layouts
03:09:22 [Florian_]
Florian_ has joined #houdini
03:09:45 [jet]
Rossen: treat custom layout as fixed size?
03:10:25 [bkardell_]
there's no sound - is there discussion off mic or did I get dropped again?
03:10:43 [jet]
iank___: API will be used by framework developers
03:10:57 [TabAtkins]
Some discussion is off-mic.
03:11:10 [jet]
roc: we need to prevent lockups even from iframe usage
03:11:20 [jet]
roc: eg. facebook like buttons
03:13:02 [jet]
Rossen: resolution: greg, iank___ TabAtkins, shane, Rossen, roc to start work on Custom CSS Layout
03:13:13 [jet]
dean: need use cases before API discussions
03:13:52 [jet]
15 minute break
03:14:56 [Rossen]
RESOLVED: shane, iank___ start work on Custom Paint Module
03:16:23 [Rossen]
RESOLVED: greg, iank___, TabAtkins, shane, roc, Rossen start work on CSS Layout Module
03:17:22 [Rossen]
s/start work on Custom Paint Modules/start work on CSS Paint Module/
03:18:44 [Rossen]
RESOLVED: SteveZ, Alan and ChrisL start work on Font Metrics Extensions module
03:23:30 [TabAtkins]
<br>
03:36:13 [johanneswilm]
johanneswilm has joined #houdini
03:37:28 [jet]
next topic: input extensions
03:37:49 [jet]
rbyers: on-screen demo
03:42:37 [jet]
rbyers: following up on TPAC discussions
03:42:49 [jet]
rbyers: these are all experiments
03:43:18 [jet]
rbyers: motivation is to enable native app scroll effects
03:43:46 [jet]
rbyers: enabling customization to tweak scroll effects
03:44:16 [jet]
rbyers: currently have to extend input events to reimplement scrolling
03:44:40 [jet]
eg. <iframe> scrolls horizontally within a container that scrolls vertically
03:45:10 [jet]
rbyers: problems with eg. iscroll libraries is that they don't feel "native"
03:45:34 [jet]
rbyers: demos scroll header (from Google material design)
03:46:31 [jet]
rbyers: demos scroll offset test
03:46:51 [rbyers]
Scroll sync test: http://tdresser.github.io/sync-scroll-offset-test/
03:46:53 [gregwhitworth]
gregwhitworth has joined #houdini
03:47:01 [rbyers]
Scroll header demo: https://www.polymer-project.org/components/core-scroll-header-panel/demo.html
03:48:11 [jet]
rbyers: shows how native vs. JS scrolling fails to sync
03:48:41 [jet]
rbyers: simplest solution: CSS scroll-blocks
03:49:05 [jet]
rbyers: currently on Chrome Canary
03:49:59 [jet]
rbyers: http://rbyers.github.io/scroll-blocks-on.html
03:50:53 [jet]
rbyers: demos different scroll-blocks settings
03:51:58 [jet]
rbyers: Chrome stops scroll blocking at 150ms
03:52:26 [jet]
rbyers: threaded fast paths will be covered later
03:52:59 [jet]
rbyers: See CSS snappoints in IE, Gecko and Safari
03:53:18 [jet]
rbyers: demos CSS snap points
03:53:38 [jet]
rbyers: demos JS implementation if snap points
03:54:22 [jet]
rbyers: you still need a hook when scroll happens (eg, setting scrollTop)
03:54:37 [rbyers]
Scroll customization design doc: https://docs.google.com/a/chromium.org/document/d/1VnvAqeWFG9JFZfgG5evBqrLGDZYRE5w6G5jEDORekPY/edit#
03:55:21 [jet]
rbyers: scrollState object (see doc)
03:56:00 [jet]
rbyers: element.applyScroll = function(scrollState)
03:57:07 [jet]
rbyers: enables snap points
03:57:37 [jet]
rbyers: JS developer doesn't need to handle different devices
03:57:49 [jet]
rbyers: complicated scenarios need more
03:58:05 [jet]
rbyers: eg. distributing scroll across multiple elements
03:58:09 [rbyers]
scroll-chaining: https://msdn.microsoft.com/en-us/library/windows/apps/hh466007.aspx
03:58:20 [jet]
rbyers: see IE's scroll chaining
03:58:51 [jet]
rbyers: IE can selectively consume scroll events and not bubble up events
03:59:33 [jet]
rbyers: distributeScroll( ) allows control for authors
03:59:54 [jet]
rbyers: we have 8 use cases to solve (as seen on native apps)
04:00:55 [jet]
rbyers: 3 main capabilities...synchronize scroling, customizing how scroll is applied, customizing how scroll is distributed.
04:01:21 [jet]
rbyers: provide 8 features, instead of 3 low-level hooks?
04:02:04 [jet]
rbyers: this feature also explains what CSS does
04:02:53 [jet]
rbyers: these API's allow for customization over time
04:03:03 [jet]
rbyers: as primitives
04:04:07 [jet]
roc: you can't implement Gecko snappoints with this API as it handles different gestures (not a generic scroll)
04:04:31 [jet]
rbyers: scrollGranularity can potentially handle it
04:04:57 [jet]
roc: it's good that API doesn't cover gestures
04:05:23 [jet]
roc: we want to be gesture-independent, but behaviors are gesture dependent
04:05:59 [jet]
rbyers: we can differentiate eg. keyboard vs. touch
04:06:41 [Zakim]
-bkardell
04:06:45 [jet]
rbyers: distributeScroll = function(scrollState)
04:07:26 [bkardell_]
hmm... something happened to the call
04:07:38 [bkardell_]
it now says "the conference is restricted at this time"
04:07:59 [bkardell_]
Zakim, why do you hate me?
04:07:59 [Zakim]
I don't understand your question, bkardell_.
04:08:29 [plinss]
zakim, room for 3?
04:08:30 [Zakim]
ok, plinss; conference Team_(houdini)04:08Z scheduled with code 26631 (CONF1) for 60 minutes until 0508Z
04:08:43 [Zakim]
-MeetingRoom
04:08:44 [Zakim]
Team_(houdini)02:02Z has ended
04:08:46 [Zakim]
Attendees were bkardell, MeetingRoom
04:09:01 [Zakim]
Team_(houdini)04:08Z has now started
04:09:08 [Zakim]
+BrianKardell
04:09:10 [glazou]
Zakim, code?
04:09:10 [Zakim]
the conference code is 26631 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), glazou
04:09:40 [Zakim]
+??P1
04:09:48 [rbyers]
Zakim, P1 is MeetingRoom
04:09:48 [Zakim]
sorry, rbyers, I do not recognize a party named 'P1'
04:09:54 [rbyers]
Zakim, ??P1 is MeetingRoom
04:09:54 [Zakim]
+MeetingRoom; got it
04:11:03 [jet]
dean: demo uses requestAnimationFrame( )?
04:11:29 [jet]
dean: top control needs to be aware of what scrolling does?
04:11:40 [jet]
rbyers: yes, that's how it's implemented now
04:12:47 [jet]
dean: twitter didn't modify system native scrolling behavior (on iOS) for 'pull to refresh'
04:13:00 [jet]
roc: like they had to do in Android
04:13:40 [jet]
shane: should allow override of system behaviors
04:14:17 [jet]
dean: scroll effects can be so platform-specific
04:14:33 [jet]
dean: how do we make it so authors don't have to catch all those cases?
04:15:24 [jet]
rbyers: enable 'pull to refresh' custom behaviors within native scrolling logic
04:16:22 [jet]
rbyers: pages that consume all touch events already override native scroling
04:17:22 [rbyers]
Scroll conceptual model: https://drive.google.com/a/google.com/file/d/0B7mjRvOU-oG-anR5LVdQQ0xxbFk/view
04:17:59 [jet]
rbyers: this conceptual model should let us implement current scrolling behaviors
04:18:54 [jet]
rbyers: JS should be able to create the scrollState
04:19:12 [jet]
rbyers: scroll bars are an open issue
04:19:55 [jet]
rbyers: scroll bars don't distribute scrolling
04:20:32 [jet]
rbyers: none of this has landed in Chromium yet
04:20:40 [jet]
rbyers: need to figure out threading
04:20:57 [jet]
dean: what's the fallback?
04:21:16 [jet]
dean: how to use it and not break on other browsers?
04:21:53 [jet]
rbyers: sites already take advantage of Chrome's custom scroll effects
04:22:39 [jet]
rbyers: polyfill on top of eg. iScroll library
04:23:08 [jet]
dirk: default scroll behaviors available? eg. native defaults?
04:23:45 [jet]
rbyers: yes, as function attributes modify applyScroll, but can call native implementations
04:24:25 [jet]
rbyers: run in an isolated realm?
04:24:28 [jet]
roc: no
04:24:36 [jet]
dean: yes!
04:26:04 [jet]
rbyers: need two ways: isolated (off main thread for speed/safety) and not (main thread)
04:26:39 [jet]
rbyers: can we keep same semantics for compositor vs. main thread usage?
04:27:13 [jet]
rbyers: can you transfer the scroll between main thread and compositor thread (to prevent jank)
04:27:23 [jet]
?
04:27:49 [jet]
rbyers: same as Chrome does after 150ms of blocked scrolling
04:29:07 [jet]
rbyers: support scenarios like google maps scrolling at 60FPS
04:30:14 [jet]
dean: how does the user handle cases for multiple devices (eg. can't do fast effects on mobile)?
04:30:35 [jet]
rbyers: revert to native scrolling when perf is an issue?
04:31:20 [jet]
rbyers: mousewheel handlers already implemented by sites (this API is similar)
04:32:30 [jet]
rbyers: scroll deltas specified as CSS pixels?
04:32:56 [jet]
rbyers: currenty implemeted in dips (Chromium units)
04:33:27 [jet]
Rossen: next steps: find editors, draft a resolution
04:33:49 [jet]
dean: experiment/implement and report back
04:34:05 [jet]
rbyers: prototypes landing soon
04:34:30 [jet]
Rossen: fallback scenarios should be graceful
04:39:17 [jet]
RESOLVED: rbyers TabAtkins mattrakow to work on CSS Scroll Extensions
04:39:48 [jet]
Rossen: next topic: Asynchronicity and Threading
04:49:33 [bkardell_]
are there any plans to talk about style isolation here? I mentioned it yesterday...
04:50:16 [jet]
bkardell_: not covered
04:50:44 [roc]
I just wrote this as a summary: https://wiki.mozilla.org/Restricted_JS_Execution_Contexts
04:51:05 [bkardell_]
not script isolation
04:51:30 [bkardell_]
or is that roc getting set up for next topic
04:51:42 [roc]
nothing to do with what you said, sorry
04:51:54 [bkardell_]
jet: not covered as in not on agenda or out of scope?
04:52:12 [jet]
bkardell_: not in the next topic
04:52:21 [bkardell_]
room is muted if people are back
04:52:48 [astearns]
roc: for style extensions, is a new isolated world needed for every property, or could a page have a single world for all the registered properties?
04:53:11 [jet]
</br>
04:53:44 [roc]
astearns: ideally, if implementation allowed it, I think we'd have an isolated world for every single parse and style computation operation
04:53:48 [jet]
vollick: Asynchrony and Threads
04:55:00 [jet]
vollick: use cases: infinite scroller, components from untrusted 3rd parties, large team coordination on large apps, material design "spinner" UI, snchronized effects (see CSS Scrolling)
04:55:30 [jet]
vollick: perf componentization & perf isolation
04:55:56 [jet]
vollick: web devs should be able to specify:
04:56:09 [jet]
vollick: what can be asynch?
04:56:15 [jet]
vollick: what can be deferred?
04:56:24 [jet]
vollick: what can be preempted?
04:56:36 [jet]
vollick: what's important on the page?
04:56:52 [jet]
vollick: classes of solutions:
04:57:10 [jet]
vollick: eg. UI workers
04:57:22 [jet]
vollick: Fancy Frames that can be asynch
04:57:38 [jet]
preempt, detachable, sandboxable
04:58:05 [jet]
Delightful DOM with asynch mutation, prioritized
04:58:21 [bkardell_]
Yes please
04:58:39 [jet]
Wicked Workers (see doc)
04:59:58 [jet]
vollick: Snazzy Scheduler for hinting
04:59:59 [roc]
roc has joined #houdini
05:00:36 [jet]
vollick: are people interested? to work on in Houdini?
05:01:04 [jet]
roc: DOM, frames, worker stuff not appropriate in Houdini? DOM experts aren't here
05:01:29 [jet]
Rossen: can we invite them?
05:02:18 [jet]
vollick: we need to involve the right people
05:02:41 [jet]
vollick: please send me names
05:03:34 [jet]
rbyers: concerns about main thread synch can be covered by Asynchrony proposals
05:04:10 [shane]
vollick's doc: https://docs.google.com/a/chromium.org/document/d/1wrBq3HMwxMTX521rE-qczF67YucdCRUsHuG3_oG5Cjw/edit
05:04:27 [jet]
Rossen: input and render parallelization in IE don't work as well on low-end devices
05:04:39 [jet]
Rossen: scheduler work should be prioritized
05:05:20 [jet]
vollick: adding capabilities to workers, spec needed?
05:05:43 [jet]
roc: WHATWG canvas in workers spec exists
05:05:44 [bkardell_]
vollick: amazing alliteration
05:06:21 [jet]
vollick: need worker threads that can affect paint
05:06:30 [shane]
bkardell_: we call him 'voluble vollick'
05:06:33 [jet]
vollick: eg. motion blur on scroll
05:07:13 [roc]
I think this is the link, but it's not loading for me: wiki.whatwg.org/wiki/WorkerCanvas
05:07:18 [roc]
http://wiki.whatwg.org/wiki/WorkerCanvas
05:07:40 [dino]
what about this one? https://wiki.whatwg.org/wiki/CanvasInWorkers
05:08:03 [jet]
rbyers: Synchronized Scroll (allowing JS to synch with main thread scrolling)
05:08:37 [roc]
hmmm
05:09:03 [jet]
rbyers: Asynch DOM sounds like low-hanging fruit
05:09:58 [roc]
dino: I think https://wiki.whatwg.org/wiki/WorkerCanvas is the consensus proposal
05:10:01 [jet]
vollick: spec should articluate what can be asynchronous (but not spell out thread creation details from engines)
05:10:48 [jet]
rbyers: ordering of events, etc. is currently browser-specific
05:11:10 [jet]
rbyers: spec could specify how authors can modify that
05:11:33 [tantek]
tantek has joined #houdini
05:12:54 [jet]
Rossen: some initial ideas for initial spec-ing now
05:13:49 [jet]
Rossen: let's socialize these ideas with other groups (UI workers, asynch DOM)
05:14:40 [jet]
shane: asynch DOM needs to work out how it affects Layout
05:15:19 [jet]
shane: start a draft here (in Houdini)
05:15:32 [jet]
Rossen: start with UI workers?
05:15:51 [jet]
vollick: features are orthogonal
05:16:23 [jet]
shane: we should resolve to work on it here or elsewhere
05:17:21 [jet]
dirk: come up with a proposal first
05:20:45 [jet]
RESOLVED: vollick TabAtkins shane Jacob Rossi to work with WebApps WG on CSS Async Style
05:21:43 [gregwhitworth]
Next topic: https://twitter.com/sgalineau/status/564280780281479168
05:21:46 [jet]
Rossen: next topic: Houdini Process
05:22:31 [jet]
Rossen: How often should we meet/discuss?
05:22:49 [bkardell_]
f2f is pretty hard for me unless you all want to come to my house or open a bridge :)
05:23:11 [jet]
glazou: F2F meeting joined with CSSWG worked well here
05:23:19 [jet]
glazou: NYC meeting is harder
05:24:33 [jet]
glazou: maybe better for the meeting after? due to budget constraints
05:24:51 [jet]
glazou: once or twice a month telecon
05:25:15 [dbaron]
FWIW, this meeting was announced (without firm dates) 2 months in advance and didn't have firm dates until 2 weeks later.
05:25:39 [jet]
Rossen: additional days before or after CSSWG F2F meetings helps travel
05:25:45 [bkardell_]
there is an extensible web summit in san francisco in april - lots of people should be there + tag, maybe good optional thing?
05:26:24 [jet]
SimonSapin: async decision making instead of telecons/F2F?
05:26:42 [jet]
dbaron: we should have docs to discuss before scheduling meetings
05:26:57 [jet]
dbaron: need more concrete stuff for the next time
05:27:14 [jet]
Rossen: move from "can" to "do" phase
05:28:03 [jet]
rbyers: Propose Houdini agenda prior to scheduling CSSWG meetings?
05:28:39 [jet]
dean: Houdini more important to synch with CSS than, say SVG
05:29:01 [jet]
Rossen: check back in a month before scheduling telecons?
05:29:13 [bkardell_]
q+
05:29:20 [bkardell_]
q-
05:29:22 [jet]
ChrisL: schedule a monthly telecon now, but assume cancelled unless agenda is set
05:30:12 [jet]
SteveZ: make every effort to resolve on e-mail and not telcon
05:31:03 [jet]
SteveZ: email, telcon, F2F as priority order for communication
05:31:34 [jet]
Rossen: adjourned
05:31:51 [jet]
glazou: thanks Google Sydney
05:32:29 [tantek]
could someone paste URL to the email to dinner?
05:33:31 [Zakim]
-BrianKardell
05:38:32 [Zakim]
disconnecting the lone participant, MeetingRoom, in Team_(houdini)04:08Z
05:38:34 [Zakim]
Team_(houdini)04:08Z has ended
05:38:34 [Zakim]
Attendees were BrianKardell, MeetingRoom
05:38:55 [florian]
florian has joined #houdini
05:42:11 [jet]
tantek: https://lists.w3.org/Archives/Public/public-houdini/2015Feb/0018.html
05:45:30 [rbyers]
RESOLVED: IanV JacobRossi (TabAtkins or ShanS) to start work on CSS async style
05:45:37 [rbyers]
(correcting previous resolution)
05:45:59 [rbyers]
they will talk to webapps on the other bits discussed (eg. async dom)
07:08:48 [Zakim]
dbaron, you asked to be reminded at this time to go home
07:24:19 [fantasai]
fantasai has joined #houdini
08:11:07 [fantasai]
fantasai has joined #houdini
08:50:16 [dauwhe]
dauwhe has joined #houdini
10:01:54 [florian]
florian has joined #houdini
10:02:31 [kwkbtr]
kwkbtr has joined #houdini
10:04:26 [kwkbtr_]
kwkbtr_ has joined #houdini
10:08:23 [florian]
florian has joined #houdini
10:09:51 [Florian_]
Florian_ has joined #houdini
10:17:37 [florian]
florian has joined #houdini
10:27:35 [Florian_]
Florian_ has joined #houdini
10:33:03 [Florian_]
Florian_ has joined #houdini
10:49:47 [johanneswilm]
johanneswilm has joined #houdini
11:13:24 [Florian_]
Florian_ has joined #houdini
11:21:58 [Florian_]
Florian_ has joined #houdini
11:27:12 [Florian_]
Florian_ has joined #houdini
11:35:25 [florian]
florian has joined #houdini
11:45:01 [kwkbtr]
kwkbtr has joined #houdini
11:52:07 [Florian_]
Florian_ has joined #houdini
12:18:22 [Florian_]
Florian_ has joined #houdini
12:29:46 [tantek]
tantek has joined #houdini
12:35:50 [florian]
florian has left #houdini
13:14:37 [kwkbtr]
kwkbtr has joined #houdini
13:50:37 [johanneswilm]
johanneswilm has joined #houdini