W3C home > Mailing lists > Public > public-houdini@w3.org > February 2016

[Houdini] Minutes Sydney F2F 2016-01-31 Part I: Updates from Yesterday, Process Model

From: Dael Jackson <daelcss@gmail.com>
Date: Sun, 21 Feb 2016 15:01:52 -0500
Message-ID: <CADhPm3ua_scaw2p96YP4r8YqM-wF6qTA3H2t8t0oCmhyFZa7+Q@mail.gmail.com>
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

  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)

  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?

  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
  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
  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
  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
  <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
  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
  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
  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
  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
  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
  Rossen: Everything becomes readily available, but now we have more
  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
  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
  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
  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
  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
  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.

Received on Sunday, 21 February 2016 20:02:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:53:26 UTC