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

[CSSWG] Minutes Telecon 2020-07-08 [css-color-5] [css-sizing-4] [mediaqueries-4]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 8 Jul 2020 18:58:26 -0400
Message-ID: <CADhPm3tJ3aBfaQrU=ZkZ9rh0h-PeWdMAV_RYEQWpmHqThRWi=A@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.

Color 5

  - RESOLVED: Publish Color 5 once #4711 (color-mix to allow more than
              two colors?) is edited in and there's a major changes

F2F Meeting

  - A virtual F2F is being planned around the time that the in person
      F2F was originally scheduled. Group members are encouraged to
      participate in planning on the private mailing list.

Sizing 4

  - RESOLVED: Min-content and max-content keywords represent size of
              element at top and bottom extremes of fit-content or
              shrink-to-fit sizing and therefore match size it would
              take under a min or max constraint when taking
              aspect-ratio into account (Issue #5032: Should
              aspect-ratio affect the intrinsic size?)
  - fantasai will evaluate the layout specs and analyze what should
      and shouldn't be aspect-ratio dependent. With that analysis she
      will propose terms to add to the specs which would define the
      two concepts. She'll also open a new issue to determine if these
      two concepts need to be keywords too (Issue #5032).
      - If a keyword is created current name suggestions are
          contain-intrinsic-size and natural-size
  - Issue #3268 (Rethinking how to prevent overflow in a container
      with an explicit aspect ratio) may need to be re-opened to
      reconsider what the default value should be.
  - Another issue will be opened to define in spec exactly how
      transferring size should happen and if the content-based size
      goes through the aspect-ratio.

