- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 4 Dec 2017 19:28:35 -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 Backgrounds
---------------
- RESOLVED: Text color has no effect on background-clip.
- RESOLVED: text-decorations should be considered as part of the
text shape for background-clip purposes.
CSS Grid
--------
- RESOLVED: Option D: percentage gaps in shrink-wrapped grids
contribute 0 and layout as 0. (Issue #509:
https://github.com/w3c/csswg-drafts/issues/509 )
- RESOLVED: Percentage tracks sized as percentage resolve the same
way for columns and rows, which involves a second layout
pass in some cases.
- The request for "Equal Gutters in both axes" feature
(https://github.com/w3c/csswg-drafts/issues/1116 ) was presented
and those interested continued talking over lunch.
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/tpac-2017#proposed-agenda
Scribe: TabAtkins
CSS Backgrounds
===============
background-flip and text-underline
----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/900
fremy: It seems we always consider underlines as part of the text
shape.
fremy: So for background-clip: text, you draw the background only
under the text of the element. Intention is you set the text
to transparent, so the background layer fills in for the text.
fremy: In Firefox though, the color of the text doesn't matter for
the shape, but the transparency of the underline is applied
as an opacity on the background.
fremy: So if people use color:transparent, the underline is too, and
the background under the underline becomes transparent.
fremy: I don't think this makes sense... Edge is not doing this.
TabAtkins: This sounds like accidentally over-applying an opacity
filter...
fremy: I think it would be good to specify the behavior.
smfr: Related, the fill and stroke module will someday handle this,
right? Should we even specify this, given that it'll be
replaced?
(We need to spec this for Web-compat; it's going in an appendix.)
TabAtkins: So back to François's point - settle that text color
shouldn't have any effect on background
fremy: And that text-decoration should be included as part of the
text shape.
RESOLVED: text color has no effect on background-clip.
RESOLVED: text-decorations should be considered as part of the text
shape for background-clip purposes.
<AmeliaBR> I would definitely expect background-clip: text to
include the underline area. Looks like browsers do that
even when the underline is from a parent element:
https://jsfiddle.net/yLwq77ss/2/
CSS Transform
=============
Transforms 3d contexts
----------------------
github: https://github.com/w3c/csswg-drafts/issues/1944
trchen: In CSS, having a stacking context does not guarantee an
element to be a containing block for every descendant
element.
trchen: And being a containing block doesn't imply being a stacking
context.
trchen: 3d context is a stacking concept - it decides which planes
need to be 3d-sorted against each other
trchen: But at the same time we define 3d context of elements based
on containing block
trchen: Causes "3d context penetration problem"
trchen: Element can be flattened by another element that's not part
of its containing block chain
trchen: We're working on a project in Blink to simplify compositing
code, found some ill-defined corner cases
trchen: Planning to have a breakout session tomorrow afternoon?
smfr: Would like to have a browser vendor rep from each for the
breakout tomorrow.
[discuss details of the breakout]
CSS Grid
========
scribe: bkardell
Percentages gaps and intrinsic size
-----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/509
<fantasai> all options for percentage gaps listed in
https://github.com/w3c/csswg-drafts/issues/509#issuecomment-333236096
A = contribute back-computation ratio, resolve as percent
B = contribute zero, resolve as percent
C = contribute auto, resolve as percent
D = contribute zero, resolve as zero
E = contribute auto, resolve as auto
F = contribute zero, resolve as percent (for column-gap) or zero
(for row-gap)
fantasai: I think we agreed to eliminate C and E.
lajava: We have two different issues
lajava: We have undefined width and height
lajava: The issue we are discussing now is for grid gaps
lajava: fantasai listed different options after some discussion
lajava: Our discussion from blink/webkit: we prefer to keep existing
behavior: keep treating them as 0 for intrinsic size/layout
(i.e. lajava is requesting option F)
lajava: In the issue there is an explanation
lajava: We think that what happens in Firefox is broken with that
approach
lajava: If we don't do that for margins, we should be consistent
lajava: We have to decide from the options fantasai listed and agree
to do it the same
fantasai: My concern with f) in that list is that it has been a goal
of grid to have symmetric behavior in both axis
lajava: Related to that, we think there are issues to do that with
tracks as well
lajava: It's not impossible, but there is no browser doing that
lajava: All of the browsers consider cols and rows differently
lajava: so I'm not sure that should be important in solving for gaps
- perhaps we decide not to do it for the tracks
rachelandrew: There are issues teaching this to authors. Generally
people understand when you say this will resolve to 0,
the goal of having symmetrical gaps would be nice.
rachelandrew: If we can't have them symmetrical, having the rows go
to 0 makes sense.
lajava: I agree with that
dholbert: Are we just talking about intrinsically resized grids
lajava: d) tries to resolve the same way in both axis
rachelandrew: If we didn't have percentage gaps, if we changed
existing behavior ...?
<astearns> so rachelandrew is for F, not D
jensimmons: If you had that situation in the inline direction where
you didn't have an explicit width those gaps would also
resolve to 0, it's just not a common use case
jensimmons: If you said you want this to be 100x100px - in both
directions the gap would be 10
jennsimmons: I don't know if what you are describing is that the
algorithm is doing the math diff?
Scribe: frremy
lajava: There are two reasons we don't want back compute for the gaps
lajava: Backcomputing when the percentages are close or bigger than
100% the solution isn't that great
lajava: The second reason is that we decided not to do that for
margins, and so we would like to work the same for gaps
dholbert: Well, on that, I think margins are just a legacy thing
TabAtkins: I would be opposed to anything that could yield to sizes
bigger than the max size a browser can allocate
TabAtkins: It's very easy to end up in such cases with back-computing
Rossen: +1
Rossen: For this issue, the currently listed options are on the
screen, and the github
<frremy> Igalia would prefer B, D, or F
lajava: Yes
Rossen: Edge's preference would be to keep symmetry
Rossen: If resolving in one of the pass is not possible, though,
resolving to zero as usual is fine
Rossen: F is therefore not a great solution
Rossen: Between B and D, I would like to hear more opinions
TabAtkins: B is expensive, there might be fragmentation issues
Rossen: Which fragmentation issue?
TabAtkins: Could contribute, but we could discuss this later when
this comes up
dholbert: What would happen for auto grid with percent columns?
Rossen: Let's say you have a 2x2 grid that has to shrink in both
dimensions
<gregwhitworth> here's the example Rossen is stating:
http://jsbin.com/lalayakuxe/1/edit?html,css,output
Rossen: If that grid had a size, we would compute properly and
things would be symmetric
Rossen: but if the grid is floated, we will have to compute
percentages has zero to find the size of the float
Rossen: but in the second pass, we are given a choice
Rossen: Either add the gaps and overflow slightly
Rossen: or you can continue to resolve to zero
Rossen: This is the difference between B and D
lajava: Igalia doesn't mind B but the problem is that if you are
auto and overflow by default, that seems counter-intuitive
Rossen: The only con of D seems that some authors could be unhappy
about this
Rossen: but I would like to make sure that is really the case
Rossen: because authors can still use other units, or give a
specified size to the grid.
fantasai: (reading a summary of the A-F proposals)
<fantasai> A = contribute back-computation ratio, resolve as percent
<fantasai> B = contribute zero, resolve as percent
<fantasai> NOT C = contribute auto, resolve as percent
<fantasai> D = contribute zero, resolve as zero
<fantasai> NOT E = contribute auto, resolve as auto
<fantasai> F = contribute zero, resolve cols as percent & rows as
zero
<fantasai> NOTE: only for intrinsically-sized grids explicit /
stretch-fit grids always resolve
<fantasai> Cons:
<fantasai> A = contribution can explode grid
<fantasai> B = unhappy authors with overflowing grids
<fantasai> C = super broken
<fantasai> D = unhappy authors missing % column-gap?
<fantasai> E = even more broken
<fantasai> F = B + D + asymmetrical
[Rossen + florian discussing why A cannot be fixed (aka, see
previous times this was discussed)]
jensimmons: Using percentages for gaps for auto-sized things is not
great
jensimmons: because they will see their gap change size when the
content changes
jensimmons: so they will realize this is not what they wanted
fantasai: Yeah, I can see that happening, I'm getting convinced by D
too now
Rossen: Proposed resolution: gaps expressed in percentages resolved
and layout-ed as 0 in auto-sized directions
rachelandrew: There might be a few people that are going to hit this
problem if they try to replace parts of an existing
layout they cannot entirely control.
fantasai: But this would apply to cases where the grid is
shrinkwrapped, not to cases that have a definite
containing block
rachelandrew: Yes, but I don't know how common that would be
iank: We are at 0.1% of all pages for grid all up
iank: so I guess this case wouldn't be frequent at all once you
consider it has to be also using percentage gaps, in a
shrink-wrapped context
Rossen: But the conversation is about porting content that currently
uses percentages to grids
Rossen: though I don't really see how they can achieve this today in
a way that works in all browsers
jensimmons: I think those cases are very fragile currently, they use
margins/paddings on floats
jensimmons: but in those cases usually, the container has a width,
even if it is 100%
rachelandrew: (general feeling of doubt, but I didn't catch the
exact words)
dholbert: So this would only happen about floated grids, and abspos
grids
dholbert: but in a flexbox, you are suppose to layout as having a
definite size after flexing, so percentages would work
there right?
TabAtkins: Correct.
[rachelandrew & jensimmons talking about author's work to port
existing things, ex: new york times shipping grid inside
bootstraps]
Rossen: So, would your doubts be enough to raise an exception today?
rachelandrew: No, I just wanted to shed some light on this, we can
come back on this if needed
Rossen: Any objection?
RESOLVED: Option D: percentage gaps in shrink-wrapped grids
contribute 0 and layout as 0.
Percentage tracks
-----------------
github: https://github.com/w3c/csswg-drafts/issues/1921
lajava: To keep things symmetric, we tried to add cases to resolve
percentages for height of rows
lajava: But we don't have min-content phase in the block direction,
like we do for width
lajava: So we would need to duplicate a second pass to make this
work.
lajava: So 1st we would like this recorded clearly in the spec if
that is required
lajava: And all browsers would have to change their implementation.
florian: And why not just follow what browsers already have
implemented?
Rossen: The change would be relatively straightforward, it's no big
deal.
florian: But we would possibly break content, right?
Rossen: Everything we do ends up breaking someone's content, I don't
think this would be an issue here.
lajava: Well, we are still unsure about what would happen in more
complex cases like in orthogonal flows
lajava: but at the very least it would require a second pass, once
you know the intrinsic height.
Rossen: Any opinion from Mozilla?
Rossen: There is still time to fix, but window is closing.
dholbert: I don't have a strong opinion, and Mats hasn't commented
on the issue.
dholbert: I don't like adding new layout steps usually.
Rossen: But it's easy to know if you need to do it beforehand
Rossen: only do it if you have percentage-sized row tracks.
dholbert: But if it is an orthogonal flow, you have to re-layout
entirely right?
lajava: Yes, but this already happens anyway.
Rossen: Any objection?
RESOLVED: Percentage tracks sized as percentage resolve the same way
for columns and rows, which involves a second layout pass
in some cases.
"Equal Gutter" with justify-content
-----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1116
Request is for next level...
fantasai: Users often want row-gaps and col-gaps to be equal
fantasai: but they also want the horizontal gaps to fill the
remaining space once you've put as many columns as
possible in the width direction.
fantasai: They can do that using justify-content
fantasai: but they cannot transfer this size in the other direction.
fantasai: This is basically a request for thoughts on the topic.
<fantasai> https://github.com/w3c/csswg-drafts/issues/1116#issuecomment-288472394
<fantasai> Just to summarize, the example is
<fantasai> definite width, auto height grid container
<fantasai> auto-fill columns e.g. 100px
<fantasai> auto-placed items
<fantasai> place-content: space-between
<fantasai> The spacing produced by space-between is not equal in
both axes.
jensimmons: So is the idea { row-gap: as-column-gap } ?
TabAtkins: Pretty much.
<leaverou> Possibly silly idea, but what if there was a unit for
horizontal gap? Are fractions of that useful or only the
whole horizontal gap?
<TabAtkins> So far the only request is matching, but if fractions
are desired later, our eventual solution for "put
keywords in calc()" will handle that.
(general discussion, but it was tough to minute)
fantasai: The tricky thing is that two things control the gap size.
fantasai: The gap property
fantasai: and the alignment properties
fantasai: you do have to consider both to get the desired effect
fantasai: and there are interesting cases of space-evenly which
creates a gap before the first column and after the last
column, we will need to define what to do about that.
<fantasai> the gap properties only distribute space between the
columns, but alignment can do other things
florian: And the proposed syntax would allow to also define
alignment in the direction in which you said to copy.
florian: I think we should have a more restrictive syntax that
doesn't allow the impossible cases would be better
florian: but I don't have a concrete proposal right now.
jensimmons: Just to clarify, the alignment do not update the gap,
they add a gutter right?
fantasai: Yes, but visually it looks like the same thing.
jensimmons: So it looks like we want something to transfer the
gutter not the gap.
dholbert: Maybe some align: symmetrical then?
dholbert: Alignment properties already are allowed to increase a gap.
dholbert: It would be possible to also shrink the gap to make it
match, that doesn't sound unreasonable.
<dholbert> Or possibly not shrink, but grow-or-leave-the-same (to
avoid)
<dholbert> *(to avoid violating author expectations that
"grid-row-gap: 100px" should actually insert at least
100px of space)
Rossen: Alright, I think we should probably break out to lunch, and
have people interested in this proposal talk with each other.
Rossen: Let's get back here at 1:30
<br type=lunch>
Received on Tuesday, 5 December 2017 00:29:35 UTC