[Houdini] Minutes Paris F2F 2017-08-01 Part III: Layout Worklets, Future Meetings

=================================================
   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.
=================================================


Layout Worklets
---------------

  - iank reviewed the changes made since the last F2F
  - There was a lot of confusion around the proposal on handling
      inlines and the childDisplay flag, especially around the
      'normal' mode (both the name of the mode and the purpose) so
      the group worked through use cases to understand it better.
  - RESOLVED: Proposal above accepted [proposal: floats and
              block-inside-inline are given their own line box
              fragment thing, whose width is given to the block as
              the available inline space. (This essentially forces a
              line break before and after the item)]
  - RESOLVED: absolutely-positioned children do not appear as
              LayoutChilds
  - RESOLVED: relpos and transforms are after layoutworklet
              positioning
  - iank received several actions to clarify text in the spec and
      move some items out to Level 2.
  - RESOLVED: Publish CSS Custom Layout FPWD

Future Meetings
---------------

  - Houdini will meet on Thursday of TPAC.

===== FULL MINUTES BELOW ======

Agenda: https://github.com/w3c/css-houdini-drafts/wiki/Paris-F2F-August-1st-2017

Scribe: fantasai

Layout Worklets
===============

  <dino> https://drafts.css-houdini.org/css-layout-api/

