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

[CSSWG] Minutes Lisbon F2F 2016-09-19 Part I: CSS Tables Level 3 [css-tables]

From: Dael Jackson <daelcss@gmail.com>
Date: Tue, 15 Nov 2016 20:56:18 -0500
Message-ID: <CADhPm3sNai_=vTvU=4z7ZyYLijfaK1fNG1m_LJS0Yys69UD15w@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 Tables Level 3

  - RESOLVED: Keep note from CSS2.1 for caption-side, add left &
              right values to note, move side captions to next level.
  - RESOLVED: Anonymous inline boxes which contain only white space,
              are the first and/or last child of a tabular
              container, and whose immediate sibling (if any) is a
              table-non-root box, are treated as if they had
              display: none.
  - RESOLVED: Gecko to review fixup re-write, then add note to new
              text and accept.
  - gregwhitworth will take the feedback on table-track &
      table-track-grouping elements to make a new paint model.
  - table-wrapper box and captions should be a side topic with
      interested parties before being a topic for the whole WG.
  - A note will be added so the change around track merging to
      indicate the change should product the exact same behavior and
      is just editorial.
  - dbaron felt that there was a historical compat reason why the
      proposed change to percentage resolution wouldn't work, so the
      issue was assigned to him to look into further.
  - RESOLVED: Drop border-radius support on table root for tables in
              collapsed mode.
  - RESOLVED: Specify gecko's behavior for height on table-row-group.
  - min-height on table-row will be specced but marked as at-risk.
  - gregwhitworth proposed four options for correcting the behavior
      of visibility: collapse:
      A: The cell's contents are clipped (What Safari and Edge
         currently do.
      B: The cell's contents overflow (What Gecko does).
      C: You don't collapse the track since the spanning cell is in
         the track.
      D: You make this a layout change and you re-layout the cell in
         the new constraint space.
      - fantasai added a fifth option to make it contingent on
          overflow property where if overflow is visible you
          re-layout and if it's not you clip.
      - gregwhitworth will spend more time thinking through the
          options and come back to the group.


Agenda: https://wiki.csswg.org/planning/tpac-2016#agenda

  Rossen Atanassov - Microsoft
  Tab Atkins - Google
  L. David Baron - Mozilla
  Brian Birtles - Mozilla
  Bert Bos - W3C
  Rick Byers - Google
  Tantek Çelik - Mozilla
  Dave Cramer - Hachette
  Emil A Eklund - Google
  Elika J Etemad - Invited Expert
  Daniel Glazman - Disruptive Innovations
  Jihye Hong - LG Electronics
  Dean Jackson - Apple
  Pierre-Anthony Lemieux - supported by MovieLabs
  Chris Lilley - W3C
  Myles C. Maxfield - Apple
  Theresa O'Connor - Apple
  Simon Pieters - Opera
  Liam Quin - W3C
  Manuel Rego - Igalia
  François Remy - Microsoft
  Florian Rivoal - Vivliostyle Inc.
  Andrey Rybka - Bloomberg
  Shintaro Sakahara - BPS
  Hiroshi Sakakibara - BPS
  Simon Sapin - Mozilla
  Geoffrey Sneddon - Invited Expert
  Alan Stearns - Adobe
  Shane Stephens - Google
  Surma - Google
  Takamasa - BPS
  Lea Verou - Invited Expert
  Jet Villegas - Mozilla
  Mark Watson - Netflix
  Greg Whitworth - Microsoft
  Steve Zilles - Adobe

  Rachel Andrew - Invited Expert
  Dael Jackson - Invited Expert

Scribe: shane

CSS Tables Level 3

