- From: Dael Jackson <daelcss@gmail.com>
- Date: Sun, 21 Feb 2016 14:45:29 -0500
- To: public-houdini@w3.org
- Cc: www-style@w3.org
=======================================================
These are the official Houdini Task Force minutes.
Unless you're correcting the minutes,
please respond by starting a new thread
with an appropriate subject line.
=======================================================
Agenda and Goal Setting
-----------------------
- Rossen opened the meeting with a conversation to re-dedicate the
group to the ambitious goals that Houdini was started with by
looking at how C++ handles extensibility and how CSS can move
in that direction.
- Box Tree API was brought up as potentially unnecessary, though
others believed that it could be used as a umbrella spec used
to describe the foundations that other specs will reference.
- There were two approaches mentioned for handling early-stage
specs: A spec with a lot of issues or a ReadMe without a spec.
- Both approaches had proponents so the selection between the
approaches will be in the spec author's hands.
- RESOLVED: Change the name of 'CSS Async Style' to 'Composited
Animation and Scrolling'
- Several specs were mentioned as close to FPWD, specifically
TypedOM, Worklets, Properties & Values, Paint and the group
decided to work on getting those to FPWD during the F2F.
====== FULL MINUTES BELOW =======
Agenda: https://github.com/w3c/css-houdini-drafts/wiki/Sydney-F2F-January-2016
Present:
Rossen Atanassov (Microsoft)
L. David Baron (Mozilla)
Bert Bos (W3C)
Rick Byers (Google)
Tantek Çelik (Mozilla)
Emil Eklund (Google)
Simon Fraser (Apple)
Joone Hur (Intel)
Koji Ishii (Google)
Dean Jackson (Apple)
Ian Kilpatrick (Google)
Peter Linss (Hewlett-Packard)
Cameron McCormack (Mozilla)
Simon Pieters (Opera)
Elliott Sprehn (Google)
Shane Stephens (Google)
Surma Surma (Google)
Alan Stearns (Adobe)
Xidorn Quan (Mozilla)
Ojan Vafai (Google)
Jet Villegas (Mozilla)
Ian Vollick (Google)
Philip Walton (Google)
Levi Weintraub (Google)
Greg Whitworth (Microsoft)
Steve Zilles (Adobe)
Regrets:
Tab Atkins (Google)
Dael Jackson (Invited Expert)
Scribe: shane
Agenda and Goal Setting
=======================
Rossen: Looking at the wiki, the agenda is light.
Rossen: Yesterday, Shane & I were chatting about how to kick off
meetings. I gave him a quick sketch that I've been using
internally.
[https://lists.w3.org/Archives/Public/www-archive/2016Feb/0002.html]
Rossen: We're going to use that sketch now to give us some focus
for what we're after and what we want to pursue.
Afterwards we'll hopefully end up with an actionable
agenda.
Rossen: When we look at the web platform, we have a platform of
network, parsing, DOM, CSS, layout, composition, render,
input.
Rossen: If we think about this at the level of extensibility, if
you're a C++ dev then you can make changes to the entire
platform.
Rossen: If you look at this from a JS point of view, though - DOM
has pretty much 100% ability to interact with the model,
Rossen: With a well defined public object, Element, and a good API
surface.
Rossen: So extensibility in DOM is pretty well covered.
Rossen: In CSS, you have CSSOM, you can access stylesheets and
play with style sheets, however if you want to extend this
you can't - you can't define your own properties or
values, interact inside the cascade, etc. So CSS is
*somewhat* available but there's a lot missing.
Rossen: Layout you can do a bunch of read-only callbacks. These
are on the element, you can't interact with layout object
directly.
Rossen: Composition and rendering you get basically no access,
Rossen: although perhaps Canvas is in this level.
Rossen: Input has some primitive events that you can use to try to
participate in the pipeline, but it's not overall well
defined.
Rossen: So bottom line, if you want to extend the platform e.g. by
adding a layout feature...
Rossen: In JS, you are forced to loop through the whole pipeline
so it's very inefficient. If you want to add the feature
in C++, you just add it.
Rossen: So what are some of the mechanisms that make things easy
in C++? There are a couple of things working for us:
Rossen: (1) strict rules, experts, code reviews
Rossen: (2) well defined internal objects to hang extensions off
Rossen: If we were to try and lift that extensibility to the JS
level, our current efforts in Houdini have been focused on
extending e.g. paint - participating in paint.
Rossen: We've also talked about custom properties and values.
There has been some interest (but no action yet) in terms
of the parser.
Rossen: There's been efforts and interest in the input pipeline,
Rossen: and we've discussed layout and layout API.
Rossen: So when I look at this picture, the one thing that is
immediately obvious is that this well defined Element,
although it corresponds to the DOM, it is not just DOM. It
gives you a lot more - lifetime, etc. - and you can use it
to impact the platform in various ways.
Rossen: For the rest of the platform, we have some kind of object
internally in all our implementations - for now I'm going
to call it the 'view' object. They're similar to Elements (
collections of properties and values) but distinct.
Rossen: All of the CSS properties we have today are applicable to
the Element object but not to the View. In CSS we have
this problem where whenever we add a new property there's
a giant matrix of interplay with other properties.
Rossen: The view object, at least in our implementation, has
really well defined properties, but they have nothing to
do with the Element. Things like width, height, custom
rendering methods, etc.
Rossen: A lot of what we're doing internally is trying to figure
out how to focus most of the intensive stuff (animation,
etc.) from layout down. We do this by trying to only
animate or change the view object properties.
Rossen: Unfortunately this is not always possible.
Scribe: leviw
Rossen: Layout and paint APIs are applicable to the view API.
Rossen: Given that there's not much of an agenda for the few days
that we're here, lets go back to the procedural things for
these meetings.
Rossen: We can try to spend some time this morning discussing the
big picture and what the things we're looking to achieve
are. What the things we believe should be there.
Rossen: ... things like the view object.
Rossen: We did something like this in Paris where we sampled the
developers and....
Scribe: shane
Rossen: If we're as ambitious as we were a year ago, we shouldn't
be shying away from the really hard problems.
Rossen: Layout, input - these are going to be hard problems.
Rossen: We don't need to figure them out completely now, but
shouldn't be putting them away completely either.
rbyers: Even if not exposing view object, what can we say about it?
Rossen: Actually there's a spec that we're going to work on -
process model for Houdini - that will outline how all of
these things fit together, explain the role of view
object, etc.
dbaron: How does what you're calling the view object differ from
what we were talking about as the box tree?
Rossen: It doesn't - I'm keeping it vague deliberately - not
necessarily a single box per view object. Speaking for our
implementation only, we have different objects based on
element type and box. They might be present but aren't the
box itself - e.g. parts of the box, things for composition
or manipulation.
Rossen: So I'm not imposing a name, but I'm trying to avoid
calling it a Box for now.
Rossen: But in terms of referential integrity, it's mostly the box
which would be backing up the view object.
heycam: Has it been discussed before how fine-grained the view
objects are?
Rossen: Yes, in the context of the box tree. e.g. what are all of
the inline fragments that are not necessarily backed by
HTML elements, but ranges of content instead? Definitely a
type hierarchy of objects that can be exposed to implement
everything.
rbyers: One piece missing: compositing. We don't have anything to
explain this, but can't explain e.g. scrolling without
compositing. Need some kind of compositing API.
Rossen: What sorts of stuff would go in here?
rbyers: Our opinion is that there should be an API that lets you
run script in a way that is typically synchronized with
compositor.
rbyers: It's known as async style, or as compositor worker. Async
style is a weird name because it encompasses scrolling
things too, which are not CSS related.
SteveZ: I'm confused by "scrolling is not CSS" - most of this
diagram is not CSS.
shane: Is it just a naming thing?
rbyers: You could ask same question about layout - is it really
'css'-layout-api?
rbyers: I'd like to believe that part of what we're doing is
enabling CSS to be swapped out,
rbyers: not that we necessarily should.
Rossen: Let's go through the specs. Aim is to get something to
look at today and tomorrow. One idea is to spend the time
getting specs ready to ship as FPWD - seems quite
actionable. Allows people to continue implementation
experiments.
Rossen: I'm looking to see how we can move from 'we can' to 'we
are'.
rbyers: One powerful idea - these are all complicated topics.
Can't solve just with design and speccing. So for me, 'we
are' is 'we are shipping features that are built
internally on these primitives'.
shane: Does it help improve confidence in the APIs if we are doing
this with Chrome?
smfr: It does to the extent that it shows the APIs are viable but
also there's a risk of lock-in.
rbyers: We need to be very humble about changing to keep up to
date with evolving specifications.
Scribe: iank
shane: I'm just going to take us through the specifications that
we have on drafts.css-houdini.org
shane: I'm going to make some strong statements here:
shane: Box Tree API, I get the impression that we don't need this
spec anymore, we don't need this Box Tree API. There for
two reasons, (1) as a measurement API (2) to help support
some of the layout API to do fragmentation cases.
shane: The first of the two use-cases is not very useful, as we
need a frame of lag between the frame, (2) is better to
roll directly into the layout API.
shane: I don't think we should keep working on the API.
rbyers: Should we still have some spec that talks about views?
Rossen: I hope that this would be the "umbrella" spec, which talks
about the main building blocks for the specs.
Rossen: It's a framework, it makes it easier to talk/argue about
things.
Rossen: I'm impartial about the Box Tree API for that reason.
shane: Should we resolve to drop the Box Tree API spec?
plinss: I think that this is premature.
plinss: I don't think we should resolve not to do this.
shane: We want to drop the "API" part. The "umbrella" spec should
define what the internal "view" object is and does, talk
about its lifecycle, actions, etc. The ways of accessing
that, in the future we may want to do that; however at the
moment, we have better APIs like IntersectionObserver etc.
shane: The fragmentation use-cases, building new boxes, etc, we
should roll these into the Layout API.
plinss: The other specs need to be able to reference these things,
I don't care about the document that they go in.
SteveZ: The API suggestions there didn't work, we should point to
where these things will be defined in this document.
shane: The "umbrella" spec should provide a really good model
about these things.
iank: I think the "umbrella" spec should cover most of these things.
shane: CSS Async Style; is currently empty, people know this as
Compositor Worker, a really solid explainer document would
help a lot.
shane: Same for the Layout API; create a Layout explainer.
dbaron: It's also useful to have a history for things that we
thought about.
ojan: Can we just have an emeritus section?
rbyers: Can just place these in the folders which have the spec?
shane: Yup.
shane: We will have a README.md for async style, and then
eventually a spec.
ojan: A good example of this is IntersectionObserver for this,
nice easy explainer that is accessible for devs and spec
authors, with the spec for spec authors.
shane: We should leave it at the more understandable rather than
completeness.
shane: I think the CSS Paint API is pretty good at the moment.
dino: Can we change Async Style to something that makes more sense?
shane: Lets just call it Compositing for now.
zcorpan: It was pointed out that there is already a compositing
spec. (compositing and blending).
esprehn: Composited Animation and Scrolling?
RESOLVED: Change the name of 'CSS Async Style' to 'Composited
Animation and Scrolling'
Rossen: Concerned that we'll still have things on the list,
because they're too hard, and pushing them off to later.
shane: I don't think that is happening.
esprehn: Instead of having an ED, we should just have an explainer.
Rossen: I'm not pushing back on this, I just don't want to push
things hard away.
esprehn: I think that we want to think about this more.
dbaron: I don't think that that has to be done in an explainer,
you can do this in a spec, with a bunch of issues.
esprehn: I find those hard to parse.
SteveZ: I think that there are two issues (1) easy for new people
to understand, (2) driving work forward; for (2) I don't
think that the type of document will matter.
dbaron: That there is a bunch of stuff that we agree on, that
isn't written down anywhere.
shane: We sort of have this issues in CSS.
dbaron: Less as TabAtkins and fantasai write this all down.
dino: Can we agree that putting them anywhere is better than
putting them in the minutes?
shane: They are just a place for people to talk about them
informally.
shane: Think about them however you want.
shane: CSS Properties and Values API; first part of this is pretty
solid, people can start implementing this, the one concern
that we have if the apply hook is worth it? We should just
drop apply hook for now; and see if we need it later.
heycam: What things does the apply hook do?
shane: Adjust style properties of an element based on another
property.
rbyers: Scroll API, I think that we want a spec here, I should
write down an explainer here. On blink we call it scroll
customization, or scrolling extensibility.
rbyers: On the naming of these, they are all about extensibility,
CSS Layout Extensibility API?
shane: TypedOM. There's solid ideas here, by no means complete,
very large surface area.
shane: Font Metrics, very much like parser, lots of talk, but
nothing written down.
iank: Worklets, are pretty good, rebuilt on modules, would like to
sit with other implementors and talk about anything that
might be content.
shane: Paint, Worklets, Typed, P&V all have drivers, should get to
FPWD.
shane: Make TabAtkins drive parser API more.
Rossen: glazou is already driving it.
shane: Sure lets leave it that way.
shane: Async Style, vollick to create explainer.
shane: Scroll API, rbyers create explainer.
shane: Layout, iank & Rossen have been working ideas on this.
jet: We have been getting requests for a css binary representation
for pre-compute selectors and other things.
shane: That could be another spec.
rbyers: That could be a use-case for the parser API.
Bert: Is the goal to make it faster or to make it smaller?
jet: These are people that see CSS as the next target for
something like WebASM.
shane: We've had experiments in the past were if you simplify some
rules, you get some things faster.
ojan: We did some experiments with HTML parser were it got 20x
faster. could do similar things for CSS.
shane: Second question that I had is that do we want to go through
each spec in one big group or split up into smaller group.
astearns: I think smaller groups make sense for explainers / for
things with FPWD makes sense for the whole group.
ojan: Would like to get TypedOM, Worklets, Properties & Values,
Paint to FPWD so that we can get implementations.
shane: Do we make this our primary goal is to get paint to a
primary goal?
Rossen: get we get a show of hands?
<everyone raises hands in the air>
Received on Sunday, 21 February 2016 19:46:30 UTC