W3C home > Mailing lists > Public > www-style@w3.org > August 2017

[CSSWG] Minutes Paris F2F 2017-08-03 Part I: Tables [css-tables]

From: Dael Jackson <daelcss@gmail.com>
Date: Tue, 29 Aug 2017 17:54:12 -0400
Message-ID: <CADhPm3ui0rd34YivoeDM1-etG0KFRHEJb8O=hJLqgX-3h05vQw@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.
=========================================


Tables
------

  - RESOLVED: All internal table displays on replaced elements to
              behave as 'inline'.
  - RESOLVED: 'display: table' on replaced elements behaves as block,
              'inline-table' behaves as inline.
  - RESOLVED: Ignore percentage min-widths on table cells.
  - RESOLVED: Accept proposed resolution for #474:
              - During the first layout pass:
                  - neither <table> nor <tr> nor <td> has height ->
                      they behave as auto
                  - else if overflow:scroll|auto -> they resolve to
                      "0px" (webkit+gecko webcompat)
                  - else -> they resolve to "auto"
              - During second pass:
                  - neither <table> nor <tr> nor <td> has height ->
                      they behave as auto
                  - else they resolve based on row's final height
  - Issue #484 (excess width distribution in fixed layout mode)
      needs web compat data checked before resolving.
  - RESOLVED: Cells spanning collapsed rows/columns are clipped to
              their resulting bounds (in both axes).

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

Agenda: https://wiki.csswg.org/planning/paris-2017#topics

Present:
  Rachel Andrew, Invited Expert
  Rossen Atanassov, Microsoft
  Tab Atkins, Google
  Brian Birtles, Mozilla
  Bert Bos, W3C
  Tantek Çelik, Mozilla
  Dave Cramer, Hachette Livre
  Emil A Eklund, Google
  Elika Etemad, Invited Expert
  Rob Flack, Google
  Daniel Glazman, Disruptive Innovations
  Koji Ishii, Google
  Dean Jackson, Apple
  Ian Kilpatrick, Google
  Peter Linss, Invited Expert
  Myles C. Maxfield, Apple
  Jack Moffitt, Mozilla
  Naina Raisinghani, Google
  Francois REMY, Microsoft
  Melanie Richards, Microsoft
  Florian Rivoal, Vivliostyle
  Simon Sapin, Mozilla
  Till Schneidereit, Mozilla
  Geoffrey Sneddon, Invited Expert
  Alan Stearns, Adobe
  Surma, Google
  Jet Villegas, Mozilla
  Greg Whitworth, Microsoft

Regrets:
  Jihye Hong, LG Electronics
  Dael Jackson, Invited Expert
  Chris Lilley, W3C
  Simon Pieters, Opera
  Hiroshi Sakakibara, Beyond Perspective Solutions
  Lea Verou, Invited Expert

Scribe: fantasai

Tables
======

Replaced elements as table cells
--------------------------------
  Github: https://github.com/w3c/csswg-drafts/issues/508#issuecomment-317529294

  gregwhitworth: Issue wrt replaced elements as table cell
  gregwhitworth: We added a diagram of what the spec says to do
  <gregwhitworth>
