W3C home > Mailing lists > Public > public-houdini@w3.org > March 2017

[Houdini] Minutes Seattle F2F 2017-01-10 Part IV: CSS Layout, Next F2F Meeting

From: Dael Jackson <daelcss@gmail.com>
Date: Sun, 5 Mar 2017 11:00:39 -0500
Message-ID: <CADhPm3u6D_zgphhomQYkfoY4ELz-f3XButCf4nQ5qn7f31TnTw@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.
=================================================


CSS Layout
----------

  - iank walked everyone through the updated explainer:
      https://github.com/w3c/css-houdini-drafts/blob/master/css-layout-api/EXPLAINER.md
  - RESOLVED: Failure to layout results in 'display: block
              flow-root' layout (BFC).
  - RESOLVED: Change blockifyChildren to childrenMode which accepts
              blockify, lines, and future values, names TBD, and
              lines representing the root inline box (and not
              individual inline-level elements).
  - RESOLVED: Hook into structure algorithm on how to structure
              breakToken and make the breakToken structure cloneable.
  - RESOLVED: Add a new method on class that receives children array
              and size - engine may call this to calculate
              minMaxSizes on parenthesis.
  - RESOLVED: For an element that uses custom layout overflow: auto
              computes to preserve space for scrollbar.

Next F2F Meeting
----------------

  - RESOLVED: Houdini meets Tuesday 18 April 2017 in Tokyo

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

Agenda: https://github.com/w3c/css-houdini-drafts/wiki/Seattle-F2F-Jan-10-2017

Scribe: fantasai

CSS Layout
==========

