- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 15 Nov 2016 20:56:18 -0500
- 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.
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/tpac-2016#agenda
Present:
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
Regrets:
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
speccing.
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
happen.
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
after.
* 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
well.
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
text.
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
work?
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
background.
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
way.
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
blocks.
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
editorial.
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
cells.
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
resolved.
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
pass.
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
one.
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
expectations.
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
support.
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
options:
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