https://github.com/w3c/csswg-drafts/issues/508#issuecomment-260486721
  gregwhitworth: Made a table of results.
  gregwhitworth: What we tried to do, where it behaved more like
                 block, specified to be as block.
  gregwhitworth: If behaved more like inline, specified as inline.
  gregwhitworth: We don't have a strong pref.
  gregwhitworth: This is first thing to discuss.

  dgrogan: We talked about this in Chrome, don't want to defend our
           behavior. It doesn't make much sense.
  gregwhitworth: For firefox, we prefer firefox behavior.
  gregwhitworth: It seems like author did something wrong, so make
                 it more obvious it's wrong.

  dbaron: One question here is do you do anonymous box construction
          around these things
  gregwhitworth: no
  dbaron: Do you think some of these results are because of
          anonymous box construction?
  gregwhitworth: They don't create separate cells.
  fantasai: They wouldn't, if they did anonymous box construction
            ...?
  gregwhitworth: ...

  gregwhitworth: So besides Chrome having pref, anyone else?
  Rossen: So path forward is to fall back to Firefox's behavior?
  fantasai: Seems to me that making it block would make more sense.
  fremy: Wouldn't be Web-compatible
  gregwhitworth: Any objection to resolve on Firefox's behavior?

  RESOLVED: All internal table displays on replaced elements to
            behave as 'inline'.
  RESOLVED: Table falls back to block, inline-table falls back to
            inline.

  tantek: Point about anonymous box construction, are there tests ?
  gregwhitworth: I'm sure we have tests for it somewhere.
  tantek: ...

  fantasai: What do you mean anonymous boxes don't get constructed?
  dbaron: Do individual things create individual table cells, or
          group together into one cell
  dbaron: Do different things depending on row-group vs table-cel etc
  <Bert> recently wanted to do 'img {display: table-cell}' and was
         rather disappointed that it didn't work. :-(
  tantek: Based on what dbaron said, maybe just copy what Firefox
          does
  <Rossen> The resolution is specific about what the behavior is
  <Rossen> ... and it is not "just repeat what Firefox does"
  fantasai: If it's defined as "behave as inline", then anonymous
            box construction is defined.
  dbaron: Could do anonymous box before, rather than after treating
          as inline.
  fantasai: That would end up with improper table structures, which
            the spec does not allow.

min-width and percentages on table cells
----------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/607
          https://github.com/w3c/csswg-drafts/issues/607#issuecomment-317532741

  fremy: Next issue is min-width and percentages.
  fremy: Width behaves as min-width on tables, so it's a bit
         redundant.
  fremy: Browser generally ignore min-width of percentage, except
         Firefox.
  fremy: Would like to ignore percentages.
  dbaron: Would like to explain why percentage on min-width
          overrides width?
  dbaron: That's the general behavior of tables.
  dbaron: If a column has cell that's a length and cell that's a
          percentage, it ignores the length instead of the
          percentage.
  fremy: We should go with the more interop solution.

  fantasai: What about fixed tables?
  Rossen: What would be different?
  fantasai: Widths aren't "minimums" in fixed layout, they're
            honored and the content of the cell doesn't matter.
  fantasai: I would expect min-width and width to interact as for
            blocks in that case.
  <Rossen> Fixed layout for table cells is the same as in normal
  <Rossen> the only difference is that the overall column sizing and
           distribution is based on the first row only
  fremy: Our goal was to spec most interoperable behavior.
  fremy: So we should go with the non-Firefox behavior.
  fantasai: But what about fixed tables.
  Rossen: You do the layout based on the first row.
  fantasai: ...
  dbaron: fantasai is saying that in fixed table layout, you honor
          the width even if the contents overflow.
  fremy: It's true content overflows even in the first row, but
         that's not the problem.
  fremy: But if you have a table and you set 300px on the table and
         100px on the two columns, then you get 150px columns.
  fantasai: But we're talking about a different case.
  <Rossen> https://jsfiddle.net/gvco0t54/2/
  fremy: min-width % on fixed tables is ignore.

  glazou: Is your goal only interop?
  fremy: Yes, all browsers except Firefox ignore the min-width
  glazou: Yes, but you haven't considered the user's perspective.
          From the perspective of the Web author, why would you
          ignore min-width percentage only on these elements?
  fremy: I don't think there's a strong reason, except this is what
         browsers do.
  fremy: No good reason not to do it, except we have multiple impls.
  glazou: Web browsers can be wrong.
  glazou: It's not all browsers, there's at least one that
          implements it.
  astearns: It's been here for decades.
  glazou: It's been in Firefox for decades too.
  dbaron: We do get requests from authors to make these things work
          in tables
  dbaron: e.g. we get requests for max-width to work, but that's a
          bit harder.
  dbaron: It's weird to try to honor web author requests for new
          features, but here where we have the feature they want, we
          decide not to have it because it only works in one browser
          not four.
  Florian: We have evidence that the Web doesn't break if you don't
           support min-width, but we also have evidence that it
           doesn't break if you support it.
  gregwhitworth: The only reason we're working on this spec is
                 because we'll try to fix a bug and other sites will
                 break
  gregwhitworth: I guarantee you that there are websites that are
                 broken if 3/4 browsers have interop
  fantasai: ...

  fremy: In tables width works like min-width.
  fremy: The author doesn't lose anything here.
  fremy: I don't buy that we are bothering authors, if you want to
         use table you would learn to use width
  [fremy recites history of widths and HTML]
  glazou: The problem is with "authors should learn CSS'
  gregwhitworth: Your assertion is also that authors should test in
                 Firefox, and we know they don't.
  gregwhitworth: We put opening in the spec...
  gregwhitworth: 3 browsers are shipping this way, that's the
                de-facto standard
  fantasai: You have to consider what browsers do but also what
            makes sense.
  fremy: ... doesn't work.
  fremy: min-width and width are just widths.
  fantasai: Except in fixed tables.
  dbaron: I guess I'm OK with this, but please add tests to WPT
  * Bert thinks 'table-layout: true' would be quite nice, with width
         acting like width and min-width like min-width...
  glazou: I can live with it, but I find it regrettable.
  Rossen: Proposed that min-width: % is ignored on table cells.

  RESOLVED: Ignore percentage min-widths on table cells.