Firefox table caption left and right for caption-side
  <gregwhitworth> https://github.com/w3c/csswg-drafts/issues/497

  gregwhitworth: I'll start off with an easy one.
  gregwhitworth: One thing that covers all the table discussions -
                 we're going for interop, nothing new, fancy, or
                 that makes sense.
  gregwhitworth: Except when there's absolutely no interop.
  gregwhitworth: There we have some new ideas we'd like to discuss.

  gregwhitworth: This one is pretty straightforwards.
  gregwhitworth: caption-side property for left or right. Mozilla
                 implements but nobody else does. It's useful but
                 would like to push to next level.
  fantasai: Should copy the note from CSS2.1
  dbaron: This was in CSS2.0
  dbaron: So it's effectively already been published as at least CR.
  gregwhitworth: OK that's fine. I just don't want to go through
  fantasai: Note from 2.1 doesn't cover left and right. Need to add
            left and right to that.

  gregwhitworth: Are you steadfast in keeping?
  zcorpan: Is anyone else going to implement side caption?
  fantasai: It's more important with vertical text available.
  (Side captions are awkward without vertical text.)
  dbaron: Want to keep unless we remove table captions completely.
  dbaron: Captions are a disastrous feature but these values mitigate.

  Florian: When we throw in vertical writing modes and logical names
           do we need to have them?
  gregwhitworth: With tables don't *need* to have anything.
  gregwhitworth: Does anyone else plan to implement?
  [ a resounding silence ]

  jcraig: Be cautious how you announce any property changes with
          anything related to accessibility - caption  is the
          official accessible labeling element for tables.

  RESOLVED: Keep note from CSS2.1 for caption-side, add left & right
            values to note, move side captions to next level.

Fixup collapsible whitespace

  frremy: Next issue is about collapsible whitespace.
  frremy: During table fixup, collapsible whitespace is mostly
          removed per-spec. There is a difference in the way
          browsers do this.
  frremy: Firefox matches CSS2.1 accurately.
  frremy: Chrome (& webkit?) have simplistic behavior - just drop it.
  frremy: So issue is if you have a table row element that contains
          another table row.
  frremy: This is invalid markup but there's a fixup.
  frremy: Rules for collapsing whitespace are very specific - should
          not collapse because there's some table elements being
          inserted inside.
  frremy: But tricky because the elements haven't been inserted yet.
  frremy: Proposal is just use display type of boxes to decide
          whether to collapse whitespace or not.
  frremy: Reasons: (1) easier to implement. (2) mostly doesn't have
          any difference.
  frremy: Only has visible impact if you specify whitespace: [missed]
  frremy: By default parser will fix up your markup for you but if
          you directly insert elements into the DOM that won't

  dbaron: Are you saying to change the spec from matching gecko to
          matching Edge?
  frremy: No we are going to match gecko.
  frremy: In Edge we do fixup, then go back and add spaces to match
          specified behavior.
  frremy: We would like Chrome to get interop as well.
  eae: That makes a lot of sense to us.
  frremy: So basically saying that we're going to do whitespace
          collapse *before* the fixup that inserts elements, not
  * zcorpan doesn't see any difference between gecko and chromium
  <zcorpan> ok the difference is in https://jsfiddle.net/nbh4r9u8/2/

  <gregwhitworth> Proposed resolution: Anonymous inline boxes which
                  contain only white space, are the first and/or
                  last child of a tabular container, and whose
                  immediate sibling (if any) is a table-non-root
                  box, are treated as if they had display: none.
  fantasai: If there's a change from 2.1 then you need to fix 2.1 as
  Florian: But you haven't found a valid use case for nested tables
           with whitespace pre.
  astearns: Does anyone object to this proposal? No? Resolved.

  RESOLVED: Anonymous inline boxes which contain only white space,
            are the first and/or last child of a tabular container,
            and whose immediate sibling (if any) is a table-non-root
            box, are treated as if they had display: none.

Fixup rewrite

  <gregwhitworth> https://github.com/w3c/csswg-drafts/issues/466
  gregwhitworth: The next one may not need a resolution.
  gregwhitworth: We rewrote fixup because it was horrible. Need a
                 PhD in mathematics. I drove myself mad.
  gregwhitworth: We rewrote to be more concise, shouldn't change
                 behavior. Could the people who wrote it please
                 confirm? Would like a resolution to accept the new
  dbaron: I would like bz to review
  fantasai: Add a note that says if there's any differences from 2.1
            then there's an error that needs to be reported
  RESOLVED: gecko to review, then add note to new text and accept

