- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 12 May 2020 19:06:44 -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.
=========================================
CSS Sizing
----------
- RESOLVED: Add an aspect-ratio option that supports fallback from
intrinsic ratio (Issue #4951: Mapping HTML’s IMG
aspect-ratio behavior into CSS)
- RESOLVED: Use the `<aspect-ratio>||auto` syntax (Issue #4951)
- RESOLVED: An aspect ratio specified with the auto option always
applies to the content-box (Issue #4951)
- RESOLVED: contain-intrinsic-size defines scrollable overflow area
for purpose of intrinsic sizing (including adding
scrollbars if so required); is ignored for the actual
scrollable overflow area during layout (Issue #4414:
Scrollbars when intrinsic-width is > width?)
CSS Align
---------
- RESOLVED: align-self affect the block static position of abspos
element (Issue #4983: Abspos alignment in vertical axis
should care about align-self, just like horizontal/
justify-self)
CSS Ruby
--------
- RESOLVED: Updated WD of css-ruby-1
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/virtual-spring-2020#day-one-time-slot-a
Scribe: AmeliaBR
CSS Sizing
==========
Mapping HTML’s IMG aspect-ratio behavior into CSS
-------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4951
fantasai: This is about the new behavior in the HTML spec about
using the img attributes for height and width, and use
that as the aspect ratio until the image loads.
fantasai: We'd like to map this to the aspect-ratio property, but
that property currently overrides intrinsic aspect ratio,
so wouldn't fall back once the image loads.
fantasai: Proposal is to add a new syntax that allows you set both
auto and a numeric ratio, so that auto is used if element
has an intrinsic ratio.
fantasai: There's more about sizing, but want to discuss that first.
TabAtkins: The proposal, just allowing both parts together, sounds
good for syntax.
astearns: Any concerns about the concept separate from syntax.
smfr: Is it clear what it means for an intrinsic ratio to be
available?
TabAtkins: Once an image has loaded, it's available.
astearns: I think we'd want to match HTML as much as possible.
cbiesinger: Is it possible specify aspect-ratio:
attr(width)/attr(height);?
fantasai: That's the idea.
plinss: The width and height attributes also affect the displayed
size, don't they?
fantasai: Yes, but that can be overridden in CSS, since they're
just mapped directly to the width/height CSS properties.
fantasai: But the aspect ratio can help it set the correct layout
box while also having one dimension responsive.
florian: Both the width/height and the aspect ratio would be based
on HTML attributes, but independently, so one could be
overridden but not the other.
fantasai: So this issue is about matching the HTML behavior.
<dbaron> I wonder why we don't also map the width and height
attributes to the intrinsic width and intrinsic height for
not-yet-loaded images.
<florian> +1, +1
<fremy> (+1 too fwiw)
[because we don't have a property to represent intrinsic width/
height in CSS]
<AmeliaBR> My question was how does this affect things other than
img? E.g., SVG?
fantasai: It should affect anything that provides an intrinsic
aspect ratio, that becomes the auto, other is fallback
<AmeliaBR> So, this could be a way to give a fallback for images
with no intrinsic aspect ratio, too.
fantasai: yes.
<AmeliaBR> OK, thanks!
astearns: I see lots of enthusiasm, any objections?
RESOLVED: Add an aspect-ratio option that supports fallback from
intrinsic ratio
astearns: any concerns on syntax?
RESOLVED: Use the `<aspect-ratio>||auto` syntax
fantasai: The other aspect of this is box sizing.
fantasai: We've defined that box-sizing affects the aspect ratio
calculation (is it ratio of border box or content box)
fantasai: But for intrinsic aspect ratios, that only applies to
the content box. If it applied to border box, the results
wouldn't make sense.
fantasai: With this new syntax, if you're using image width & height
attributes, you always want that to affect content box
even for the explicitly-specified <aspect-ratio>.
fantasai: Some options: If you use the auto keyword plus a ratio, it
always applies to the content box.
fantasai: Or, take an additional keyword to determine which box
applies.
<tantek> I'm wondering if that assertion (you don't want to include
the border in the aspect ratio) is true for form-control
like things, whether actual replaced form control elements,
or images being made to look like form controls.
<tantek> I don't have an answer, just wanting to raise the question
for consideration
dbaron: Doesn't this also affect width and height of image from the
elements?
fantasai: Yes, I think so. But maybe less of an issue in a modern
responsive layout where you're also using box-sizing.
fantasai: I can't see a reason you'd want intrinsic sizes to affect
the border-box. But I can imagine wanting an explicit
ratio to affect border-box. So auto could always be
intrinsic & keyword could only affect ratio.
florian: What about just always having box-sizing be used for
explicit?
fantasai: Because that wouldn't work for mapping attributes to an
explicit ratio.
astearns: We could always have defaults for html for now with option
of adding keyword later.
fantasai: We have three types of aspect-ratio values:
<fantasai> 1. aspect-ratio: <ratio>
<fantasai> 2. aspect-ratio: auto
<fantasai> 3. aspect-ratio: auto <ratio>
fantasai: In case of explicit ratio only, there's a good argument
for matching box-sizing. For auto, needs to match
content-box always. For third case (fallback), that's the
issue. Should explicit ratio apply to content box, despite
normal behavior, because of auto> Or do we match box-sizing
as for case 1, but have a syntax for switching to
content-box?
fantasai: So that would look like option 4
<fantasai> 4. aspect-ratio: auto <ratio> content-box
<fantasai> Behavior of 4 is required to map IMG. Whether it's
equivalent to 3 is the question
fremy: I can't see any case where you'd want to use auto and not
want the content-box. So I think it's solved by saying the
auto keyword means content-box
cbiesinger: Could you clarify? How does the box affect the
calculation?
fantasai: The box size should be the one that matches the aspect
ratio.
astearns: So the mood is that the new syntax, with auto, always uses
the content box. Any objections?
RESOLVED: An aspect ratio specified with the auto option always
applies to the content-box.
astearns: We can decide later if a keyword is necessary.
<tantek> I'm ok with prototyping it that way and quickly seeking
feedback on how it interacts with box-sizing of other
things in the layout
<TabAtkins> yup agree
<break>
Scrollbars when intrinsic-width is > width?
-------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4415#issuecomment-614345165
TabAtkins: Following along from the linked "top of thread"
TabAtkins: now that contain-intrinsic-size defined to give result of
doing child layout
TabAtkins: basically, pretend that bounding box of your laid-out
contents is this size
TabAtkins: should that trigger scrollbars or not?
TabAtkins: We think it should
TabAtkins: because if the contents were that large, they would
indeed create scrollbars
TabAtkins: And we're saying, here's a shortcut to running your layout
TabAtkins: cbiesinger brought up question of what does this mean for
intrinsic size?
TabAtkins: Is the intrinsic size that plus scrollbars or what?
TabAtkins: Have a specified width and auto height,
contain-intrinsic-size is wider than that, adds a
scrollbar to the bottom.
TabAtkins: Result of applying that is that width is specified width,
auto height is resolved according to
'contain-intrinsic-size' plus mbp
TabAtkins: If you add 'overflow: auto'
TabAtkins: contents wider than box would add a horizontal scrollbar
to the bottom
TabAtkins: Would height of scrollbar be added to the auto height
(based on contain-intrinsic-size)?
cbiesinger: There was a proposal in the issue that the used size
should be max of actual content size and
contain-intrinsic size, and that is where it gets
complicated
cbiesinger: because then you need to know the actual content size to
know whether there's a scrollbar
iank: For purposes of layout overflow calculation, the content size
rectangle is unioned with previous calc?
TabAtkins: Stepping away from contain-intrinsic-size for the moment
TabAtkins: if you have contain + overflow: auto
TabAtkins: assume zero size content
TabAtkins: If you add content, can you not scroll to it?
iank: Depends on impl
iank: We will currently add scrollbars, rerun layout
iank: This will affect intrinsic size of the box
iank: Unsure what Firefox does
dholbert: We do not do that relayout
dholbert: We treat it as zero height / width as if explicitly
specified
dholbert: In the case of zero width/height, you wouldn't see it
cbiesinger: Don't remember how we handle this, we maybe increase the
size of the element
TabAtkins: dholbert, if you have 'contain: size' element with
specified height of '100px' and ?
TabAtkins: would you say that Firefox won't show scrollbars?
dholbert: If we have space to show scrollbars we will
dholbert: Just won't influence sizing of the box
TabAtkins: That's reasonable to me, and if that's what we want to be
more specific about, I'm fine with doing that
cbiesinger: I think that's more reasonable behavior
AmeliaBR: Balance of that is, if there is room for scrollbars we
will put them
AmeliaBR: if the intrinsic size is bigger than contain size
AmeliaBR: Then there will be scrollbars, the same as for content
larger than for the contained size
cbiesinger: Downside is that you'll definitely get scrollbars in the
other side, too
TabAtkins: oh, yes, because if you say `contain-intrinsic-size:
200px`
TabAtkins: ...
AmeliaBR: Proposal I suggested was that, as soon as you know you
have scrollbars, you only do either the intrinsic sizing
or the content and the intrinsic size goes away
AmeliaBR: Another thing I just thought of is we have an option for
an overflow value where the scrollbars never take away
content size
AmeliaBR: Is there a way maybe to say, for the purpose of the
'contain-intrinsic-size' calculation, we always treat as
overlay scrollbar instead of as scrollbar that takes away
content size?
AmeliaBR: While still laying out the actual content size as normal?
TabAtkins: In other words, treat 'contain-intrinsic-size' rectangle
as ignoring scrollbar for determining if there's overflow
in a given axis
Scribe: TabAtkins
fantasai: I think we should say the actual scrollable overflow area
is the union of the content and contain-intrinsic-size
fantasai: But size the box as if the scrollable overflow area is
only the area given by contain-intrinsic-size
fantasai: You'll possibly need to add a scrollbar then, but it's
only dependent on contain-intrinsic-size, not content
fantasai: If your contain-intrinsic-size is accurate (matches
content size), you'll get scrollbars, and size will
accommodate the scrollbars as you'd expect
fantasai: If contain-intrinsic-size is too big, you'll get to scroll
to more area than the content actually takes
fantasai: If contain-intrinsic-size is too small, you might get two
scrollbars rather than one, but you'll still be able to
scroll to everyone
<tantek> As much as we want to avoid having unviewable content, I'd
also like to see us adopt a principle of making it *easy*
for web authors to avoid automatic scrollbars showing up
especially when "it doesn't seem like they should be needed"
<tantek> yeah I pretty much hate this problem
<tantek> would really prefer to avoid situations where we make the
layout so scrollbar-fragile that it's too easy to cause
scrollbars
cbiesinger: The scrollbar is still in the area defined by
contain-intrinsic-size, right?
fantasai: If you have an element sized to fit content exactly, and
then you set that size explicitly, then add more content
that creates a scrollbar, you end up adding a scrollbar to
the bottom as well.
fantasai: So you can still scroll to see everything, but one of the
scrollbars might just be scrolling a tiny bit
fantasai: You'll get into that situation if your
contain-intrinsic-size is inaccurate.
cbiesinger: I think if you overflow in one direction, you'll always
get two scrollbars.
fantasai: Say you have 100x100 box, contain-intrinsic-size is 200px
tall, you'll get a vertical scrollbar
cbiesinger: If your scrollable area is the union of content and
contain-intrinsic-size
cbiesinger: Then contain-intrinsic-size needs to be scrollable-to.
And since scrollbar is in that area defined by
contain-intrinsic-size, you'll always need a scrollbar
for it.
<tantek> in particular when a vertical scrollbar shows up e.g. due
to fantasai's example, it should not *also* cause a
horizontal scrollbar
<tantek> that's a particularly bad side-effect to avoid
Scribe: fantasai
fantasai: No, that's not what I'm saying
fantasai: What I'm saying is, you size based on
contain-intrinsic-sizeize
fantasai: and contain-intrinsic-size increases size of scrollable
overflow area
fantasai: potentially causing scrollbars, which get accounted for
fantasai: based on that, you size the box.
fantasai: Then after you lay out the contents, you increase the
scrollable overflow area (if needed) to fit the contents,
so that you're not clipping anything
fantasai: This increases the size of the scrollable overflow area,
but does not change the size of the box
fantasai: So you might get extra scrollbars added if your
contain-intrinsic-size value wasn't accurate. But at least
you can see all the contents
<cbiesinger> <div style="width: 100px; contain-intrinsic-size: 100px
100px; overflow: auto;"><div style="width:
120px;"></div></div>
<cbiesinger> you get a horiz scrollbar. this covers up the bottom
15px or so of the 100px contain-intrinsic-size
<cbiesinger> but the scrollable area is the union of actual content
and contain-intrinsic-size
<cbiesinger> so you need to be able to scroll to that
<cbiesinger> no?
TabAtkins: So, example here, you have a float
TabAtkins: it is contain-intrinsic-size of 200px x 200px
TabAtkins: specified height of 100px
TabAtkins: This should create a vertical scrollbar on the right
TabAtkins: What should be the float's width, assuming no mbp?
TabAtkins: Should it be 200px or 216px, to account for scrollbar
<tantek> Thank you TabAtkins, that's exactly the problem I was
referring to
<cbiesinger> yes, that's what I was asking too
fantasai: Yes, it would be 216px
cbiesinger: How can that be 216px if the scrollbar doesn't affect
the size of the box?
AmeliaBR: So a scrollbar form content shouldn't affect the size of
the box, but a scrollbar from contain-intrinsic-size
should affect the size of the box?
AmeliaBR: If we're in a context where just the dimensions that we
have on the container, combination of explicit sizes plus
contain-intrinsic-size are enough to create a scrollbar
AmeliaBR: and usually scrollbar would be outside the content
AmeliaBR: Normally a scrollbar would go inside defined width of
container
AmeliaBR: but not necessarily in something like a float, which
doesn't have a defined width
<cbiesinger> <div style="width: 100px; contain-intrinsic-size: 100px
100px; overflow: auto;"><div style="width:
120px;"></div></div>
fantasai: In that example, your width is specified, so it won't
grow. contain-intrinsic-size width is fine. There's no
height specified, so it sizes to 100px tall.
cbiesinger: You end up a horizontal and a vertical scrollbar
cbiesinger: because horizontal scrollbar takes up space
<iank> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=8034
<iank> (view in chrome canary)
fantasai: Yes. But size of box would be 100px, doesn't grow
cbiesinger: Right, then the content is 120px tall, so you need a
vertical scrollbar. And that covers up part of the 100px
contain-intrinsic-size, so you get a horizontal
scrollbar too
fantasai: yes
dholbert: I think mental model of it that makes sense:
dholbert: Sounds like we size scrollable overflow area as if only
one child size of contain-intrinsic-size
dholbert: Other elements are sized similar to abspos, don't affect
sizing
dholbert: I think that approximately matches
TabAtkins: Problem with children: grid + multicol act very
differently if have one child
TabAtkins: If ignore that, pretend block layout with one child, that
works
cbiesinger: So Ian's testcase, Chrome is wrong
<cbiesinger> Ian's testcase would get two scrollbars, then
iank: So width of this element should be 100px?
fantasai: That's what I'm saying
fantasai: The point of the feature was that box doesn't resize in
response to contents
fantasai: so should not change size
fantasai: but also should not clip contents, or make them
inaccessible underneath scrollbars
TabAtkins: So use contain-intrinsic-size to figure out if you need
to add a scrollbar
TabAtkins: but then when do layout, then ignore
contain-intrinsic-size for purpose of scrollbar
TabAtkins: So adding vertical scrollbar for excess content won't
change the size
TabAtkins: but won't trigger extra scrollbars due to
contain-intrinsic-size
TabAtkins: Want content to be reflowable, and avoid unnecessary
scrollbars
TabAtkins: so contain-intrinsic-size should factor into scrollable
overflow area during intrinsic sizing
TabAtkins: but not affect the scrollable overflow area when actually
laying out the content
cbiesinger: Makes sense
fantasai: +1
iank: So during intrinsic sizes phase, if we have size containment,
we ignore the scrollbar, but if not we include?
cbiesinger: In intrinsic size phase, include scrollbar if
contain-intrinsic-size triggers overflow
cbiesinger: for actual layout, do what we do today
TabAtkins: I think we fall back to model where post doing intrinsic
size layout, lay out as if that was an explicit width +
height
TabAtkins: Proposed resolution is, 'contain-intrinsic-size' is used
to figure out whether or not scrollbars should show up
during sizing of container. Scrollbars that would appear
are factored in.
TabAtkins: but when doing layout of interior contents,
'contain-intrinsic-size' has no effect -- cannot trigger
additional scrollbars. Only the actual contents affects
scrollbars
<tantek> I agree with the resolution, and let's explicitly capture
the principle that no additional scrollbars should appear
RESOLVED: contain-intrinsic-size defines scrollable overflow area
for purpose of intrinsic sizing (including adding
scrollbars if so required); is ignored for the actual
scrollable overflow area during layout
cbiesinger: There can be actual scrollbars depending on the actual
contents, just not based on contain-intrinsic-size
<tantek> Right what Tab said, not caused by the
contain-intrinsic-size value
astearns: let's get testcases
AmeliaBR: Scrollbars should not be caused by interaction of actual
content and contain-intrinsic-size
<cbiesinger> yeah, I think AmeliaBR is right wrt the interaction not
causing additional scrollbars
<TabAtkins> So in `div { width: max-content; contain-intrinsic-size:
100px 100px; overflow: auto; }` with 150px of content,
the element is 100px by 100px, with a vertical scrollbar
only. (Unless for some reason there's an unbreakable
inline in the content that wouldn't fit into 84px.) But
in `div { width: max-content; height: 50px;
contain-intrinsic-size: 100px 100px; overflow: auto; }`
with 150px of content, the element is 116px by 50px with
a vertical
<TabAtkins> scrollbar, because the cis overflowed the specified
height and triggered a scrollbar, so scrollbar size is
part of the max-content size. The content lays out into
there, and continues to have *only* a vertical
scrollbar, again unless the content has an unbreakable
inline long enough to force a horizontal one.
<cbiesinger> TabAtkins: that matches my understanding
CSS Align
=========
Scribe: fremy
Abspos alignment in vertical axis should care about align-self
--------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4983
fantasai: When you use abspos, and auto inset on both sides, when we
try to find its static position
fantasai: This historically depends on the direction of its
containing block to decide on which margin we ignore.
fantasai: If you use alignment properties however, like end, then we
decided to honor that.
fantasai: We didn't do that in the vertical axis however
fantasai: So, the question is why not?
fantasai: I would like to make that change, and propose it to the
group.
iank: Today, justify-self affects where the static position is in
the inline position of the static containing block, not the
actual containing block.
fantasai: Yes
fantasai: The proposal is to also do that in the other direction (in
the block axis) of the static block containing block.
iank: Don't we do that for flexbox?
fantasai: Maybe, I'm not sure
Rossen: I'm pretty sure we do
iank: If that's in the direction of the static block containing
block, that sounds fine to me
fantasai: ok
iank: That sounds good to me then
cbiesinger: One concern though
cbiesinger: So far, all properties don't affect all layout modes
cbiesinger: like in flexbox, justify-self don't apply (?)
cbiesinger: Not sure we should change that
fantasai: That's an interesting point
iank: justify-self doesn't work today
fantasai: I think we should take that as a separate question
fantasai: Whether to make justify-self apply to the flexbox case
<iank> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=8037
iank: I am looking at what chrome is doing today
iank: Basically justify-self should probably work on that case, that
seems fine to me
cbiesinger: But justify-self doesn't mean anything for flexbox,
that's why it doesn't apply though
iank: We might run into some webcompat issues yeah
cbiesinger: webcompat is one thing, but more than that, I'm not sure
it makes sense
fantasai: We want to make align-self apply in the vertical axis (?)
fantasai: align-self does not affect the static position in that
layout mode but it would probably be useful
iank: You mean block direction of the static containing block right?
fantasai: Yes
iank: And in block layout?
fantasai: staticpos rectangle is defined to be zero height in that
case
iank: Still sounds fine then
astearns: So, do we make that a proposed resolution ?
astearns: Any objection to that?
astearns: If that doesn't cause webcompat though
fantasai: We definitely need to look into flex more closely, but I
think the case we discuss now should be fine wrt web compat
astearns: Proposed resolution is to have align-self affect the block
static position of abspos element
astearns: Any objection?
RESOLVED: align-self affect the block static position of abspos
element
Schedule
========
astearns: We are about out of time
astearns: We didn't finish the agenda for the day
astearns: So I think we should probably have special meeting the
next week also
<TabAtkins> I highly suspect we'll want more meetings around this -
going from 24ish hours of meetings to just 8 is, uh,
tight.
astearns: We usually don't have meetings the week after a f2f but
this is special
<TabAtkins> And yeah, getting another meeting next week would work
for me, maybe shifted to be APAC-friendlier?
CSS Ruby
========
<fantasai> https://lists.w3.org/Archives/Member/w3c-css-wg/2020AprJun/0065.html
fantasai: Can I get new updated working draft? [explains changes
since 2014]
astearns: Ok, no strong feedback
astearns: So we are resolved to publish an update of the draft
RESOLVED: Updated WD of css-ruby-1
[ This was published at https://www.w3.org/TR/2020/WD-css-ruby-1-20200429/ ]
Received on Tuesday, 12 May 2020 23:07:28 UTC