Review of the explainer
-----------------------

  iank: I updated the explainer.
  iank: Explainer in spec is a stripped down version of what we had
        at TPAC.
  iank: Doesn't have exclusions, fragmenting is simpler.
  iank: Anyone want to see the API currently?
  iank: I'll step through explainer.
  <iank> https://github.com/w3c/css-houdini-drafts/blob/master/css-layout-api/EXPLAINER.md

  iank: As we discussed before, everything is in logical coordinates.
  iank: This section is for random web dev who doesn't know what
        logical coordinates are.

  iank: The layout worklet is basically exactly the same as paint
        worklet.
  iank: Similar to custom paint, you have a function called
        registerLayout.
  iank: Here it's registering one called 'centering'.
  iank: In most cases you'll want to extend the basic Layout class.
  iank: It has things like width, height, min-width, min-height, etc.
  iank: If you want to use the standard set of heading border, etc.
        that'll all be here.

  iank: Similarly as we talked about before, have a layout function.
  iank: This takes your constraint space, list of children, and
        computed style.
  iank: First thing this list does is a typical CSS layout;
  iank: First this example resolves inline size.
  iank: This takes the constraint space and the style map.
  iank: Basically resolves whatever width is.

  iank: Next computes the available inline size: inline size minus
        borders & padding and scrollbar
  iank: Then resolve block size.
  iank: This takes an optional third argument, which is the content
        size-
  iank: similarly subtract out borders/padding/scrollbar.
  dbaron: Is there a way to consider min-height and max-height if
          your height is auto?
  iank: That's done at the end.
  iank: If it's auto, because you haven't filled in third argument,
        it'll just return infinity in this case.
  iank: Down below you try to resolve again, can pass in content size
  dbaron: Will this get invoked again if scrollbars cause changes?

  iank: Next we lay out of all of our children.
  iank: Added ability to blockify all children
  iank: Similar to how grid and flex blockify their children.

  iank: Here we're setting child constraint space.
  iank: Percentage resolution size will default to available.
  iank: These two vars capture biggest child.
  iank: This loop lays out all the children.
  iank: Each child produces one fragment, push it onto the list.
  iank: At this point it does the second block size resolving to
        settle e.g. auto with min-height.

  iank: Last step here centers everything.

  iank: Finally, you return your fragment: inline size, block size,
        overflow sizes, child fragments.
  Rossen: Why return child fragments?
  iank: In case where you're fragmenting, may want to speculatively
        lay out some children.
  Rossen: What is the return type here?
  iank: Called it fragmentOptions, a dictionary type.

  surma: One syntactic question.
  surma: Child layout fragment-
  surma: That call could return multiple fragments, shouldn't it
         yield?
  iank: It will only return one.
  surma: Was wondering if you're laying out a text node, might need
         multiple fragments
  surma: but that's the next example.

  fremy: Can you return in a function that does yield?
  iank: When you return in a function that does yield, then exit
  iank: So jump to IDL
  iank: To show you all the options on various things
  iank: When you get a child fragment from laying something out, has
        these properties:
          inlineSize, blockSize, inlineOverflowSize,
          blockOverflowSize.
        Only things you can set (not readonly) inlineOffset,
        blockOffset. Also breakToken and dominantBaseline (readonly),
  fantasai: Do you want to return the dominant baseline or alignment
            baseline?
  fantasai: I think you want the alignment baseline here.

  iank: Options for the constraint space:
        inlineSize, blockSize
        two booleans inlineSizeFixed, blockSizeFixed, these indicate
        that the fragment should be exactly the inlineSize and
        blockSize, not stretched

  iank: Next boolean is inlineShrinkToFit
  iank: You can use this in e.g. block formatting context, auto
        consumes all the available space. In flex e.g. shrink-to-fit
        instead of filling available space.
  fantasai: You have a boolean here, but we have many ways of
            computing auto. Not sure you're covering it all properly.
  Rossen: This flag basically is a hint which tells you that this
          particular constrained space has been created during
          shrink to fit calculations, and it's given to you
          expecting to do layout and produce results of shrink to
          fit.
  Rossen: After this layout pass is compete and you return from this
          custom layout function.
  Rossen: Should be able to return your minimum and maximum
          preferred size (min-content and max-content sizes).
  Rossen: For example, in all layout shrink-to-fit modes, we resolve
          percentage values to zero.
  Rossen: On margins or padding.
  [....]
  iank: We have the sizes to resolve percentages against.
  iank: inlineOverflow and blockOverflow booleans say whether a
        scrollbar is present.

  iank: Finally, you've got an option to set the
        blockFragmentationType.
  iank: At the block size, if the lbockFragmentationType is not
        none, you should try to fragment at the given blockSize.
  fantasai: So blockSize is actually the remaining space until the
            end of the fragmentainer
  fantasai: and percentageBlockSize is the size of the containing
            block.
  iank: Yeah.
  iank: Passing in dictionary of these things, initial values are
        falsy/infinity.
  iank: This is the fragmentResultOptions dictionary-
  iank: Has inline size and block size
  iank: overflow sizes
  iank: defaults to inline and block size if no overflow.
  iank: List of children fragments
  iank: breakToken
  iank: and the alignment baseline.
  iank: It'll by default return alignment baseline of your first
        child, or bottom in case you have no children.

  fantasai: We have two different kinds of overflow: scrollable and
            ink, which kind is this?
  iank: Scrollable.

  Bert: Not an error if overflow is less than size of the box?
  iank: No, messed up calculation maybe but no error.
  iank: Here are some utility functions
  iank: for resolving inline size & block size
  iank: and resolving borders and padding, and the scrollbar size.
  iank: We can probably put them on the layout class instead of
        global scope.
  iank: To use this, you set it by 'display: layout(foo)'
  iank: Take an ident

  iank: There's open question of what to do if function throws an
        error?
  TabAtkins: I'm unhappy with something that would cause content to
             break and become invisible
  TabAtkins: Could maybe make it behave as 'display: flow-root'
  iank: Should we resolve on that?
  TabAtkins: A valid layout() is always a formatting context root,
             so this should also be a context root.
  * fantasai strongly agrees with this

  RESOLVED: failure to layout results in 'display: block flow-root'
            layout (BFC)

  <br type=tea>