What CSS is applicable to table-track & table-track-grouping elements

  <gregwhitworth> https://github.com/w3c/csswg-drafts/issues/469
  gregwhitworth: Next. What CSS is applicable to table-track &
                 table-track-grouping elements?
  gregwhitworth: Everyone does this differently. Want to concentrate
                 on what properties are whitelisted.
  dbaron: For width & height - those only work in the appropriate
          dimension, right?
  dbaron: position: relative is weird. There are three different
          things that position: relative does. Different browsers
          support different combos. (1) establishes containing block
          for abspos descendants. (2) moves the thing. (3) messes
          with z-index ordering
  dbaron: The containing block one is interoperable (I think)

  <gregwhitworth> https://jsfiddle.net/5um10zts/
  gregwhitworth: Don't want to get too hung up on that. Not only
                 test case.
  fantasai: Blink most recently rewrote background impl. Will render
            much closer to Gecko post this.

  fantasai: Not opposed to having a whitelist on tables.
  fantasai: Each individual property should be considered
  TabAtkins: I'm kinda against a whitelist, other than for layout
             properties. Why don't the rest of the properties just
  dbaron: One of the issues there is the way table backgrounds &
          borders interact with stuff.
  dbaron: In some ways can be addressed by defining the way
          backgrounds & borders work more precisely.
  dbaron: e.g. sometimes border mightn't apply to row's own
  frremy: Want to whitelist for now to let these things stabilize.
  frremy: Better to start from a small subset.
  TabAtkins: But the definitions should just pop out of whatever's
             been written.
  <dbaron> I agree with Tab.

  Florian: Regardless of the color of the list, people are just
           going to rely on what works.
  <fantasai> +1 to Florian
  gregwhitworth: Not leaving anything undefined. That's the point.
  Florian: Yeah but you can't rely on expanding a set later, because
           people will just rely on it not working.

  TabAtkins: Just a whitelist - OK. But opposite of that is "these
             properties are banned and guaranteed not to work"
  TabAtkins: Probably not going to do that.
  TabAtkins: Instead should make sure everything is defined
             properly, then we can just allow any non-layout
             properties without doing anything special.
  frremy: Do we actually want to be able to do this? We'll need to
          change implementations.
  TabAtkins: Will need to change impls anyway at some point.
  Florian: If you want to leave it undefined at this level, that's
           OK. But can't write down that 'it should not work'
           because will need to change impls, then can't make it
           work later.
  gregwhitworth: ok we have an action from the group. Describe a new
                 paint model.

table-wrapper box and captions

  <frremy> https://github.com/w3c/csswg-drafts/issues/471
  frremy: Next issue. Captions in CSS2.1 inside tables
  frremy: Are [missed]
  frremy: Gecko does it, but that's the only browser that works this
  fantasai: What do you mean by inside the table
  <zcorpan> <table><caption>
  frremy: If you have a caption inside a table (in markup).
  gregwhitworth: Please look at issue.
  gregwhitworth: If you have a table, with a div on top of the table.
  gregwhitworth: In gecko, it's acting as if it's a block box
                 outside of the table.
  gregwhitworth: Everyone else sizes it along with the table.
  frremy: Gecko is laying out caption as if table did not exist.
  frremy: CSS2.1 resolved that width of table should increase to
          match caption.
  frremy: Makes no sense if both depend on each other.
  frremy: Better to just specify that caption is being laid out as
          child of table.
  fantasai: Can't do that. If there's a border, caption is not
            inside that.
  frremy: Position absolute elements can be outside border area.
  fantasai: But caption takes up space.

  Florian: So you're suggesting a new layout mode that only applies
           to captions?
  Florian: So percentage would resolve against table, intrinsic
           width of table would take caption into account, etc..
  frremy: Yes. A lot of the CSS2.1 spec already implies this.
  dbaron: Percentage widths are normally resolved according to
          containing block.
  dbaron: Table boxes and table wrapper boxes are not containing
  fantasai: Whole point of table wrapper box is to put a border
            around the table and put the caption outside it.
  [ divers alarums ]
  <fantasai> https://www.w3.org/TR/CSS21/tables.html#model
  <fantasai> "The width of the table wrapper box is the border-edge
             width of the table box inside it, as described by
             section 17.5.2."
  <fantasai> What exactly is the problem here?

  [ decided that a small group should break out to discuss this. ]

  <zcorpan> dbaron gecko doesn't comply with the above, correct?
  <dbaron> zcorpan, not sure -- there were a lot of changes in 2.1,
           and we may well not have implemented all of them
  * dbaron also thinks table captions were a mistake
  <dbaron> since the results they produce aren't actually what
           anybody wants
  <zcorpan> (fantasai sayeth table wrapper was intended to be a
            containing block)
  <dbaron> if the table wrapper box were a containing block, I think
           that would break percentage width on <table>
  <dbaron> fantasai ^
  <fantasai> dbaron, no there's an exception for that
  <fantasai> "Percentages on 'width' and 'height' on the table are
             relative to the table wrapper box's containing block,
             not the table wrapper box itself. "
  <fantasai> dbaron, if it wasn't intended to be a containing block,
             that sentence would not have been necessary
  <dbaron> fantasai, I think that assumes the spec was written all
           at once by a single author who remembered all the other
           parts of the spec

