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

[CSSWG] Minutes Lyon F2F 2018-10-22 Part III: Flexbox, CSS Inline, CSS Overflow, Off Topic [css-flexbox] [css-inline] [css-overflow]

From: Dael Jackson <daelcss@gmail.com>
Date: Mon, 12 Nov 2018 19:22:12 -0500
Message-ID: <CADhPm3stnaTQJseWkSsdsVMqWEefCLJafEqmCbYMMph4Lg1=4w@mail.gmail.com>
To: www-style@w3.org
  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: Proposal accepted.


  - The inclination was to allow align-content to apply to single-line
      flex containers (Issue #3052) but TabAtkins is going to gather
      usage data to determine if that's web compatible.

CSS Inline

  - Please add preferences for the rename of initial-letters to issue
  - Discussed spacing above initial letter, see slides at
  - RESOLVED: If the initial letters container has no border or
              padding then the glyph content above the alignment point
              for initial letter is not considered for layout. (Issue
  - RESOLVED: Note to be added that the default behavior may change in
              the future. (Issue #719)
  - RESOLVED: The margin box of the initial letter must be inside the
              content box of its container. (Issue #719)
  - RESOLVED: Add an example that shows default overlap. (Issue #719)
  - RESOLVED: Initial letter does not increase the height of the line
              box. (Issue #719)

CSS Overflow

  - RESOLVED: Intrinsic block size only affected by forced breaks
              (Issue #3214)
  - RESOLVED: Ellipsis string is non breakable. (Issue #3213)
  - RESOLVED: There is no interaction between ellipsis and
              ::first-line or ::first-letter. (Issue #2906)
  - RESOLVED: Edit in Mats proposed solution from issue #2905.
      - Text from above resolution's github:
          - flow the block as if block-overflow doesn't exist
          - if it caused overflow, then shorten the available space to
              accommodate the size of an ellipsis and flow the last
              line again
          - repeat 2 until there is no additional overflow or the line
              is empty
          - during painting, render an ellipsis in the reserved space
              in the last line (same as a text-overflow ellipsis)


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

Scribe: fantasai

  Rossen: The topic is off-topic.
  Topic: Off-Topic
  ChrisL: The topic is me reminiscing a little, thinking back to
          January '97
  ChrisL: when I first started this Working Group, chaired the Working
  ChrisL: Thinking back to like 2001, when the first TPAC was.
  ChrisL: I was thinking back to the last time I was here in Lyon,
          which was TPAC 2012. That was when I met Lea.
  ChrisL: I was remembering back to other meetings, the one in Paris
          in particular, which was the first time we came back to the
          meeting together when we were dating.
  ChrisL: And now we're back in Lyon.
  ChrisL: So that's very happy for me.
  ChrisL: *walks over to Lea and kneels*
  ChrisL: Will you marry me?
  LeaVerou: Yes!
  Rossen: Thank you, Chris.
  fantasai: Chris, you to go back and do that again, because I have to
            take a photo.
  glazou: That was not off-topic at all.
  ?: Do we have a resolution?
  Rossen: By the power vested in me...
  glazou: Resolved!
  RESOLVED: Chris's proposal accepted.

Scribe: eae

Investigate applying align-content to single-line flex containers
  github: https://github.com/w3c/csswg-drafts/issues/3052

  TabAtkins: align-content for a flexbox: you can do align-content on
             a muiltline flexbox but a single line flexbox does not
             respond to align-content
  TabAtkins: Instead we have a behavior where we stretch the line
             always. Not super happy that we made that choice.
  TabAtkins: The problem is there are cases where we'd like to use
             alignment for single line flex container. Specifically
             for things like baseline alignment.
  TabAtkins: By the current definition we can't do anything about it,
             it is always stretching. We can't add in the fake margin
             to cause it to align.
  fantasai: The lines are stretched but the individual items aren't,
            if you want to baseline align you can't do that.
  TabAtkins: Only moves the line, not the items.
  fantasai: The proposal is to make it apply also to single line flex
            containers, would allow more alignment options for
            flexboxes. Nogood reason it isn't allowed already.
            Main concern is whether it is web compatible.
  TabAtkins: Use cases, baseline alignment, no reason why a single
             line shouldn't be allowed to align but a multi-line does.
  florian: A similar use case is when making lines, requires wrapping
           for alignment to work. Declaring it to wrap has caused it
           to work, I don't need wrapping but it isn't causing any
           problems. What's the problem with having to declare wrap.
  TabAtkins: Not consistent with not wanting wrapping.

  cbiesinger: Makes sense but please explain baseline align items vs
  jensimmons: The idea that long term that people have to know that
              wrap is needed isn't ideal. Better to have something
              that works for single line.
  TabAtkins: Compat risk is in two cases, single line row of flex
             containers and non-auto cross size. In auto cross sizes,
             will shrinking to the size of the elements anyway.
  fantasai: If you did self alignment which pushes everything to the
            top and everything is shrink wrapped and the flex
            container is taller, you then have extra space, in this
            case align-content can have an effect where it didn't
  TabAtkins: Auto-height won't have the problem.
  TabAtkins: Fixed height will
  TabAtkins: A column flexbox whose columns are all fixed with would
             have changed behavior with this proposal
  TabAtkins: Those are likely to be rare cases.
  fantasai: We probably want to run a use counter on this before
            committing to it.
  florian: Either that or chrome tries it and reports back.

  astearns: Preferences?
  cbiesinger: I'd rather do a use counter
  TabAtkins: I'll open a crbug.
  astearns: Collect data and report back?
  TabAtkins: Yes
  astearns: Objections?
  astearns: We'll wait on data.
  dbaron: Are we going to revisit once we have data?
  astearns: Yes

CSS Inline

Better name for initial-letters property
  github: https://github.com/w3c/csswg-drafts/issues/2950

  fantasai: Still open issues around better name for initial-letter
  fantasai: My favorite so far out of the proposed ones is
  fremy: Why not drop caps?
  florian: Also raised caps
  astearns: Caps treatment?
  fantasai: Not only caps
  <fantasai> Also ideographic chars

  astearns: We've spent a lot of time on this before without coming to
            an agreement, still an open issue. Preferences should be
            expressed on the issue.

Spacing above initial letters
  github: https://github.com/w3c/csswg-drafts/issues/719

  dauwhe projects
  dauwhe: We've been trying to sort our issues around spacing around
          initial letters.
  dauwhe: This gets somewhat complicated especially as it can have
          ascenders and marks extending outside. Runs the risk of
          overlap. Something had to be done. The idea is to define
          boxes that helps us explain initial letter.
  dauwhe: One is visual box which is the bounding box without padding
          and borders.
  dauwhe: You see at the bottom here and initial letter and the ascent
          mark extends outside.
  dauwhe: Initial letters have alignment requirements
  jensimmons: Are these diagrams explanations of what we have in the
              spec or what you are proposing?

  fantasai: What's the relationship between the top of initial letter
            and the top of where it's placed.
  fantasai: If you have a paragraph and the second paragraph with an
            initial letter, has to ensure enough space between the
            two. We don't want content to overlap. We don't want to
            add too much space or it'll look bad.
  fantasai: Initial letter spec has a lot around how letter is aligned
            with other content in the paragraph and talks about how
            the bottom edge is aligned and excluded. Sometimes there is
            a descender, if there is a second line we don't want the
            descender to blend into the second line. Open questions
            around what happens at the top.
  fantasai: Such as a border or the previous paragraph. Trying to
            answer the question about how to create space around the
  dauwhe: We have the spacing box, no padding and border, same as the
          visual box. It there is padding and border we have the
          union, taking the larger of the physical box and the border
          box, hopefully becomes clearer with some examples.
  dauwhe: We have four cases depending on padding border on the
          initial letter itself or the containing box.
  florian: This is initial letters 3

  dbaron: Can we not have margin collapsing?
  iank: That bit is pretty magical
  florian: Isn't most of the dread around margin collapsing around
           margin collapsing through, which we're not doing here?
           Should be fine?
  iank: This introduces what looks like margin collapsing for
        inlines, which we do not do today
  jensimmons: Margin collapsing where you use the ability for authors
              to remove margins?
  dbaron: The container is a block which can have margin collapsing
          with many things already

  dauwhe: Case 4a, no border or padding on initial letter or
          containing block.
  iank: This is avoiding something earlier in the tree without a
  iank: Say the previous box, nested five times in, has a border. Is
        it shifting down to avoid that border?
  florian: This is collapsing the ascender with the margin
  iank: This is participating in margin collapsing?
  fantasai: Yes, we're not going to get sensible results if we don't
            do that.
  fantasai: We set margins on our paragraphs to get enough space
            between our paragraphs. If there is ascent authors don't
            want to create more space if it fits within the declared
  fantasai: That is not what you typographically want.
  florian: In the example currently on the screen you wouldn't be able
           to tell them apart.
  fantasai: If you have sections which don't start on their own page,
            which happens often, and you're expecting three lines
            worth of spacing between sections you want that to always
            be three lines worth, regardless of ascents on the initial
            cap. But also want to make sure it doesn't overlap with the
            previous section if it is taller, so needs to be able to
            extend the margin.
  dbaron: My worry about this is that it probably more than doubles
          the engineering complexity of initial letter. Adding margin
          collapsing, my gut feeling, is at least 2x the engineering
  dbaron: It's more stuff, nothing in initial letter was all that
          complicated, was a relatively simple feature up until now.
          Margin collapsing is very complicated and performance

  astearns: Is it possible to have a solution without margin
            collapsing solving the non-overlap case.
  fantasai: Would require you as an author to know the distance
            between cap-height of glyph and glyph bounding box. Would
            work but be font specific.
  dauwhe: ...and authors would have to do it for each letter
  So font *and* character specific.

  myles: The ascent is sticking out of the box, why is this different
         from any other case where text is outside it's layout box?
  fantasai: In this case we potentially have a lot of extra content
            outside of the box.
  fantasai: We *could* say that we don't care if we overlap the ink
            with the previous line, but it's not great.
  florian: Latin scrips don't stack up a lot, other writing systems
           have cases where there is a lot of stacking and potentially
           more ink overlap.
  florian: Line-height often reserves space for this, in this case we
           align with the top of the bounding box so anything that
           reaches out reaches out far
  myles: My response to fantasai's point, by default in css, we
         overflow and don't clip.
  fantasai: By default we try not to have it be unreadable.

  TabAtkins: Can and should do it as a generic case where you never
             have ascents running into previous content. Would make
             initial-letter simpler if it wasn't a part of
             initial-letter, but generic for all inline content.
  fantasai: If we were to do it for text in general we'd take a
            different approach.
  florian: You don't want to do it in a small feature
  fantasai: You're more likely to run into problems here, it's a
            bigger chunk of ink that would overlap than a normal line
            of text
  fantasai: People don't tend to run into this for normal text and
            writing systems with more stacking tends to have a taller
            line height for that reason.
  TabAtkins: Can we settle on a simpler model that pushes it down to
             avoid ink overlap?
  fantasai: In that is likely to be less of a problem, I would
            recommend to have it potentially overlap, and have authors
            address it with ample margin, rather than introduce extra
            spacing due to the ascender, which would require
            per-font-per-character margin tweaking by the author to
            get consistent spacing, which they would require.
  TabAtkins: I like it

  astearns: Do we want to raise an issue around dealing with this
            problem in a generic case?
  fantasai: Case of line boxes is a little different. With lines of
            actual text, rhythm is important and the text is smaller.
            Not convinced that you'd want to have the same solution.
  astearns: Is there anything with meaning in this proposal for
            initial letter?
  fantasai: I think it's really a question of how. If the working
            group objects, it puts a strict constraint in what we can
  iank: I think people are going to need implementation experience to
        see how much work this would be. If David is saying this will
        be complex that scares me.

  florian: Should we put a note in the spec about that?
  florian: Do we specify the behavior as described, overlap with
           preceding content, and also put in a note explaining the
           thing dauwhe presented and say "this is what we really
           want, if you want to implement go ahead"
  iank: The only thing that scares me there is that for some
        implementation this would be easy, for others hard.
  astearns: Clarify in spec what would happen with insufficient margin.
  fantasai: We would have to be clear that the proposal being
            considered for the future changes behavior, it wouldn't
            just add a new feature (switch).
  dbaron: I'd be curious if other implementors have same reaction as I
          as with regards to margin collapsing complexity. Another
          example, what if you have a float that is anchored within
          the block with the initial letter but before the initial
          letter, how does the collapse of the margin influence the
          tentative collapse of the float?
  iank: In our current layout implementation there is no way we could
        implement this sanely. In our new one, maybe. I agree, very

  futhark: If you have an imaginary margin for the initial letter
           collapsing as if it was a block, if you change the font,
           you'd reflow and layout the text before we know the margin.
  dbaron: In the presence of floats you don't know if the initial
          letter is at the top of the box as the float might push it
          lower. A lot of complexity
  iank: Super scary!

  astearns: Sounds like we're not willing to make any changes to the
            current spec
  fantasai: We need to agree on some desired behavior. What behavior
            we're going for?
  myles: My proposal would be to use the layout box of the glyph for
         the layout behavior and not consider the bounding box.
  astearns: What I remember you saying, don't move the content down.
  fantasai: Would lead to more correct behavior in most cases, much
            more tangible than the alternative. If we went with the
            other approach, where ascenders take up space, authors
            will have to compensate with negative margin per glyph.
            And we'll never be able to go back and fix it.

  fremy: If you draw a border around it then everything needs to fit
         inside of it.
  fantasai: Inline blocks are laid out differently from inlines.
  koji: If the glyph overflows the inline block that doesn't work
  fantasai: cap-height is used for sizing and positioning of the
            initial letter.
  fantasai: But it doesn't dictate the size of the initial letter box,
            which includes glyph ascent
  fantasai: Initial letter box by default sizes to the glyph bounding
            box. Ascent bounding box would have a lot of undesired
            extra space around it in typical cases.
  koji: David's proposal is very similar to this
  fantasai: Does not change how inline boxes background are is
            painted. Here, the background area of the inital letter box
            coincides with the glyph bounding box

  heycam: What is meant to happen when you don't have as many lines of
          text as the height of the initial letter?
  fantasai: Defined in spec, clearing. The initial letter is part of
            the first line, everything below that is an exclusion
            area, everything will wrap around it, even if it is the
            next block. Like how floats work. However initial letter
            in the next block will clear previous initial letters.
  heycam: The exclusion area also includes the descenders?
  fantasai: There isn't anything special about descenders. Any glyph
            area below the first line, all considered exclusion area.

  iank: If you have two paragraphs and they're nested. What happens
  fantasai: If one of them is a BFC then BFC might get narrower, same
            as for floats or exclusions.

  fantasai: The proposal on the table, if border or padding is used
            then the initial letter must be contained within the
  astearns: If the initial letters container has no border or padding
            then the glyph content above the alignment point for
            initial letter is not considered for layout?
  astearns: Objections?

  dauwhe: In general, content area includes everything up to ascent,
          why did you phrase it as you did?
  fantasai: Ascent would be much too high for some fonts.
  astearns: Second option, that fantasai was against. If we assume
            that the author would add enough space to avoid overlap
            that would require negative margin and by font specific.
  fantasai: You could have more slack there, with the negative margin
            approach it's more strict, different amount of space per
            character, per font. The negative margin is specific to
            the font and the glyph. That's really, really bad.
  astearns: dauwhe are you okay with default to overlap?
  dauwhe: I'm totally fine with that, majority of use-cases would not
          be affected. Would only apply to a minority of content.
  astearns: Any other objections?

  RESOLVED: If the initial letters container has no border or padding
            then the glyph content above the alignment point for
            initial letter is not considered for layout.

  <myles> ("alignment point" usually means "cap height")

  RESOLVED: Note to be added that the default behavior may change in
            the future.

  <fantasai> the margin box of the initial letter must be inside the
             content box of its container

  RESOLVED: The margin box of the initial letter must be inside the
            content box of its container when there is borders/padding.

  astearns: Any other initial letter topics?
  fantasai: Going back to dbaron's initial question. Be clear about
            whether it is created space between the top of the first
            line and the container. Whether the line box itself is
            increased or if a different kind of height is added?
  [dbaron points out it is detectable by how vertical-align: top
      behaves: if the item is aligned to the top of the first line or
      to the top of the raised cap]
  <fantasai> I think in Sydney we decided the top of the first line
             minus the raised cap, so suggest we resolve on that

  RESOLVED: Add an example that shows default overlap

  <fantasai> proposed resolution: initial letter does not increase the
             height of the line box
  astearns: What mechanism pushes everything down then?
  fantasai: The initial letter itself is able to take up space. The
            initial letter box itself takes up space.
  astearns: Does that satisfy your question David?
  dbaron: Could you say what you proposed yourself again?

  RESOLVED: Initial letter does not increase the height of the line box

  fantasai: I think that's it for initial letter. We have other inline
            layout stuff, though.

CSS Overflow

Intrinsic sizing of elements with continue:discard
  github: https://github.com/w3c/csswg-drafts/issues/3214

  florian: Intrinsic sizing, currently the spec says that, in the
           block direction, is from the beginning of the content to
           the first forced or unforced break.
  florian: That is problematic in that we don't know where the first
           unforced break is until layout
  florian: Would suggest we change it to the first forced break. From
           start of content to first forced break.
  dbaron: Two thoughts, one is that I hope the content that is after
          the first forced break contributors to the intrinsic size of
          something. Not sure what but should contribute to something.
  florian: Only talking about the discard case now.
  dbaron: For discard that seems reasonable, for some other cases min
          and max content would do different things. Min content would
          look at first break opportunity, while max-content looks
          until first forced break
  astearns: In cases where there is a fixed height then discard
  florian: We should only consider forced breaks only for the purpose
           of intrinsic sizing, for other purposes the spec stays
  fantasai: I think this makes sense.

  RESOLVED: Intrinsic block size only affected by forced breaks

  <fantasai> it would be problematic I think for the 2nd fragmentainer
             and beyond, but for the first fragmentainer it's doable
             and reasonable
  <cbiesinger> why is it important to compute block-axis intrinsic
               size before layout? in most cases we can't do that

Long block ellipsis strings
  github: https://github.com/w3c/csswg-drafts/issues/3213

  florian: I have a paragraph with lorem ipsum, the width is very
           narrow, we line clamp it and have ellipsis. What should
           happen when the ellipsis itself is longer than the line.
           One option is to consider the ellipsis unbreakable and have
           it stick out.
  florian: The alternative, it is wrappable, and wraps up into the
           previous line.
  myles: How does the implementation know which line to start on?
  florian: I feel it is an edge cases that will rarely happen, first
           option seems a lot easier.

  TabAtkins: The wrapping behavior doesn't solve the problem of it
             being too wide
  florian: Do we need to solve the problem where it could wrap. I
           suggest we don't.
  florian: If in the future we want to allow wrapping, then we give
           it a pseudo-element which we assume has 'white-space:
           nowrap' and the author can override that if they need.

  florian: Third way is leave it undefined, don't like it.

  TabAtkins: Should be similar to have we do ellipsis now, remove
             enough characters until it fits
  fantasai: This seems easier, don't have to care about the many ways
            of doing wrapping.
  fantasai: I think the proposed resolution is to go with the first
  Proposed resolution: ellipsis is treated as unwrappable and will
           extend outside
  TabAtkins: It's not great to overflow but at least you can see it.
  astearns: Objections?

  RESOLVED: Ellipsis string is non breakable.

block-overflow, ::first-line, and ::first letter
  github: https://github.com/w3c/csswg-drafts/issues/2906

  florian: If you have max-lines 1 your ellipsis string will be on the
           first line, will it be styled by the first line style? If
           it is long enough to extend to start will it be styled by

  RESOLVED: There is no interaction between ellipsis and ::first-line
            or ::first-letter

  TabAtkins: When I've seen this sort of thing show up in printing it
             is not styled as drop caps or first line, distinct style
  fremy: If you say max-lines 1 you don't need first-line in the first

Allowing (or not) alternate ellipsis behavior for block-overflow
  github: https://github.com/w3c/csswg-drafts/issues/2905

  florian: A part of the spec that says it's undefined. Gives two
           options. You layout your text and insert your ellipsis and
           remove content up until it fits. Properly insert text and
           you redo layout.
  florian: Then there is a may. If you are time-pressed there is an
           easy way, inserted the same way as text overflow. Does not
           affect layout, paint time effect.
  florian: Not great that spec allows two different behaviors.
  florian: There is a next level of spec that allows other behaviors.
           Should we remove the may and make the correct behavior
  florian: Mats suggested that we might want to do an intermediate.
           You do the right thing when removing content but the
           insertion of the ellipsis is allowed to be a paint time

  astearns: If the ellipsis removes the entire last line would that
            change the line-height?
  florian: Would retain a strut to preserve line height.

  heycam: What happens with interactions like bidi reordering?
  fantasai: I would imagine that the ellipsis would be bidi isolate
  heycam: Also other interactions?
  fantasai: If the ellipsis is rendered in a font that is taller than
            the line it is rendered onto the line would be taller
            which could cause that line to be dropped
  florian: That problem doesn't necessarily need solving.
  heycam: Removal of glyphs, back up to however many glyphs needs to
          be dropped.
  florian: How far you're allowed to back up, if you have hyphenation
           or in japanese where you can break anywhere. Line wrapping
  myles: So not glyph based at all?
  florian: Not half glyphs, at least one glyph, often more

  astearns: Proposal as I understand, remove content as required to
            ensure enough space, leave a strut as needed, and then add
            ellipsis at paint time?
  heycam: Logically trim of pieces of the DOM that won't be rendered?
  florian: You don't drop the line wherever, reuse the same logic as
           used for line breaking or fragmentation. Consider the last
           line to be shorter to allow for the ellipsis.
  astearns: Would this be better for screenreaders?
  florian: That is one case.

  astearns: Any concerns about removing content and then paining
  astearns: Mats said:
            - flow the block as if block-overflow doesn't exist
            - if it caused overflow, then shorten the available space
                to accommodate the size of an ellipsis and flow the
                last line again
            - repeat 2 until there is no additional overflow or the
                line is empty
            - during painting, render an ellipsis in the reserved
                space in the last line (same as a text-overflow

  florian: Repeat is potentially needed to reflow. Proper layout for
  astearns: One additional thing: If the line is empty, preserve the

  astearns: Any concerns?
  heycam: I don't like the searching and dropping bits to adjust the
          line height.
  florian: Tempted to say yes, haven't thought about it in detail.
  florian: Would look a bit odd if you had a Japanese word with ruby
           that has been dropped but still have a large gap above the
  florian: I do think we should make it narrower, don't want large
           gaps. Not common but would look really bad.
  florian: Not taking to CR anytime soon, edit it in and then revisit
           once speced?

  RESOLVED: Edit in Mats proposed solution from issue 2905.
Received on Tuesday, 13 November 2018 00:23:06 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:15:09 UTC