Text Layout/Fragmentation
-------------------------

  iank: Let's talk about fragmentation! :D
  iank: In previous example we blockified children. What happens
        when we make this false?
  iank: There's two types of layout children-
  iank: We've got the current ... LayoutChild.
  iank: Two types is an InlineLayoutChild-
  iank: this allows text-shaping across element boundaries and
        things like that.
  iank: Other is BoxLayoutChild-
  iank: everything which is atomic.
  iank: Main difference in API is that one you can query styleMap
        and one you can't.
  iank: Simple reason for this is that exposing what the style is
        for all of the inlines inside the InlineLayoutChild is kind
        of hard API design problem.
  iank: I cheated and said you can't.
  dbaron: So InlineLayoutChild is a block that wraps all the inlines?
  iank: Depends on impl.
  iank: You could imagine we'd create an anonymous block which
        handles that wrapping, have to fragment it.
  iank: Conceptually all these return ...
  iank: For the block child, can query the child styles.

  iank: Does everyone see why we made this distinction?
  fantasai: no...
  iank: It's if you want to do something like [shows example]
  iank: Here is some Arabic text that's two elements (works
        correctly in Firefox, not Chrome)
  iank: Don't want to represent as two different children in layout
        API.
  iank: Want to represent them as one child, handled as a single
        fragment.
  iank: Allows for shaping across boundary.
  fantasai: So if you have consecutive inline boxes, they are
            represented as InlineLayoutChild?
  iank: yeah
  dbaron: ok, so it's just for consecutive runs of non-atomic inlines

  iank: If you implemented block flow layout with this API, you
        would ...
  iank: inline block would be a separate box.
  Rossen: So you are returning two different types of boxes.
  Rossen: And they both derive from LayoutChild.
  Rossen: And the distinction that you're drawing between the two is
          that the InlineLayoutBox is what corresponds to, in CSS, a
          'display: inline' fragment.
  fantasai: Is this a box or a fragment?
  iank: It's a box.
  fantasai: So it can be multiple fragments.
  Rossen: Not clear.
  Rossen: Say you have a span, which has some border.
  Rossen: Let's say you can only fit part of the span on the line.
  Rossen: Your layout function, what does it return?
  <Rossen> <span style='border: 10px solid">foo bar</span>
  iank: What happens here, this whole element is one
        InlineLayoutChild
  iank: and it can potentially be two fragments, if you gave it
        available space only enough for foo.
  iank: Produce second fragment with bar
  fantasai: That's all one InlineLayoutChild.
  iank: Yeah
  iank: Let's say there's another span in here, say with color: red
        for example
  iank: That would also be part of that single InlineLayoutChild.
  iank: Because you want to perform text shaping across those two
        boundaries.
  iank: If the span didn't have border, would interact with text
        outside of it, all part of single InlineLayoutChild.
  iank: But if you've got in here a separate inline-block
  iank: This would be a separate BoxLayoutChild.
  iank: If the inline-block is inside the span, wouldn't see it,
        it's embedded in the InlineLayoutChild.
  iank: Wait hang on might need to break it?
  iank: No, you need to break it.
  [iank writes <span>foo <div>bar</div> quux</span>]
  iank: I think we'd want to represent this as [InlineLayoutChild]
        [BoxLayoutChild][InlineLayoutChild]
  Rossen: Back to my question, why drawing distinction between the
          two?
  iank: Because you can't query the style on InlineLayoutChild.
  Rossen: When you're implementing queries from CSSOM, like
          getChildRects
  Rossen: If that span is not identifiable in this collection you
          have fun times.

  dbaron: Not entirely sure how relevant this is, but
  dbaron: I know why a bunch of those test cases worked in Gecko.
  dbaron: It's because we have this concept called text runs.
  dbaron: For certain types of things, text within inlines, we will
          do the text layout across inline boundaries
  dbaron: But a whole bunch of rules must hold, e.g. same font, etc.
  dbaron: would need to define that.
  fantasai: It's specced in css-text, though there's "must", "must
            not", and "up to UA".
  Rossen: Let's say you've applied all the combining rules
  Rossen: suppose we have well-defined rules for this.
  Rossen: Why would you care if this is an inline box vs block?
  iank: If you're combining a whole bunch of elements.. the
        difference between the two interfaces is existence of
        styleMap.
  ...
  jack: In Servo we have all these elements in a vector to compute
        text runs.
  jack: Have indices into vector for the different elements
  jack: Can get the full run.
  Rossen: How are you going to compute
  Rossen: your fonts?
  Rossen: If you don't have the styleMap here?
  Rossen: At any given time, in order to make layout for this
          particular run...
  iank: This is an input.
  iank: You're going to call layoutNextFragment on the child, and
        that happens internally in the browser engine. You're not
        laying out the child.
  iank: This will just produce a fragment, gives you its size, etc.
  iank: Internally it has all this style info, but as far as the
        layout API here is concerned, it's just some geometry.
  Rossen: The layout child is just the callback.
  iank: It's the input into your layout.
  iank: You're iterating over the children, getting the next
        fragment for that child.

  [looking at an example of some text]
  Rossen: So where do you do custom inline layout?
  iank: You don't.
  iank: We can add that later, but it's much harder problem.
  iank: If we want InlineLayoutChild to have a styleMap, would have
        to specify which styles we're able to return and which ones
        we can't.
  fremy: Which properties would work? I can't think of any you could
         return that would be useful.
  iank: Are people fine with having these two different concepts?
  iank: Or should we have a styleMap that only returns values for
        some properties?
  fantasai: It's an inline layout black box. Can't see inside.
  iank: Could maybe request styleMap for "first part", "second
        part", etc.
  gregwhitworth: Are you worried that the ergonomics of the API will
                 be weird once we tackle inline layout?
  iank: My intuition of how we'd do inline layout style, you'd get a
        bunch of text runs which have a style map.
  ...
  Rossen: Let's say you're making flexbox layout, if I have loose
          text I don't want to deal with that.
  iank: That's why we have blockifyChildren.
  Rossen: If we don't allow user to initially override the fact that
          something will produce inline or block layout internally
          in the engine.
  Rossen: Then let's not expose this API.
  Rossen: They don't get to see into or participate in that.
  Rossen: When we give them the option to call explicitly layout
          children without the parameters meaning do text layout,
          because I want you to and this is supposed to be text
          layout
  Rossen: vs "do some kind of layout, dunno what you are doing".
  Rossen: The only thing I care about is, the final result, which
          will be a box and potentially some geometry data
  Rossen: If we tell them "oh, but there are two different ones, and
          use this one for text and this other one for everything
          else".
  iank: They both have the same fragment, the only difference is the
        ability to pull style.
  iank: The instance type of the object is different.
  iank: I'm fine with both of them being called LayoutChild and
        having the styleMap and just for some properties we just lie
        or something.
  fremy: For all of them!
  fantasai: I don't like that.
  fantasai: What if we made blockifyChildren always true?

  fantasai: What's the use case you're trying to solve with this
            system here?
  iank: Case is if you want to do, e.g. CSS Shapes yourself.
  iank: An InlineLayoutChild with a lot of text.
  iank: In this version for the API you can create text fragments
        which step down like this...
  iank: And then they step back up.
  iank: You'd be able to do that in this version of the API.
  [iank draws a shapes thing with differently-length line boxes]
  fantasai: OK, so you can do that without having a mix of
           InlineLayoutChild and BoxLayoutChild. Just treat the
           entire stream of inline-level content as such, don't
           distinguish between inline boxes and atomic inlines.
  Rossen: That's what I'm saying.
  Rossen: Keep going until you get transition from inline to block
  Rossen: and return the styles as if it was an anonymous inline.
  iank: So what do we call this flag?
  Rossen: yieldOnInlineLevelContent
  iank: produceLine?
  Rossen: buildLine?
  fantasai: Can't get rid of the flag, because it generates a
            different box tree: blockification makes individual box
            objects out of each element and run of text, whereas a
            run of inlines would be wrapped into a single anonymous
            box object that represents the root inline of the block
            container.
  iank: So group all inline-level children into same layoutChild,
        which has computed style of the anonymous inline that it
        represents
  iank: And we'll add a buildLine option to ConstraintSpace Options?
  fantasai: I don't think it belongs on ConstraintSpaceOptions.
  fantasai: It's not about space geometry, it's about layout model.
  fantasai: Should be on Layout object.
  fantasai: How you do layout depends on whether you blockify or not.

  [fantasai draws example on the whiteboard]
  [fantasai explains that laying out a child that's been blockified
            would be different from laying out a stream of content
            that isn't]
  [Rossen explains that the parameter would be passed into the
          child's nextFragment() function, not into the container's
          Layout function]
  ...
  iank: Flex etc. will blockify children, which changes computed
        style of all children.
  iank: If we pass this flag to the children instead as a param of
        constraint, wouldn't be recomputing style.
  fantasai: If you blockify the children, you're operating on a list
            of, say, 15 boxes.
  fantasai: If you don't, if it's a stream of inline-level boxes,
            then it would be treated as one single abstract box.
  TabAtkins: Huge difference between 15 blocks vs one anonymous
             inline. You have to know this up front.
  esprehn: We also need to know up front to handle white space
           correctly.
  esprehn: We don't make boxes for white space between blocks.
  esprehn: We don't make boxes for that today.

  [fantasai draws on the board:
      <div>
      A B <span>C</span> D <em>E <strong>F</strong></em>
      <div>
  ]
  fantasai: This is either one anonymous inline inheriting from the
            parent with no directly cascaded declarations
  fantasai: or four children, two of which are anonymous inlines and
            two of which correspond to actual elements with their
            own styles.
  fantasai: You cannot make this decision the moment you call
            nextFrag on the first child -- you need to know that
            when you start the loop
  fantasai: Because what that child is that you are calling nextFrag
            on, depends on whether you are blockifying the children
            or not.

  dbaron: I'm a little concerned about doing this
          merge-all-children-into-one-object thing.
  dbaron: In the future we will want to expose a richer API to do
          custom inline layout [missed details]
  dbaron: Maybe we should just do blockified children for now.
  iank: There's potentially another layout API which allows building
        up text runs from a series of children.
  iank: I think that building individual text runs is a separate
        thing.
  dbaron: I guess it feels a little weird to me that you aren't
          doing the thing I thought you were doing when you started
          to describe this.
  dbaron: You are giving layout information that are within atomic
          inlines that are in a run.
  fantasai: That was what I was saying earlier that we shouldn't do,
            just treat it as a single stream.
  dbaron: Is there a more sensible way we could defer more of inline
          layout.
  iank: The thing we could do is blockify all the children by
        default.
  fantasai: I'm not sure this is that inconsistent with expansion
            later. We do have this concept of a root inline box that
            wraps around all inline-level content, and this is just
            representing that.
  dbaron: I think getting into the root inline is getting into
         inline layout.
  dbaron: Two things won't get into inline layout.
  dbaron: Blockifying the individual children, or wrapping inline
          content in an anonymous block.
  fremy: But wrapping in an anonymous block won't let you solve the
         Shapes use case.

  fantasai: We could, instead of having a single blockifyChildren
            boolean, we could have a multi-state flag (or maybe
            multiple booleans if that's the correct style?)
  fantasai: one state would be blockifying children
  fantasai: another would be handling the root inline as a box as
            we're discussing
  fantasai: and in the future a third would give a richer API
            exposing full inline layout.
  fantasai: I think each of these three is useful, and even when we
            have full inline layout, the root inline version will
            still be useful of itself.
  iank: So instead of blockifyChildren we'd have childrenMode, which
        could have blockify, ... not sure what to call it.
  TabAtkins: Blocks only, blocks and lines, and future values.
  iank: Blockify will blockify all the children, which we all
        understand.
  iank: Lines version will wrap all the inlines in an anonymous box
        and spit out line by line.
  iank: Then don't get option to spit out individual fragments or
        boxes.
  fantasai: They'll be fragments, but fragment representing entire
            contents of a line.
  iank: And then future would get into nitty gritty of inline layout.
  iank: This also makes it much easier to spec.
  iank: OK, I'm happy with that!

  RESOLVED: Change blockifyChildren to childrenMode which accepts
            blockify, lines, and future values, names TBD, and lines
            representing the root inline box (and not individual
            inline-level elements)

  iank: In general, if anyone has suggestions for better names for
        any of this stuff feel free to suggest...

Next F2F Meeting
================

  Rossen: Next F2F is Tokyo in April, do we want to have a Houdini
          meeting?
  TabAtkins: I wouldn't mind
  <dbaron> The Houdini meeting would presumably be Tuesday April 18,
           immediately preceding CSS (19-21).
  shane: I should be able to have typedOM and properties and values
         ready by then.
  iank: I should be able to have an update too.
  Rossen: OK, sounds like we'll have Houdini for one day before the
          CSSWG meetings.

  RESOLVED: Houdini meets Tuesday 18 April 2017 in Tokyo

  <br duration=10min>

CSS Layout (con't)
==================

  Scribe: nainar

Break tokens
------------

  TabAtkins: I want to rename break tokens.
  <TabAtkins> "break" token doesn't tell you wtf it's doing. It's
              holding the information necessary to resume layout of
              that child, to generate the next fragments. Need a
              better name for it that actually communicates that.

  iank: When you get a fragment it potentially has a break token -
        pass to the layout
  iank: so for yourself if you want to fragement in the block
        direction in current API you can read of constrained space
        if fragmentation is not null.
  iank: In that case if you can return in you dict the property
        break token which is a dict itself
  iank: and you add a list of child break tokens.
  iank: When the engine calls ??? back it returns the data you
        passed it.
  gregwhitworth: Aren't we each time calling on the box we are
                 laying out.
  gregwhitworth: Need for multiple break tokens if concern is laying
                 out box.
  iank: You get one break token back but you may need to take care
        of child break tokens.
  iank: <explains break token on board>
  iank: Data is engine stashing the info you pass to it.
  Rossen: You could, for example, ask space?
  iank: Data is a nice thing to stash state instead.

  RESOLVED: Hook into structure algorithm on how to structure
            breakToken and make the breakToken structure cloneable.

  gregwhitworth: I can stash whatever I want but it feels like its a
                 sign of missing something.
  TabAtkins: It's not, you will get called once and you need to know
             how much you have already done so as to resume.
  eae: We don't know what kind of layout people will perform on top
       of this.
  Rossen: You can add gradient info to resume on next frame.

Min/Max Content
---------------

  iank: Next min and max content.
  iank: There are two models you can do for min max sizing.
  iank: Resolved inline size needs to know min max size to do stuff
        like shrinkToFit
  iank: so if you need to do things like grdiContent you need to
        know available size min size max size.
  iank: One way to do it don't need to do anything special call min
        size with 0 and max size with infinite.
  fantasai: If you are specified size then that will be your min
            content.
  iank: My understanding is that they resolve to zero - min max.
  dbaron: Replaced elements there are some cases where they resolve
          to 0
  iank: Option 2 introduces a new callback and returns a tuple of
        min max.

  Rossen: This is something we should punt to CSSOM -
  Rossen: we get requests for this - we just want to know what the
          min max size of my element is
  Rossen: if we expose this on an element level - curious to know if
          there are scenario we wont be able to ???
  Rossen: One thing you will say I want to have this API on a range
          - give me the min and max.
  dbaron: I feel like we can live with something similar to it -
          element one flushes layout houdini doesn't.
  Rossen: You don't have to flush layout.
  dbaron: You have to flush style at least.
  dbaron: The stuff in custom layout should only have layout.
  Rossen: Your style is not changing ...
  dbaron: There may be cases where you do layout with non current
          style.
  dbaron: There are cases where we stop doing relayout and paint a
          partial new/old layout.
  dbaron: There are cases where we do that with style.
  esprehn: Where?
  dbaron: In cases where it takes too long.
  Rossen: We had incremental layout where we could resume and push
          partial frames - user experience wasn't great.
  dbaron: Custom layout should be separate from api for elements.
  Rossen: If we assume for a given subtree on which we are doing
          custom layout - then the api we talked about is sufficient
          for level 1.
  iank: The engine would provide for min max size on element level
        and child has that available?
  Rossen: Sure, and engines figure out how to do this - we already
          do this.
  <nainar> Please check issue
https://github.com/w3c/css-houdini-drafts/issues/343 for details
  <nainar> https://www.irccloud.com/pastebin/ShmkAr9J/

  Rossen: Assume this API exists today on CSOM level.
  Rossen: I can say minContentSize like offsetHeight.
  iank: Inside of layout it becomes a simple function - children
        have the min and maxsize as well.
  iank: Add a new method on class that receives children array and
        size - engine may call this to calculate minMaxSizes on
        parent.
  dbaron: How does this relate to ho a element with custom layout
          provides custom min and max content.
  iank: If you have an element that needs to know min and max size -
        engine would invoke this on the child.
  iank: This can be invoked by the engine or you can do it yourself.

  RESOLVED: Add a new method on class that receives children array
            and size - engine may call this to calculate minMaxSizes
            on paren

  dbaron: One orthogonal thing this should have separate property
          dependencies as opposed to layout - as there are some that
          don't effect layout - make explicit?
  Rossen: At this level?
  dbaron: No, but less efficient as it would have to compute for
          things that don't effect.
  Rossen: Can we add this as a note? these are the properties that
          will recalc min and max.
  Rossen: Addition of these will also force recalc.
  dbaron: Should the class have a separate input prop list - for the
          ones that effect min and max sizes.
  dbaron: Don't have idea of how big this list?
  TabAtkins: File an issue to look into this - call this function
             less number of time.
  Rossen: Optimize the function call it as many times as needed.
  dbaron: Servo architecture is related to min max thing.
  esprehn: Benefit of added function?
  esprehn: They share a lot of stuff - closer to merge better.

  esprehn: I'm questioning the resolution - we can cache this and
           add needsMinMaxSizes to our 3rd plan.
  iank: <adds edits to the plan in the issue>
  esprehn: Doesn't work if you want to query the min/max size
  iank: assumes that children have both minSize and maxSize on them.
  dbaron: If in the example in the explainer - the code loops over
          the layout.
  dbaron: Servo splits up the subtree of the children.
  iank: <typing> const fragments = yield children .map(c =>
        c.layoutNextFragment(space));
  <dbaron> https://github.com/w3c/css-houdini-drafts/issues/347
  iank: files issues about explainer mentioning that we use parallel
        layout when possible
  <dbaron> ok, so yielding one layout request at a time doesn't
           allow the engine to parallelize, but yielding an array of
           them lets the engine parallelize them
  <dbaron> it would be useful to have that explained in the explainer

  [Summery of un-minuted conversation:
      Jack was saying it would be better for performance in parallel
           engines to structure the api to be like the three
           callbacks in Servo
      Ian says the developer ergonomics of that are bad
      Jack would be interested to see the code that they tried
  ]

  iank: How to handle scrolling 1) on the constraint space there are
        two bools telling you if inline or block scrollbar present.
  iank: You can't set this on your child - handles by the engine.
  iank: If you return a fragment that has an overflow size bigger
        than the one.
  iank: We talked about having scrollLines - this is better.
  iank: Other approach is what Tab suggested - you cant turn on the
        overflow: auto for custom properties.
  iank: overflow: auto will resolve to allow us to layout once only.
  iank: If we go for Tab's option it simplifies it from authors
        perspective.
  TabAtkins: I'm pretty sure few people would write code to restart
             when they become too large.
  iank: If you have overflow size bigger than your size we will call
        you with boolean.
  Rossen: Tab's option forces us to have better implementation of
          that value.
  Rossen: If all of a sudden we reserve space for overflow: auto
          even though we don't need it - we have different layout.

  RESOLVED: For an element that uses custom layout overflow: auto
            computes to preserve space for scrollbar.

  Bert: Would it be possible to specify initial offset of scrollbar.
  Rossen: This should be in the scroll spec and not the layout one -
          as has nothing to do with it.
  Bert: The layout function is the only one that knows.
  Bert: If its a different api how will know the layout of the
        element.
  iank: If you scroll 100px down and then there is a child inserted
        - its not layouts job to adjust scrollbar.
  iank: Stays at where engine thinks it should be.<div
id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br />
<table style="border-top: 1px solid #D3D4DE;">
	<tr>
        <td style="width: 55px; padding-top: 13px;"><a
href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon"
target="_blank"><img
src="https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif"
width="46" height="29" style="width: 46px; height: 29px;" /></a></td>
		<td style="width: 470px; padding-top: 12px; color: #41424e;
font-size: 13px; font-family: Arial, Helvetica, sans-serif;
line-height: 18px;">Virus-free. <a
href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link"
target="_blank" style="color: #4453ea;">www.avast.com</a>
		</td>
	</tr>
</table><a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1"
height="1"></a></div>
Received on Sunday, 5 March 2017 16:01:49 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 5 March 2017 16:01:50 UTC