Track merging

  <gregwhitworth> https://github.com/w3c/csswg-drafts/issues/473
  gregwhitworth: Next topic.
  gregwhitworth: In 2.1 there was a bunch of text about if this is a
                 valid cell, do x, if this is a row do x, etc.
  gregwhitworth: We wrote something that merges the empty tracks
                 together so we don't need to do all those checks.
  gregwhitworth: Shouldn't see any implementation difference. Just
  Florian: Put the note saying 'this is supposed to be the same as
           that, if not then tell us'
  Florian: The note distinguishes these sections from the sections
           where there are behavior changes.

Percentage resolution

  frremy: Next. Percentage resolution.
  frremy: This is for elements that are direct children of table
  frremy: If you specify relative width, how do percentages resolve?
  frremy: Tables have multiple layout passes, need to specify for
          each of these.
  frremy: Not interoperable.

  dbaron: Interesting case is height, right?
  frremy: Mainly, some width issues too.
  frremy: Mainly writing modes related.
  gregwhitworth: Yeah, mainly it's height that is the issue.

  frremy: Gecko does not resolve percentage, treats as auto
  dbaron: No, we sometimes resolve percentage height.
  frremy: Edge & Chrome treat as auto on first layout pass, then in
          second layout pass when size is known the percentage is
  frremy: This is used to size objects based on size of rows.
  dbaron: Last time I looked at this (10 yrs ago) there was a web
          compat requirement that the percentages be resolved in
          some cases, not be resolved in some cases, and no strong
          requirement in some cases.
  frremy: Chrome also has different behaviour. If overflow: scroll
          is specified, then height resolves as 0 in first layout
  frremy: Some sites rely on this.
  frremy: Causes a scroll bar rather than big cell.
  frremy: Suggestion is to specify Chrome's behavior as the correct

  dbaron: I think there are still some cases where there's a
          requirement not to resolve them in second pass
  dbaron: e.g. what if table has a height and one row has a height
          but not the other.
  dbaron: How do percentages resolve in row with no height.
  frremy: Can resolve in second layout pass based on heights in
          first pass.
  dbaron: I believe there are web compat cases where it's required
          not to do this.
  gregwhitworth: Use case we've seen is license agreements in table.
                 Big chunk of text with height set to 75%. Button at
                 the bottom isn't accessible in Edge, but scrollbar
                 gives access in Chrome.
  frremy: Works in Firefox because reasons.

  Rossen: dbaron, the question about interoperability requirements
          of 10yrs ago is, do these still apply today?
  dbaron: Would like to look into this more?
  <dbaron> http://dbaron.org/css/test/2006/percent-height-in-tables
  gregwhitworth: Can we assign issue to you then?
  <astearns> dbaron: https://github.com/w3c/csswg-drafts/issues/474

border-radius in collapsed mode

  <gregwhitworth> https://github.com/w3c/csswg-drafts/issues/475
  gregwhitworth: Next. Border radius in collapsed mode.
  gregwhitworth: Need to figure out what to do with border radius
                 when in collapsed mode.
  gregwhitworth: Edge is only browser that implements this.
  gregwhitworth: There is an interesting test case where you apply
                 drop shadow. Everyone propagates radius into shadow
                 but only Edge shows radius on table.
  gregwhitworth: Proposing we drop this behavior - add into spec
                 that border-radius doesn't work on tables in
                 collapsed mode.
  eae: We're fine with that.
  dbaron: Us too.
  fantasai: Would need to update CSS3 backgrounds spec.

  RESOLVED: Drop border-radius support on table root for tables in
            collapsed mode.

