• lars started
• overflow computation
• vertical writing direction
• CSS generated content and web components
• Servo Workweek

pcwalton, azita, jack, lbergstrom, brson, eschweic, eatkinson, kmc

• Need a pass to compute overflow regions, prune to a display port.

• pcwalton: Came up in NZ. Shouldn't call things 'top', 'bottom', 'left', 'right' because of 'vertical writing direction'.
• pcwalton: Instead of float-left, float-right it's float-bottom, float-top, etc.
• pcwalton: Don't name things assuming writing left to right.

• pcw: there is a spec with content/decorator, which allows you to create DOM nodes from CSS. there's some quesiton as to how this should be done. roc thinks that we should create actual dom nodes, but simon and i don't think that's necessary. we could generate a renderbox that doesn't have a real dom node associated with it.
• brson: the generated content is something that's visible to the user. you can't select generated content for example. is this visible to script?
• pcw: it is not visible to script
• kmc: this is stuff like ::before with text(foo).
• pcw: web components are the aiblity to create custom tags and they have a shadow dom. and it's only visible inside the tag not the outside. this is similar to XBL, which is a mozilla proprietary thing. making dom nodes in css is bad for off-main-thread css. we don't want to have to make it threadsafe (slow). it's possible that in the future that someone would make the generated stuff accessible to script; i hope not.
• kmc: shadow dom is the name for dom nodes you cant access from script right? and gecko uses these for controsl?
• pcw: yes. i think we should use web components for our form controls, etc, instead of using native stuff. contenteditable can also be implemented this way. decorators may die, so this may not be a problem. ithe easiest wya if we have to gneerate dom nodes from css is to run a pre-pass that generates those nodes. can just turn it on if websites use this.

• jack: this is still happening even though we upgraded rust, which we hoped would fix it. i will be working on this issue this week.

• seo: where should we send changes to glfw-rs? upstream repo or mozilla-servo repo
• jack: upstream. our local repo is mostly for the build system changes, but bjz is very responsive upstream. once we switch to rustpkg for builds, i expect we can stop forking the upstream repository.

• eston: i think the issue is unrelated to quad-tree memory; i suspect it is the glyph atlases in skia.
• pcw: roc and i discussed this and the only reason to use skiagl is for these glyph atlases. maybe the future we switch to cpurendering mostly of the time, but a smart layer system that renders on gpu where it helps (fonts).

• jack: flow tree is getting redone as an owned structure instead of a gc structure. that patch should land tonight or tomorrow. https://github.com/mozilla/servo/pull/721
• seo: there is currently rust-css submodule that represents css values by CssFloatLeft using different type for all the offsets. currently they are all different types, and i think they can be represented by the same time.
• jack: it probably makes sense to add what you need to add to make progress on servo work, but not spend a lot of time refactoring or fixing netsurfcss or rust-css.

[discussion of rust-css]

• jack: it was intended to be an abstraction layer so that we could replace netsurfcss and keep the same API. but it seems to be the wrong abstraction so now the plan is to throw it out entirely in favor of the new style system (rust-cssparser etc)

• jack: did samsung have an update on when a korean workweek would work?
• seo: not yet.
• jack: we're thinking of having one in september in MTV. I'll send an email to the list to hash out dates.