- From: Dael Jackson <daelcss@gmail.com>
- Date: Sat, 7 Nov 2015 09:50:30 -0500
- To: public-houdini@w3.org
Agenda Setting
--------------
- This conversation held no technical details.
The Model of CSS Houdini
------------------------
- Rossen brought the feedback he had received from the domain
experts of his team.
- There was concern that there was a lack of definition for
high level objects/concepts.
- There is a need for more APIs related to Layout.
- It was agreed that having a document explaining the overall
model would be helpful.
- There were several potential use cases and examples
discussed for inclusion in the document.
- The model Ojan created for the rendering pipeline was held
up as a good example of what this document should look like.
- The document should also have use cases and requirements in
it to increase understanding.
- RESOLVED: Write an umbrella spec/explainer to explain the big
picture Houdini model.
===== FULL MINUTES BELOW ======
Agenda: https://github.com/w3c/css-houdini-drafts/wiki/TPAC-F2F-October-2015
Present:
Rossen Atanassov
Tab Atkins
David Baron
Dean Jackson
Ian Kilpatrick
Peter Linss
Myles Maxfield
Ryosuke Niwa
Simon Pieters
Simon Sapin
Alan Stearns
Shane Stephens
Ojan Vafai
Scribe: iank
Agenda Setting
==============
Rossen: TPAC wiki only has one agenda item, next F2F item.
Rossen: So who has a real agenda topic?
<Rossen> https://github.com/w3c/css-houdini-drafts/wiki/TPAC-F2F-October-2015
shane: Have a look through properties and values.
iank: Same for processors.
iank: Same for paint.
shane: Properties and values, processors, paint... what if
anything is needed for FPWD?
dino: I would like to talk about scroll.
shane: TypedOM is not ready for FPWD. But would like a quick review.
Rossen: Anything else?
Rossen: "The Model"
shane: 15m bikeshed for processors/isolated-workers/worklets.
shane: Anything we need to talk about for Sydney? Set some goals
to reach for then?
Rossen: Who wants to start?
Rossen: The "model" is more of an overall strategy for how we do
things in Houdini.
Rossen: I'm not sure the current way of doing things is the most
optimal way to do things.
Rossen: Lets start with the "model" then.
The Model of CSS Houdini
========================
Rossen: Since last F2F we spent some time talking to people within
our organization, about Houdini, to test the ideas which
are starting to happen in Houdini.
Rossen: In order to get all the feedback with the domain experts.
Rossen: The current feedback that I've been getting is "what are
you talking about?"
Rossen: "Why are you trying to do these things they way that you
are doing them?"
Rossen: Let's talk about the pipeline as we currently talked about
it in Paris.
[draws on whiteboard] : DOM Style Layout Paint ...
Rossen: Good set of APIs exposed to the DOM. Some APIs available
for Style. None for Layout. Some available for Paint.
Rossen: Input not really many APIs.
astearns: Some API for Layout, but people just absolutely position
things for Layout.
Rossen: This is more or less a good mental picture to keep in mind
for web developers.
Rossen: I think we can agree that there is a huge need for more
Layout.
Rossen: The reason for the feedback that I've been getting, as a
platform developer, you can say that DOM is good as
Element etc. has a good set of APIs.
Rossen: Layout is bad as we don't have anything that we can refer
to...
ojan: The stuff we have is all shoe-horned into Element.
Rossen: The presentation part of our MVC model is missing.
Rossen: Lollipops; there is a point in time were we can provide an
API hook, and give developers a API hook.
shane: I don't think that this is what we've done with Paint.
shane: I think we've extended the current primitives on the
platform, not exposed a lollipops.
Rossen: I've seen any effort spent with defining the "view" object
for this system.
ojan: Currently on the web we expose the lollipops through the
Element.
Rossen: Another way that we could approach this to have a polyfill
to which exposes the "view" object.
ojan: The thing that you've described, that I think we've done
already.
ojan: Today we expose the DOM to javascript.
ojan: Today what we've been designing is a new set of APIs in an
isolated context.
ojan: Why don't we expose the layout tree objects in the main
javascript contexts.
ojan: The feedback that you've got internally is, why do you want
to do it in this separate context.
Rossen: Why are we not spending enough time defining this "view"
object.
ojan: You are saying that we have the DOM element, then the "view"
element which does style/layout/paint.
shane: What is the view element?
shane: I'm not seeing the missing piece.
ojan: It might be an object that has x, y, width, height then a
canvas which you can paint to.
ojan: In the current world there is a paint object, and layout
object which are two separate things.
shane: It does have a consistent view, it asks people to look at
as a pipeline, and treat it like a GL pipeline, where you
install "fragment" & "vertex" shaders into the pipeline.
Rossen: I can also give examples which expose with a "view" object
model.
Rossen: I don't want to spend time spending engineer resources to
design a propeller when I might be building a bike.
ojan: We have a set of proposals that we talked about in Paris,
it's hard for me to understand without a proposal.
<astearns> question whether it's an alternate proposal or whether
we're just not putting enough focus on layout and box
model
dino: At the moment we are trying to expose, in Apple what we call
SPI.
dino: Rossen is saying is we haven't really defined what we high
level objects are.
ojan: In our model we defined a model which is well defined.
dino: It's a question about details about how style effects layout.
ojan: We talked about the pipeline stages in Paris.
Rossen: We can talk about things we can expose to the pipeline,
and hope that it fits into the "view" objects, or we can
define the "view" objects and try and to make sure they
fit into the rendering pipeline.
astearns: Example - I have a DOM element, and in layout it gets
split into layout, and I want a custom paint routine for
each linebox in each fragment in that layout.
astearns: Is this something that your pipeline is going to get to
at the moment?
shane: I'd really like to see a concrete sketch with what you are
proposing.
shane: Without that having a hard time to see what this is.
Rossen: I haven't seen anything prepared.
shane: Asking a few questions...
shane: Would you like to see features exposed in the main
javascript context instead?
Rossen: Not necessarily.
Rossen: I would like us to to spend some time to expose a view
object. We need to define what the relationships between
elements, view-objects, style, etc. Then need to define
what type of methods to expose from the get-go to expose
layout, paint, etc.
ojan: People are MS object to split up into style/layout/paint
into different APIs.
ojan: There is the main context, and possibly another context.
ojan: There wouldn't be a separate context for style/layout/paint.
ojan: The way that we ended up this way, is to allow
implementations to be multi-threaded. Not lock into
single-threaded mode.
ojan: When you call offsetHeight on an element, it needs to flush
all the view-objects.
Rossen: No, why. Let's say that I have a view-box, that I have a
reference to.
ojan: Yes that fine, but let's just say that you have a widget on
a page, that widget uses a custom layout, then you have
jQuery which will use offsetHeight etc, that code uses
offsetHeight. You need to flush the object pipeline to get
offsetHeight.
ojan: I'm trying to narrow down on a more concrete thing we can
talk about.
Rossen: I have an unpolished sketch but, not ready yet.
Rossen: I don't want to change course, but I want to create a new
view on what we are doing.
Rossen: We don't have any document that is currently talking about
this, no document that is talking about this overall
object model.
Rossen: If you even think about the abstract pipeline from a devs
point of view, I haven't specified properties, and I will
have computed properties that will appear from a cascade.
Used-properties don't belong to the element, belong to the
view instead.
Rossen: If I have a view-object, how can I attach paint callbacks,
etc.
Rossen: We can define this programming model, we can build it as a
polyfill, which is the north-star, we can start lighting
it up with various points.
shane: I think one major part of what you are asking for is the
data-flows through the pipeline.
Rossen: This is implementation.
ojan: Let me try and make this more concrete.
shane: I think we've had discussions internally, but poorly
explained to the group.
Rossen: [Explanation of how Brian explained animations]
shane: When we built the animations API, we co-evolved the APIs
and Model.
ojan: Lets just try and explain this now.
ojan: My model for this is what do we need to do to compute
offsetHeight. Each stage of the pipeline has an input and
output.
ojan: The input is the specified style, and the output is the
computed style. With the typed OM proposal these will be all
the typed objects not just strings.
ojan: The input to layout is computed style, and output is the
"viewbox"
ojan: Input into paint is the computed style, and "viewbox".
Rossen: Only flow data through when we need to so we don't have
combination explosion.
ojan: Would a version of that be to say what properties do pipe
through?
Rossen: No. We need to define what is on the "viewbox".
ojan: [explains material design ripple effect]
Rossen: How would you do this today in javascript?
shane: We've done this multiple ways in javascript; you need to
create a bunch of elements.
Rossen: Let's pretend that we have a new object, and then what
information do you need on the viewbox.
Rossen: I didn't hear that you need the computed style.
shane: The paint API does this already, you need to register a set
of dependencies, that are then given to the paint class.
ojan: Lets say that you have a ripple-property that you register.
ojan: That ripple-property depends on a bunch of things that you
registered on.
ojan: You wont get information for the <random-property> here.
astearns: You do get access if you get a pointer back to the
element.
shane: We have tried to avoid doing this.
Rossen: Style information is always read-only.
astearns: It's sometimes easier to have access to information to
everything. Now you need to do the record keeping to
different stages to the pipeline.
shane: That is true if you explicitly know the dependencies, we
engineer that can do clever things be skipping stages.
ojan: If you give access to the full computed style in the
pipeline, you don't know which stages that you need to re-run.
ojan: I agree that some ergonomics are missing, it is hard to
write code for this.
Rossen: I want to try and make it as simple as possible.
shane: Can add restriction to computed style that you can't get
properties that don't effect layout already.
Rossen: For having the entire computed style available on the
viewbox, for the point of view of the viewbox the computed
style is immutable. If it changes in the DOM context, it's
a copy on write.
ojan: The jQuery code will get the wrong value?
Rossen: The viewbox will be invalid for layout purposes.
ojan: How do you know you need to run layout again?
shane: If you don't register dependencies, you can't know when to
run layout/paint.
Rossen: In order to talk about tracking dependencies, we need to
have the mental framework for what to talk about.
Rossen: We are trying to track dependencies, but we haven't said
what we are tracking dependencies of.
dino: We've never talked about dependencies for the native
paint/layout phases.
ojan: Even webkit and blink have diverged as we've done different
optimizations.
Rossen: One proposal I have is to start working on this.
dino: Ojan you had a spec in Paris for the rendering pipeline.
dino: A document similar to that would be helpful.
shane: It's some type of unifying principle, what is the high
level system.
Rossen: We can use this document for everything, i.e. what is our
roadmap.
astearns: This will be useful, not just for us, but for other
working groups, i.e. dpub.
rniwa: In the editingTF the one thing that has been useful is list
of concrete use-cases.
rniwa: If (A) doesn't work for use-cases, you can fix the proposal.
It's useful as you have guidance for what we are building.
shane: Document should have use cases, by putting them with the
spec, much more clear.
zcorpan: You can put in requirements, for example this is
web-developer-friendly enough to be actually used for
example.
rniwa: Useful for shadowDOM as you can track which parties care
about which use-cases.
shane: One thing that we've done internally is that we've been
building concrete implementation on a branch. And can give
this to people.
ojan: The demos that we have given to people have completely
changed their view for what is possible on the web.
rniwa: It's too hard to do a hackathon on the beach.
dino: I don't think that we can dedicate a day.
ojan: It might be useful to come to Sydney, with some more examples.
shane: Some type of umbrella spec is a good idea.
Rossen: I'm happy to work on it as well.
[br len="15m"]
Scribe: TabAtkins
iank: Here's a demo I wrote showing the Google logo morphing when
you animate the width of the element.
iank: Goes from the Google logo to the bobbling dots, like when
you bring up the microphone.
iank: Let's look at code.
iank: [shows the registerPaint call]
iank: The paint callback gets a restricted paint context, the
width and height, and the style map, containing your
explicitly requested dependencies.
iank: Here, that's --scale and --total.
iank: All this does is draw the picture based on those two inputs.
iank: [shows the main-thread script]
iank: We'd done a rudimentary registration of the properties
[example: document.registerProperty("--scale", "<number>"); ]
iank: An animation.
shane: We can't do Web Animations on custom properties quite yet,
so this example does manual animation for it.
shane: But it would be replaced with a CSS animation normally.
iank: So onclick, this sets up a web animation that animates the
width (and indirectly animates --scale and --total).
iank: But in a mature implementation that would just change
classes and trigger a CSS animation.
iank: [shows the quantum paper "ripple" example"]
iank: [shows code]
iank: If we had a typed OM, you wouldn't have to parse the custom
properties like I'm doing here, you'd just get the numbers.
iank: Very simple - you don't have to resize the canvas backing
context to match the element, or anything like that.
iank: To use it, just write "background-image: paint(ripples);"
ojan: Pointing out that as a page author, all you do is that
paint() function.
ojan: As the paint author, you just write that small script.
iank: This could also maybe be a --ripples property, which mutates
the background-image itself.
iank: If the width was animating or something, the paint callback
would automatically be responsive to it.
RESOLVED: Write an umbrella spec/explainer to explain the big
picture Houdini model.
shane: There might be conformance requirements on other Houdini
specs in there.
Received on Saturday, 7 November 2015 14:51:28 UTC