W3C home > Mailing lists > Public > www-style@w3.org > February 2020

[CSSWG] Minutes A Coruña F2F 2020-01-23 Part I: CSS Multicol, Masonry Layout, CSS Sizing, CSS Rhythm [css-multicol] [css-sizing] [css-rhythm]

From: Dael Jackson <daelcss@gmail.com>
Date: Tue, 18 Feb 2020 19:19:37 -0500
Message-ID: <CADhPm3siyMqBexN6MkxRtkCb=UrAV=u8dADWfZTkjG=X9JVjyg@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.

CSS Multicol

  - RESOLVED: Confirmed that we do indeed want (at least generally)
              Firefox's behavior; get Morten to confirm exactly
              what he wants clarified in further issues. (Issue #4689:
              column-fill in unconstrained containers)

Masonry Layout

  - Discussed Mats's masonry layout proposal, which builds on the Grid
      Layout model. https://github.com/w3c/csswg-drafts/issues/4650
      - Open question of whether this is a variant of grid, or a
          separate layout mode.

  - RESOLVED: Adopt Masonry layout proposal, editors fantasai and Tab,
              and Mats if he's convinceable, and Jen if she's allowed.
              Exact relationship to Grid TBD.
              (Issue #4650: Masonry Layout)

CSS Sizing 3

  - Christian will write up the behavior originally implemented by
      Chrome for issue #3973 (Why was min-content etc. to be redefined
      to be nothing like Block axis?) and then the group will discuss
      changing the spec based on that definition.

