- From: Dael Jackson <daelcss@gmail.com>
- Date: Sun, 21 Feb 2016 15:01:52 -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.
=======================================================
Updates from Yesterday
----------------------
- There were several updates on the progress for adding feedback
from yesterdays conversations to various specs.
- RESOLVED: Publish the FPWD of Properties and Values Lvl 1
pending edits (animation section)
Process Model
-------------
- Rossen led a discussion to move to a common terminology for the
process model to avoid confusion.
- Starting at the top of a tree, there are content objects and
underneath that are view objects that can be accessed
without knowledge of ancestors.
- After discussion that led to a common idea of concepts, even
though the exact language wasn't reached.
- It was suggested when writing the spec that it's easier to
have areas and fragments as separate in the beginning and
merge if needed.
- There was still a lot of concern about exposing browser
internals, though it was suggested in many or all cases the
used value could be what is exposed.
- The group got caught up on what would go in each category and
couldn't come to a final understanding of how the process
model should work.
====== 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)
Jihye Hong (LG Electronics)
Joone Hur (Intel)
Koji Ishii (Google)
Dean Jackson (Apple)
Ian Kilpatrick (Google)
Peter Linss (Hewlett-Packard)
Cameron McCormack (Mozilla)
Simon Pieters (Opera)
Florian Rivoal (Vivliostyle)
Hyojin Song (LG Electronics)
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: iank
Updates from Yesterday
======================
shane: I made edits to the Properties & Values API, so we could
talk about.
smfr: I think the make-or-break for Typed OM is how usable it is
for JS developers.
smfr: I would love more examples in the TypedOM spec, just to get
a feel for ergonomics, benefits etc.
shane: We have a polyfill, I'd like to check it into the houdini
drafts repo, next to the spec.
shane: Any objections to that?
smfr: Would be really great to bring up a codepen with it, etc.
surma: Would be good to have a separate repo, forkable, etc.
shane: Could be under a w3c repo and link.
shane: We'll make a separate w3c repo for the current polyfill,
and then link it from the spec.
Properties and Values
---------------------
<iank> https://drafts.css-houdini.org/css-properties-values-api/
shane: No apply hook now in the spec. Need to update title of the
example, but updated the example as discussed yesterday.
shane: With dbaron's help we fixed the prose about the calls to
registerProperty & unregisterProperty.
shane: I added support for all of the syntax strings.
shane: I also added a section describing how animation works. Not
a lot of spec, as can use a lot of current animations spec.
smfr: Is there any prose for describing animations of custom
properties are resolved?
shane: I have an issue on the wiki with a description.
shane: I don't know how to turn this into prose.
smfr: <uncomfortable with the prose at the moment>
dbaron: Choosing transition endpoints happens after computation,
but doing the interpolation at a specific time happens
before computation, and when a transition starts the
computation happens twice (because the first computation
results in the transition and then the second changes the
value to the appropriate start point for the transition)
shane: Anyone who is interested in this issue <above> will break
out today.
Rossen: This is the first one that we'll bring up as a FPWD
shane: I hope that we'll bring up those four at the same time.
Rossen: In terms of publishing these as FPWD, should these be
Houdini or CSS?
plinss: Houdini can't itself publish, TAG can't as no patent
protection, we'll need to publish under the CSSWG.
<tantek> Don't you still need the CSSWG in person to declare a WG
consensus to publish?
shane: Shall we resolve to publish this pending the addition of
the animation section, then follow up with the CSSWG?
RESOLVED: Publish the FPWD of Properties and Values Lvl 1 pending
edits (animation section)
astearns: Will confirm with the CSSWG in the next few days.
Rossen: Anything else from yesterday?
Worklets
--------
Scribe: leviw
iank: I added prose about the intrinsic sizes, removed all the
canvas text stuff (that was fairly straightforward).
iank: I just need to add some prose about these callbacks
happening on frame time boundaries.
iank: If we cycle back this afternoon I can have that stuff done I
think.
rossen: We can just do a pass at the end of the day about what's
been done unless folks have substantial changes they want
to mention.
rossen: Next we have the animation and scrolling extensibility spec.
shane: We were also going to break out the font metrics and parser
things at this time.
rbyers: To recap what we said yesterday: we're not reviewing
specs, we're brainstorming and talking use cases.
Process Model
=============
rossen: We have the same thing for the process model. Same basic
state -- need to provoke discussion in the broader group.
rossen: Since we already have everyone in the broader group, we
might as well do that. No reason to avoid broader
discussion if we have everyone.
SteveZ: Text metrics will be more useful after layout discussions.
Rossen: Let's go back to the process model. Like rbyers, I don't
have a spec, but I'd like to go over the use cases and
round out the model.
Rossen: One of the interesting points from yesterday was that we
spent the morning going over the model then spent the rest
of the day talking about various things and ended the day
talking about Typed OM.
Rossen: Even at the end of the typed OM discussion, some folks
kept talking about layout properties as CSS properties.
Rossen: This frightens me, as if we can't keep these straight as
implementers and speccers, how are folks outside this room
going to understand it?
Rossen: I can go back and redraw some of the ideas I was going on
about yesterday to talk about the shape of the model we
want to build.
Rossen: Mostly I want to focus the discussion and terminology to
make sure no one is confused.
SteveZ: Maybe because I'm layout-biased, having some concept of
the view object is one of the central things about making
your model work.
SteveZ: At least as far as the typed OM is concerned, this is a
place the confusion was coming from.
Florian: We need to make sure that even when we're only halfway
through everything, we need to make sure we still have
something usable. Fragmentation is an example of this.
<Rossen steps up to the podium to present>
Rossen: Back to SteveZ's question about the view object
Rossen: If I was to draw a diagram... we have Content elements,
generated from svg or anything... they make a tree and
contain each other. They also have styles attached.
Rossen: We all know about specified vs computed vs used, but we
don't necessarily expose them in a good way that people
can use.
Rossen: I would say that elements have a specified style...
Rossen: Actually, I would call them properties.
Rossen: They would get there via matching rules or inline styles.
Rossen: A parsed set of properties that end up attached to an
element.
Rossen: The specified properties object has the entire set of
properties that can be defined,
Rossen: after the full cascade and matching.
Rossen: The computed properties are a subset of the properties
that are specified.
Rossen: You don't need to have cm or inches, or any of the
font-related lengths.
Rossen: All you need in computed values is pixels, percent, and
auto.
Rossen: Everything else reduces down to those,
Rossen: including vh.
Rossen: "what about Calc?"
Rossen: It's the same as percent,
Rossen: just more complicated.
Florian: The only thing that surprises me here is "vh"
Rossen: Backtracking 5 minutes ago, we are currently dealing with
an element in the middle of cascade.
Rossen: It got the computed style form its parent, it has its set
of properties, and at this point in time you know what
your viewport size is.
Florian: What about paged media?
esprehn: They don't depend on what page they're on.
Rossen: Moving along... after we have the full set of content
elements and their properties (I'm skipping animations),
we have the full set of computed values.
Rossen: From this point on... MAGIC
Rossen: Boxes are generated, and I'm calling these view objects.
<Florian> quoting the spec: "For paged media, the exact definition
of the viewport-percentage lengths is deferred to
[CSS3PAGE]."
<Florian> (and CSS3PAGE is silent on the subject)
Florian: How is a view object different from a box?
Rossen: It's not.
Rossen: I'm trying to pick something no one uses to avoid confusion.
Rossen: This thing is drawable, you can query a bunch of things
from it, it ideally has a collection inside it...
dbaron: Given that the spec has called these boxes, I'm skeptical
of giving these a new term.
Rossen: I don't mind calling them boxes.
shane: They may have multiple boxes in them.
Rossen: Because of fragmentation.
Florian: Then we shouldn't call them boxes.
Florian: The thing we call boxes in the spec doesn't multiply
because of fragmentation.
SteveZ: I wanted to observe that XSL:FO differentiated between
areas and traits, and areas have children.
SteveZ: You can get multiple areas per element even without
fragmentation.
Florian: Does fragmentation cause them to multiply?
SteveZ: It has a different pagination model, but yes.
SteveZ: I agree with Florian that using boxes for both is confusing.
Florian: Do we know how many of these objects we have before
layout or do we need to do layout to figure out how many
of these we need?
Rossen: "yes"
Florian: I think from this terminology, we know how many boxes we
need before layout, but not how many fragments.
Bert: Except for inline boxes.
shane: Does this distinction matter?
Florian: We want the entity that has everything required up unto
layout, but before.
shane: This discussion is getting difficult to follow. Probably
best written down and talked about offline.
Rossen: I want to settle on terminology
Rossen: Let's not use "traits" when we mean "properties"
Scribe: Florian
Bert: What about regions and generated content? Can't we get areas
without elements?
Rossen: Properties can create areas?
Bert: Pseudo elements as well.
Rossen: Content elements in the diagram are not necessarily markup
based element,
Rossen: they're just a tree. We're not discussing yet how that
tree comes into existence.
Rossen: But let's keep it high level.
Bert: How about the page margin boxes, are they content elements?
Rossen: I think so.
Florian: How about grid slots?
Rossen: Good point. Maybe there's something in the middle that
creates these areas.... That's where we need spacial
information.
Rossen: Starting with the viewport, and building from there.
Rossen: This is part of the process of creating areas, you don't
necessarily need them after.
SteveZ: To be able to write APIs for that process / black line in
the middle, you need to know how much context you have
access to.
SteveZ: We don't want cyclic dependencies.
Florian: Are all these things trees? Doesn't ::first-line break
that?
Rossen: On the Area side, it should be clean, regardless of how we
got there.
Rossen: At the very start it's a tree as well. In the middle it
might not be.
SteveZ: Region styling as well.
Florian: Same situation
Bert: Both input and output are trees, but they may not have the
same shape.
Rossen: Absolute position also changes which is your parent, so yes.
Rossen: But trying to stay high level...
Rossen: If we look at getComputedStyle()
Rossen: It's interesting. Some kind of a mix between properties
and traits, picking information on the fly from all over
the place.
Rossen: Typed OM should be fixing this.
Scribe: zcorpan
Rossen: Areas have references to elements.
Florian: On the element wording, in this view of elements, they're
not DOM elements.
Rossen: They're content elements.
Florian: ::before is a content element?
Rossen: Yes.
Florian: Call them something else.
Rossen: Content objects?
Florian: Yep.
Florian: So then I agree content objects have computed properties.
esprehn: No they're also DOM elements.
esprehn: The marker is one as well.
Florian: I don't care what we call these things but there's DOM
things and something else. Some of the latter come from
CSS like pseudos.
Rossen: We don't define how these are created. They can come from
SVG, or styling.
Florian: I think it's useful to have a difference.
Rossen: I disagree.
<dbaron> discussion is about whether the thing properties are on
("content objects") is distinct from DOM elements because
it also includes pseudo-elements that are created from CSS
Rossen: For the purpose of what we want to do in this task force
the distinction is not useful.
Rossen: If the only thing we're explaining is paint then the area
is what we care about, not the content element or anything
else.
Rossen: Let's say I have another API that's called hit test, is
this point inside of you. Should work on only area also.
Florian: I'm confused about what kind of ancestor you should
consider.
Rossen: Only "am I going to be hit on this point."
Rossen: Not ancestors.
Rossen: Also "can you resize yourself?"
Rossen: You can go back to the content element etc, but "can you
resize yourself?" you should be able to do this without
ancestors.
Rossen: Everything becomes readily available, but now we have more
context.
Rossen: We are dealing with view objects that have traits.
Rossen: It has a reference to content object.
Rossen: It could go there and grab more info.
Rossen: Now we have more common terminology.
Rossen: As a group here I think we're trying to help doing these
things.
Rossen: We're talking about typed OM and we're still talking about
traits which I find disturbing. We shouldn't do these
kinds of mistakes.
Rossen: We need to have a common understanding of the model.
Rossen: We're going to compete in quality of implementation
Rossen: There are many reasons that I'm considering to have this
as high-level as possible.
Rossen: One day we might have a View object.
Florian: What you're going after is very useful.
shane: Rather than arguing about the details, I think there are
features [???]
shane: I think the important parts are: there's a boundary here, a
style API should expose the left half [computed props,
content objects]
shane: It shouldn't expose the right half [area, traits]
shane: We should do the right half later.
shane: Computed props are style, not layout.
Florian: OK I agree.
Rossen: This is an open discussion.
Rossen: If we disagree about high-level, we're gonna have a bad
time when going lower.
Rossen: We also talk about the apply hook, which is relevant here
also.
Rossen: Let's stay away from API for now.
Rossen: What are the building blocks that we want to be extending?
Rossen: When we start talking about e.g. compositor, what are the
things we will be changing there?
Rossen: Some things are traits.
Rossen: some things are properties.
Rossen: I don't want us to be confused about terminology.
Florian: I agree with the model on the whiteboard
Florian: There are going to be more things we want to expose.
dbaron: I don't know where this conversation is going
dbaron: We're inventing new terms.
Florian: Start calling things traits instead of properties.
Rossen: offsetTop etc
dbaron: Those are ....
Rossen: getClientRect
dbaron: OK...
SteveZ: So geometry.
Florian: Right.
Rossen: elementFromPoint
dbaron: Where are we going with this?
Rossen: If we have the broader mind-share that this makes sense to
everyone, then we can stop here and put it in a spec.
Rossen: When we talk about callbacks, what are the properties when
we do a layout API, what is going to be there?
Rossen: It will make our life easier if we talk about these things
in a consistent way.
Rossen: I don't like the terms themselves but I want clarity.
Florian: Moving from this to a spec and later realize areas are
actually fragments it's not going to make things clearer.
Rossen: We can bikeshed the names.
SteveZ: It's easier to start by areas and fragments as separate
and then prove that they're the same, instead of the other
way around.
Rossen: Yep.
Rossen: We can talk about what happens in the middle etc, and
parsing, and so on.
Rossen: Print is on the right side.
Rossen: This is a first step.
Rossen: There will be a lot of things that are happening in the
middle;
Rossen: layout, render, compositing.
Florian: Determining the containing block is in the middle.
Rossen: Yes.
Bert: Say we have an animation, does that create new areas?
Rossen: Animations are cool. Fast paths of animations, at least
for us, are the ones that we can apply to areas and traits.
Rossen: Those are fast.
Rossen: If I'm transitioning a scale, only the traits changes.
Rossen: I don't have to recompute the style.
Bert: There may also be animations that create additional areas
during the animation?
Florian: Like changing the width of an element changes the number
of line boxes, so new areas.
dbaron: One characteristic of the fast animation is that in theory
they change things on the left side, but implement only
the right side.
Rossen: I like traits.
Rossen: OK any other comments?
Rossen: Can we capture this into a doc?
vollick: We're not talking about CSS properties, so the question
is do we need to reach consensus about what's common
among implementations about what is a trait?
Rossen: We haven't talked about types of areas, etc. grid areas
will be different from table column.
Rossen: The base class of the area will have traits that are
common, like width/height (though I don't like calling
them that).
Rossen: I haven't defined what the relationship of the areas is.
vollick: If we start exposing browser internals we need to be
careful.
Florian: Used values are not used values of properties.
Rossen: Not in our implementation, sure.
Rossen: The only type of trait is pixel.
ojan: Color is not a trait but it can have a used value.
ojan: It's not the output of layout.
Rossen: The used value of grid tracks.
Rossen: You will have a used value, whether it's a trait or not, I
dunno.
Florian: What about background of ::first-line?
Florian: Trait or not?
ojan: There's style that feeds into layout that feeds into paint.
ojan: This model makes more sense to me than the previous diagram.
Rossen: This makes no sense.
Bert: Direct traits like color, computed color is the same as the
trait because there's no additional computation involved
Rossen: After blending?
Bert: hmm OK.
Florian: We should keep in mind that this is fuzzy and tricky.
Rossen: getComputedStyle is often used values
Florian: This API is just wrong.
Rossen: Time for a break.
[break]
Received on Sunday, 21 February 2016 20:02:50 UTC