Resolution of percentage heights on children of table cells
-----------------------------------------------------------
  Github: https://github.com/w3c/csswg-drafts/issues/474#issuecomment-317544515

  fremy: Bit of history:
  fremy: 1st issue is that Firefox for a long time had very
         different usage for height on table cells.
  fremy: Height on table cells was applied on table cell not on row.
  fremy: But earlier we resolved that height on table cells is
         applied to the row.
  fremy: That change was not made in Firefox.
  fremy: For that reason, Firefox does very different resolution of
         percentage on table cells.
  fremy: All other browsers have similar behavior
  fremy: Which is 1st computation of layout, cell doesn't have any
         size, so percentage is treated as auto.
  fremy: Then you do a 2nd layout pass.
  fremy: In this case, all browsers will apply the percentage based
         on size assigned to the row
  fremy: Which is also assigned to all cells in the row.

  dbaron: Is it interoperable when you do the 2nd pass and when
          don't bother with 2nd pass?
  fremy: We always do 2nd pass when there's a percentage
  dbaron: That's not what I found.
  fremy: Testcases we wrote gave identical results.
  fremy: One exception unfortunately.
  fremy: In Chrome, if you set overflow: scroll on an element.
  fremy: Rule in CSS, if size is auto and you're allowed to scroll,
         automatic size is smallest size possible such that you
         don't need to scroll
  fremy: That's in general for CSS.
  fremy: This is what edge implements
  fremy: But not web compatible, because this is not how it works.
  fremy: In that case, in the 1st pass the auto size is considered
         0px
  fremy: So in 2nd pass you are going to have a scrollbar.
  fremy: The scroller will match the size of the rest of the cells
         in the row.
  fremy: In Firefox, because you resolve percentage based on the
         height set on the cell, you get exactly the same behavior
  fremy: because 1st pass in Firefox, you already know your
         percentage.
  fremy: Edge is outlier, because we don't give the same behavior.
  fremy: So we propose that we match Chrome behavior, because Web
         interop requires it.
  fremy: Canonical example is ToS.
  fremy: People set height 100% on scrollabe ToS, and then button to
         accept in the next row.
  fremy: In Edge the 1st row blows up and gets as big as needed to
         contain entire ToS.
  fremy: So we would like to resolve on doing what Chrome is doing.
  fremy: If you're allowed to overflow, your automatic size will be
         0px.
  fantasai: And that's for a table cell?
  fremy: Percentage is set on the child of the table cell

  <dbaron> second testcase in https://dbaron.org/css/test/2006/
           percent-height-in-tables
  dbaron: You claimed that you always do 2nd pass, so I loaded
          testcase and loaded in Chrome
  dbaron: And I got as far as the 2nd testcase in the set before
          finding a contradiction with your assertion.
  <dbaron> <table border><tr>
  <dbaron> <td><div style="height: 25%">25% height div</div></td>
  <dbaron> <td>text</td>
  <dbaron> </tr></table>
  fremy: Percent doesn't get applied.
  fremy: Percent inside auto container is ignored.
  dbaron: Except that's not how it works in tables.
  dbaron: there are things in tables that can make things non-auto
          height, that don't match that CSS rule.
  fremy: Rule in CSS is extended in css-tables-3
  ???
  fremy: You need at least one table element with a height defined
  fremy: that isn't a percentage.
  dbaron: If you define height on table itself, then ...
  fremy: "It is appropriate to resolve percentage heights on direct
         children of a table cell if the cell is considered to have
         its height specified explicitly or the child is abspos, see
         CSS2. It is further clarified that a cell is considered to
         have its height specified explicitly if the computed height
         of the cell or any of its table ancestors is a length or
         percentage and that length does not "beheave as auto""
  fremy: Cases where we don't have interop are on tbody we don't all
         behave the same way
  fremy: but agreed we'd behave the same way on tbody, so fixing
         that issue every browser should behave the same.

  Rossen: Interop with firefox?
  fremy: Firefox has a different model.
  dbaron: We have tests if any cell in a row has a specified height.
  dbaron: The code that decides whether heights are definite looks
          at whether there's any cell in the row that has its height
          specified
  dbaron: So I wouldn't blow that all off as having not implemented
          that decision.

  Rossen: So what is the proposed resolution to this issue?
  fremy: The stuff I just quoted:
  fremy: "During first pass, percentages are resolved as auto,
         except if they are height-related and used on a scrollable
         box, in which case they resolve as 0px. Edge changes its
         behavior, as well as Firefox once it fix the other bug."
  <fantasai> https://github.com/w3c/csswg-drafts/issues/474

  fremy: To explain behavior in dbaron's testcase
  fremy: ... that's a scroll-snap option, not fragmentation
  fremy: Like other places in CSS, you don't apply percentages if
         you're in auto height. For tables it's more complex, looks
         at table ancestors.
  dbaron: Is this also interoperable when tables are paginated for
          printing?
  dbaron: Because I know that the behavior is different when tables
          are paginated.
  fremy: I haven't tried printing tables...
  fremy: Why would it be different?
  dbaron: Shouldn't be but in Gecko it is.
  fantasai: Consideration for printing, maybe. When printing you
            can't scroll, so if you can size the item to show all
            its content that's better.

  Rossen: So should we resolve?
  dbaron: I'm still trying to understand some of these cases...
  dbaron: I'm okay with resolution for now, if I think it's wrong
          I'll reopen
  * fantasai defers to dbaron
  Rossen: Objections?

  RESOLVED: Accept proposed resolution for #474

  dbaron: afaict, 1st testcase that I found a difference between FF
          and Chrome is where FF does what you say and Chrome doesn't
  <dbaron> <table border><tr><td>
  <dbaron>  blah<br>
  <dbaron>  <div style="height: 50%">hello</div>
  <dbaron>  <table style="height: 50%" cellpadding="0"
            cellspacing="0">
            <tr><td>hello</td></tr></table>
  <dbaron>   blah<br>
  <dbaron>   blah<br>
  <dbaron> </td><td height="200"></td></tr></table>
  dbaron: There's an outer table
  dbaron: Inside of it there's two cells
  dbaron: 2nd one is empty but has explicit height of 200px.
  dbaron: In your model means row has 200px definite height
  dbaron: other cell has ...
  dbaron: In Gecko, we honor the height 50% on the div
  dbaron: and also on the table but the table overflows the cell
          (??????).
  fremy: There is no reason for a table to behave differently from a
         block here.
  dbaron: So the thing we just resolved on is not what Chrome and
          Edge do
  dbaron: matches Firefox better
  dbaron: Which I'm okay with :)
  dbaron: testcase is the 2nd one after the horizontal rule.
  ...
  fremy: You look for a definite height on the ancestors
  fremy: ? does not apply
  dbaron: ...
  dbaron: ok whatever.