Handling inlines
----------------

  <dbaron> https://drafts.css-houdini.org/css-layout-api/#breaking-and-fragmentation
  iank: Last time we talked about handling inlines
  iank: discussed having a flag childDisplay
  iank: default is childDisplay = block, which blockifies every
        child.
  iank: Other value, currently called normal, is that a root inline
        box will spit out line boxes
  iank: into given available widths.
  iank: This example here, takes two copies, one which is
        indentation and the number of lines to apply that indentation
  iank: and will adjust the inline size of that root element.
  iank: Simple example.
  iank: Some issues open on inspecting the resulting line box, but
        can get into that later.
  * fantasai thinks normal is a terribly generic name for this
             behavior and suggests "line" (as opposed to "block")

  franremy: What's blockFragmentationType?
  iank: Not native to this example, can ignore that.
  franremy: What does it do tho?
  iank: When set on a child means it will try to fragment at the
        block fragmentation offset
  iank: e.g. if child has avoid break column on it then [...]
  iank: This example shows a lot of fragmentation things.
  iank: Can talk about making layout more powerful, but conceptually
        this is it.
  iank: Default for childDisplay is block, which is like flex/grid
        layout.

  fantasai: Why isn't it called "lines" or something?
  iank: Could do that, yes

  iank: Conceptually, you could have a bunch of blocks represented
        by layout children which would behave like ...
  iank: then children that are part of root inline turn into line
        boxes.
  fantasai: I didn't understand that at all.
  fantasai: I have a box, this is the parent, it has some children.
  fantasai: Each display property value is assigned to at least one
            of these children.
  fantasai: When childDisplay is block, they all get blockified
  fantasai: when childDisplay is normal, what happens?
  iank: They have their normal display type.
  fantasai: What does that mean?
  iank: You get their normal display type.
  fantasai: But what does that mean? what does the API return?
  [iank shows Fragment idl]
  iank: If you lay out a thing that's a block, you will get a single
        fragment
  iank: You can position it by setting the inline block offset.
  iank: In the normal mode, and you're laying out a root inline box,
        you will get returned line by line.
  fantasai: So the fragment represents a line box or a block?
  TabAtkins: Basically a fragment.

  dbaron: What I originally thought you were saying is not what I
          now think you're saying.
  dbaron: What I originally thought was that you were describing a
          thing that said whether you would treat a bunch of line
          boxes as giving each line box, or just treat it as a child
          anonymous block that wraps the line boxes.
  dbaron: And now what I understand you to be saying is that you're
          talking about whether you're going to blockify each
          individual child as flex and grid do.
  TabAtkins: Yes, that is what this is about.
  dbaron: I'm a little worried about putting that in the layout API,
          because it seems like it's about box tree construction,
          which I see as happening earlier in the process.
  iank: There are basically two ways the box tree can be constructed
        here, and that's controlled by childDisplay.
  iank: UA would read childDisplay value, and would change the box
        tree construction based on that value.
  TabAtkins: This happens when you register the layout, so it's
             available at box tree construction time.
  dbaron: It's annoying to have to handle this before handling
          children.
  iank: Why annoying?
  dbaron: There are other parts of box tree construction that I
          think come out a lot easier if you do bottom up rather
          than top down
  dbaron: Servo does it bottom up, was thinking of making Gecko do
          that.
  TabAtkins: Then how do you deal with blockification in flex/grid?
  dbaron: I guess it handles it some way
  TabAtkins: We're not doing anything more than what the specs do.
  dbaron: But then you need to load your custom layout stuff before
          box tree construction.
  dbaron: You have to do it in the middle of box tree construction.
  TabAtkins: You need to do execution of it.
  iank: Otherwise it falls back to block.
  TabAtkins: This is at registration time.
  iank: Otherwise you'd treat it as an invalid layout.
  dbaron: Forgot about registration bits, that's all right.

  Rossen: The default is normal?
  iank: The default is block.
  [Rossen asks for why normal mode exists, ian explains use case is
      for controlling available widths for inlines]
  [Rossen, see minutes at
https://lists.w3.org/Archives/Public/www-style/2017Mar/0021.html]
  TabAtkins: This allows layout worklets to do some basic level of
             inline layout.

  fantasai: So can we rename this thing that's called normal to
            lines or flow or something else that's less generic?
  TabAtkins: It's do what you do normally.
  fantasai: Normally isn't a thing, there's different layout modes,
            they each have their own "normal". You pick one.
  TabAtkins: It's not lines though.
  dbaron: You're defining children as line boxes effectively.

  dbaron: There are three things that this doesn't control but could
          expose.
  dbaron: If you're laying out a block of inlines, does the layout
          expose blocks, does it expose line boxes, or does it
          expose inline boxes.
  fantasai: And we decided not to tackle inline boxes right now,
            because it's too complicated.

  TabAtkins: The API takes inline boxes as input, gives line boxes
             as output.
  iank: The input is a root inline box, the output is a line box.
  dbaron: Which may be substantially larger than the root inline box.
  TabAtkins: Boxes don't have width or height.
  TabAtkins: That's a pre-layout concept.
  dbaron: By the time you have done layout it does.
  TabAtkins: No, by the time you've done layout you have fragments
             and text.
  TabAtkins: I'm using modern terminology of boxes and fragments.
             Boxes are box tree structure. Fragments are rectangles
             with geometry.
  TabAtkins: Right now we're outputting line boxes, internally it
             does inline layout but we don't look into that it's too
             complicated.
  TabAtkins: At some point later we'll expose that.
  TabAtkins: Then I'll position the line box how I want, and inside
             it'll lay out however it wants.

  fantasai: Overall seems reasonable, but need to rename 'normal'.
  Rossen: It's not a line, could be a table.
  fantasai: The closest thing it does is what Gecko does, which is
            wrap each line of inline-level content and each
            block-level fragment into its own line box.
  fantasai: And then returns a Fragment object representing that
            line box.
  [TabAtkins asserts its not a line box, because CSS's concept of
      line box doesn't ever contain a block-level element, but
      that's not what fantasai was talking about she was talking
      about Gecko's internal architecture and its lineBox objects]
  <TabAtkins> That's not what I was asserting either. >_<
  dbaron: childDisplay should maybe have "force" in the name
  fantasai: I think it's fine.

  iank: Question is inside of a root inline box, if you see a float
        and if you see something that is block-level, what do you do?
  dbaron: I think those are two very different questions.
  iank: Tab and I thought they should just become atomic inlines.
  dbaron: Why wouldn't you want them to do what they do everywhere
          else and do block-in-inline splitting?
  iank: Because it's scary.
  dbaron: Doing column display requires that.
  iank: No it doesn't.
  iank: We don't want to bake inline splitting into the platform.
  fantasai: I think you should just wrap the block into one of your
            line box fragment things.
  iank: fantasai and I discussed this at lunch.
  iank: Idea is to force break before/after and have it just take up
        that space as its container.
  ...
  iank: In our impl, whenever we see block-in-inline, we split into
        3 boxes.
  iank: First half is one anonymous box, then there's another
        anonymous box with the block, and then a third with an
        anonymous box containing the rest of the inline.
  iank: This is why abspos is broken in these cases in our impl.

  Rossen: From PoV of what you were outlining
  Rossen: about block-level and float /inline level
  Rossen: For second case, we have a float inside an inline
  Rossen: spec says "instead it must be treated as in-flow, and be
          inlinified"
  Rossen: why?
  iank: For 1st level of spec, didn't want to deal with floats.
  iank: If you have a float intruding outside the line box, want to
        skip that complexity.
  fantasai: It's not really “normal” is it, if the floats and
            block-in-inlines don't behave as they “normally” do.
  Rossen: ...
  iank: What we're suggesting is that floats are treated as
        inline-block.
  Rossen: So you're back to internal layout.
  Rossen: Things will happen. Set of floats might be positioned
          around a line of text, and at the end line of text you
          come back to as a fragment
  Rossen: And then you register a bunch of exclusions.
  iank: ...
  iank: Ignore floats and forces them to be inline blocks.
  franremy: Basically there will be no floats in custom layout.
  iank: If we handle floats, we have to add exclusions and stuff to
        1st level which is complex.
  fantasai: If you're going to do custom layout, including floats
            makes no sense. Not sold on doing what's in the spec, but
            floats should certainly not float.
  fantasai: If we're wrapping block-level stuff in line boxes like
            we described, I would suggest doing the same thing for
            floats.
  iank: Yeah, that makes sense. Then you could implement floats
        yourself if you wanted.
  fantasai: So I think we should do that. If you really want floats
            to work, you can implement floating yourself, and
            otherwise you treat them as block-level boxes.

  fantasai: Do margins collapse?
  iank: No
  fantasai: Then it's not “normal”.

  [Summary of the proposal is that floats and block-inside-inline
      are given their own line box fragment thing, whose width is
      given to the block as the available inline space. (This
      essentially forces a line break before and after the item)]

  RESOLVED: Proposal above accepted

  franremy: If you have abspos inside an inline...

Positioning
-----------

  <astearns> https://drafts.css-houdini.org/css-layout-api/#interaction-positioning
  iank: Next round of simplifications.
  iank: I think it'd be nice if all positioning stuff is handled by
        the UA
  iank: e.g. if you have an out-of-flow child, doesn't appear in
        LayoutChildren.
  iank: You don't get to control them.
  fantasai: Did you mean abspos? out-of-flow includes floats.
  iank: Yeah

  ACTION iank talk about absolutely-positioned boxes rather than
         out-of-flow boxes in the positioning section

  franremy: This is fine, except you wouldn't be able to implement
            the abspos aspects of Grid.
  TabAtkins: Not in v1, right.
  franremy: You could work around that with custom properties in
            place of 'position: absolute'.

  iank: For relpos, the inlineOffset and blockOffest values of the
        fragment are considered to be before relpos and before
        transforms.
  Rossen: Inline and block offsets, you can additionally offset
          those.
  iank: Yes, they're initially set to 0 0, you can set them wherever
        you want.

  RESOLVED: absolutely-positioned children do not appear as
            LayoutChilds
  RESOLVED: relpos and transforms are after layoutworklet positioning

  fantasai: Wrt the static position bullet... the alignment
            properties are supposed to affect the static position,
            so it's not a point you're defining here, it's a
            rectangle.
  fantasai: And also, the padding box is relevant for the abspos
            containing block, not its static pos
  Rossen: Do we need this bullet point?
  fantasai: Yeah, need to define static pos.
  fantasai: Could define to do what flex or grid do.
  fantasai: Can't define to do what block does, because that
            requires figuring where the box "would have been" if it
            was a block... which we don't know
  fantasai: because we're not doing block layout.

  ACTION: iank update staticpos bullet to fix above issues

  franremy: If you have position: sticky, this is the same as
            position: relative
  franremy: the UA will just make it stick

  ACTION: iank clarify that point explicitly as well

Overflow: Scrolling and Fragmentation
-------------------------------------

  iank: Next section is interaction with overflow
  iank: Because we're handling transforms and position: relative by
        the UA, seems that overflow should also be handled by the UA
  iank: Stuff we discussed in Tokyo, that we assumed you might get
        relayed out twice once without scrollbars and once with
  iank: You still need to be able to reason about relpos and
        transform to decide whether a fragment will trigger
        scrolling, in this level don't deal with it. Maybe add an
        API for more efficient figuring out later.

  ACTION: iank add stuff about double scrollbar layout above

  iank: Final section is fragmentation.
  iank: Two attributes, blockFragmentationType and
        blockFragmentationOffset
  iank: set by your parent.
  iank: Your parent layout can set your blockFragmentationOffset
  iank: blockFragmentationType is enum none/page/column/region
  fantasai: If you set blockFragmentationType to none and
            blockFragmentationOffset to 100px what happens?
  iank: It's invalid for the parent to give you that.
  fantasai: But what if they do.
  Rossen: Your fragmentation break creation is based on the value of
          the blockFragmentationType, if set to none then the offset
          is irrelevant.
  Rossen: If it's not none, then you're expected to propagate it
          down.
  iank: If the blockFragmentationType is none, then the UA will
        coerce blockFragmentationOffset to zero.
  fantasai: Is that in the spec?
  iank: No.

  ACTION iank add blockFragmentationOffset coercion to zero on none
         to spec

  astearns: Pages can be left to right or top to bottom depending on
            the writing mode.
  iank: This is only in the block axis.
  fantasai: This is an important point, actually. An orthogonal
            multi-column element can fragment between columns (in
            its inline axis)
  fantasai: And this is actually a reasonably common use case.
  [iank and Tab draw this on the white board]
  Rossen: iank's point still holds.
  TabAtkins: We might need to pass in information about being
             orthogonal flows, but yes, in this case the element is
             fragmenting in its parent's block axis.
  <fantasai> This case though, the fragmentationtype/offset is in
             the layout container's parent's writing mode's block
             axis, but not its own block axis.

<br type=coffee>
  fantasai and iank discuss how blockFragmentationOffset needs to
  be handled for orthogonal flows; plan to have the caller indicate
  no fragmentation, otherwise the layout function author would need
  to know to treat the blockFragmentationOffset as an inline-axis
  fragmentation offset
  ACTION: iank specify that an orthogonal flow's blockFragmentation*
          args get reset to none/zero (meaning orthogonal flows
          can't fragment in custom layout) so that authors don't get
          confused and try to fragment in the wrong axis
</br>

baselines in custom layout
--------------------------

  iank: There are several levels here...
  iank: This gets into a hairy topic I don't want to get into yet
  iank: which is basically, do we want a separate line fragment type.
  iank: This is that font metrics object.
  iank: ta-da!
  [iank displays FontMetrics api
https://drafts.css-houdini.org/font-metrics-api-1/#intro ]
  iank: We agreed that having childDisplay=normal being useful, root
        inline boxes spitting out lines is useful simplifies things
        a lot
  iank: One powerful thing to talk about later is having explicitly
        a line fragment object
  iank: which inherits from a normal fragment
  iank: but it has extra information about what is inside that line
  iank: so you can inspect the segments in that line
  iank: and the baselines and stuff like that.
  iank: That's sort of baselines part one:
  iank: where are the baselines in the text
  iank: the way to do for fragments more generally.
  iank: As an input to layout you give it the baselines that you
        want.
  iank: You may want to know the alphabetic and middle baselines of
        the block
  iank: you can get those baselines from the fragment.
  iank: Conceptually a UA could propagate which children need to
        produce which baselines and bubble those back up.
  iank: We probably won't wait for implementations of css-align-3
        which has additional baselines.

  fantasai: I think you meant 'central' there rather than 'middle'
  fantasai: They're all different (middle, center, central),
            unfortunately.

  iank: I went for this model instead of having a baseline offset on
        each fragment
  iank: because more powerful / nicer
  iank: didn't want to wait for css-align-3 for multiple baselines.
  franremy: for baselines, can you change positioning based on the
            alignment?
  iank: This will return the offset from the top of the fragment.
  fantasai: There's a first baseline and a last baseline, is this
            the first baseline? :)
  iank: ummmm
  iank: Might need tuples.
  iank: first/last vs alphabetic/central/etc
  iank: Do we need first-letter baseline?
  fantasai: I don't think so.
  fantasai: I would say if it's stuff we can add on later, we should
            add it later.
  Rossen: Certainly first and last should both be there.
  iank: Might want to wait until css-inline-3 shapes up.

Sizing
------

  iank: Last bit of interactions is how sizing works
  iank: implicitly, what happens is ...
  iank: Let's go with this version of constraintspace atm
  iank: Can have 3 types of sizes:
  iank: Can give a fixed size
  iank: can give child available sizes
  iank: can also give child percentage sizes.
  iank: This is slightly different from what I had here.

  fantasai: Why is percentage not considered fixed
  iank: For example ...
  fantasai: Oh, it's not the percentageSize, it's the size against
            which percentages are resolved.
  iank: Maybe should change that to percentageResolutionInlineSize
        etc. Since most of the time you won't be setting this anyway.
  iank: Defaults to the value of the availableSize
  iank: or 0 if you set infinity.
  <fantasai> (random bikeshed idea: { inline100percents:
             <somevalue>, block100percents: <somevalue> } for the
             name)
  iank: If you set fixedInlineSize then percentages will resolve
        against that size.
  fantasai: Wait, that doesn't happen currently, the child would
            resolve against some aspect of the available/parent size.
  iank: I think it's the grandchild that cares?
  iank: ...
  iank: If the author only sets the fixedSize, then available and
        percentageresolution sizes copy that value.
  fantasai: I think, since we don't currently ever resolve a box's
            own percentages against it's own specified size, then
            defaulting avail/percentageResSize to fixedSize would be
            confusing.
  iank: So just default them to zero?
  fantasai: Yeah, I think that would make more sense.

  ACTION: iank have percentageResolutionSize and availableSize, when
          unspecified, default to some initial value like zero
          rather than to fixedSize so it's clear what's what

Automatic Inline Sizing
-----------------------

  iank: This has some interactions with how other layout modes
        interact with this
  iank: e.g. positioned layout sizing should size the positioned
        sizing equations if they need to and then fix their layout
        to that size
  iank: e.g. if containing block has width=height=100px
  iank: immediate child which is abspos with tblr=10px
  iank: UA will set a forced fixed size.
  TabAtkins: This is a result of default stretch alignment
             calculating the box's width/height from the offsets.
  fantasai: So if you set align-self: center;, then it wouldn't
            force a fixed size.
  iank: You have fixed size, you have available size, and you have
        percentageResolutionSize, which the UA can pass in to get
        the different sizing constraints.
  iank: I think that's all we need.
  fantasai: Can the author ignore the fixed size?
  iank: No, the UA will force it.
  fantasai: So letting the child know, you're getting this fixed
            size, deal with it.
  iank: Yeah.

  iank: So now the constraintSpace here is a bit wrong
  iank: inlineSize here needs to be split into "availableInlineSize"
        and "fixedInlineSize" etc.
  iank: This brings us to resolving inline sizes.
  iank: Currently in all of the examples
  iank: the first thing the custom layout size does is resolve the
        inline size using the resolveInlineSize(space, styleMap)
        utility function.
  iank: This does the default things!
  iank: One thing we could do is to always do this call for the
        author
  iank: But this wipes out a class of use cases
  iank: Where you can't adjust the inline sizes
  iank: Like happens currently in flexbox.

  fantasai: What's the output of the layout function?
  iank: dictionary FragmentResultOptions
  fantasai: So, you could give that a constructor that could
            optionally take the styleMap and space as optional args,
            and if they are present, calculate the inlineSize as
            part of construction.
  surma: Options bag as return object is more common in JS APIs.
  surma: So keep that.

  [iank shows off utility functions]
  iank: Function called resolveInlineSize, which every example calls
        immediately
  iank: Doesn't cover all cases, though, like bubbling up sizing in
        MathML

  fantasai: I think if you want to make this more ergonomic you
            could incorporate it into defaulting on the output,
            either by building it into the constructor or by
            automatically converting null output on inlineSize to
            run this calculation.
  fantasai: I wouldn't choose to force it to this calculation.
  Rossen: If I have 42 custom layout where all sizes are 42, you're
          preventing me from doing that by "helping me".
  fantasai: It's not really custom layout if I can't customize it :)

  franremy: [......]
  iank: There's a separate intrinsicSizes pass.
  ...
  iank: At some point we'll be able to do layout in intrinsicSizes
        pass, but Gecko can't do that currently.
  franremy: There was a mention gecko could not handle layout of
            children to compute intrinsic sizes; I was wondering
            whether that was not required for tables since there is
            spanning of cells etc, but dbaron doesn't think it
            requires it.
  dbaron: Tables don't do that.
  ...

  jack: Resummarize?
  iank: Servo has 3 passes, bubble up content sizes, recursive down
        layout sizes (?), then tertiary positioning phase
  [missed]
  jack: SimonSapin implemented writing modes
  jack: In cases where height depends on width or whatever, we defer
        the calculation to later pass
  jack: It's resolved slightly later.
  iank: Would you be fine with [...]?
  iank: Let's say a custom layout is a float.
  iank: You have to lay it out first to know its inline size.
  jack: Floats already cause problems.
  dbaron: He's talking about floats defaulting to using intrinsic
          sizes.
  iank: Similar also flexbox initial pass.

  dbaron: Not sure about custom layout being as problematic as you
          thought, but I also don't understand the model.
  dbaron: I'm understanding is you're computing inline sizes on the
          way down the tree, block sizes on the way up the tree
  dbaron: what you do in between is lay out children
  dbaron: which seems reasonable consistent with this.
  iank: We won't report the inline size until after we lay out the
        children.
  iank: In all cases so far, we calculate inline sizes ahead of time
  iank: not strictly needed.
  iank: You could not set the inline size until the end, where you
        always report 42.
  dbaron: You can report a different inline size that you were given.
  iank: If it's not fixed, yes.
  iank: You can tell your children to be fixed at 50px, or that they
        have some arbitrary layout with available size.

  jack: We would like to get out of this is to run in parallel for
        multiple elements at a time.
  Rossen: Can you run something deep in your subtree parallel with
          something much higher, or boxes that are disjoint in the
          box tree.
  Rossen: I've played with both models.
  jack: We won't run computations simultaneously on parent and child.
  Rossen: In that case ian's concern is not a problem.
  iank: We can say "layout these 5 children", this supports that.
  iank: This API creates a child constraint space, and gives it all
        of its children, and all of those children will lay out in
        parallel (or could be laid out in parallel).

  till: You're not concerned about other way of laying things out
        because infeasible anyway?
  Rossen: It is feasible, but in that case when you're stitching
          between your chain of layout, the assumptions that you
          projecting down in your further start need to match up
          otherwise you have to restart.
  Rossen: In those cases, what iank is saying, is you can set inline
          sizes ahead of time and then start your execution.
  iank: You could then change your inline size.
  Rossen: Otherwise doing a lot of work and redoing it.
  till: Seems like this could be solved by requiring you to opt into
        both modes, where you have to be explicit about whether you
        want inline sizes to be dynamic or fixed.
  till: If we don't require that then probably in those cases we'd
        ???
  till: once you had this kind of optimization.
  till: Not requiring specification of inline size would probably
        lead to most content not specifying an inline size, so you
        don't have the optimization.
  till: Whereas if you have to decide whether to specify or not at
        the beginning, then ...
  till: Because it doesn't matter in that case.

More Utility Functions
----------------------

  iank: It's really nice to have the padding/border/scroll edges
        given to you up front.
  iank: There's an interface called LayoutEdges that provides this.
  [iank shows API]
  iank: You can choose border/scrollbar/padding or all since you
        frequently want them all together
  iank: LayoutEdgeSizes gives you access to each side or each pair
        of sides like this: edges.all.inline
  fantasai: That's great, I love it

* SimonSapin returns

Automatic Inline Sizing (cont.)
-------------------------------

  Rossen: Box tree inline size servo, and integration with other
          modules.
  Rossen: Did you cover this?
  Rossen: We wanted to know whether or not Servo requires to know
          inline sizes on the way down the box tree in order to
          produce heights on the way up.
  SimonSapin: In short yes, there are three main traversals.
  SimonSapin: Each is parallel
  SimonSapin: First style computation on the way down
  SimonSapin: bottom up intrinsic sizes.
  SimonSapin: If intrinsic sizes depend on full layout, we have a
              problem.
  SimonSapin: Once we finish traversing the tree, go back up to the
              root, second traversal.
  SimonSapin: Based on intrinsic sizes, assign inline sizes.
  SimonSapin: On the way down
  SimonSapin: And on the way back we assign block sizes.

  Rossen: ...
  Rossen: Custom layout can have inline size predefined by the UA.
  Rossen: That would allow you, Servo, to always set the inline size
          and then keep going down.
  Rossen: But from custom layout pov, custom layout is not so custom
          if it cannot change the sizes
  Rossen: So if you forfeit this requirement or assumption that
          inline size is always given, how much would that be a
          problem?
  fantasai: We're not assigning inline sizes on the way down, but we
            are assigning available sizes on the way down.
  SimonSapin: For existing css models, when this isn't flexible
              enough, we go up one level in the tree and ask the
              parent to assign inline sizes.
  SimonSapin: Inline size of one node is an input into tree traversal
  SimonSapin: But that is based on calculation done on the parent
              level
  SimonSapin: So inline sizes children of a node can be assigned by
              the parent.
  Rossen: ...

  Rossen: Would it be a problem?
  Rossen: You have 3 boxes nested, starting layout from the top box
  Rossen: what I understand is you will do one pass down to compute
          styles, when you're in 3rd box, will compute intrinsic size
  Rossen: based on that work up to compute intrinsic sizes.
  Rossen: Then start by assigning inline sizes on the way down
  Rossen: top will set inline size, then set inline size of 2nd,
          then third
  Rossen: on the way back up computing heights.
  Rossen: Let's say middle box is a custom layout
  Rossen: Root box still has size set by input space
  Rossen: It wants to go down and compute layout, but the child is
          custom layout.
  Rossen: It can suggest an inline size, but the custom layout wants
          to set its own size.
  Rossen: It says my size is 42.
  Rossen: Then you continue to third box.
  [missed a bunch of stuff in example]
  SimonSapin: Whether we have custom layout or not, we don't want
              every layout mode to know about every other one.
  SimonSapin: Want some division of responsibility.
  SimonSapin: Top box would compute some inline size it wants its
              children to have
  SimonSapin: Its child can change that decision if it wants.
  Rossen: So we seem to be correctly speculating that this won't be
          a problem for Servo
  [various discussions about layout models. summary of the
      discussion was that servo would be able to handle what is
      currently in the spec]

Inspecting LineFragments
------------------------
  Scribe: franremy

  iank: Line fragments are useful to inspect in custom layout.
  iank: This is a very early prototype api we came up with in 5min
        but we want opinion.
  iank: The idea is that you might want to be able to inspect the
        various segments inside the lineFragments
  iank: where each char is, where the baselines are, etc...
  iank: which enable powerful things to authors, like line-text
        alignments.
  Rossen: One of the principles of layouts steps is that you are
          operating at one level at at time.
  Rossen: What you are proposing breaks this invariant.
  Rossen: It is still worrisome even if only applies to lines
          metrics.
  Rossen: Second issue is that we are going to expose metrics, we
          might also want to do it for non-line fragments.
  Rossen: If we want to support inline layout, maybe we should be
          transparent and support all of it.
  iank: But this is a read-only api, we don't allow changing.
  Rossen: for now ;-)
  Rossen: (slippery slope argument)
  Rossen: I would rather not have this in level 1.
  iank: sounds fine

  ACTION: iank remove LineFragmentSegment from level 1

  iank: Final idea though would be inspect where words would break,
        and re-layout with other space constraints.
  astearns: We already expose baselines, right?
  iank: Yes, this would allow you to get more details though.
  astearns: Seems sufficient for level 1 though.
  iank: ok, this would be for level 2 then.
  iank: Since we are rewriting our layout engine, we are going to
        build in three or four phases.
  iank: The new engine will first be to support "block" stuff
        without fragmentation.
  iank: Step up would be childDisplay "normal"
  iank: and then once we have fragmentation, we will light up the
        breaktoken and further fragmentation capabilities.
  iank: My understanding is that there is broad consensus that would
        allow us to work on this further.

Publication
-----------

  Rossen: I think that covers the implementation progress for
          everyone.
  iank: I guess.
  Rossen: It would be good to republish.
  iank: ok
  iank: One thing left to bikeshed is the "constraint space" name;
        an idea would be "layout input space".

  astearns: We need a resolution to publish fpwd actually.
  Rossen: Any objection to RESOLUTION: Publish CSS Custom Layout
          FPWD?
  (no)

  RESOLVED: Publish CSS Custom Layout FPWD

Meeting wrap up
===============

  Rossen: Is there one more thing we need to discuss today?
  iank: Lea Verou replied to an issue mentioned earlier, we could
        discuss that.

  iank: issue 434
  iank: the issue about { inherits: true } by default
  <astearns> https://github.com/w3c/css-houdini-drafts/issues/434
  Rossen: What do we want to discuss further here?
  Rossen: Can we not leave this as a github topic for now?
  iank: Encouraging true by default being a performance footgun is
        something we really wouldn't like
  iank: but if there is strong pushback, we could revisit.
  Rossen: It is not optimal.
  iank: Not strong pushback, so let's keep it as is.

  Rossen: OK so there shouldn't be any other topic to discuss.
  Rossen: We should decide if we want to meet at tpac though.
  Rossen: Thursday or Friday are the options.
  Rossen: Any strong preference?
  Rossen: Personally, I think we should meet.
  dbaron: There is the AC meeting but most people prefer not having
          the gap, so Thursday is fine.
  Rossen: OK let's aim Thursday then.

  Rossen: Thanks Mozilla for hosting us today.
  Rossen: See you all tomorrow for css.

  TabAtkins: And I published an update to Typed OM.
  (people happy)

  Rossen: Meeting adjourned for the day.

Received on Sunday, 27 August 2017 18:33:44 UTC