[CSSWG] Minutes Sydney F2F 2018-07-05 Part III: CSS Align, Logical Properties, Overflow 3 [css-align] [css-logical] [css-overflow]

  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.

CSS Align

  - There was agreement on behavior, but disagreement about the
    correct way to describe intrinsic sizing so interested parties
    will work together over a break. (Issue #1431)

Logical Properties

  - frremy brought up some confusion he's running into implementing
    logical properties and how they are exposed in CSS properties
    and animations in hopes that the spec can be simplified.
    However, the group still felt the spec minimized author confusion
    so should stay as-is.
  - RESOLVED: Fix unicode-bidi to be non-animatable, and make sure
              all propdefs are using the proper terminology.
              (Issue #2751)

Overflow 3

  - RESOLVED: discarded content is treated as display:none, not laid
              out (Issue #2860)
  - RESOLVED: block-overflow value can be set in the line-clamp
              shorthand (Issue #2860)
  - RESOLVED: Add the longhands to the spec in whatever form editors
              find convenient to *describe* the functionality, and add
              a note requesting implementation of just the shorthand
              for now. (Issue #2860)
  - RESOLVED: After these edits, publish a new WD of Overflow.


Agenda: https://wiki.csswg.org/planning/sydney-2018#schedule

CSS Align
Scribe: tantek

Should justify/align-self on abspos elements apply when offsets are
  github: https://github.com/w3c/csswg-drafts/issues/1429

  dbaron: First one I wanted to bring up was probably this one,
          about how magical do we want the initial values to be
  dbaron: One of the cases where I was disagreeing was in some ways
          some of these new properties are better than the old way
          of doing things, and I don't feel that strongly about
          this one. But there are some cases where it would be
          relatively simple to make these properties work in more
          cases, but it means making the 'normal' or whatever initial
          value do today's behavior
  dbaron: This one in particular is about justify-self and align-self
          on abs pos elements
  dbaron: this is not static position stuff, this is actual absolute
  dbaron: IDK maybe this is kinda the same as earlier
  fantasai: We discussed early justify-self align-self on a abspos
            element when ...
  TabAtkins: This is about one offset not being ...
  fantasai: Per 2.1 the 2nd offset is computed after you compute
            the width
  TabAtkins: In other words like an auto margin
  fantasai: Yeah

  dbaron: My perspective, I've never particularly liked auto margins
          as a mechanism, and these properties ought to override them
  fantasai: Specific examples?
  dbaron: e.g. ...
  dbaron: Maybe it's ok, I'm ok with this one, but I've kinda
          forgotten what we resolved here
  dbaron: I'm ok with it
  dbaron: There was one other one I thought was worth discussing,
          and I need to find the list of issues again

intrinsic sizing in the block axis
  github: https://github.com/w3c/csswg-drafts/issues/1431

  dbaron: I think this came up in two issues
  dbaron: Layout regarding intrinsic size ...
  dbaron: I objected ... IDK if I'm the only upset about this
  TabAtkins: IE already does layout while computing block layout
             sizes so they get correct values for column wrapped ...
  dbaron: Even if it is possible, we should only do it when it
          is absolutely necessary
  dbaron: If an alignment thing can happen after layout,
          then we are better off describing it as something
          that happens after layout
  dbaron: instead of describing computing the intrinsic size
  TabAtkins: There are other things that want this sizing
  TabAtkins: such as sizing a float at all
  TabAtkins: Me and fantasai already went to / want to express this
  TabAtkins: customLayout already expresses ...
  iank: No it doesn't
  dbaron: Basically, what do you think about describing block direction
          alignment as computing the intrinsic size in the block
          direction and doing the alignment vs doing the layout and
          aligning the result

  Rossen: In our case we align only after a layout
  Rossen: In general the cases of layout are measuring, arranging,
          and aligning - for us
  Rossen: and aligning only happens naturally after arranging
  Rossen: which is what you are referring to as layout
  Rossen: and measuring is what you refer to as intrinsic sizing
  Rossen: ...
  astearns: Do you mind if the spec says you get those block direction
            measurements for arranging?

  fantasai: We are talking about the sentence about baseline alignment
            can influence the ...
  Rossen: Yes
  fantasai: If you say it doesn't increase the size of the intrinsic
            box, then the size of the box won't increase
  fantasai: In order to accommodate the content it will overflow
  Rossen: In this case, what we would do in the cases where we need
          to stretch, we do the normal pass of computing intrinsic
          and doing layout
  Rossen: and then do the actual alignment, and then based on the
          alignment stretch, similar to what you do with table cells
  Rossen: Sometimes this means we have to go and do one more pass
  Rossen: sometimes when you do the stretch because of alignment,
          you have to relayout inside such items as well
  Rossen: We are already doing it, pretty much everyone is doing it
  Rossen: I don't think we have a way out of this

  dbaron: I thought we were talking about a different sentence
  dbaron: I thought it was the sentence "Values other than stretch
          or normal cause non-replaced absolutely-positioned boxes
          to use fit-content sizing for calculating auto sizes in
          the affected axis."
  dbaron: It used to describe ..., now it is saying you use
          fit-content sizing ...
  fantasai: Since min-content and max-content are the same in the
            block axis, that's what you get -- either/both
  dbaron: But you're using fit-content size which is not a function
          of the other dimension
  dbaron: but if you're doing it for layout, your layout is a
          function of measurement in the other axis
  fantasai: That sentence is a bit of shorthand. Could have written
            out that in inline-axis it's fit-content and in block
            axis it's max-content
  fantasai: but I don't particularly see the point since they're
            equivalent statements
  dbaron: The fit-content size of a block is the result of layout
          at what width?
  TabAtkins: Do you have an answer to that question for min-content
  dbaron: No

  dbaron: Intrinsic sizes come before layout
  dbaron: I think you defined it somewhere but I don't remember where
          the answer was
  dbaron: It doesn't particularly make sense to me so I have trouble
          remembering it
  fantasai: At what size depends on the rules of alignment in the
            ... axis
  fantasai: The rules for layout says you lay out in the containing
            block minus the margin, border, padding... then depending
            ... 100% of that remaining space, or shrink wrapped
  fantasai: ... or block size, and then that becomes the size used
  fantasai: ... and then when you do alignment ...
  fantasai: [missed]
  <fantasai> Rules for abspos say that you find the inline size using
             the containing block size, offsets, margins/borders/
             padding, etc. Take the remaining space, lay out into that.

  astearns: dbaron do you have alternate wording that you would be
            satisfied with?
  dbaron: I think I liked what was in this section before
  dbaron: If you are aligning in the block direction, you do layout,
          and then you align the result
  astearns: Seems reasonable to me

  astearns: fantasai you were using the phrase the content-based size
  astearns: rather than intrinsic size
  fantasai: Intrinsic sizes are content-based sizes
  fantasai: the size of an image is an intrinsic size
  <fantasai> To find the content-based (intrinsic) size in the block
             axis, you need to lay out the content into the inline
             size to find out how tall it is
  <TabAtkins> https://github.com/w3c/csswg-drafts/commit/7d1efdc3e96a94a6a426016d8752a2ddcd10af59

  Rossen: Intrinsic sizes are well defined in the inline direction,
          and in the block direction (too soft to hear)
  Rossen: Talking about intrinsic sizes in the block direction...
  Rossen: I think what dbaron is suggesting makes sense, which is
          you layout and then you align
  Rossen: I don't know what it means to align then layout
  TabAtkins: My issue here is that the text before we made the change
             was effectively identical
  TabAtkins: We didn't change the concept at all, we just made a
             copy/paste error
  TabAtkins: Before we said ..., now we said ..., but that didn't
             change the meaning of the sentence at all
  dbaron: I think there might have been something else before a prior

  astearns: If archeology, then we table this for now, and work on
            whether there was previous wording that was better or
            can we improve it now some other way
  Rossen: Can we whiteboard it at the break
  fantasai: No argument about behavior, just terminology
  TabAtkins: Happy to fix terminology offline

  astearns: Any other alignment issues
  dbaron: I don't think so, but the thing we discussed is why I was
          unhappy with 2 or 3 of them
  astearns: Table this for now

Logical Properties
Scribe: TabAtkins

Simplifying logical properties

  frremy: I was looking at logical props, and the more I tried to
          work on this and discussed with internal devs, the more
          we realized how crazy the whole thing is
  frremy: We never had the concept of ordering properties within
          a declaration block before, but now we need it
  frremy: For margin-top vs margin-before, etc.
  dbaron: We explicitly decided to depend on that when we went with
          this proposal.
  frremy: And then it goes further - you don't know the mapping
          until you compute writing-mode/etc
  frremy: And if you're animating these values, their meaning can
  frremy: If you're animating margin-top and margin-start, and in
          the middle of the animation change writing-mode, they
          might change directions completely
  frremy: Implementing this is very tricky - doable, but tricky.

  frremy: So I get the value of these logical props. I don't think we
          need to have both of them working together at the same time.
  frremy: Why do you need margin-left and margin-start both working
          on the same element?
  frremy: I think pages generally use one or the other.
  frremy: So can we instead use something like using margin-before,
          margin-left never applies?
  fantasai: margin-inline-start is used in the UA style sheet, so
            your proposal would make physical margins *never* work
            on any element with those margins applied.
  frremy: Edge doesn't do logical yet, and this works
  fantasai: We used to do it with magic, but we don't want the UA
            stylesheet to be magical if possible.
  fantasai: The point is that we don't want authors to have complicated
            rules to reason about, and changing behavior like this is
            troublesome for them.
  frremy: I think it's confusing now.
  fantasai: It's confusing for the implementor, less confusing for the
            user. We value the user's confusion over the UA's
  frremy: I just think the complexity of having these mapped properties
          that can change at runtime, in the middle of animations,
          isn't worth the complexity.

  emilio: Animations get canceled when the element turns display:none,
  emilio: Can we do the same when writing-mode or direction changes?
  dbaron: I don't think that's needed. Style changes during animation
          already requires you to recompute style.
  dbaron: True of changing fontsize when you're animating a length in
  dbaron: This is a little bit different, but not *very* different.
  frremy: I see the point, but it's much more difficult for us.
  myles: An animation example, the content author is animating a
         property and switching writing mode, so the margin that
         animates changes. That seems expected...
  astearns: Part of the example is animating left and start at the
            same time.

  myles: My second point is that according to caniuse, we have wide
         interop on this.
  frremy: In Chrome the props don't have the right name and different
  fantasai: Being fixed now.
  frremy: If people are fine with the current model, I'm fine with
          letting it go, but now that Blink is trying to follow the
          spec, I think it's a reasonable time to discuss this.

  Rossen: So wrapping around your proposed simplification - you're
          saying if you have a logical prop you don't look at physical
  frremy: yeah
  Rossen: So if I have margin-inline-start:10px, and margin-right:5px,
          depending on writing mode I may or may not pay attention to
  florian: No, it's a kill switch. You don't pay attention to -right
           at all.
  Rossen: Ah, okay. So it's per-element.
  Rossen: What does that mean for cascade? If I say margin:inherit,
          what happens?
  frremy: You still cascade/compute normally.
  Rossen: So inheritance is not affected, what I would expect.
  Rossen: So say we have margin-right:2em...
  frremy: I think computed style would still be two different things,
          but used style would merge them
  Rossen: So you have both logical and physical props resolved to
          computed values.
  Rossen: From which point you have to start animating.
  Rossen: So I have any logical property specified, all the physical
          ones are excluded from animations...
  fantasai: No, they animate, they just don't do anything.
  Rossen: Okay, cool. So they've animated. Now we do layout.
  Rossen: So we say "I have a logical value specified, so I don't pay
          attention to physical ones".
  florian: So the killing is per-group? margins, separate from padding?
  frremy: Yes
  florian: What about ones that are linked? overflow and background?
  frremy: They're separate
  florian: Okay, so just the shorthanding relationships.

  fantasai: I think it's reasonable for the author doing not doing
            vertical text, just dealing with English and Hebrew,
            to use margin-top/bottom, but then depending on what
            they're doing, using margin-left or margin-inline-start.
  fantasai: I think it is bad if, as soon as they apply a
            margin-inline-start, it'll turn off margin-top and
  frremy: They can switch to block-start and block-end...
  fantasai: I think this is a bad model, we decided explicitly against
            this before.
  myles: I agree with fantasai in her assertion that authors wanting
         to use only logical or physical isn't right - we've seen a
         lot of UIs that are only for horizontal, and fantasai's exact
         example happens
  dbaron: Also, if it's a large project, you'd have to get every
          component to use the right property, and they might be
          used in other contexts...
  myles: And there are 3 browsers that all implement this, so impl
         complexity doesn't seem like a very strong argument
  Rossen: We've had unexposed logical props since IE9.
  Rossen: So this isn't about what's not possible, it's about how
          they're exposed in CSS properties and animations.
  Rossen: I think Fran├žois is only saying that when you expose the new
          properties via css it's problematic.

  heycam: I agree that we could probably have come up with a better
          model, though I'm not too interested in changing now.
  heycam: But one suggestion is to have two completely separate sets of
          props, and for layout purposes you add them together.
  fantasai: Which is incompatible with what's shipping today.
  frremy: Okay, I was getting the temp of the room, but people don't
          seem too happy about it.
  heycam: I agree that the OM implications aren't the best.

Writing Modes

Animating writing-mode/direction
  Github: https://github.com/w3c/csswg-drafts/issues/2751

  birtles: Like Fran├žois says, animation is tricky because they share
          the same computed properties
  birtles: and animations works on computed values, so you need to do
           mapping to computed properties before you animate
  birtles: This is different to font-size
  birtles: There the dependency is between property *values*, but here
           it's a dependency between properties themselves
  birtles: In gecko, we distinguish between properties from animation,
           and changes from OM.
  birtles: Re-resolving that mapping in response to animation change
           is harder than in response to OM change
  birtles: So it does add significant complexity
  birtles: I think if we say they're not we still need to update the
           mapping from OM, and that's some complexity, but much less.
  <fantasai> Actually, writing-mode, direction, and text-orientation
             aren't currently animatable anyway
  <fantasai> https://www.w3.org/TR/css-writing-modes-3/#direction
  <fantasai> https://www.w3.org/TR/css-writing-modes-3/#propdef-writing-mode

  florian: Any use-case for animating?
  [TabAtkins tries to imagine a use case, other people say it's not
     very credible use case]

  heycam: Why are direction and unicode-bidi excluded from all
  TabAtkins: They shouldn't have been in CSS in the first place,
             they're really content attributes

  fantasai: They're already described as "animatable: no"
  florian: It's unclear whether that's the old meaning of "no"
           (meaning "discrete"), or the new sense (meaning not
  fantasai: Currently unicode-bidi says "discrete" and the rest say
            "no", which doesn't make a lot of sense

  astearns: So the proposed resolution is to take
            direction/writing-mode/unicode-bidi and make them not
  shane: This'll be confusing for authors if they do put them in
  fantasai: Authors already shouldn't be using direction or
            unicode-bidi in stylesheets
  shane: That's a good argument in general, then!

  RESOLVED: Fix unicode-bidi to be non-animatable, and make sure all
            propdefs are using the proper terminology.

  frremy: With this resolution, I'm much happier about the previous

Overflow 3

max-lines is not forward-compatible
  github: https://github.com/w3c/csswg-drafts/issues/2860

  florian: Issue raised by dbaron
  florian: The way we've specified, max-lines automatically makes the
           thing into a fragmentainer that discards the leftover
  florian: The problem is that in experimental L4, we have a property
           that lets you turn arbitrary elements into fragmentainers.
           One possibility is discarding, another is the content goes
           into an auto-generated pseudo-element sibling.
  florian: So if someone is trying to use L4 to say "3 lines in first,
           put rest in cloned element", it'll work in browsers that
           work in L4, and discard the content in L3 browsers.

  florian: The way fantasai and I propose to solve this is to backport
           the property only with "auto" and "discard", and max-lines
           is changed to only apply to fragmentainers.
  florian: So if you turn on continue:discard, max-lines will work,
           otherwise it won't.

  heycam: This has some implication on the names of values in
          block-overflow, right? Maybe "clip" should be "none"?
  heycam: block-overflow property has ellipsis/clip
  heycam: But clip sounds like something you want to apply to the
          fragmentainer concept.
  florian: Yeah, these are different, but if you think the names are
           confusing, I can't disagree that bikeshedding might be

  florian: Additionally, shorthanding...
  florian: We have max-lines (triggers fragmentation breaks after X
           lines), block-overflow (at that fragmentation break, insert
           ellipsis or not), and a shorthand called line-clamp, which
           sets both.
  florian: To make it easy to use, line-clamp would also set
           continue:discard, making it a fragmentainer.
  florian: And to set it all in one go, you could set the
           block-overflow part in line-clamp
  florian: So `line-clamp: 3 ellipsis`, etc. would be valid

  Rossen: Is this model... if I have `max-lines: 2` and `widows: 3`,
          what happens?
  fantasai: It triggers a forced break, so any avoid-break controls,
            like break-inside/widows/etc are overridden.
  Rossen: So it disables all of the smarts
  fantasai: To an extent.
  fantasai: If you have max-lines:5, and a float next to it, the
            triggering a forced break after the five lines,
            widows/etc doesn't affect where we break in-flow
  fantasai: But once we do that, there's no forced break in the float,
            it's just told where the container's size is. If there's
            content there, widows/etc applies.

  Rossen: Second question, what happens to discarded content?
  Rossen: Assume we have abspos element used for a sidebar. Its left
          position depends on static position, with top:0, but it
          comes somewhere at the end of content.
  Rossen: So if max-lines discards the linebox that the abspos's
          anchor is in, what's the static pos?
  fantasai: Open issue. I'm happy to perform layout in the discarded
            parts, tho.
  fantasai: Main reason to not do layout are for performance. But
            most use-cases are small amounts of content, or that
            you're gonna dynamically reveal anyway.
  fantasai: So my inclination is to say we do layout, and if there's
            problems with that in the future we can change it.
  Rossen: If we continue to layout it'll be fine, even if subsequent
          fragments aren't the same size...
  Rossen: I think in most cases UAs can optimize away without having
          to do full layout

  Rossen: Even for purposes of object model, if I ask for bounding
          rect of something after the limit, do I get anything?
  florian: The discard behavior that we're talking about already
           exists in regions, in the last region. There's a switch
  florian: For the purpose of the discussion, this is same switch.
  fantasai: We're replacing that property.
  florian: Right, we renamed it here.

Scribe: fantasai

  TabAtkins: I don't think we can do layout
  TabAtkins: Because the absence of those lines can affect other
             layout on the page
  TabAtkins: Such as how other floats position
  TabAtkins: A later or longer float...
  Rossen: Fragmentainers are BFCs.
  TabAtkins: Oh, ok.

  TabAtkins: I suspect there are some things that would make it
  TabAtkins: because we're changing the size of stuff
  Rossen: Things that are problematic
  Rossen: Obvious we're trying to hide this from render and hit test
  Rossen: Computing static position for elements
  Rossen: Fulfilling OM calls in subsequent content
  Rossen: Also whatever needs to happen in such cases is whatever is
          already supposed to happen in Regions
  myles: You could potentially happen position: relative thing that's
         farther down and moves up
  Rossen: Similar issue with static position

  florian: Doing the layout would be problematic because stuff would
           interact with stuff below
  florian: I don't think this is the case.
  florian: E.g. in multicol, the content in subsequent columns doesn't
           impact content below the first columns
  florian: We just place it differently. In this case we don't place
           it all
  florian: You need to do layout within the columns to do the layout of
           the content in the columns. You don't need to position the
           columns then
  TabAtkins: 4 lines of content, down in 20th line, static positioned
  TabAtkins: Container is shrunken down, you have to do full layout?
  florian: Yes.
  florian: But that layout isn't going to impact the rest of the page
  florian: You might see the top half of content if it's above the
           fold, but it won't disturb subsequent content
  iank: It seems like doing a layout would be too much work for
        something like static pos

  Rossen: For the same purposes, we have to figure out what to do for
  TabAtkins: Can still be in AT
  Rossen: There's visibility: hidden; and display: none
  florian: Currently specified as display: none. Can change if needed
  Rossen: If already done that way, then we don't care
  Rossen: In that case would say don't do layout

  heycam: Related things, like selections that go into the laid out but
          not actually rendered frames or boxes, might be a bit tricky
  Rossen: You can't for same reasons for AT
  Rossen: If you consider the content that goes inside of the max lines
  [Rossen draws on the board <f max-lines=5>]
  Rossen: In here you have whole bunch of text with other things
  Rossen: What Florian's saying is that you do layout, consume some of
          this text
  Rossen: And then pretend that there was a <span display=none> on the
          rest of this, and that's it
  Rossen: You cannot hit test here, you cannot expose to A11y
  Rossen: Just as if span with display: none
  Rossen: If this is the model, makes sense. Less computationally
  Rossen: Just need to verify that it's acceptable to a11y
  Rossen: Once you hit your max-lines, you're done
  heycam: I think I would prefer that.
  florian: I think that's what's in the spec, but didn't work out the
  iank: Also need to figure out what to say for CSSOM APIs
  Rossen: This is mostly sorted out by display: none
  myles: Ian's comment about laying out all that stuff so figuring out
         static pos not worth it makes sense
  heycam: This would be the first time when we would have some
          fragments of a box be display: none and others not.

Scribe: TabAtkins

  astearns: Hearing consensus that we're going to take what's proposed
            in the issue
  astearns: Clarify that the discarded content is display: none, and
            what are the implications of that.
  fantasai: So first is that discard content is display:none, not laid

  RESOLVED: discarded content is treated as display:none, not laid out

  fantasai: Second is that block-overflow value can be specified in the
            line-clamp shorthand.
  fantasai: It currently takes a number and affects max-lines and
             block-overflow; right now block-overflow is reset-only.

  RESOLVED: block-overflow value can be set in the line-clamp shorthand

  fantasai: Third is to add continue:[auto|discard] to Overflow3, make
            max-lines depend on the element being a fragmentainer
            (such as from continue:discard), and making
            continue:discard be set by line-clamp.
  heycam: What are the implications of being a fragmentainer? What if
          continue:discard without max-lines?
  fantasai: It establishes an FC, and causes the element's overflow to
             be discarded. This is a new feature
  astearns: Take the element's height, and whatever lines fit into
            there, it's like max-lines:X for that number.
  florian: So the effect is very similar to multicol with hidden
           overflow columns.
  koji: What happens to abspos?
  astearns: Gone, same as previous topic.
  TabAtkins: It's the same as a one-column multicol, except all of the
             oveflow columns are display: none
  astearns: So an auto-height would have all the content unless there
           was a forced break
  Rossen: Selection, works on dom ranges, in the absence of actual
          element computed to display:none, selection would go into
          that range.
  florian: Selection is a thing, yes, but depends on what you do.
  Rossen: Like caret selection, if you get to the segment that's
          discarded it'll continue into there.
  Rossen: But a display:none element just gets skipped over.
  florian: This is like a multicol with visibility:hidden in the later
           columns, your caret will go into there.
  heycam: So this means selection code will have to ask what line it's
  myles: So previously selection depended on DOM and computed style.
         Now it also depends on layout.
  astearns: Anyone want to revisit the display:none issue, or leave it
            as it is and think thru the selection issues?

  Rossen: In any script-based editor, they're laying out a magazine and
          want an article to be five lines, they continue navigating
          thru content, suddenly their cursor goes into the void.
  florian: You already have to depend on layout. If you press down,
           you need layout to know what character you'll be going down
           into on the next line.
  myles: News website is common use for max-lines. In this facility,
         you'd get the first paragraph or so of the article.
  myles: If the selection included the missing parts and they copied,
         it either wouldn't contain the display:none part and depends
         on layout, or it would contain parts that they don't see.
  heycam: Don't we already have this with text-overflow?
  florian: Yeah.
  florian: If selection is a domrange, you can make it cover the
           discarded part. But the copy operation itself can be smart
           and skip over.

  heycam: So this isn't just about recasting existing functionality.
          Now I have to worry about implementing continue:discard
          without max-lines, and worry about other work...
  florian: If you have max-lines:3e6, it also basically is a
           fragmentainer, but unlikely to actually trigger the forced
  heycam: I have a div with continue:discard and a fixed height,
          I have to worry about dropping more stuff.
  koji: I understand you saying it's similar, but defining limits by
        number of lines but also by height is different code.
  florian: But max-lines *already* says you're a fragmentainer that
           discards things, so continue:discard isn't new code.

  myles: Back to selection. If user does select with mouse, they'll
         drag over the discarded part, if we want to keep that out
         of the selection we need multirange
  florian: No, it's the same as today if you drag over a display:none.
           One range, but copy can skip the discarded part.
  astearns: It's not possible to set continue directly from the
            shorthand. Is there any concern that 'continue' by itself
            might have applications that are separate from max-lines,
            so that it's weird that line-clamp will override?
  fantasai: In that case you'd probably want to not use line-clamp,
            but use max-lines directly

  Rossen: If the height of your element with continue:discard depends
          on its siblings, like it's a grid item, every time you adjust
          the height you have to relayout everything inside.
  Rossen: And by doing so you might bring stuff in which is now
          affecting your width.
  fantasai: The way fragmentation is defined is that min-content and
            max-content is constant across all fragmentainers.
  fantasai: That should remain true for discarded content.
  fantasai: And we should make that clear.
  Rossen: I'm concerned about relayout that has to pull content up
          because of resizing due to siblings e.g. in grid rows
  TabAtkins: It's the same as if you put a multicol in the grid
  Rossen: I have two grid items, one with continue: discard. The one
          that is not sets the height
  Rossen: You have to go and re-layout the second one which is
          continue: discard, because you don't know what's next
  Rossen: If that was a normal grid item, you'd have laid everything
          out, but now you have to juggle thing.
  TabAtkins: This is exactly the same as a multicol
  TabAtkins: It's not a new thing.

  astearns: So are we at the point we can decide that continue is a
  Rossen: Any other option?
  fantasai: We can define line-clamp as if the longhands existed,
            but not expose them yet, so L4 would introduce continue.
  TabAtkins: So if we did that, if you just want ellipsis, you'd have
             to say `line-clamp: infinity ellipsis`?
  florian: Yeah

  fantasai: And note that as soon as we started doing this, authors
            were asking for "as many lines as fit into <length>";
            that's what 'continue' does
  fantasai: My preference is to put these three into the draft now,
            but with a note asking implementors to just implement
            'line-clamp' shorthand right now; but because we do need
            to figure out these interactions we should go ahead and
            keep them in the draft to help work them out.
  fantasai: So any concerns about implementability can be figured out
  astearns: So proposed resolution is to add the longhands to the spec
            in whatever form you find convenient to *describe* the
            functionality, and add a note requesting implementation
            of just the shorthand.

  skk: In this context, ruby is a line?
  fantasai: It's part of a line.
  myles: So if you said max-lines:1, you don't just get the ruby
  fantasai: And we'll revisit in TPAC
  astearns: Objections?

  RESOLVED: Add the longhands to the spec in whatever form you find
            convenient to *describe* the functionality, and add a
            note requesting implementation of just the shorthand.


  florian: Can we do a new WD?
  fantasai: We didn't do one after Berlin because of David's concern
            about forward-compat.
  astearns: Any objections to publishing a new WD of overflow with
            all these edits in place?

  RESOLVED: After these edits, publish a new WD of Overflow.

<br dur=15min>

Received on Tuesday, 24 July 2018 23:52:57 UTC