CSS Rhythm

  - Since there are still outstanding issues the group decided to
      remove tests and add warnings to line-height-step and line-grid
      (Issue #938: Line grid and tests)


Agenda: https://wiki.csswg.org/planning/galicia-2020

  Rachel Andrew, Fronteers
  Rossen Atanassov, Microsoft
  Tab Atkins, Google
  L. David Baron, Mozilla
  Amelia Bellamy-Royds, Invited Expert
  Christian Biesinger, Google
  Mike Bremford, BFO
  Oriol Brufau, Igalia
  Tantek Çelik, Mozilla
  Emilio Cobos, Mozilla
  Elika Etemad, Invited Expert
  Javier Fernandez, Igalia
  Koji Ishii, Google
  Brian Kardell, Igalia and OpenJSF
  Jonathan Kew, Mozilla
  Ian Kilpatrick, Google
  Chris Lilley, W3C
  Stanton Marcum, Amazon
  Myles Maxfield, apple
  Cameron McCormack, Mozilla
  Tess O'Connor, apple
  Manuel Rego, Igalia
  François REMY, Invited Expert
  Florian Rivoal, Invited Expert
  Hiroshi Sakakibara, BPS
  Jen Simmons, Mozilla
  Alan Stearns, Adobe
  Lea Verou, Invited Expert

Scribe: TabAtkins

CSS Multicol

column-fill in unconstrained containers
  github: https://github.com/w3c/csswg-drafts/issues/4689

  rachelandrew: New issue, but refers back to a previous issue; trying
                to wrap up.
  rachelandrew: Previous Multicol said that in continuous media,
                column-fill is only used if height of columns is
                constrained; otherwise they're balanced.
  rachelandrew: Was commented out in 2012.
  rachelandrew: Chrome and WK implemented column-fill as if that line
                was there; Firefox implemented without.
  rachelandrew: We put the line back in for #3224, to match Chrome,
                but in #4036 we reverted based on dbaron's issue.
  rachelandrew: dbaron suggested we change the line to say "in
                continuous context, and last fragment in fragmented
                contexts...", and I updated the table accordingly
  rachelandrew: So we need to figure out what to do when
                column-fill:auto and unconstrained height
  rachelandrew: If we honor it, that means all the content goes into
                the first column.
  rachelandrew: This is only outstanding issue in multicol.

  florian: In addition to Firefox vs WK, there was browser vs print
  florian: Wanted consistency between multiple things.
  florian: "browser when screen" and "browser when printing" should
           act the same
  florian: Shouldn't randomly become different, people don't test
  florian: But also didn't want browsers and print formatters to do
           different things
  florian: It seemed to me there was only one behavior we could use
           that satisfies those
  rachelandrew: We resolved to revert the change and put an issue in
                the spec in Fukuoka

  florian: dbaron, do you remember what the "one harmonious approach"
  dbaron: I think our conclusion was...
  dbaron: There were two constraints.
  dbaron: One was we don't want the rules between continuous and
          fragmented contexts to be different, such that you get
          different results if you have a small multicol in a
          fragmented context that is small enough to not fragment.
  dbaron: Second is making the behavior of print formatters, and
          browsers when printing, consistent.
  dbaron: I think shortest path to satisfy both and be sensible is
          Chrome and WK changing their behavior, I think to the Gecko
  dbaron: I think if we look at continuous context behavior, it would
          involve Chrome and WK matching Gecko. I don't remember about
          fragment context
  faceless: Prince matches Firefox
  florian: Remaining open question is, are Blink and WK willing to do
  rachelandrew: Morten says yes, but we'd have to clarify what
                column-fill:auto and height:auto means
  iank: Morten's fine, yes. Depending on how difficult, we might not
        get to it immediately; it might wait for our new fragmenting

  dbaron: I'm reading Fukuoka minutes, but I think we already decided
          to do this.
  dbaron: Morten was concerned about, once we make that change,
          there's more that needs to be defined more clearly.
  dbaron: so I think we agreed on the behavior we wanted, but then
          needed to follow up with issues to make it more fully
  dbaron: Resolution was "revert #3224, and add spec issues to define
  dbaron: So I think our resolution was reverting, and then there were
          other issues that aren't fully defined and need to be
  dbaron: I suspect Morten might be the best to remember what that
          undefined stuff was.
  iank: And I think Morten wanted it to all be done at once rather
        than a dripfeed of impl issues, so he'll want it all defined
        before he makes the change.

  florian: Was the question about min-height:auto, max-height, etc.
  dbaron: [reads Morten's comment]
  * dbaron was reading
      [ You're asking if I'm okay with #3224 being reverted and
        willing to implement it in Blink? Sure, but then we won't
        have to clarify what column-fill:auto + height:auto means,
        do we? The spec, prior to #3224 said that column-fill:auto
        means that we should never balance (except before spanners),
        didn't it? ]
  rachelandrew: All right, so I'll need to talk to Morten to see what
                he was really wanting to be defined
  rachelandrew: Can we have a clear resolution confirming this
  iank: Yeah, could we have fully defined behavior before we make the

  RESOLVED: Confirmed that we do indeed want (at least generally)
            Firefox's behavior; get Morten to confirm exactly what
            he wants clarified in further issues.

Multicol tests

  rachelandrew: As part of this work I've been going thru the testsuite
  rachelandrew: Some are quite old, going back to old Opera tests
  rachelandrew: I've been inlining the tests as I go to see what's
                tested and not
  rachelandrew: I've got a whole bunch of tests now that are
                Fragmentation, not Multicol, or Box Alignment.
  rachelandrew: Don't have anywhere for them to live.
  rachelandrew: What's the process for moving those?
  TabAtkins: If those tests belong to Fragmentation or Align, we can
             just move those in WPT, right?
  rachelandrew: Dunno, got shrugs in #testing before
  florian: If it still involves multicol, you can also still link in
           the metadata to the part of it that's relevant in Multicol.
           You can also include tests in <wpt> that aren't in your
           spec's folder, if they're relevant.
  fantasai: Yeah I think florian summarized it. Test goes in the
            folder of the spec it's primarily testing; if it's testing
            interactions you can link those cross-spec sections; if
            the test is just using a feature for generic purposes
            (like using backgrounds to make sizing effects visible),
            you don't link that spec.
  fantasai: Some tests you can go either way on whether they're tagged
            Multicol or not, but they're definitely fragmentation;
            only things like "how wide is a column, etc" are def
  iank: If you do move a whole bunch of tests, it's easier for us if
        you do them in one large commit
  iank: We have to update test expectations, etc.
  rachelandrew: I've already got a spreadsheet, so I can do it all at
  iank: How many?
  rachelandrew: Dunno, a fair few. Tens.

Masonry Layout
  scribe: fantasai
  scribe's scribe: heycam

  github: https://github.com/w3c/csswg-drafts/issues/4650

  jensimmons: Mats Palmgren, layout engineer at Mozilla, over
              Christmas break, this is what he did for Christmas
  jensimmons: He's thought in detail about what it would take to add
              something to Grid to accomplish Masonry layout
  jensimmons: It's lots of detailed from implementer perspective

  jensimmons: So what is Masonry layout?
  jensimmons: It's a popular idea of how to lay out content on the
              Web, e.g. on Pintrest
  jensimmons: People wanted to do it with Grid, but you can't really,
              still have to use JS
  jensimmons: works fast on Pintrest because they put a lot of money
              and effort into it
  jensimmons: others use this library [shows library]
  jensimmons: Here's what the layout looks like [shows outline]
  jensimmons: Why not do it with flexbox? well that would give the
              wrong content order
  jensimmons: Don't want the early things to be below the fold with
              late things up at top in the later columns
  jensimmons: also makes a problem with lazy loading, would rejigger
  jensimmons: Order people need is going across
  jensimmons: This version of Masonry, the most common one, is that as
              it goes to fill in the rest of the pieces of content
  jensimmons: puts next item into the column that is the shortest, so
              always closest to the top
  jensimmons: Other option is to go from 1st column to last column
  jensimmons: but skip columns that are too full to keep things
              roughly in order
  jensimmons: Mats believes he's figured out how to do it in Grid
  jensimmons: That's the issue
  jensimmons: I think it would be popular and people would be super
              happy to have

  TabAtkins: Yes, this has been requested for like 15 years
  TabAtkins: Overall, love the proposal, think it's great, lots of
             detail in it
  TabAtkins: Only concern, making it part of Grid instead of its own
             display type
  TabAtkins: Think we should make it display: masonry, copy over
             concepts from Grid
  fantasai: Any examples of things you're concerned about?
  fantasai: This is somewhat similar in that subgrid is also kind of
            like a mode
  fantasai: which creates a different way of laying out items in the
  fantasai: Masonry is just a different model for doing the rows
  TabAtkins: Subgrid is fundamentally a grid still
  TabAtkins: But masonry is different
  TabAtkins: Example, Mats suggests an align-tracks property that only
             applies to masonry
  fantasai: What's it do?
  TabAtkins: It aligns the Masonry stuff within their track
  TabAtkins: So there are a few different layout concepts
  TabAtkins: that don't apply to Masonry in Grid
  TabAtkins: and that don't apply to Grid in Masonry
  TabAtkins: So I think we should re-use as many concepts as possible
  TabAtkins: but separate out as a distinct display type
  TabAtkins: that has a clear signal for what applies here vs in Grid
  <tantek> Is this orientation specific? I.e. presumably masonry
           refers to the overlapping brick like layout. Flickr does
           this for displaying photo results, e.g.
  florian: For align-tracks property, if we did have different modes,
           could we use an existing alignment property to do this?
  fantasai: If I understand correctly, you have a box, then some
            masonry tracks
  fantasai: each individual track aligning its content to the bottom
  fantasai: rather than taking the entire masonry chunk and sliding it
            to the bottom
  fantasai: Isn't this exactly what justify-content does in flexbox?
            why not just reuse align-content?
  TabAtkins: Only given an hour thought to this
  fantasai: I think it's premature to split it out as its own
            layout model, but which should think about that
  fantasai: for now leaving it as part of grid makes sense until we
            have a clearer idea of what doesn't fit

  Rossen: Fan of this proposal
  Rossen: What are we trying to get out of this discussion?
  heycam: Wanted to get temperature of the room, see if there's
  heycam: and also get thoughts on integration
  bkardell: Of course I want this
  bkardell: Want to say same thing as Grid and Flexbox, we should stop
            and solve the a11y problem with content reordering
  bkardell: I have concerns about that, that's all
  <TabAtkins> I think this doesn't introduce any new
              content-reordering problems; it's definitely no worse
              than "a pile of floats", still according with the
              standard "left to right, top to bottom" ordering.
  <TabAtkins> (Unless you use 'order', of course.)

  rachelandrew: I would really like to see Masonry solved
  rachelandrew: I also agree we should look at content reordering
  rachelandrew: Don't think it should be part of Grid
  rachelandrew: Trying to teach it, it's not a grid
  rachelandrew: would make a lot more sense to have a separate layout

  <tantek> Is there no attempt to do baseline alignment across masonry
           items in different columns?
  <tantek> That might be one reason to consider it grid-like
  <astearns> tantek: I doubt it would be feasible to to baseline
             alignment when there are not grid lines in the block

  emilio: I don't know if should be separate model
  emilio: but multicol changes layout model quite a lot, this still
          mostly fits within grid layout paradigm
  emilio: can share a lot of code
  emilio: so not quite like multicol

  jensimmons: I think these are great issues to bring up.
  jensimmons: Taking off introducer hat
  jensimmons: this is jen

  jensimmons: I was also concerned about a11y order
  jensimmons: but after explaining, I think it's less of a problem
              than Grid
  jensimmons: It does seem like people are tabbing through DOM order,
              focus rings
  jensimmons: Easier because content doesn't go below the fold

  jensimmons: I do feel like this belongs as grid
  jensimmons: There are 2 axes, and this only works in one axis
  jensimmons: Do this in row directly, have all power of grid in
              column direction
  jensimmons: Things when it comes to subgrid and nesting a grid
              inside a grid, might want things to interact
  jensimmons: things interact
  jensimmons: Just choose how you want to treat other axis
  jensimmons: ...

  <tantek> would https://flickr.com/photos/tags/csswg be an example of
           doing it in the "row direction"?
  <astearns> tantek: I don't think the flickr thing is masonry-row.
             The content order would go top to bottom in that case,
             and it looks to me like the first three pictures in the
             first row are in content order
  <tantek> astearns, I have heard what Flickr does called "masonry"
           layout as well so that likely deserves some clarification
  <tantek> in particular, the feature of resizing images to fit like

  iank: I'll try and channel Adam Argyle
  iank: He previously worked in industry and built lots and lots of
        Masonry layouts
  iank: He had similar reaction that might fit better as a separate
        layout model

  <TabAtkins> Ah, I remember why *-content can't work for distributing
              the items in a masonry track!
  dbaron: Jen was talking about, and think this might relate to Tab's
          comment on IRC, applying grid properties in vertical axis in
  dbaron: One thing I was wondering is how many interact with
          placement concept of Masonry
  dbaron: e.g. if you have align-content in the vertical axis
  dbaron: space-around, you want even gaps
  dbaron: you don't know how many items until you place them
  dbaron: and you can't place them until you know the number of gaps
          in each column above the item
  TabAtkins: Mats answered it by saying you place items before
             applying align-content
  TabAtkins: align-content is a different thing, it moves the whole
  TabAtkins: repeat autofill doesn't work
  TabAtkins: But back to fantasai's point about align-content, in Grid
             it aligns the entire grid
  florian: If you have a grid with sized tracks in the Block axis, and
           the size of the tracks is smaller than the container, then
           you can align
  florian: but masonry tracks don't have such a size
  TabAtkins: Track does have a size, it's the sum of all masonry items
             in it

  myles: Want to jump on bandwagon and say it's really exciting
  myles: With regard to the new display type, I think Mats makes a
         compelling argument wrt graceful degradation
  fremy: You can just say `display: grid; display: masonry` which works
  TabAtkins: Especially if we re-use grid-template-columns or
             whatever, it's easy fallback

  astearns: Side conversation with Tantek on IRC
  astearns: Has example of Flickr, wants to ask if that's also Masonry
  <tantek> specifically with the resizing of items in the masonry
  Rossen: This is a multiline flex
  <tantek> it's not just flex. it's about resizing the images
           automatically to fit them in the row
  jensimmons: Flickr decides how many photos to put in a row
  jensimmons: then makes the outer edges to match the container
  jensimmons: then changes the height of the row to match
  jensimmons: It's weird and complicated and totally done in JS
  dbaron: Each image is sized based on other photos in the row
  jensimmons: If you [...] then you get basically that layout, but the
              images are cropped by object-fit
  jensimmons: Flickr uses JS to avoid cropping the images
  jensimmons: and Masonry is a whole different layout
  <tantek> anyway the point is due to the brick-like layout, this is
           *also* called masonry
  <tantek> having the row heights adjust automatically is key
  <tantek> I'm saying that web developers (some at least) know this as
           masonry as well
  <tantek> so if you call something masonry, some may/will expect this
           to be supported
  <jensimmons> The demo I was just talking about:
               It only works in Firefox because of the flexbox sizing
               bug of images in Chrome, Edge & Safari.

  Rossen: In summary, I'm hearing a lot of support for this proposal
  Rossen: reminds me of early days of Grid, when we proposed something
  Rossen: and 2nd model was proposed to add to it, at first seemed
          unlikely to fit
  Rossen: but ended up with a harmonious merge
  Rossen: Let's get something in a more spec-like proposal
  Rossen: then decide if it should fit into Grid, or should be its own
  Rossen: Are there parts that should be extensions to Grid?
  Rossen: I think it will take some time to figure out
  Rossen: but overall goal of proposal and exposure of topic is
          achieved in sense that there's a lot of support and demand
          for this, so let's continue working on this in a separate
          module for now to bake out the details and decide the next
          path forward
  Rossen: Might be Grid, might be something else
  Rossen: Sound good?
  fantasai: +1
  <tantek> +1
  <bkardell> ... and to double down on solving the general reordering
  Rossen: So I propose we take a resolution to adopt Masonry layout
          and move from there.
  fantasai: Who's editing?
  TabAtkins: I'll co-edit, but not primary edit
  Rossen: Mats?
  dbaron: We might have to do some convincing.
  fantasai: I can edit.

  RESOLVED: Adopt Masonry layout proposal, editors fantasai and Tab,
            and Mats if he's convinceable, and Jen if she's allowed

  bkardell: Masonry isn't in content order
  florian: Yes and no, it's not a 1D thing, they're in 2D space
  florian: but within that space they're in content order
  <astearns> they are always top to bottom, not necessarily left to
  <bkardell> for the record, not pushing back on 'this' - worried
             about the general space

Motion Path

Merging All the Shape Functions

  fantasai: Do we want to wait for Amelia?
  TabAtkins: I agree with Amelia, so can represent her position

CSS Sizing 3

content-sizing keywords in the block axis
  github: https://github.com/w3c/csswg-drafts/issues/3973

  cbiesinger: Seems to be disagreement between me and dbaron
  cbiesinger: For a long time min-content/max-content/fit-content were
              defined to work in the block axis
  cbiesinger: to be the size the item would have if it weren't
              explicitly sized
  dbaron: Size at what width?
  cbiesinger: I know that's your objection to this
  cbiesinger: Chrome had implemented this
  cbiesinger: This is also essentially the same size that Flexbox uses
              for min-height: auto
  cbiesinger: At one point spec was changed to say that block axis
              just computes to auto, and Chrome removed it
  cbiesinger: However I think this is a useful thing to have
  cbiesinger: Intrinsic size in the block axis at the specified width
  cbiesinger: I would like to have that feature back
  cbiesinger: Discuss.
  dbaron: You said Chrome implemented it. I'd like to see the
          definition of what Chrome implemented
  TabAtkins: In particular our resolution was for you to tell us what
             you did so we can look at it :)
  <TabAtkins> "Leaving the issue open to: hopefully get some info from
              @cbiesinger as he promised ^_^"
  cbiesinger: Can write it up, but should I talk about it? or write it?
  dbaron: I think there are a bunch of gaps in the specs, want to know
          how you would fill in the gaps

  scribe: heycam

  fantasai: For block layout, in the block axis, by saying it becomes
            auto, we're saying it becomes the max-content size
  fantasai: the max content size, min content size, and auto size, are
            exactly the same
  cbiesinger: It doesn't work for min/max-height this doesn't work
              right now
  fantasai: And in that case, defining them to be the same in the spec
            doesn't cause any problems.
  dbaron: Except the auto height of the block is a concept at layout
          time after you know the width
  dbaron: whereas min/max content heights don't have a width to use
  dbaron: and min/max content are referenced all over these other
          specs without saying it's at a particular width
  dbaron: A particular block has a unique min content height
  dbaron: If min-content and max-content are a function of width, then
          every spec that needs to use those concepts need to say what
          the width input is
  fantasai: I'm pretty sure grid does
  dbaron: Pretty sure most specs don't
  fantasai: For block, you always have a width
  dbaron: You have many widths. Available width?
  dbaron: Intrinsic size of an orthogonal float...
  fantasai: That's defined in Writing Modes
  fantasai: WMs says if you need the width you use viewport size plus
            some other calculations
  dbaron: Does it say that for intrinsic size? I think it says to do
          that for layout, but these are different concepts
  fantasai: So you want to WMs to clarify that it's used for both?
  cbiesinger: You could say it uses the width in the current layout

  dbaron: It's hard for me to argue this without preparation, but the
          last time I went through the specs following spec links I
          couldn't find out how it was defined
  cbiesinger: I don't disagree
  fantasai: One thing that we are losing by defining everything to be
            auto, if min/max content and auto size in block axis were
            always equal, it wouldn't matter
  fantasai: but the problem is that in grid and flex, they have
            different meanings
  fantasai: You get a different size, content lays out differently, in
            the block axis, depending on min-content/max-content/auto
  fantasai: and being able to request those sizes and being able to
            use them within the context of other nested layouts is
  dbaron: But the spec right now pretends these are generic concepts
          across all layout systems, and not derived from widths
  dbaron: but layout systems define these all over without saying what
          width to use
  dbaron: cbiesinger and I agree that this is not currently defined in
  cbiesinger: Are you objecting to the concept of this? Or just the
              fact that this is currently not well defined

  Rossen: Let's double down on the previous resolution
  dbaron: I think it's a huge architectural change for our layout code
  dbaron: I want it to be important and clearly defined before doing
  dbaron: I think this is one of those things where you can get pretty
          close with a bunch of hacks, but that's not the same as
          following the spec
  dbaron: and I still don't know what the spec is
  fantasai: You need to do some intrinsic sizing in the wrong axis to
            get grid/table to work with orthogonal flows
  fantasai: I think the architectural changes is whether you do this
            or not, and you already have to do it to handle orthogonal
  dbaron: Right now in code the functions that compute intrinsic size
          don't take a width argument
  dbaron: and if these things are a function of width we need to work
          out what width to use for every caller
  dbaron: Some of this is complicated because intrinsic size is
  dbaron: It depends on all its descendants
  dbaron: In some of these non-recursive cases it could depend on
          layout, but we need to say what these cases are
  dbaron: but I think there are cases where there are hundreds of
          calls to intrinsic size calculations across our code, we
          need to work out what to pass in
  Rossen: I agree this is a large change if you are computing
          intrinsic size without doing layout
  Rossen: Might be best to close the discussion today until we have
  Rossen: Christian has the action to write this up

CSS Rhythm and Line Grid
  Scribe: TabAtkins

Line grid and tests
  github: https://github.com/w3c/csswg-drafts/issues/938#issuecomment-575499518

  koji: We discussed quite a bit on issues for rhythm sizing last time
        two years ago
  koji: As far as I understand, this issue was the most blocking for
        the feature
  koji: Since then, Blink shipped LayoutNG. I didn't re-implement this
        in LayoutNG yet.
  koji: Currently this test fails in all browsers.
  koji: I don't see a way to solve this properly
  <dbaron> The issue is blocking what?
  florian: We talked about multiple solution for the double-sizing.
           What is the test assuming?
  koji: We just have tests for rhythm-sizing in general.
  florian: We have a spec, and tests; you fail because you don't
           implement. That's normal, right?

  fantasai: What are the tests for? There's block step sizing and line
            step sizing
  fantasai: Were the tests for block step sizing, or line step sizing?
  koji: Line step sizing
  <rego> are these the tests?

  koji: Question isn't about that, tho. I have to admit that I've got
        not great confidence on how I understand this accidental
        double-spacing issue.
  koji: But if I understand correctly, florian and astearns consider
        this a critical blocking issue.
  koji: From my perspective, any solution can't avoid accidental
        double-spacing in some cases.
  koji: So if we say accidental double-spacing fundamentally breaks
        the feature, we're basically saying CSS won't have this
        feature. Is that correct?
  florian: Problem here is we want a vertical rhythm where the lines
           are the same size, and what to do when you can't have that.
  florian: So either you break the rhythm and let some lines get
           bigger, or you double size the line to keep the rhythm.
  florian: Can't avoid one or the other. What you can avoid is
           double-size when you don't need them to be.
  florian: So if we have a mode where we double-size some of the time,
           making sure it doesn't happen gratuitously, or in a brittle
           UA-dependent way, is the essential issue.
  florian: So it's not "we can never have double sizing", it's "we
           have to be careful and make double-sizing happen
           consistently and predictably"
  <tantek> rather than "that would be bad", can you state the desired
           fallback behavior?

  hober: Isn't there a third option?
  hober: Enforce the rhythm, and let the line overlap slightly.
  florian: I think it's a bad one, but yes.
  hober: I think some would prefer that.

  florian: Circling back to koji's question, we have multiple specs
           addressing this problem.
  florian: My feeling is that the most realistic part of this story is
           block-step-sizing; easiest and least brittle.
  TabAtkins: Not going to break your layout if all your blocks are
             slightly larger in one browser than another
  TabAtkins: but very broken if every line is double-spaced

  faceless2: This only applies when line-height is normal, correct?
  florian: Different concepts here. block-step-sizing has the problem
           without line-height.
  florian: So they overlap to varying degrees.
  fantasai: I think neither of these specs should be actively tested
            or implemented yet; I don't think we have great consensus
            on this as the correct solution yet.
  fantasai: Fwiw, block-step-sizing doesn't have this sensitivity to
            UA differences in inline layout or font rendering.
  fantasai: So I think we could point to a wpt revision that had those
            tests, but I don't think we should highlight failures
            before we have agreement on the concept at all.
  fantasai: I think we need to handle font fallback in a more robust
            way. I think there's a lot of work to do to solve rhythmic
            sizing well, and a lot of that is solving inline layout
            problem generally.
  koji: We could just set line-height and it works, tho.
  fantasai: Right, but baseline-to-baseline spacing is still
  fantasai: So because we have this discrepancy, almost all the time
            we trigger the double-spacing.
  fantasai: So we want to clear this up, make the lines naturally
            rhythmic, so then when we need to *interrupt* the rhythm
            with something significantly different we can invoke
            rhythmic sizing.
  koji: True for Latin, I don't think it's true for CJK.

  koji: Really just want to know if we should even be thinking about
        implementing right now.
  fantasai: I don't think so, no. If you remove those tests, drop a
            link to the last revision with them into the spec.
  koji: Ok. But even block sizing has these problems too.
  fantasai: I don't think so, no. Rhythmic sizing *will* increase the
            size of blocks sometimes.
  koji: We will have the same problems as text tho.
  florian: How?
  TabAtkins: If we have rendering differences in line heights, and the
             block height is based on text content, we'll have the
             same UA-dependent differences!
  florian: If you size with lh unit, then...
  florian: Really my issue is just about line-step-height. I don't
           think it's about block-step-height, but if you think there
           is, go ahead and open an issue about that.

  astearns: Elika went over a bit of my comment, but if the feature
            isn't in active dev, I think it's perfectly fine to remove
            tests from WPT. I just approved a PR to remove all the
            Regions tests for this reason.
  astearns: I'd prefer if there *was* active development - I don't
            think this issue is a blocker to doing work at all.
  koji: So I hear consensus to remove the tests, and add warning to
        line-height-step and line-grid; block-step is fine.

  faceless2: RealObjects have implemented this; I can't speak for how
  faceless2: AH have an implementation as well.
  faceless2: We've got it too.
  faceless2: I think this is all about the differences in what
             line-height:normal means between impls.

  TabAtkins: I'll note that the ".tentative" substring in the filename
             is designed for this - tests that shouldn't be considered
             normative yet, but are in development.
  Rossen: So current proposal is to remove tests, add warnings to
          line-height-step and line-grid.
  myles: What will the warning say?
  florian: In line-height-step it can link to this issue.
  florian: For line-grid, there are concerns, but no issue yet.
  astearns: I can add the warning.
  astearns: "We haven't figured everything out yet, but don't try to
            implement blind assuming it's stable. Please give feedback
            if you're okay with working on bleeding edge."

Received on Wednesday, 19 February 2020 00:20:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:15 UTC