W3C home > Mailing lists > Public > www-style@w3.org > May 2018

Minutes Berlin F2F 2018-04-12 Thu Part I: Flexbox, line-clamp/max-lines/block-ellipsis [css-flexbox][css-overflow]

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 29 May 2018 15:58:23 -0400
To: "www-style@w3.org" <www-style@w3.org>
Message-ID: <b96c353a-b763-d4c8-0348-004499140887@inkedblade.net>
   These are the official CSSWG minutes.
   Unless you're correcting the minutes,
  Please respond by starting a new thread
    with an appropriate subject line.


   - RESOLVED: Accept the proposal to have width/height influence
               min-content contribution of shrinkable flex items
               [https://github.com/w3c/csswg-drafts/commit/4225207523013fe3d5689b1b37ca4df5142437c3 ]
               (Issue #2353)

max-lines & block-ellipsis (CSS Overflow)

   - fantasai and florian introduced their proposal to create two new
       properties, max-lines and block-ellipsis, which combine into a
       shorthand line-clamp.
       - The goal of these properties is to serve as a replacement for
           -webkit-line-clamp while removing some of the behavior
           people don't like, thus allowing browsers to alias
           -webkit-line-clamp to line-clamp.
       - Generally this was favorably received though there were
           requests to add more examples and notes as well as to ensure
           that there won't be breakage when an implementor switches
           from the current -webkit-line-clamp behavior to line-clamp.
       - An issue will be opened to ensure that the extension path for
           these features is clear before this can go into a full WD.

   - RESOLVED: Continue this work in Overflow as an ED

   - RESOLVED: Copy text-overflow from UI3 to overflow-3, move
               text-overflow from UI4 to overflow-4.
   - RESOLVED: Having max-lines not apply across BFC boundaries (Issue


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

   Rachel Andrew, Invited Expert
   Rossen Atanassov, Microsoft
   Tab Atkins, Google
   L. David Baron, Mozilla
   Christian Biesinger, Google, observer
   Brian Birtles, Mozilla
   Oriol Brufau, Observer
   Tantek Çelik, Mozilla
   Monica Dinculescu, Google
   Elika Etemad, Invited Expert
   Rob Flack, Google
   Simon Fraser, Apple
   Jihye Hong, LGE
   Koji Ishii, Google
   Dael Jackson, Invited Expert
   Ian Kilpatrick, Google
   Rune Lillesveen, Google
   Chris Lilley, W3C
   Peter Linss, Invited Expert
   Myles C. Maxfield, Apple
   Naina Raisinghani, Google
   Manuel Rego, Igalia
   Florian Rivoal, Invited Expert
   Richard Rutter, Clearleft
   Geoffrey Sneddon, Invited Expert
   Alan Stearns, Adobe
   Shane Stephens, Google
   Surma, Google
   Majid Valipour, Google
   Lea Verou, Invited Expert
   Eric Willigers, Google

Scribe: dael

   Rossen: I want to thank the hosts. It's been an awesome venue. Vlad,
           thank you for organizing and TYPO was a great host.


Min-content sizing currently too smart to be web compatible?
   github: https://github.com/w3c/csswg-drafts/issues/2353

   fremy: The issue was that... by default when you can shrink could
          shrink to the min-content. Web expected specified width to
          be considered as well. I reviewed the change and it seems
          right, but the summary was missing details.
   fremy: Still means you have elements that could shrink further but
          will not. I'm fine with the change how written.

   Rossen: What's the summary?
   fantasai: We made the min-content contribution of the flex item
             consider specified width and height.
   cbiesinger: Does it match what min-width: auto computes to?
   fremy: Spec changed the minimum size all the time. Width works
   fantasai: If we changed how 'min-width: auto' works it would
             change how it shrinks down.
   fantasai: We had to do it through the min-content contribution
             rather than 'min-width: auto' because the web depends
             on it.

   Rossen: Proposed resolution is accept this change?

   fremy: The width and height property does affect min-content
          contribution, right?
   fantasai: Yeah.
   cbiesinger: We don't implement intrinsic size computation per spec.
               Does anyone?
   Rossen: We're close. We had reworking recently and since we were
           close to shipping we had to pull back due to unexpected side
           effects. This is part of the changes.
   Rossen: So, kind of.
   cbiesinger: You find it web compat?
   fremy: We won't know until we do this fix and try again.
   cbiesinger: I should prioritize?
   Rossen: Yes fingers crossed.
   Rossen: Objections?

   RESOLVED: Accept the proposal 
[https://github.com/w3c/csswg-drafts/commit/4225207523013fe3d5689b1b37ca4df5142437c3 ]

CSS Overflow

max-lines / block-ellipsis / -webkit-line-clamp
   <fantasai> https://drafts.csswg.org/css-overflow-3/#max-lines
   <fantasai> https://drafts.csswg.org/css-overflow-3/#block-ellipsis

   fantasai: There's been a need to have the -webkit-line-clamp
             property specified and implemented.
   fantasai: Problem with it is it has a lot of problems. Clamps
             container but overflows visibly after the ellipsis. It
             puts ellipsis after any character. It requires old flexbox
             display in webkit.
   fantasai: florian and I tried to figure out how to have a feature
             that does mostly what webkit-line-clamp does but less
             broken and builds on features we want.
   fantasai: Decided it might make sense to split the control to number
             of lines and ellipsis. So we filled out max-lines definition
             and added a separate block-overflow property.
   fantasai: Spec I'm sure isn't perfect but wanted to review and get
             feedback and support for folding this into main draft.

   fantasai: Way max-lines works: specifies the number of lines and it
             only applies to block containers. Counts number of in-flow
             line boxes and forces a break. That triggers standard
             fragmentation behavior and the content acts much like if
             it was display:none.
   fantasai: We wanted max-lines to work across block boundaries. For
             example, you want to break after 10 lines but you don't
             know how many paragraphs there will be.
   fantasai: Open issue as to whether we want to cross BFC boundaries.
   fantasai: max-lines skips over other types of content like a table
             or flex/grid. We jump over it, effectively.
   astearns: Do not count it?
   fantasai: Yeah.
   florian: Tables and flex and grid can be fragmented but it would be
            more complicated and not use case driven.

   fantasai: That's an overview of max-lines. We added block-overflow.
             It inserts content into the line box before a forced or
             unforced region break.
   <dbaron> Is there a way to do block-overflow indicators based on a
            height rather than a number of lines?
   florian: Region break terminology is a little unfortunate.
   fantasai: It depends on css-break not css-regions. It's just a third
             type of break (others being page and column).
   florian: We should fix that word to make them not think it depends
            on css regions. It would work with regions if we have them,
            but it doesn't require you to impl regions.
   fantasai: Naming is a bit confusing, but should be fine in general.

   fantasai: When you combine the features max-lines causes a break and
             then block-overflow adds the ellipsis. For text-overflow
             you don't remove the content, you just hide. Right now we
             allow doing that here, but going forward as we have regions
             and want ellipsis between we can't just remove the content
             because you want the content in the next region.
   fantasai: Spec is written to specify that you move the content to
             make space for ellipsis and if there is no next region you
             can do it as a visible paint time, so that UA can reuse
             text-overflow behavior. Slight behavior difference since
             when you click on ellipsis it goes through to the content
             that's behind it, and also if you actually move the content
             it can change height of line.
   fantasai: But those seem like small differences, so for now it seemed
             better to leverage existing text-overflow behavior instead
             of forcing the better behavior. But both are allowed in the
   florian: There is an issue about picking one.

   florian: In respect to the amount of text you remove to place the
            ellipsis, you find the point to remove based on the same
            rules as line-breaking, so we honor those properties here.
   fantasai: If you allow line breaks at this point it's a reasonable
             point to cut and move on, instead of after every letter
             as WebKit does.
   florian: And that should limit misinterpretations of where to slice

   fantasai: line-clamp is just a shorthand for both properties.

   myles: When would you use block-overflow without max-lines?
   fantasai: When there's overflow fragments in the future. At this
             point in the impl of CSS, max-lines is the only way but
             once we have multiple regions you can use this as well.

   Rossen: Thank you for starting this work. Few comments. I recently
           had some experience implementing -webkit-line-clamp. You
           started by saying it's not really good. I would argue that
           point, I think for what it does and the way it's built from
           impl PoV it's straight forward. It doesn't require heavy
           fragmentation logic when you break or trigger any orphans or
   fantasai: Neither does this.
   fantasai: It creates a forced break which is not subject to the
             break avoid conditions.
   fantasai: We thought about that.
   astearns: There is a note about that in the spec.
   Rossen: Okay, that's important.

   Rossen: Apart from history the one thing that I was curious about is
           when do you foresee a usage of max-lines without
   fantasai: I want the first 3 lines of my paragraph in all caps or I
             want the first 16 lines to be full width and the rest in
             two columns.
   florian: This is the first step where this says 5 lines and discard
            the rest. In the L4 we'll be able to put the rest of the
            content somewhere. Be it from regions or another approach.
            This was designed to be compatible with all the future
            options we've considered so far.
   Rossen: So this introduces a new fragmentainer that applies to
           anything. Now I can add max-line to a table cell. But it's
           not really a region so I can't use region APIs.
   florian: If we as a WG decide we want to implement Regions we can
            do that. This is designed so that if we revive Regions it
            works; and if we do the overflow fragments proposal,
            it also works.

   dbaron: I think the model Florian described doesn't have the right
           graceful degradation properties to be extended in the future
           to different styles for different fragments. If the model
           right now is you get these lines and the text disappears if
           we add this where you get these lines and then you style it
           will degrade in older browsers where you get these lines and
           the rest disappears.
   florian: We do have @supports and that can help, but yes.
   fantasai: With overflow fragments you can also do max-lines as the
             style on the first fragment of the chain, so it won't
             take effect unless we're doing overflow: fragments.
   florian: Another way is to require another property where it doesn't
            turn things into a fragmentainer, it only applies to things
            that are, and then have a value that means throw this away.
            That seemed like overkill at this level

   dbaron: It seems like an important usecase if to break the block at
           a certain height, not a certain number of lines and it
           doesn't address that.
   florian: We aimed for a smaller subset. If we re-introduce the
            property I just mentioned you can use it with max-lines or
            max-height and it works.

   florian: To an early comment from Rossen that the nice thing to
            invoke all in -webkit-line-clamp...what does it do when
            there is a float in the middle?
   Rossen: Currently it overflows if your float fits. People use
           -webkit-line-clamp and if it clips it clips. Intended usage
           is not to put your entire article and have it overflow,
           usually people use it mostly for shortening text so it looks
           nice and has card-based layout with titles you can nav from.
   florian: If we ignore funkiness of being in an old-style flexbox...
            the main trouble is if you apply it to just text it does a
            job  that's close to what's wanted, but it's not extensible.
            This is.
   Rossen: I'm just correcting the overstatement that it's bad. I'm not
           pushing for -webkit-line-clamp

   cbiesinger: Spec says -webkit-line-clamp is an alias of line-clamp
               but line-clamp applies to more. So would
               -webkit-line-clamp on a flex container be ignored?
   florian: The intent we had was to write it knowing that it's not
            quite right and wait for people with impl experience to
            tell us what is the least amount of strange things we need
            to do for web compat.
   cbiesinger: We have to make -webkit-line-clamp make it not be not a
               flex container perhaps.
   fantasai: Interesting idea.
   florian: I hope we can spec web compat with minimal craziness.
   cbiesinger: Have to do something about it though.
   Rossen: Currently -webkit-line-clamp doesn't allow 0.
   fantasai: 0 or negative int are invalid and cause declaration to be
             ignored. In max-lines and in line-clamp.

   Rossen: We've discussed in the past about ellipsis moving toward
           being a pseudo element. For the block ellipsis I hope we can
           still go through that path.
   fantasai: Think so.
   florian: Whatever the pseudo element is the initial value is normal
            and you can override that. We'd need to figure out exactly
            how it should work.
   TabAtkins: And there's a further note about letting an actual
              element force itself to be an ellipsis.
   fantasai: I want to get there eventually, but we have to start

   Rossen: Apart from these comments, what do people think? Would this
           attract impl interest?
   eae: We'd want to do this.
   myles: It's an interesting idea.
   myles: We don't want to have 2 separate incomparable
          implementations. I'm a little worried because it's not
          exactly the same it won't work well. I'm comfortable moving
          forward with this with the idea that if this requires a
          second impl we should change css property to not require.
   florian: I understand. I'm hoping the amount of differences can be
            limited and scoped to aliasing
   fantasai: We don't want to need different implementations for
             -webkit-line-clamp and line-clamp.
   florian: Not for layout differences. I just want things like if you
            need that weird webkit property for flexbox.
   Rossen: The simplicity of how webkit works where you layout flex
           item and count and then redo your layout with max lines
           allowed and then you re-layout with just those lines. This
           isn't layout. If you don't have full fragmentation and
           handling of breaks so everything around fragments sensible
           you have to do more work. What myles is saying I don't
           believe will be true. You can't do property aliasing and
           have -webkit-line-clamp. I don't believe it can ever be this.
   fantasai: We're expecting if you have a -webkit-line-clamp you have
             to create a separate impl of this and then remove
             -webkit-line-clamp and have it alias to this. The code
             inside your browser cannot be extended to this, but once
             you impl this you should be able to get rid of the old
             thing. We're hoping this is an acceptable substitute.
             There are issues around -webkit-line-clamp and the behavior
             changes are that we fixed those.
   TabAtkins: That it's not a fragmentation container is the thing that
              makes it hardest to work with.
   florian: It is simple to impl, but not good.
   Rossen: I'm not defending -webkit-line-clamp, I'm pointing out that
           the impl of this will be very different.
   myles: I'm worried that because they're different enough we won't be
          able to remove original impl. If we need 2 impl of same
          feature that's not good.
   florian: I'm concerned but hopeful.
   fantasai: We've been getting requests for block ellipsis that
             doesn't suck.
   myles: Some behavior changes are okay. Issue is about breaking
          websites. We're comfortable with not exactly the same.
   fantasai: Goal is to not break websites unless they depend on the
             lines after the ellipsis being visible or the ellipsis
             being after every character, both of which seem undesirable
             even now.
   florian: We'll need to see. We can't answer for sure until we try
            and impl.

   TabAtkins: This is so unambiguously better.
   tantek: It's clear that it's better. Does it satisfy a superset of
           the use cases?
   TabAtkins: Yes, but fantasai listed the "use cases" not satisfied by
              this and they're all bad.
   fantasai: They're things people have complained about.
   florian: It is possible that some website depends on things behaving
   tantek: You won't know until someone impl. But us arguing won't make
           a difference until we try.

   fantasai: Do people want to impl this spec? There are individual
             issues, but we just put this proposal in the ED. We can
             make it dependent on some issue.
   fantasai: It hasn't been in a WD
   fantasai: max-lines was not written, it was just waiting for text.
   florian: Do we want to pursue this?

   TabAtkins: We have a concern about it counting BFC. Or orthogonal
              flows it would count into....that should be carved out,
              maybe other, perhaps exempting BFCs.
   florian: That's the first issue on out list.

   dbaron: I have mixed feelings. It seems like it's based on a future
           model in your heads, but it doesn't offer a good extension
   fantasai: florian said we could make 'continue: discard' a required
             part. We can put that into the shorthand but if you use
             max-lines you then have to set 'continue: discard' to get
             useful behavior. In that case, if you leave 'continue: auto',
             it overflows.
   florian: Max-lines would do nothing.
   fantasai: We can think about what to do there. There are interesting
             things we can do like shorten the container but not clip.
   tantek: Sounds like you accept the concern but don't need to solve
           it right now.
   fantasai: Sounds like that would solve it. It is solveable.
   florian: We can open an issue on it.
   tantek: Open it as a blocker for WD.
   florian: I don't know if this was implied in your comment, but as
            spec now it's meant to be compatible with future, but
            doesn't need it to work.
   florian: I'm not sure if you were saying that.
   tantek: He was talking about creating a new compat problem.
   fantasai: I prefer to have a 'continue' step folded in. I think it
             would make max-lines more powerful.
   florian: I'll file the issue.

   tantek: I think overall I like the direction and I'd like to add to
           it. I'd like to see more explanation of the relationship and
           differences to text-overflow. There's one reference right
           now and if you're new to text-overflow you need to have a
           better explanation of when to use each or together.
   florian: More notes more examples.
   tantek: If you put this here, which I think you should, I suggest
           moving text-overflow here to be right before the
           block-overflow definition.
   fantasai: Makes sense.
   tantek: I think text-overflow is simpler and gets people to look at
           it first, see if it fixes the use case, and then move on if
           it doesn't.
   fantasai: Makes sense.

   myles: I'd like to hear more about what you think the future is for
   florian: As a first bit, the 'discard' value is part of regions and
            the other thing [overflow fragments proposal] the CSSWG is
            considering. Regions has a property to control what happens
            to the last region in the change. It's that property we've
            re-purposed with more values. There's a rough sketch of that
            in Overflow 4. Once you overflow we create a clone and put
            the remainingt there.
   fantasai: You can discard the extra content, let it overflow the box,
             or clone the box and fill that--and each of those clones
             can be individually styled. There's also a value that turned
             it into a paging thing so that the box once you run out of
             content it makes a paginating mechanism.
   florian: That last is most exploratory.
   fantasai: That's a bunch of brainstorming. We might not get all of
             those but it looks toward that.
   florian: Clone overflow and discard are realistic. Paginate might
            not be.
   myles: When you clone the box how do you place?
   fantasai: Sibling in the box tree.
   myles: Special selector to select?
   fantasai: Yeah.
   myles: That's a little worrying.
   fantasai: It's a rough sketch in L4. But this is compatible with
             everything we've considered so far: both that proposal and
   myles: I'm worried we reinventing regions.
   fantasai: This is a tool that can expand to help regions or help
   myles: We should make a note that this should work well with regions.
   fantasai: It does.
   <TabAtkins> Let's not let architecture-astronomy over region-ish
               things prevent us from just Finally. Solving.
   astearns: I don't look at this as a thing that will flower into some
             duplicate this. It is just some fragmentation tools that
             will work in any fragmentation context we've considered.
   myles: If you'll use the super-special selector and wanted 3
   florian: If you do max-lines or max-height on the element it gets
            cloned and that applies to all clones.
   astearns: This is a separate feature.
   florian: That's the vision, but not necessary for this level.
   myles: When and if that happens proposal should be clear on
          interaction with regions.
   fantasai: Yeah. I think it's clear.
   florian: I suggest you look at L4. It's not well defined enough to
            be implementable, but it can give you a sense of what we're
            aiming for.
   florian: We don't have to head toward that specifically because it
            would also work with regions.

   Rossen: [missed]
   florian: We considered it but making max-lines apply to columns is
   Rossen: max-lines per column?
   florian: Once there's a pseudo element to target columns why not?
   myles: I'm a little worried because it seems like the direction is
          re-impl stuff.
   florian: Trying to use things that exist.
   myles: As long as when it happens the relationship is well defined
          it's fine.

   Rossen: We have a request by dbaron to open an issue and address it
           before we move into a WD. I'm assuming florian will file
   fantasai: There's a handful of issues to discuss, but we want a
             resolution that we're putting this in the spec.
   tantek: I'd like to see text-overflow folded in before WD.
   florian: We can resolve to move text-overflow to Overflow.  I think
            we should put the UI3 definition into overflow 3.
   Rossen: Objections from moving text-overflow out of UI 3 and into
           overflow 3?

   RESOLVED: Copy text-overflow from UI3 to overflow-3, move
             text-overflow from UI4 to overflow-4.

   florian: Do we resolve as a WG to pursue this?
   Rossen: There's the issue dbaron wanted.
   florian: I want to know if this is a thing we're interested in do.
   fantasai: Or do we remove the text from the ED.
   <tantek> +1

   Rossen: Back to next steps. I've heard a number of people supporting
           this and also a number of concerns before they really
           commit. I think it's net positive.
   fantasai: Question is does the WG like this and leave it in the ED
             or remove it from the ED.
   TabAtkins: Yes.
   eae: Yes.
   Rossen: Other browsers?
   tantek: We've seen demand for more text-overflow like features. I
           agree there's a need.
   fantasai: Do you want the text to be removed or in?
   tantek: I haven't heard anyone say they don't like it. I'm in favor
           of optimistically letting editors put something in the ED
           for review.
   florian: Do we need a resolution to keep working on this?
   fantasai: If the WG doesn't want us to work on this we shouldn't put
             time in. If the goal is to have us work on the issues and
             then people say they hated this from the beginning, that's
             not useful. I just just want approval to have the properties
             in this draft in this order.

   Rossen: Objections to continuing this work in the ED?
   florian: My reading from the Mozilla bugzilla there is interest.
   fremy: What I don't understand is why is this in overflow?
   florian: We had to put it somewhere.
   TabAtkins: Overflow is in the property name
   tantek: From a webdev view it talks about what you do when things
   fantasai: Can we leave it in the ED? Can we get a resolution? If
             people don't want it in the ED we can put it in an
             unofficial draft.
   fremy: Looks like fragmentation.
   fantasai: It uses fragmentation, but doesn't describe it so, no.
   fremy: I don't care, leave it in overflow.

   RESOLVED: Continue this work in Overflow as an ED

Which descendants are skipped in max-lines?
   github: https://github.com/w3c/csswg-drafts/issues/2429

   florian: Within the broad topic of what's skipped, when you're
            counting lines do we cross BFC boundaries? Yes we shouldn't
            count inside obviously insane things like orthogonal flows,
            but what about basic BFCs?
   dbaron: What sorts of BFC are okay?
   fantasai: We excluded scroll containers. Orthogonal flow are insane.
   florian: Nested BFCs. [gives example]
   dbaron: Other then the display:flow-root that exists to create a
           BFC, others?
   fantasai: Align-content is probably okay. Triggers BFC when not normal.
   dbaron: Which axis?
   fantasai: Vertical.

   Rossen: Is anyone implementing?
   fantasai: Don't think so.
   iank: In your implementation we skipped all this for line counting?
   Rossen: Yes.
   Rossen: Also when you start reasoning it becomes insane. What would
           it mean on a grid?
   TabAtkins: Those are all excluded.
   TabAtkins: There's several in the issue.
   florian: Table caption is another I'm not sure.
   fantasai: We skip tables.
   iank_: Someone uses display:flex it triggers a formatting context
          and it will display a part.
   florian: If you have a BFC that's not excluded and it's not what you
            wanted you make it a flex.

   TabAtkins: align-content makes me think we want it to work. We want
              to do it on an align content thing
   dbaron: When something with align-content is fragmented what happens?
   fantasai: I don't think we define that yet.
   fantasai: I'm not sure that's what we want. If you have a box
             supposed to be centered and it's fragmented I don't think
             you want each of them centered.
   TabAtkins: Regardless, boxes don't have size.
   fantasai: They do.
   TabAtkins: Fragments have size.
   fantasai: Box has computed size.
   florian: Different topic.
   <fantasai> The fragments eat up the computed size, they don't each
              get 100px if you specify 'width: 100px'

   Rossen: Is there a reason why you wouldn't want to make the easier
           part work, get a model that makes sense, and then extend?
   florian: I'm not against get rid of BFC.
   Rossen: I'm sympathetic to exclude all BFCs, get stable, and then
           see what we can include. But until we're they're we're
           hypothetically speculating.
   TabAtkins: Easier to cut off BFCs.
   Rossen: Also that will make it more compatible with -webkit-line-clamp.
   florian: Yeah.
   Rossen: Prop: Having max-lines not apply across BFC boundaries

   RESOLVED: Have max-lines not apply across BFC boundaries.

<br type="15min">
Received on Tuesday, 29 May 2018 19:58:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 29 May 2018 19:58:53 UTC