W3C home > Mailing lists > Public > www-style@w3.org > May 2020

[CSSWG] Minutes Virtual F2F 2020-04-29 Part III: CSS Sizing, CSS Align, CSS Ruby [css-sizing] [css-align] [css-ruby]

From: Dael Jackson <daelcss@gmail.com>
Date: Tue, 12 May 2020 19:06:44 -0400
Message-ID: <CADhPm3sQo2x9tT6_mh-5GfKL9BBSmKLPHf11WLMcOaAdzrmwYA@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Tuesday, 12 May 2020 23:07:29 UTC