Media Queries 4

  - RESOLVED: Drop the [overflow-block:optional-paged] value with a
              note explaining why (Issue #5287: Drop


Agenda: https://lists.w3.org/Archives/Public/www-style/2020Jul/0003.html

  Rachel Andrew
  Rossen Atanassov
  Amelia Bellamy-Royds
  Mike Bremford
  Oriol Brufau
  Tantek Çelik
  Hui Jing Chen
  Dave Cramer
  Simon Fraser
  Megan Gardner
  Daniel Holbert
  Dael Jackson
  Brad Kemper
  Chris Lilley
  Peter Linss
  Alison Maher
  Myles Maxfield
  Tess O'Connor
  Manuel Rego Casasnovas
  François Remy
  Florian Rivoal
  Cassondra Roberts
  Devin Rousso
  Jen Simmons
  Alan Stearns
  Miriam Suzanne

Scribe: dael

  astearns: I think we've got enough people to go. Is Tab on?
  astearns: First agenda is what Tab introduced, not sure if it's
            ready on the call yet. Does anyone on the call want to
            cover or should we wait?
  Rossen: Wait

Color 5

  Rossen: I wanted to have a quick question on Color 5 publication
          state and if we'll see a WD update soon because there are
          people experimenting with the features in the ED but not the
  Rossen: Weird to link to the ED, prefer WD
  astearns: Do we have a Color 5 editor on?
  tabatkins: As a helper I'd like that. I expect we can soon
  Rossen: Can we record a new resolution?
  Tab: Yeah

  miriam: And Colors 5 is still a diff spec so we're okay publishing a
          diff spec?
  many: Yep.
  astearns: Tools may hiccup but we've done it before

  astearns: Proposed: Publish a WD of Color 5
  astearns: Is this regular or first?
  Rossen: Regular
  astearns: Objections?
  fantasai: Is there a list of major changes?
  <AmeliaBR> Changes since FPWD:
  Rossen: Some include syntax of color-mix function as well as LAB and
          new color spaces added
  Rossen: I don't know if there's a changes list, but I'd encourage
          authors to add one

  <fantasai> https://github.com/w3c/csswg-drafts/issues/4711
  fantasai: Issue marked as needs edits. Maybe that should go in full
            publish. #4711
  Rossen: I see.
  Rossen: Defer to authors

  astearns: Is color-mix being implemented?
  fantasai: Yes
  Rossen: Yes, it's the one being worked on
  astearns: Then it would make sense to get it in before republish

  astearns: Proposal: Publish Color 5 once #4711 is edited in and
            there's a major changes list
  Adam: All of these resolutions are perfect
  chris: Changes list in Color 5 is up to date as of a week ago

  RESOLVED: Publish Color 5 once #4711 is edited in and there's a
            major changes list

  astearns: Any other agenda changes?
  florian: If we get to #10 and a resolution on it I'd like to discuss
           MQ4 as CR

F2F Meeting

  astearns: Other housekeeping; we had a F2F at end of month. We're
            proposing virtual meetings in that week. Possibly could
            move earlier but not later. Please respond on private list
            about the dates.
  astearns: Other changes?

CSS Sizing 4

Should aspect-ratio affect the intrinsic size?
  github: https://github.com/w3c/csswg-drafts/issues/5032

  <fantasai> https://github.com/w3c/csswg-drafts/issues/5032#issuecomment-639874263
  fantasai: Here's summary comment for Tab and I ^. It's complicated
  fantasai: I guess people should read it
  astearns: I think people can read and listen to a summary

  fantasai: Question was for min-content and max-content size; does
            aspect-ratio impact what they resolve to
  fantasai: We went through what are the design constraints. One is
            currently on an image with aspect-ratio if you spec size
            as auto and height in one axis other axis responds.
  fantasai: Take a 1x1 image naturally 200px. If you make it 100px
            tall it's 100px wide with auto width
  fantasai: Intention of the stretch and fit keywords was replicate
            behavior of css 2 blocks. Fit-content is shrink to fit and
            stretch is fill the box. Tables were shrink and now can
            ask to fill container.
  fantasai: We then added min- and max-content which is min and max
            range of fit-content. There's a min- and-max content
            range. Intended to map to extremes of fit-content size
  fantasai: Authoring point of view seems having width min-content has
            same sizing as if sized under min-content constraint.
            Float is shrink to fit in a 0 size container it's as small
            as it can be and that's min-content size.
            width:min-content is same result
  fantasai: Last constraining factor is aspect-ratio property if you
            apply to replaced element it should have same behavior. An
            iframe with aspect-ratio behaves same as SVG with an
  fantasai: Those are design constraints.
  fantasai: Resolution of #3268 which was how to have strict
            aspect-ratio vs allow content to stretch box. Example is
            you have 1x1 cards, fill with text, text is too big and
            want card to grow. But sometimes you want strict. Author
            can choose if they want strong constraint
  fantasai: Current resolution to do that is when you spec
            aspect-ratio initial value of min-width or min-height
            being auto, auto resolves to content-height. That allows
            it to like any min-size blow out aspect-ratio. That's in
            #3268 so assuming we want that to continue it's a
  fantasai: Thought through the constraints.

  Rossen: I don't want to cut in front of the solution. But as I'm
          getting up to speed I'm a strong advocate to keep
          aspect-ratio or the dependencies of min- or max-content on
          the cross axis; keep aspect-ratio away from contributions to
          min- or max-content.
  Rossen: Instead treat similar to the way we do percent in a shrink
          to fit case where resolve to 0 and only content contribution
          is those that are computable
  Rossen: To me aspect-ratio is another form of percent where instead
          of looking at container, example width axis, you're looking
          at cross axis. So we don't take other dependencies like this
          one for max-content.
  Rossen: But that's me talking before you spoke of conclusion
  fantasai: Taking that comment; there's 2 sizing concepts.
            Min-content size of item which is size it reports when you
            give it a min-content keyword. Other is min-content
            contribution which is what it contributes to the parent.
            If it's inside a float what size does it ask the float to
  fantasai: Take a png image that's 100x100, height is set to 50px. We
            can argue what width:min-content is but we can't argue if
            it contributes 100px because breaks the web. To be
            consistent with what images do right now has to account
            for aspect-ratio
  fantasai: We cannot change that. This is about what is size returned
            when you ask for the keyword

  Rossen: Proposal to separate behavior or keep consistent?
  fantasai: Consistent. Back to the image example if you ask for
            width:min-content on the image. The min-content
            contribution is 50px because that's what it has to be.
            Question is does it return 100px with is natural or 50px
            which is size it would have to take.
  fantasai: Currently implementations return 100px. We're arguing
            should be 50px to match size it would take if sized under
            min-content constraint and reported contribution
  AmeliaBR: Argument is this is a breaking change but because min- and
            max-content keywords are fairly new and this is a bit of
            an edge case it should be okay to correct this as if it
            was a bug in original spec impl
  fantasai: Yeah. Spec is clear that's intended output. This change
            would only effect replaced elements with an aspect-ratio.
            Current behavior on non-replaced elements doesn't change.
            For images with an aspect-ratio whatever behavior you
            wanted from min- or max-content you would get from auto so
            author has no reason to use this keyword

  AmeliaBR: You talked with people on impl teams and people are
            willing to change?
  fantasai: Talked to Blink and Gecko and they seemed to believe it's
  AmeliaBR: Are there webket devs on call that disagree?
  smfr: Probably happy to, don't know enough to say definitively
  AmeliaBR: For basic spec I agree having these keywords behave same
            way as logical concept where they respect aspect-ratio
            that's the ideal spec definition. Unless web-compat
            concern I'd say change

  Rossen: I think I'm okay with proposal and it aligns with my
          previous description. Question; what happens for
          align-stretch cases or align-height:min-content
  Rossen: Are there cases where you will be asked to compute
          aspect-ratio in current constraint while looking at cross
          size in order to compute defined height and get aspect-ratio
          out of it?
  Rossen: Or is it only when height or min-height is defined
  cbiesinger: In block min- and-max content don't do anything. There's
              an issue to change that pending dbaron input
  Rossen: So only time this takes effect is if cross-axis is fixed
  cbiesinger: Yes
  Rossen: Reasonable

  fantasai: Do we want to pause and resolve on that before we go to
            second part of issue?
  <florian> +1
  astearns: I'm hearing a lot of this sounds possible. Can you
  fantasai: Proposal: Min-content and max-content keywords represent
            size of element at top and bottom extremes of fit-content
            or shrink-to-fit sizing and therefore match size it would
            take under a min or max constraint
  astearns: And it would match constraint when taking specified aspect
            ratio into account
  fantasai: Yes

  dbaron: Starting to think, does this introduce problems when both
          width and height use these keywords?
  fantasai: Currently the rules; need to clarify how the interact.
            auto, auto for example aspect-ratio only takes effect in
            block axis. Fixed height and auto width aspect-ratio does
            width. If both are auto or a content keyword we resolve
            width and use aspect-ratio to get height
  dbaron: A little worried about interesting cases where height is
          fixed but max-height that's min-content and could constrain
          off of fixed value. Don't know
  cbiesinger: And it's because that we don't support min-content in
              block axis
  fantasai: One of the rules we thought of is when you transfer sizing
            constraint through aspect-ratio you don't transfer an
            indefinite size
  fantasai: That's not yet explicit in spec
  fantasai: I think we need that regardless
  dbaron: If you think it's okay that's fine. Haven't thought through
  fantasai: If some kind of difficulty in a combination of keywords
            and aspect-ratio we should address it there instead of
            changing global. I haven't thought through every possible
            combo of sizing algorithm. I think we should start here

  astearns: Other discussion about the resolution or objections?
  AmeliaBR: Sounds like second possible resolution about aspect-ratio
            is ignored if transferring indefinite size
  AmeliaBR: Just saying 2 resolutions
  astearns: Not hearing objections to first.

  RESOLVED: Min-content and max-content keywords represent size of
            element at top and bottom extremes of fit-content or
            shrink-to-fit sizing and therefore match size it would
            take under a min or max constraint when taking
            aspect-ratio into account

  astearns: Do you want to talk about AmeliaBR second item or
            something else on this?
  fantasai: Something else on this issue.
  fantasai: Now we'll get into interactions with other resolution
  fantasai: We have definitions but we also have 2 different behaviors
  fantasai: I have a non-replaced element with fixed width 100px and
            aspect-ratio of 1 to 1.
  fantasai: If content is too much I want it to stretch out the size
            of the box and not be 1x1
  fantasai: #3268 we said you get that when min-height is auto
  fantasai: Means min-height:auto can't respect aspect-ratio. Its job
            is not to in order to create min-height value that's larger
  fantasai: So keyword auto sometimes has this functionality. When it
            has this functionality no keyword except auto grants it.
            We have behavior we can't represent unconditionally
  fantasai: Also have concept that's different than min/max-content
  fantasai: May or may not need separate keyword. Definitely need
            concept in spec.
  fantasai: tabatkins and I suggested we should go through specs and
            split concept of while respecting aspect-ratio and while
            not because we have min/max-content after keywords.
            Introduce 2 new terms to ignore the constraint.
  fantasai: Given we use intrinsic in contain-intrinsic-size we
            propose min/max-intrinsic.
  fantasai: Could be a keyword to width and height properties.
            Certainly need terms in the specs and audit all the layout
  fantasai: That's the direction we're going in and wanted to ask WG
            what they think.

  florian: As you stated, this is complicated. I thought previous
           resolution only made difference for replaced. This only
           matters for non-replaced elements. Therefore I'm not sure
           why separate keywords. Do we?
  fantasai: There is slightly different behavior. I'm not sure if we
            need one. Behavior difference is in non-replaced case in
            order to be consistent with replaced min/max-content
            keywords have to respect aspect-ratio.
  florian: What does it mean for non-replaced to honor aspect-ratio on
           block axis min-content
  fantasai: Have aspect-ratio. Apply to non-replaced block it should
            apply aspect-ratio to that
  fantasai: Supposing I have a 1x1 box. Have too much content give a
            fixed width of 100. Height is auto which means takes
            height from aspect-ratio width. Since it's 1x1 with 125px
            so height is 125px. Min-height looks up height of content.
            min-height wins. Will be 125px tall. In order to get that
            auto has to resolve to content height which is not same as
            min or max height because they're using the aspect-ratio
  fantasai: Height:min-content or max-content would resolve to 100px.
            min-height min-content will not give you the behavior of
            grow to fit. min-height: auto we decided should
  fantasai: Two concepts. Min-height:auto has the extra magic. If we
            want a content for always the content-baseline height we
            need a keyword
  florian: I thought about previous for only replaced elements. If
           we're not doing that we need what you said at least as a
           concept and maybe a keyword

  dbaron: Haven't fully processed layout. Naming aspect comment. Way
          we ended up with min/max-content was there was originally a
          concept in spec we called intrinsic-size and impl called
          that. I proposed min-intrinsic size, people thought too
          complex and we used content instead of intrinsic
  dbaron: Then seems weird to me is that they meant the same thing but
          then we introduced contain-intrinsic-size when we had named
          it out of the language. Seems odd for intrinsic to mean
          something different instead of a word to describe the
  fantasai: I'm happy to take alternative names. I think it makes
            sense to make sure contain-intrinsic-size renamed
            accordingly. Another name would make it easier to audit
            spec. Would be great to have another term.
  fantasai: Could for with natural-size which I think is in HTML

  AmeliaBR: Leaving aside naming issue; I think to get this behavior
            where aspect-ratio is ignored in order to contain
            overflow...I don't think that should be default of
            min-height and not what min-height:auto does. Would be
            confusing for those starting to use aspect-ratio. Works
            fine with small text but once have real world text you
            have an element stretching out to contain overflow
  AmeliaBR: I think that's confusing default behavior that
            aspect-ratio is ignored. Regarding min-height it would
            mean auto does respect the aspect-ratio and we need a new
            keyword for min-height to contain the content
  florian: I disagree I think. We have had that discussion and
           previously resolved. I think we can continue on this topic
           without re-opening. If we're re-opening I disagree because
           it means you get overlapping content by default and authors
           need to deal with people resizing text. It's much safer
  AmeliaBR: We have this with absolute height. A min-height:auto
            doesn't override that. If you define height in terms of
            width and aspect-ratio that's less powerful then define
  florian: If we're going to add a keyword we can discuss that
           separately. Maybe we re-open the other issue. I disagree
           but I don't want to hijack. Topic is getting a keyword that
           would do this. You're wanting a keyword to do this, if it's
           the default or not is separate
  fantasai: Depends on if you set overflow. If it's visible we have
            the content behavior. If you have scroll it resolves to 0.
            But that's the other issue, as florian said. #3268

  astearns: Make sense to open a separate issue about these keywords,
            do research on these keywords in various layout models,
            and not resolve today. This proposal doesn't seem quite
            fleshed out for a resolution. Not hearing objections to
  AmeliaBR: fantasai talked about auditing specs to see which uses
            should or shouldn't be aspect-ratio dependent. Nice to
            have that list
  fantasai: If we add keywords or not the key is to name them because
            we do have two concepts. Here it's about we need terms. I
            think term proposals are min/max-intrinsic and min/
            max-natural. We can open separate issue on terms
  florian: I would argue against intrinsic because if we have both I
           would expect the inverse between intrinsic and content.
  <fremy> +1 to what florian just said
  astearns: Let's open a new issue and discuss what names we might use
            on GH and discuss if we need to add them as values in CSS
            or in spec terms.

  cbiesinger: Previous was to change min-content definition
  fantasai: Proposal was keep it as is in spec right now
  astearns: Let's close this discussion.

  astearns: Should we go back to transferring sizes?
  AmeliaBR: Nothing to argue on that. fantasai said something isn't
            currently clear in spec. Up to her about if it should be
            clarified at this point
  fantasai: Transferring in general I think content-base size
            shouldn't go through aspect-ratio. But I think if you have
            shrink to fit with everything initial value, aspect-ratio
            should have some effect. I have to come up with wording
            but I can open an issue
  AmeliaBR: Okay. We'll follow up
  astearns: Anything more on this issue?

Media Queries

Drop overflow-block:optional-paged
  github: https://github.com/w3c/csswg-drafts/issues/5287

  florian: We have the overflow-block MQ which lets you ask if you're
           paginated or scrolling document when you overflow
  florian: One value, paged, is optional. Hybrid and last found in
           Opera 12. Looked normal but if you put a forced break you
           get a new page. If user set browser for presentation mode.
           It's like screen but you can get pages. That's optional
  florian: Opera 12 no longer ships and no other UA does this. I don't
           expect it to be implemented any time soon.
  florian: Also, I'm not sure next time someone experiments with that
           kind of behavior that they'd do it like Opera so I'm not
           sure spec should define how impl behaves
  florian: In favor of dropping this. fantasai argued mark at-risk
           which is normal for spec but not impl. Since I think it's
           not clear that mode wouldn't be used as spec prefer drop
  tabatkins: Agree with florian

  AmeliaBR: No reasonable expectation of any impl to match this
            between CR and REC?
  florian: We wouldn't. Interesting reason to leave it in is if
           someone wants to experiment to something like that they
           wouldn't map to the other values. Could be a note saying if
           you're doing none of these come talk
  tantek: Could leave with either option. Concern from content side
          where if it did exist there might be content out there using
          it. Could we consider 3rd option to mark as obsolete to say
          it was exposed to web
  fantasai: MQ wasn't
  florian: Browser that behaved like this existed, but didn't have MQ
  florian: Browser shipped the behavior but didn't have the value
  tantek: How did they ship?
  florian: If user pressed F11 they would get forced pages, but no MQ
           to get that
  fantasai: Responded to presentation media-type so that's how you
            could get it. It was before MQ4 existed
  tantek: Obsolete the presentation-type already?
  florian: Yes
  tantek: Okay dropping. Also okay in a draft as at-risk and it will
          be dropped in next draft. Gives public a chance.

  astearns: We have a good signal from implementors that none are
            looking into this. Prefer to drop though happy to have a
            note we're dropping without prejudice. No implementations
            now but we're open to experimentations
  florian: Put note in section so if UA have interesting another mode
           you should talk to us since we had an interest.
  tantek: But looking for impl interest
  astearns: Proposal: Drop the value with a note explaining why
  <tantek> +1

  RESOLVED: Drop the [overflow-block:optional-paged] value with a note
            explaining why

  fantasai: New publication?
  florian: I have DoC and changes section and tests. Before resolving
           I do want to ask for another item to be at-risked.
  astearns: So that's got to go into next week's agenda.
  astearns: Thanks all.
Received on Wednesday, 8 July 2020 22:59:25 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:15:14 UTC