- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 4 Dec 2017 19:28:09 -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.
=========================================
Sizing
------
- RESOLVED: When finding the min-content size of a replaced element
with no intrinsic size, if there is a specified min-width
or min-height use that rather than 300px/150px.
(Adjusting a previous resolution on issue #951:
https://github.com/w3c/csswg-drafts/issues/951 )
- RESOLVED: Add textarea content-based sizing to Sizing L4.
- TabAtkins will add auto sizing of iframes into the WICG, since
there are complexities involving interaction with media queries,
security, and layout engine architectures that need to be worked
out in detail, and solutions might involve non-CSS technology (
HTML, HTTP).
- RESOLVED: Don't remove stretch / fit-content from min-width/height.
- Discussed the proposal to address issue #1865,
Intrinsic size of 'overflow: auto/scroll' and its impact on
auto-sized grid/flex item ancestors:
https://github.com/w3c/csswg-drafts/issues/1865
- RESOLVED: Pending approval from dbaron, the group accepts the
proposed text to define which replaced elements are
affected by width: % rule zeroing min-content
(https://github.com/w3c/csswg-drafts/commit/6a3be51bdda0ccb92af0d09556d6d1f2e7d8874d
)
with an addendum to add "button-like" things to the list.
- RESOLVED: Move definition of the min-width:auto keyword to Sizing.
- RESOLVED: Move the box-sizing property from UI 4 to Sizing.
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/tpac-2017#proposed-agenda
Present:
Rachel Andrew, Invited Expert
Rossen Atanassov, Microsoft
L. David Baron, Mozilla
Christian Biesinger, Google
Tantek Çelik, Mozilla
Dave Cramer, Hachette Livre
Emil Eklund, Google
Elika Etemad, Invited Expert
Javier Fernandez, Igalia
Rob Flack, Google
Simon Fraser, Apple
Chris Harrelson, Google
Daniel Holbert, Mozilla
Jihye Hong, LGE
Koji Ishii, Google
Brian Kardell, JS Foundation
Brad Kemper, Invited Expert
Ian Kilpatrick, Google
Tomoya Kimura, VOYAGER Japan
Vladimir Levantovsky, Monotype
Chris Lilley, W3C
Peter Linss, Invited Expert
Myles Maxfield, Apple
Xidorn Quan, Mozilla
Simon Pieters, Invted Expert
Naina Raisinghani, Google
François Remy, Microsoft
Melanie Richards, Microsoft
Florian Rivoal, Vivliostyle
Alan Stearns, Adobe
Surma, Google
Dave Tapuska, Google
Lea Verou, Invited Expert
Jet Villegas, Mozilla
Greg Whitworth, Microsoft
Eric Willigers, Google
Scribe: gregwhitworth
Sizing
======
max-content size of percentage-sized replaced elements
------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1722
Rossen: max-content size of replaced elements
fantasai: We discussed what to do with replaced elements that is
percentage sized that has an intrinsic aspect ratio.
fantasai: *gives an example*
fantasai: If there is a specified min-width or min-height use that
rather than the intrinsic aspect ratio in that dimension.
dbaron: The effect that that would have is that if your min-width or
min-height is smaller than the intrinsic size in that
direction then you use that.
dholbert: If it's not min-width/height of auto?
fantasai: Yes.
dbaron: What you're saying is if min-width/height are non-auto you'd
use them in the aspect ratio?
fantasai: Yes.
dbaron: There are some weird interactions around this.
dbaron: It seems worth trying.
dbaron: I think someone should try it before committing.
dbaron: I'm worried about web compat.
fantasai: This scenario is not a very common case.
fantasai: I don't know why you'd be doing this.
dbaron: The main case I can think of is SVG.
Rossen: Currently that will work.
dholbert: In FF that doesn't work.
fantasai: So it isn't interoperable right now
fantasai: so...
fantasai: let's give it a try.
dbaron: Put it into the spec with the note to provide feedback.
tantek: We're changing a resolution right?
fantasai: Right, from a few months ago.
tantek: I'm worried about back compat.
tantek: They may have implemented.
fantasai: They haven't, that's the point.
* dholbert thinks the resolution from a few months ago was in
https://github.com/w3c/csswg-drafts/issues/951
<dholbert> Firefox bug related to this is
https://bugzilla.mozilla.org/show_bug.cgi?id=1409529
<AmeliaBR> There are some examples in this pen, if you want to look
at current behavior: https://codepen.io/AmeliaBR/pen/brdBvQ
<tantek> thank you AmeliaBR !
tantek: When we had box sizing for SVG things we had all kinds of
interop issues.
Rossen: who's going to write the test cases.
Rossen: I hear some concerns about compat
Rossen: but also given the fact there is no interop on the issue
then we should resolve on something that makes more sense.
Rossen: any objections?
<tantek> no objection, now that we have a test case to check impls
Rossen: resolved
Rossen: Please bring the test cases forward when you start working
on the actual text.
RESOLVED: If there is a specified min-width or min-height use that
rather than the intrinsic aspect ratio in that dimension.
Auto resizing of iframes and textarea based on content size
-----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1771
TabAtkins: There have been many requests for textarea and iframes
resize on content.
TabAtkins: We talked it over and thought, yeah probably ok.
TabAtkins: We started experimenting with this.
TabAtkins: figure our some mechanism content based sizing for
textarea and iframes
TabAtkins: We learned some issues implementing seamless with iframes
due to COR leaking information.
TabAtkins: We suspect we'd walk up the frame tree until we hit a
fixed size to resolve the MQs.
TabAtkins: Someone from Mozilla implemented this.
<tantek> would really like this as a content author
<tantek> for iframes in particular
<tantek> The iframe use-case for me is known width (set by
container), auto (preferably auto-expanding) height
dbaron: We got the spec to say that's how media queries work, but
seamless was removed.
dbaron: We have code for it - but it's not necessarily something you
can write up in a spec.
dbaron: You need to figure out how to spec it, it does some very
interesting things.
iank: What type of interesting things?
dbaron: I'd need to look, like it tries to do layout, and then tries
again.
Rossen: We used to have a technology that would allow you to do
layout based on then content size and we killed it
Rossen: performance becomes a concern for those.
Rossen: When you consider extensions they try to size the box, and
it's shrink to fit it becomes very bad for perf.
Rossen: Our experimentation for this suggests it was bad, but maybe
you'll find something.
TabAtkins: They're both pretty separate features anyways.
TabAtkins: Are we ok experimenting in this space?
TabAtkins: The textarea would go into sizing 4.
smfr: We've had the auto sizing of the iframe, even cross-origin.
smfr: It makes your frame layout outside in rather than inside out.
smfr: We've had quite a few media query bugs.
smfr: We ran into media query cycles.
TabAtkins: That means that you weren't doing media queries the way
we defined.
smfr: It does bring about nasty things in the code.
TabAtkins: How is this different from regular layout
smfr: You can avoid laying out the iframe, if you have to you have
to dirty the other nodes.
TabAtkins: ok, let's talk about this later.
dbaron: I think the media query problems you had were due to doing
what authors weren't expecting.
TabAtkins: This would be opt in.
tantek: How do you trigger behavior in iOS?
smfr: You always get it.
smfr: Users don't experience nested scrollers, we always wanted page
scrolling to win so you don't get trapped.
tantek: Width is expected and height is auto.
smfr: Yes.
Rossen: ok, so - it seems that Google wants to experiment with this
- Apple has it and wants to remove it
Rossen: Do you want a resolution?
TabAtkins: The textarea one is simple enough to go into sizing 4.
TabAtkins: The iframe one can go in WICG.
Rossen: Any objections to adding textareas to CSS Sizing L3?
fantasai: Yes.
TabAtkins: I said 4.
Rossen: Ok, L4.
fantasai: ok - I'm ok with that.
fantasai: we can add a note for L3 that this is upcoming
Rossen: Changes to sizing L4.
RESOLVED: Add textarea sizing to Sizing L4
*discuss whether to do in WICG*
*TabAtkins to spin up a WICG regarding auto sizing of iframes*
<tantek> I'm a bit surprised that we're not even putting into a WD
something that's been shipping in iOS for 10 years
Restricting stretch and fit-content to width and height
-------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1913
TabAtkins: I missed the telecon.
dbaron: I'm a bit hesitant as it exposes primitives to the system
but yeah you can't use it over here.
dbaron: I don't feel that strongly though.
TabAtkins: We didn't feel that strongly either but it felt like more
effort than warranted.
TabAtkins: We use min in weird ways, fit-content especially
fantasai: It's fine but we couldn't figure out how to use the
stretch as a minimum
fantasai: Question was, Do we need this?
fantasai: If we don't we don't need to put the effort in for testing
etc.
Rossen: So do we keep it?
florian: Do authors have any opinions?
jensimmons: fantasai can you explain what this is?
fantasai: Would you ever use min-width or min-height of 100%, it
does effectively that.
jensimmons: I'm sure people do use that.
fantasai: If that seems like a reasonable thing to use.
<gsnedders> I've definitely used min-height: 100%; height: 0; in
some cases.
cbiesinger: Seems useful, might want to fill a screen but grow if
more content.
dbaron: The other question is would you want to use them inside a
calc() expression for min-width and min-height.
jensimmons: I am hesitant to remove it
RESOLVED: Keep them as they are in the spec (don't remove them)
Intrinsic size of 'overflow: auto/scroll' and its impact on auto-sized
grid/flex item ancestors
----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1865
fantasai: Grid and flexbox show this issue, where people have an
element with a scrollbar and they put it among a whole
bunch of other content
fantasai: It forces that has a min-content size which defeats the
purpose of the scrolling the author defined
fantasai: this leads to a lot of confusion for authors
fantasai: They're already handling their overflow and it would be
nice if they just worked
fantasai: Filed this issue to allow us to come up with a way
for this to work as expected.
fantasai: I was talking with cbiesinger on Saturday, thought about
having the min-content zero'd out on scroll containers
fantasai: The min-content contribution which has overflow be 0, but
not the logical height since that would require re-layout
of all surrounding content to determine the min and max
fantasai: it's an idea, we're looking for other ideas also.
dbaron: The thing with overflow that is not visible the size is the
content within it, it has to propagate through it if it's
the only thing.
dbaron: I tend to think, that there is not going to be a thing that
we can do to solve this with a property that allows them to
choose the thing that they want.
dbaron: I think there are two different scopes.
1. intrinsic control intrinsic width that has overflow
2. properties that allow assignment to the intrinsic widths
dbaron: The advantage of the first one is it gives more room for
auto behaviors that do the right thing
dbaron: The advantage of the second is it is strictly more powerful
fremy: I wanted to note that we had a similar issue in the table
spec.
fremy: If you have a % height and you're overflowing in a non
visible way we should resolve to 0
fremy: the author intent is pretty clear here
fremy: To me this makes sense and is generalized
fantasai: For grid and flex items specifically the automatic minimum
size is not triggered on items that are overflow !=
visible, but their content still does impact the
min-content contribution.
cbiesinger: You said that the single items need the content
contribution to propagate through.
dbaron: Because people will use 'overflow: hidden' to hide things
rather than scroll it.
fantasai: That's a good point
dbaron: You're talking about zeroing out the min-content sizes.
<fremy> @dbaron: overflow hidden is excluded in tables, only
scroll|auto
fantasai: Yeah, just the min-content size.
dbaron: Presumably the min-content sizes don't matter.
cbiesinger: For the min size of flex and grid would make it zero in
this cases.
dbaron: In many cases you want them to get smaller but not to 0
fantasai: A lot of the cases that are here the minimum would be
controlled by other content that happens to be there
fantasai: If they don't want it to get to 0 they can set a min size
on the flex or grid item, or on the scroller itself
<fantasai> This is more understandable than having a scrollable
descendant of a grid or flex item several layers deep in
a subsection of a subsection cause the flex/grid item's
width to explode out
dbaron: The other thing I worry about here is compat.
cbiesinger: That is concerning.
dholbert: Chrome already does this correct?
cbiesinger: I don't think we do that, but we do is for nested column
flexboxes we don't give it a min-height.
dholbert: I thought there was something there for overflow: scroll.
cbiesinger: I'd need to look at it.
<fantasai> Proposal in two parts:
<fantasai> 1 flex/grid items with overflow != visible | hidden have
min-content contribution of zero
<fantasai> 2 inline dimension of block with overflow != visible |
hidden has min-content contribution of zero
Rossen: I read through the post about this issue, but I'd want more
use cases for this. I am not going to object, but there will
be compat issues for this.
Rossen: dbaron any objections?
dbaron: I wouldn't object, but I'd like to discuss the compat
implications.
Rossen: We can discuss this on the side - let's not rush the
resolution.
dbaron: I would be hesitant to come up with something too magical.
Rossen: Unless there is something else to be discussed.
Define which replaced elements are affected by width: % rule zeroing
min-content
--------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1889
fantasai: We would like to resolve on this issue.
fantasai: We would want dbaron's approval though.
<astearns> text is:
https://github.com/w3c/csswg-drafts/commit/6a3be51bdda0ccb92af0d09556d6d1f2e7d8874d
<fantasai> https://drafts.csswg.org/css-sizing-3/#min-content-zero
<Rossen> elements include: select, textarea, progress, meter.
*explains commit up above*
fremy: The only one I can think of is input type="color" as I think
most browsers implement it as a button.
fantasai: These are things that the min-content contribution is
going to be zero'd out if a percentage is used on there.
fremy: I think for us it's just easier to add color to this.
dholbert: Same for us.
fantasai: For things that need to remain for UX, you might want to
reserve some amount of that space, the exception list
should include button.
fantasai: The button gets its size from the content.
Rossen: What fremy is advocating for is so that input type color
doesn't disappear.
TabAtkins: We can say some spec language to allow anything that's
like a button.
Rossen: In our case it's just a button that has the swatch.
fantasai: That makes it so that you can't go down to zero and would
loose the swatch?
Rossen: Yes, which defeats the point.
fantasai: That is the same with the text input you can go down to 0
and can't type.
Rossen: What is the push back on including color.
fantasai: Maybe it's that is tied to a button.
TabAtkins: That's why I suggested "button like".
TabAtkins: Everything that looks like a button.
Rossen: Are you ok with this?
fantasai: Yeah.
Rossen: With the amended button like to the list, any objections?
Rossen: ok resolved, pending dbaron opinion.
*break 15 minutes*
Moving min-width/height partial definitions to Sizing
-----------------------------------------------------
Scribe: TabAtkins
github: https://github.com/w3c/csswg-drafts/issues/1920
fantasai: Oriol pointed out the Flexbox isn't the best place to
define a new initial value for min-width/height.
fantasai: Suggested it move to the Sizing spec. Makes sense to me.
fantasai: Definition of what automatic size means in Flexbox will
stay, but move the propdef table that defines the keyword
to Sizing.
Rossen: Sounds reasonable.
RESOLVED: Move definition of the min-width:auto keyword to Sizing.
Move box-sizing to Sizing
-------------------------
github: https://github.com/w3c/csswg-drafts/issues/1906
florian: Width and height are defined in 2.1. Box-sizing is defined
in UI as a monkey-patch on that.
florian: Works, but is ugly.
florian: Now that UI is getting to Rec, it's about time we get that
into a spec of its own.
florian: So we should take what's in 2.1, apply the box-sizing
patch, and put it into a spec, probably Sizing.
florian: Also need to make sure it work for logical/etc.
florian: So Sizing 4 looks like a good place to have it.
Rossen: This is in UI3, already tested, right?
<tantek> Yes
florian: Right, it's in UI3, and staying there as it goes to Rec.
It's only in there, tho, because 15 years ago we thought UI
would be the first to hit Rec. Turns out to have been true,
but there are better places for it.
fantasai: Happy to pull in the monkey patch, hesitant to pull in all
of 2.1...
Rossen: No need to dive into details, just about moving box-sizing
from UI4 to Sizing.
RESOLVED: Move the box-sizing property from UI 4 to Sizing.
Received on Tuesday, 5 December 2017 00:29:06 UTC