Excess width distribution in fixed layout
-----------------------------------------
  GitHub: https://github.com/w3c/csswg-drafts/issues/484#issuecomment-317943064

  gregwhitworth: Doing excess width distribution of space
  gregwhitworth: Edge and Mozilla render the same
  gregwhitworth: We do same distribution as non-fixed mode
  gregwhitworth: We wanted an actual resolution
  gregwhitworth: Chrome team said they're ok with the change
  dgrogan: we're okay with caveat that we check web compat data.

Visibility collapse: clip or not to clip
----------------------------------------

  gregwhitworth: Talked about this at TPAC.
  gregwhitworth: Specified Edge behavior currently
  gregwhitworth: To not get rid of data
  gregwhitworth: But when author asks for visibility collapse on
                 column or row
  gregwhitworth: They've asked that row or column to be gone.
  gregwhitworth: If you have a spanning cell that goes into the
                 collapsed column/row, then clipped to visible
                 columns/rows.
  fantasai: I think that's what's in the spec. Not really that great.
  gregwhitworth: FF overflows the content.
  gregwhitworth: Behind a flag in Chrome.
  dgrogan: We also clip to border box. Behind a flag.
  fantasai: I think there were two options we were considering here,
            and overflowing was definitely not one of them
  dbaron: This would ...

  <gregwhitworth> https://jsfiddle.net/v23h0338/
  [gregwhitworth explain the demo]

  dbaron: Suppose before collapsing you have a cell here and it's
          part of 3 rows that are conceptually here.
  dbaron: Cell has some content which overflows in theses various
          directions
  dbaron: And then you collapse the middle one.
  dbaron: When it's not collapsed, these overflow visibly
  dbaron: Are you saying when its collapsed, we only draw...
  dbaron: I'm collapsing the middle row.
  gregwhitworth: You only draw what's in the first / third cells
  [drawing on whiteboard, behind Bert, can't be captured for minutes]

  fremy: If you're clipping the middle row, do you draw the content
         in the 1st and 3rd rows, or do you show the 1st and 2nd
         rows and clip out the end?
  dbaron: Once you collapse the middle row, you're clip everything
          that overflows the top and you're clip out stuff [over
          there, over there nobody is telling me what that means and
          I can't see it]
  gregwhitworth: This is an edge case.
  gregwhitworth: Haven't seen people hiding rows/cols except in data
                 grids, and ...
  gregwhitworth: What you're proposing is complicated.
  dbaron: If it's not a use case why clip anything?
  * fantasai wants a link to the previous minutes
  Rossen: That is the use case.
  Rossen: Your primary purpose was to have a layout.
  Rossen: We go to extreme lengths to avoid overflow
  Rossen: To make sure that all content is displayed in all cells.
  Rossen: Then you have user facing behavior that allow ppl to
          collapse things away, purposefully make things appear or
          disappear.
  Rossen: When they explicitly asked for something to disappear, and
          you continue to show them what disappeared, weird no?
  dbaron: I just meant don't clip this cell.

  gregwhitworth: In dbaron's example ...
  <gregwhitworth> https://jsfiddle.net/dgrogan/9uduq99L/3/
  gregwhitworth: If you collapse
  gregwhitworth: we end up clipping in both axes.
  gregwhitworth: My statement to dbaron is, he forcefully asked for
                 no wraps which will overflow.
  gregwhitworth: I don't see circumstances where it isn't primarily
                 the excel-based scenario.
  gregwhitworth: This is the most performant way to accomplish,
                 which is clipping to bounding box.
  gregwhitworth: Weird side effect.
  dbaron: Proposal is that if you have a cell that spans some
          collapsed rows or columns
  dbaron: that cell clips its content to its resulting bounds.
  gregwhitworth: Yes.

  RESOLVED: Cells spanning collapsed rows/columns are clipped to
            their resulting bounds (in both axes).

  Rossen: Goal of work on this spec is to minimize interop pain
  Rossen: not trying to rewrite history.
  Rossen: Issues aren't introduced, we're trying to write out the
          path of least resistance.

  * fantasai found the minutes to last time we discussed
             https://lists.w3.org/Archives/Public/www-style/2016Nov/0069.html

  <dbaron> Gecko bugs on implementing the results of our previous
           discussion on tables:
https://bugzilla.mozilla.org/buglist.cgi?bug_id=1386981%2C1386982%2C1386983%2C1386985&list_id=13708350
.
           If it's not in that list, I don't know about it.
Received on Tuesday, 29 August 2017 21:55:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 29 August 2017 21:55:08 UTC