Height on a table-row-group

  <frremy> https://github.com/w3c/csswg-drafts/issues/476
  frremy: Height on a table-row-group.
  frremy: There's no interop.
  frremy: It's so broken that nobody can rely on this. Chrome
          ignores. Firefox implements and distributes height to
          rows. Edge puts same height on every single row.
  dbaron: HTML4 specified that if you put width on a column group it
          applies that width to every column in the group,
  dbaron: but it didn't say anything like that for rows.

  frremy: Proposal is to either do what Firefox is doing, or specify
          that we don't care about this height.
  eae: Could go either way.
  frremy: Then let's spec Firefox behavior. Better match for author

  RESOLVED: Specify gecko's behavior for height on table-row-group

min-height on a table-row

  <gregwhitworth> https://github.com/w3c/csswg-drafts/issues/477
  gregwhitworth: min-height on table-row
  gregwhitworth: Currently only edge supports.
  gregwhitworth: Authors probably expect this but blink/gecko don't
  gregwhitworth: Proposing to match other browsers and drop this.
  gregwhitworth: Unless other browsers want to implement?

  dbaron: It is a somewhat frequently requested feature. min-height
          shouldn't be that hard.
  dbaron: I could go either way.
  dbaron: probably can't implement in the short term.
  fantasai: Spec it and mark at risk.

visibility: collapse

  <astearns> https://github.com/w3c/csswg-drafts/issues/478
  <gregwhitworth> https://jsfiddle.net/wj5tjvcy/
  gregwhitworth: visibility: collapse
  gregwhitworth: Blink doesn't implement.
  gregwhitworth: Big compat risk.
  gregwhitworth: Should behave same as visibility: hidden.
  gregwhitworth: Seems to actually modify layout somewhat. There's 4
  gregwhitworth: A: The cell's contents are clipped (What Safari and
                    Edge currently do.
  gregwhitworth: B: The cell's contents overflow (What Gecko does).
  gregwhitworth: C: You don't collapse the track since the spanning
                    cell is in the track.
  gregwhitworth: D: You make this a layout change and you re-layout
                    the cell in the new constraint space.

  dbaron: Proposed options seems unrelated to rest of issue.
  dbaron: Is issue talking about what happens if you apply
          visibility: collapse to rows or cells?
  dbaron: Proposed options seems to be cells, everything else row.
  frremy: Rows. It's when there are cells that span.
  dbaron: I think A is correct behavior per spec, but getting into
          this situation doesn't make any sense.
  fantasai: Current behavior is useless, nobody wants that. Should
            provide something that is usable.
  gregwhitworth: I think authors would expect re-layout.
  dbaron: Some cases where you want to be able to hide things
          without doing re-layout.
  gregwhitworth: But you're already relaying out table wrapper box.
  dbaron: But nothing inside the table changes size.

  fantasai: Could make it contingent on overflow property?
  fantasai: If overflow is visible, then do re-layout
  fantasai: Otherwise clip.
  frremy: Would rather just choose one thing
  fantasai: But this gives both options in a sensible way.
  frremy: Spec is defined so visibility collapse doesn't cause
          re-layout of table
  frremy: but I doubt anyone actually avoids layout.
  frremy: Not convinced there's performance benefit.
  Florian: But from usability POV, hiding some rows shouldn't cause
           everything else to jiggle.
  Florian: Not an implementation thing.

  dbaron: One of the effects that can happen is that if you have a
          row and one of the cells in the row significantly impacts
          width, then collapsing the row causes all of the cells to
          change width, and scroll shifts accordingly.
  frremy: If you have a cell that spans multiple columns with
          centered text.
  frremy: Collapse center columns [missed] and can't see anything
          any more.

  Florian: I agree with fantasai's suggestion
  Florian: If overflow is visible on the cell then do re-layout,
           otherwise don't.
  Rossen: So if it's auto then you will be introducing a scrollbar.
  Florian: I think so,
  Rossen: How are you going to address this? It's a layout issue but
          you don't want to re-layout.

  gregwhitworth: So where do we stand?
  gregwhitworth: We'll think about it and come back for a resolution.
  fantasai: If collapsing things and spanning cell contributes
            something, might want to subtract out part of that.

  <br duration=15min>
Received on Wednesday, 16 November 2016 01:57:22 UTC

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