- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 13 Feb 2017 21:32: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.
=========================================
Scrolling
---------
- The group revisited scrollers and overflow now that they could
draw out visual aids.
- To help understand the problem, they created a grid of the
current values of 'overflow' (scroll, auto, hidden) and
behavior groups desired (auto=current, always, stable).
Picture:
https://cloud.githubusercontent.com/assets/113268/21948275/e636cae4-d99e-11e6-87eb-d2b35769e3de.png
- RESOLVED: scrollbar-gutter is a new property independent of
'overflow'.
- RESOLVED: Values are auto | stable | always, potentially
with a rename for always if it becomes an issue in
later discussion on hidden/visible.
- RESOLVED: Add the 'force' keyword to apply gutter even when
overflow is not scroll/auto. (But bikeshed the name.)
- RESOLVED: Add 'both' as an optional keyword: gutter is applied to
both sides of element (for cases that desire symmetry).
- RESOLVED: 'both' will only affect the block direction.
Sizing
------
- RESOLVED: Add width/height:contain to Sizing 4 for review.
- RESOLVED: Change "width: fill" to "width: stretch".
- RESOLVED: Treat min/max-content keywords as "auto" in the block
axis.
- RESOLVED: Treat fit-content that way, too.
- The authors will rename "fill-available sizing" to "stretch
sizing".
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/seattle-2017
Scribe: gregwhitworth
Scrolling
=========
Rossen: Looking at next issues.
Rossen: Who added scrolling?
Rossen: [Lists off issues]
Florian: I added the overflow thing.
astearns: The other was discussed on a telecon and it was deferred
to the f2f.
Overflow: Consider reserving space for scrollbars with some property
--------------------------------------------------------------------
<Rossen> https://github.com/w3c/csswg-drafts/issues/92
Florian: This is the overflow gutter and overflow overlay issue.
Florian: Does everyone remember what this is about?
Rossen: I think we should draw them out.
Rossen: I can draw them.
Florian: So, this is about overflow: auto
Florian: it doesn't always do what you want.
Florian: There are two sets to consider:
Florian: some browsers have overlay scrollbars
Florian: some browsers have scrollbars that consume space.
Florian: If you put something into overflow: auto and the
scrollbar consumes space will appear.
Florian: In browsers that have overlay, it doesn't change the
amount of space that is available for the content.
Florian: In browsers that have scrollers that consume space, even
though I'm not overflowing please consume the space
anyways.
Florian: Basically, I know what size I want for my content, just
give me a gutter.
Florian: The one we have today is we have always consuming space.
fantasai: I thought that was the first one.
Rossen: [shows whiteboard picture]
[picture of whiteboard at end of discussion:
https://cloud.githubusercontent.com/assets/113268/21948275/e636cae4-d99e-11e6-87eb-d2b35769e3de.png]
Rossen: You have the border, then some padding, and then the
content box
Rossen: if this box has overflow: auto.
Rossen: When the content reaches this boundary, the scrollbar is
currently defined to go between the outer padding edge and
the inner border edge.
Rossen: In order to do this we take space out of the content width
or height
Rossen: this caused a new reflow.
Rossen: In the case of overflow: overlay it may still be 17px wide
but it takes no layout space in the box model.
Rossen: Of course the drawback of this is that if you don't have
padding the scroller is overlapping your content.
Rossen: One of the proposals is to control the space that is where
the scroller is.
Florian: We had agreed on 3 behaviors:
Florian: 1 being what we have today-
Florian: always reserving that space in browsers that don't have
overlay.
dbaron: How much do you consume if you have overlay?
Florian: The size of the scrollbar widget that is displayed.
Rossen: Is this defined by UA?
Florian: Yes.
Florian: Yes, this is UA defined.
Rossen: So this isn't exposed to the user?
smfr: On mac it's a bit more magical, it's in a skinny state and
then when you mouse over it's a fat state.
smfr: Probably need to leave it up to the UA.
Florian: You could potentially use the unit for other things.
zcorpan: The use case for the scrollbar unit and this sets to get
two boxes the same size.
fantasai: If you preserve the space and overflow: auto you'll
never get the scrollbar.
fantasai: This solves that use case.
Florian: Depending on the property that we solve that with, there
is an overflow: auto but it doesn't show a scroll bar.
Florian: If you want an overflow: auto and it will scroll but it
won't show a scroll bar.
Florian: I'm just mentioning it
fantasai: And if you don't have a touch interface and need a
scrollbar to scroll?
smfr: I drew this just to clarify this.
smfr: For overflow: scroll we already preserve space even if it's
not scrollable.
smfr: This is asking the question when does the UA preserve space.
smfr: If you're overflow: auto it only shows when overflow, if
you're not overflowing do you preserve space.
Rossen: For your proposal I think it's the opposite.
Rossen: You need one more column which is for the proposal.
Florian: We haven't resolved if this is a new prop or unit.
Rossen: Sure, but let's add a column for it to show the usecase.
smfr: Does this new property ever preserve space if the scrollbar
isn't being shown.
fantasai: I thought that was the whole point.
Rossen: Yes, you should preserve the space whether you're showing
it or not.
Florian: There is the three behaviors we've stated.
dbaron: Also there's scroll that always preserves space even if
you have overlay scrollbars.
esprehn: Overlay is 0 size.
esprehn: What's missing from this is the unit that is the size of
the scrollbar.
fantasai: We already discussed this.
fantasai: This is too abstract
Florian: That's what this table is for but it isn't complete.
esprehn: You're wanting to take space that takes the space of the
scrollbar.
Florian: Yes, if you use a unit it also can be used everywhere.
Florian: If you're in a browser that has a scrollbar, consume the
space.
esprehn: Authors normally just preserve the space.
Rossen: Florian, I think this is correct, smfr please correct me
if you can:
Rossen: The UA will reserve space when the scrollbar is needed.
Rossen: If you don't have an overflow you don't reserve space.
Rossen: In the case of overlay scrollers nothing is reserved.
Rossen: The feature that is being reserved, it will reserve it no
matter when the overlay scrollers come out.
Rossen: For hidden, we don't reserve for anything.
smfr: One question is whether we need different behaviors for
overflowing, not overflowing, for overflow:auto.
fantasai: You need a third column for on an overlay scrollbar you
don't reserve the space.
Florian: [drawing an additional column]
[Table Description (from fantasai):
There are three rows for the three values of 'overflow'
(scroll, auto, hidden)
There are 3 column groups:
B1 (current behavior aka auto), B2 (always), B3 (stable)
Each column group is split into columns for
"scrollbars that take up space" and "overlay scrollbars"
For B1 (auto), space-consuming: scroll=reserve,
auto=reserve-when-on,
hidden=0
For B1 (auto), overlay: scroll=0, auto=0, hidden=0
For B2 (always), scroll=reserve, auto=reserve, hidden=?
For B3 (stable), space-consuming: scroll=reserve, auto=reserve, hidden=?
For B3 (stable), overlay: scroll=0, auto=0, hidden=?
ASCII-art:
auto || always || stable
spaced | overlay || spaced = overlay || spaced | overlay
'scroll' | reserve | zero || reserve || reserve | zero
'auto' |r if need | zero || reserve || reserve | zero
'hidden' | zero | zero || ? || ? | ?
]
[picture of whiteboard at end of discussion:
https://cloud.githubusercontent.com/assets/113268/21948275/e636cae4-d99e-11e6-87eb-d2b35769e3de.png]
Florian: The last time we discussed this we agreed on having these
three - but we didn't agree on what triggers it:
<Florian> https://github.com/w3c/csswg-drafts/issues/92#issuecomment-251727301
[
Syntax proposals were:
#1 scrollbar-gutter: auto | stable | always
#2 overflow-gutter: auto | stable | always (longhand of
overflow)
#3 overflow: visible | hidden | scroll | auto [stable |
spaced]?
]
Florian: This references the three syntax we have proposed.
Florian: 1 was a completely independent property scrollbar-gutter:
auto | stable | always
Florian: I think the last time we discussed this we didn't discuss
overflow: scroll we only discussed auto.
fantasai: There are a lot of questions here.
Rossen: Can we discuss this for overflow-style?
fantasai: We renamed -style to -gutter.
Florian: That's how far we went.
smfr: I have a strong preference for the scrollbar-gutter property
because the others will cause author confusion.
fantasai: A more important problem is that the prop cascades and
inherits independently.
fantasai: For that reason number 1 is the best option.
Rossen: For number 1 what does that mean for visible as well?
Florian: For visible they do nothing.
Rossen: Then for hidden they do nothing.
Rossen: They should be the same.
Rossen: The reason I'm saying this, for people that do their own
scrollbar they will use the property to set hidden to
preserve space and then scroll the content.
fantasai: First let's resolve on that first question.
fantasai: Do we accept option number 1?
Rossen: Before we do this, the third option went a little bit
unnoticed.
Florian: It is not a new property, but it becomes an optional
keyword on the auto keyword.
Rossen: Which means you can't use it for hidden, visible or scroll
Rossen: so this breaks the usecase I just suggested.
Florian: Also what fantasai was saying, they don't cascade
separately.
Bert: Using the word scrollbar in the property helps explain what
it does, the others aren't as intuitive: what happens when
the scrolling mechanism doesn't look like a scrollbar.
Rossen: That's another good feedback in favor of 1.
fremy: I want to come back to what esprehn and gregwhitworth said
is the unit so that the author can control it.
fremy: There is the space that you as the UA should preserve and a
new unit to get either option.
Rossen: It would need to be a calc(padding + Nsw).
fremy: It allows people to use the unit where we don't want people
to use it.
smfr: We also need to think about horizontal scrollbar.
smfr: We have various scrollers so I don't want to have multiple
units for each.
myles: We have an API function that will change if we put it on
the left for RTL or not so to have the authors to define
this would be very hard.
Rossen: We have the same behavior as well.
dbaron: For us it depends on the situation, it changes for the
viewport and the iframes, etc
Rossen: Is this really a problem with #1? - only with the unit.
smfr: I wanted a clarification, but we can come back to that.
zcorpan: Florian says that a unit allows authors allow for things
that we don't know of, but the gutter doesn't take into
account designers.
zcorpan: ... they sometimes want to reserve the space on both
sides.
esprehn: And designers want to get the size and match them to a
grid to make them symmetrical and they use hacks to make
it happen.
smfr: I think it's somewhat orthogonal.
esprehn: I think having the gutter and making it symmetric is
possible, that would be good
dbaron: The thing I wanted to bring up - do we want
scrollbar-gutter to be an inherited property?
dbaron: I was leaning against but I don't feel strongly.
fantasai: I think it should be.
Rossen: We don't inherit overflow.
Rossen: If I have a bunch of divs, one inside the other, what do I
get?
Florian: That depends.
Rossen: Even if it's on scroll, I'm squeezing the content because
I want to preserve space on the first one.
Rossen: I lean against inheritance.
fantasai: The benefit is to allow you to not have to reset it on
every scroller. At that point you might as well have it
be an overflow keyword.
fantasai: You need to be able to set scrollbar-gutter on the
entire page at once.
fantasai: Once it's set it should not have an effect on something
that is not a scroller.
fantasai: As far as inheritance vs universal selector, universal
selector will jump through scopes.
fantasai: Inheritance allows you to have different behaviors. But
I could go either way.
<zcorpan> fantasai+
<zcorpan> using universal selector in the common case indicates a
design failure
Rossen: To move forward, let's resolve on... I hope everyone
understands the feature and the need for it...
Rossen: can we resolve on getting the scrollbar-gutter property?
Rossen: Any objections?
RESOLVED: scrollbar-gutter is a new property
Rossen: Now let's move on to the set of values.
Rossen: We have to decide if we want symmetric or not.
smfr: There is a case that doesn't change between overflow and not
overflowing please show a space.
Rossen: What is it that you want to do.
smfr: They want to preserve space no matter if the overlay
scrollbar is there.
smfr: If there is an overlay scrollbar please preserve space.
Rossen: That's stable.
Florian: What he wants is unstable.
dbaron: I think he said two different things.
smfr: With overlay scrollbars, they may want a value if the UA
will preserve space if the UA will show an overlay scroller.
Rossen: You want to counteract the overlayness
Rossen: that will cause layouts.
dbaron: It feels like what Simon wants is to treat overlay
scrollbars as a completely different access.
dbaron: Maybe that calls for a separate control for whether
overlay scrollbars should be treated as taking up space.
Rossen: Let's try with adding auto.
fantasai: Let's resolve on the initial three.
dbaron: That may raise the question of "always" vs "really-always".
Rossen: It sounds like the only one we can resolve on is auto.
smfr: What does auto do?
TabAtkins: I'm not resolving on one value.
Florian: How about stable, most people agree with stable.
gsnedders: Can we resolve on stable and always and just put a note
to bikeshed the name?
fantasai: I'm ok with that.
Rossen: It doesn't sound like we're ready.
Rossen: What does always do?
Rossen: No objections, let's add always
RESOLVED: Values are auto | stable | always, potentially with a
rename for always if it becomes an issue in later
discussion on hidden/visible
<break type=lunch>
Florian: So we had to resolve with the three values but a better
name for always.
Florian: We haven't resolved on what b2/always do.
Florian: The natural answer is that they do nothing
Florian: but
Florian: there is a gmail problem.
Florian: This is the gmail UI:
Florian: there is scrollbar on the right and it's always.
Florian: Right above it you have a toolbar, and you want to align
the UI with the other content which is pushed in by the
content.
Florian: One way to solve this is to have always apply to
overflow: visible
Florian: but this is bad on a lot of other areas
Florian: but we probably shouldn't change the current setup.
smfr: You shouldn't use units though because of the RTL arguments.
Florian: In gmail's case they have scrollers on both sides, so
that isn't an issue - but that isn't always the case.
Florian: One way to solve this is by adding a keyword in
combination and how it works for this usecase.
Florian: For this keyword I suggest force.
Florian: Always can be reserve.
<fantasai> the proposal is that we fill in hidden/visible/clip
with 0 for the general case and with a copy of the
'overflow: auto' value if the optional keyword 'force'
is present.
smfr: You still have the inheritance problem right?
Florian: Yes, but don't put "always force" on the entire page
Florian: So do people like force?
Florian: Thoughts?
Rossen: I'm not crazy about the name.
smfr: Do we have more use cases, we have one but does this need to
be l1?
fantasai: I think so.
Rossen: This will eliminate the need for force.
Florian: No, this is just showing when force will reserve and it
won't.
Florian: Is this resolved?
Florian: The behavior and the name, or separately.
esprehn: The name isn't great, but the behavior is fine.
Rossen: Any objections to adding the force optional keyword for
hidden and visible?
tantek: This is just for the gutter?
Florian: Yes.
tantek: Then why not just gutter?
Rossen: So you'll have something like scrollbar-gutter: gutter.
tantek: I just tend to dislike generic keywords like force.
tantek: We should re-bikeshed on the force name.
Rossen: That's in agreement.
RESOLVED: Add the force keyword but bikeshed on the name
smfr: scrollbar-gutter: force would add gutters to all elements
Florian: No that is when using always force.
Rossen: If I have in my case, rather than taking space from the
content it will keep adding space-
Rossen: it takes width away from the box.
fantasai: Yes.
Florian: It just takes space away from the scrollbar not how you
go it.
Rossen: Any objections to both?
RESOLVED: Add both as an optional keyword: gutter is applied to
both sides of element (for symmetry).
Florian: Now that we have overflow-x and overflow-y do we want a
different behavior there?
Rossen: Can't that work automatically.
Florian: If you do overflow: auto or hidden at the bottom, but
this on the side - you don't need this.
Florian: I put scrollers on both sides, and try not to overflow.
Rossen: That's what you do because you're trying to follow good
practices.
fantasai: We don't want to forbid this just to get this effect to
work properly.
Florian: Proposal, turn this into a shorthand and add x and y.
fremy: Do we need logical props?
fantasai: Yes.
fantasai: It's either that or we only do this in the block axis.
Rossen: That's not going to work.
Florian: No one's thrilled with this, but what else do we do?
Rossen: Would you use it for anything other than block, seriously?
Florian: Yes.
Rossen: When would you want the symmetrical in the vertical axis?
Florian: jensimmons please help!!!
Florian: You have a multicol that may overflow
Florian: and you want to preserve the space.
Rossen: But why would you want the symmetrical.
Florian: Not sure about both.
Rossen: So it's already not working out for horizontal.
esprehn: The use case I can think of is like a dialog is you want
the same space all the way around the box and you don't
want the content to shrink.
Rossen: You have padding.
Rossen: [not impressed]
Florian: I think there may be needs for inline.
Florian: I agree most use cases are block.
Rossen: We can make it a long hand later if enough demand calls
for it.
Florian: So if it's a shorthand you'd omit the keywords.
philipwalton: Isn't that inconsistent with how overflow works?
Florian: Yes.
philipwalton: That seems confusing.
Florian: The day that we solve this is by making the syntax for
both, and the omitted one will mean auto.
<philipwalton> the majority use case for both is
scrollbar-gutter-y: both and scrollbar-gutter-x:
auto
fantasai: Having it default to the block makes sense.
fantasai: When you have multiple keywords we allow you to re-order
them arbitrarily.
Florian: We can put a comma or slash in between them.
TabAtkins: Slash is the appropriate one here.
Florian: We'll put some kind of separator when we get to that
point.
Florian: I've never been a big fan of x/y doesn't make much sense.
Rossen: Do we need a resolution?
Florian: We need a resolution that it applies to the block
direction only.
philipwalton: I think we should do both.
TabAtkins: Yeah.
Rossen: It's easier to add than remove.
TabAtkins: esprehn gave an example.
philipwalton: I'd hate to have a confusing long hand later.
Rossen: I have a feeling that we may add it sooner than later.
Florian: I think it's good that if you only specify it once it
only applies in the block direction.
Florian: I don't care either way.
Rossen: I could go either way.
philipwalton: My objection was only contingent was the single
applying to both.
philipwalton: If everyone is ok with inconsistency with overflow
then I'm ok with that.
RESOLVED: both will only affect the block direction
Florian: Behavior number 4
astearns: Can we do this later?
Florian: Yes.
myles: We've been talking this whole time about layout, you have
to paint something in this - do you just paint what you
would paint in the padding box?
TabAtkins: Imagine your scrollbar is not there, that's what you
get.
myles: Imagine I adjust it in script, you'll get more padding
visually to the end user.
Scroll bounding behavior
------------------------
Scribe: fantasai
<smfr> https://github.com/w3c/csswg-drafts/issues/769
smfr: I think we need some discussion here.
smfr: There are differences between being in the beginning/middle/
end of a gesture.
smfr: UAs have different latching behavior.
gregwhitworth: I'd like Matt Rakow to be involved here.
TabAtkins: Should have a proposal for this.
Sizing
======
Scribe: TabAtkins
fantasai: Continuing from morning, do we want to add width:
contain to the spec?
dbaron: Want to see a more solid proposal for it first.
<dbaron> (given that you were talking about putting it in a draft
that's about ready for CR)
fantasai: So maybe add it to 4, we can pull it down if it's
miraculously stable.
jensimmons: Just don't punt it too far?
gregwhitworth: Would be helpful to then gather more interest.
fantasai: We have an ED of level 4 for the purpose of defining
intrinsic sizes already.
fantasai: We can add to that.
fantasai: Intrinsic sizing was taking a long time; we just punted
it out and deferred to CSS 2.1 (left it mostly
undefined, but no worse than status quo).
astearns: So proposal is to add width:contain to Sizing 4 for
review.
RESOLVED: Add width/height:contain to Sizing 4 for review.
fantasai: Request from jensimmons to rename "fill" keyword to
"stretch", to tie it into the stretch keyword in
Flexbox/Grid.
jensimmons: Like it. "stretch" seems more obvious than fit/fill.
astearns: Is "fill" implemented?
fantasai: Think so, but looks like no wild usage yet.
dbaron: We have it implemented prefixed.
astearns: Any concern with changing "fill" to "stretch"?
RESOLVED: Change "width: fill" to "width: stretch".
<gregwhitworth> dbaron fantasai -moz-fill-available was not seen
on any of the 800K sites we crawled
<gregwhitworth> dbaron fantasai for perspective:
-moz-control-character-visibility was used 166
times
<gregwhitworth> it's important to note that this ensures that the
element is on the page, not just parsed
<dbaron> gregwhitworth, sorry, it's just -moz-available, not
-moz-fill-available
<gregwhitworth> dbaron: my only -moz prop that has an a is
-moz-appearance - so that -moz-available isn't
there as well
Intrinsic size of replaced elements incorrect
---------------------------------------------
<fantasai> https://github.com/w3c/csswg-drafts/issues/794
fantasai: About max-content and min-content keywords.
fantasai: And whether they should be sensitive to the aspect ratio.
fantasai: fit-content is "shrink-to-fit sizing". It operates as a
min/max formula that takes in min/max size, and a
constraint (usually containing block).
<TabAtkins> min-content and max-content represent the extremes of
fit-content sizing.
<TabAtkins> min-content is size with maximum soft wraps (longest
unbreakble content), while max-content is size with no
soft wraps.
fantasai: Images have just one size, no text.
fantasai: But they have an aspect ratio.
fantasai: So if I have a floated image, and I set the height, it
transfers thru the aspect ratio and affects the width.
fantasai: We wanted to make sure that min/max-content are affected
by the sizing constraints of the other dimension.
fantasai: Do this by saying "size as a shrink-to-fit float".
fantasai: So if you say min-content, it acts exactly like a float
in a zero-width container, max-content with an
infinite-width container.
fantasai: dbaron had a different concept.
fantasai: That they should be the intrinsic size of the image,
without regard for specified sizes.
fantasai: The advantage is that this corresponds to an internal
layout concept.
fantasai: Downside is it's not a concept that appears in CSS in an
author-exposed manner.
fantasai: We *always* respect the aspect-ratio if possible.
fantasai: So you never see the raw intrinsic size.
dbaron: I don't think it's true.
dbaron: We've exposed it thru these new width keywords.
dbaron: I've been particular to insist that all the intrinsic
sizes definitions for an element *not* consider its min/
max-width/height properties, so we can have keywords for
those properties that represent those values.
dbaron: But instead you have values that pay attention to those
properties as part of determining the size of its parent.
dbaron: Also, I thought you were proposing there would be an
affect from the outside of the element.
dbaron: There's no cases where this happens yet, we really don't
want to do that. This is computationally a bottom-up thing.
fantasai: There are cases where we do this.
fantasai: Set a floated image sized in width percentage.
dbaron: These concepts only exist in the inline dimension.
fantasai: What do we do for height:max-content?
dbaron: We treat it as auto. It's only useful for writing-mode
content.
fantasai: Is that okay for other people?
gregwhitworth: Seems okay to me.
RESOLVED: Treat min/max-content keywords as "auto" in the block
axis.
<dbaron> (and the other two)
<dbaron> and fit-content
RESOLVED: Treat fit-content that way, too.
fantasai: Back to the inline axis.
fantasai: [example] 300x300 container. Image has "height: 200px".
fantasai: Goal of min-max/content is to represent shrink-to-fit
extremes.
fantasai: To match shrink wrapping, width:min-content should be
200px.
dbaron: That's fine for fit-content on the parent. I don't want to
change the behavior on the image itself.
fantasai: That's the point tho. A floating image with width:auto
is same as width:fit-content, right?
dbaron: I'd like to keep "auto" separate from that.
fantasai: My understanding was that the goal of "fit-content" was
to give the float behavior. But you're saying that's not
the case...
fantasai: for replaced elements.
gregwhitworth: I'm trying to understand what the engine is
supposed to do with that.
astearns: You've got a 300x300 image, set to 200px height.
astearns: What's the difference you want to see between
fit-content and auto?
fantasai: I don't, dbaron does.
dbaron: I'd like to see fit-content be the simple formula, but
maybe replaced elements is where you do something
different.
dbaron: I'm not comfortable with changing min-content, it
precludes us doing expression languages with them later.
dbaron: I was thinking fit-content would still be 300px (not
consider height property), but auto would be 200px.
dbaron: I might be okay with fit-content, but really not min or
max-content.
dbaron: In the future, if we want to write "calc(min-content *
1.5)"...
fantasai: If you want a keyword to access to size of a replaced
element no matter what, we can add that -
"intrinsic-size" or something.
dbaron: I'm willing to think about that more, but not accept it
today.
fantasai: The Grid spec defines auto sizing as max-content sizing.
fantasai: Pretty sure we want Grid to take this stuff into
account, so it's not just fit-content.
fantasai: I think generally the intrinsic size of an image isn't
useful.
[missed a little bit]
fantasai: I feel like if you wanted to multiply min-content by 2,
you want the result of shrink-to-fit, then multiply that
by 2.
fantasai: Or you want specifically for replaced elements to blow
up the image by 2.
fantasai: Which I think we already have a property for.
fantasai: But if you say "I want my grid track to be min-content
size", and some of the images have explicit height, you
want to use the altered height.
dbaron: I'm feeling less confident about fit-content now.
fantasai: We really just need to think about Grid here. We did min/
max-content with the understanding that it would do
something useful for sizing the track.
fantasai: If you're using it for the intrinsic size of the image,
that's kinda weird.
<fantasai> https://drafts.csswg.org/css-sizing-3/#extrinsic
astearns: Any further issues?
fantasai: Nothing we can resolve in the next 7 minutes.
ACTION fantasai and tab to rename "fill-available sizing" to
"stretch sizing".
<trackbot> Created ACTION-825
<break type=short><div id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br />
<table style="border-top: 1px solid #D3D4DE;">
<tr>
<td style="width: 55px; padding-top: 13px;"><a
href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon"
target="_blank"><img
src="https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif"
width="46" height="29" style="width: 46px; height: 29px;" /></a></td>
<td style="width: 470px; padding-top: 12px; color: #41424e;
font-size: 13px; font-family: Arial, Helvetica, sans-serif;
line-height: 18px;">Virus-free. <a
href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link"
target="_blank" style="color: #4453ea;">www.avast.com</a>
</td>
</tr>
</table><a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1"
height="1"></a></div>
Received on Tuesday, 14 February 2017 02:33:15 UTC