- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 29 Aug 2017 17:54:12 -0400
- 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