[CSSWG] Minutes New York F2F 2022-08-03 Part IV: CSS Sizing; CSS Shapes [css-sizing] [css-shapes]

  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: Clarify that aspect-ratio:auto doesn't pull aspect ratio
              from the default object size, it can only pull from an
              actual loaded resource (Issue #7524: aspect-ratio via
              width and height attributes doesn't work for <video>)
  - A new issue will be opened to further discuss the proposal that
        applying an aspect ratio via aspect-ratio property prevents
        the natural size from falling back to the default object size.

CSS Shapes

  - RESOLVED: Update the basic shape functions and update
              radial-gradient (Issue #824: ellipse() grammar
              gratuitously inconsistent with radial-gradient())


Agenda: https://github.com/w3c/csswg-drafts/projects/30

Scribe: bramus

CSS Sizing

aspect-ratio via width and height attributes doesn't work for <video>
  github: https://github.com/w3c/csswg-drafts/issues/7524

  TabAtkins: So, the aspect ratio property has the auto keyword and it
             will take the aspect ratio from the resource otherwise use
             the other one as the fallback
  TabAtkins: This works great, except for video
  TabAtkins: because video does not communicate the aspect ratio
  TabAtkins: Instead the size is 300 by 150
  TabAtkins: and the algorithm will say cool I have an aspect ratio
  TabAtkins: Needs a small fix, suggested by jaffathecake
  TabAtkins: New concept of pending your first resource size instead of
             "do you have an aspect ratio" ask "have you ever received
             an aspect ratio from your content?"
  TabAtkins: If not use the fallback from the aspect ratio property
  TabAtkins: this would fix the problem so that img and videos are not
             considered to have an aspect ratio until they load their
  TabAtkins: It is flipped when they obtain the aspect ratio
  TabAtkins: Other reason for a f2f because the relevant algorithms are
             in images-3

  fantasai: Why do we ignore width and height in favor of the 300 by
  fantasai: If we have better info shouldn't we us that instead?
  TabAtkins: Correct

  emilio: To clarify, this only changes behavior before the video loads
  TabAtkins: Correct
  <iank> There is also some special behaviour for video image
         placeholders I think.
  emilio: I think images are a bit special ?? when there is mapped
          aspect ratio
  <emilio> https://searchfox.org/mozilla-central/rev/417eb46de41c31c3223d7b84c275ba56fc7d4343/layout/generic/nsImageFrame.cpp#659-661
  emilio: So why don't we do the same for video?
  emilio: Here is the gecko code for image intrinsic sizing
  emilio: Fallback has a lot of stuff
  emilio: but basically intrinsic size is 0 if broken
  emilio: ???
  emilio: Why cant we do same for video
  emilio: That function does a lot of stuff … once you get to the
          bottom the intrinsic size of a broken img is 0x0
  emilio: Instead of that, have it check if you have an aspect ratio
          then return no intrinsic size and use the aspect ratio instead
  emilio: I don't see how that isn't gonna work for video
  emilio: I think we need just the same check also for video

  iank: I want to point out that videos are more complicated
  iank: They define a poster image and we get the aspect ratio from
  emilio: We also do that
  emilio: check the actual video, check the poster, and then the
  TabAtkins: In the html spec, images do not have a fallback size
  emilio: Yes, 0x0
  TabAtkins: So we do not want that for video
  fantasai: ??? if you have an aspect ratio use that and not the
            default object size
  TabAtkins: Where would this change be? html?
  emilio: Possibly
  emilio: If the fallback is defined in html
  fantasai: It is fine to say the fallback size is what it is
  fantasai: We should make it clear if the aspect ratio is set, you do
            not need that fallback size
  TabAtkins: Yes, you are saying what I suggested

  Rossen: Everyone is agreeing, which is great
  Rossen: Other opinions?
  florian: Given that videos have controls, how realistic is that we
           can know the aspect ratio without the size?
  TabAtkins: Controls are overlaid
  Rossen: Tab, can you verify?
  TabAtkins: If a video or any replaced element has not yet loaded,
             then we do not consider it to have an aspect ratio to come
             from its fallback size
  fantasai: The default object size should never provide an aspect
            ratio, it's just a width+height
  Rossen: No, this is not the case.
  Rossen: If we have a defined aspect ratio, we do not have a prob?
  Rossen: We need to figure out in case of auto to fallback to 350
  TabAtkins: You should not be doing that, that is the point
  TabAtkins: If your default sizes are used, do not consider that to
             provide an aspect-ratio but us the auto
  Rossen: auto by default?
  fantasai: 16/9 set … use that initial loaded
  fantasai: What Tab is trying to say that auto is not giving the
            aspect ratio, until the resource is loaded
  TabAtkins: It is what we intended for images, but a clear error we
             need to fix (in images-3)
  fantasai: images-3 does not define that
  TabAtkins: It does ?? with size
  TabAtkins: The default object size is defined in 2.1
  fantasai: sizing rules for replaced elements is not in css-images-3
  fantasai: css-images-3 defines sizing algorithms, but not for
            replaced elements
  fantasai: it covers things like list-style-image and background-image

  iank: We may only want to do this for video and ?? elements because
        there is some funky stuff with object elements
  Rossen: Object and embed have similar problem which you do not want
          to change
  fantasai: We are not gonna run into problems here
  iank: Any other elements?
  TabAtkins: Not sure
  iank: Canvas?
  TabAtkins: Maybe
  emilio: <input type=image>, <video>, <img>, <canvas>
  florian: svg?
  emilio: No
  iank: It might take us a while to do because the way our intrinsic
        logic handles it historically
  Rossen: ok, thank you
  Rossen: but shouldn't prevent us from resolving

  emilio: I don't know if saying getting the aspect ratio from the
          fallback size or not, or if you have an aspect ratio make
          sure you do not have a fallback intrinsic size to being with
  iank: You mean the natural size?
  emilio: Yeah
  emilio: I need to check how it works
  emilio: but we are in agreement
  emilio: I think you may not want an intrinsic size to begin with
  iank: (thinks)
  iank: This will lose the natural fallback sizing as well?
  emilio: I think it should
  emilio: I need to check where that makes a diff
  iank: That will make the diff when you do something like width
  iank: in certain circumstances
  emilio: Maybe yes

  TabAtkins: Can I interrupt?
  TabAtkins: Suggestion is to resolve to fix it, without detailing it
  fantasai: Maybe more precise
  fantasai: that the auto part only pulls an aspect ratio from
            an actual resource
  fantasai: that you do no get it from the fallback size
  TabAtkins: Sure
  fantasai: The spec was never intended to pull the aspect ratio from
            the fallback size
  fantasai: We should clarify that it doesn't
  fantasai: It should always fall back to the provide aspect ratio, that
            the whole point
  emilio: For iframes?
  fantasai: No
  fantasai: They don't get one auto-magically
  fantasai: same with svg, until you load it

  Rossen: Back to resolution
  fantasai: 2 resolutions
  <fantasai> Proposed: Clarify that aspect-ratio:auto doesn't pull
             aspect ratio from the default object size, it can only
             pull from an actual loaded resource
  fantasai: Proposed: When providing the aspect ratio through the
            property then you no longer use the default size as your
            natural size
  Rossen: So aspect ratio overrides default
  fantasai: Yeah
  TabAtkins: Would like to address in separate issue if needed
  Rossen: First one is easy to resolve on
  emilio: Poster image?
  fantasai: That is a loaded resource
  emilio: But not a video
  florian: Proposed resolution says a resource
  fantasai: If video is 16 by 9 and poster 1x1, then loaded poster will
            give 1 by 1 aspect ratio
  emilio: ok
  emilio: we agree on behavior
  Rossen: Anyone objecting?
  Rossen: No, ok

  RESOLVED: Clarify that aspect-ratio:auto doesn't pull aspect ratio
            from the default object size, it can only pull from an
            actual loaded resource

  fantasai: Second one when providing aspect ratio via aspect-ratio
            property then don't fallback to default object size
  iank: Unsure about that
  fantasai: If you want to hang on to the aspect ratio, you have to at
            least let go of one of the sizes
  iank: (missed)
  iank: I think the behavior today you will still size at width 300 and
        take into account the new aspect ratio, so you wont end up with
        150 height
  iank: and I think that might be fine
  emilio: Not sure
  emilio: images may want to overrride that
  emilio: because their intrinsic size is 0x0
  emilio: but video maybe we do not need to change intrinsic size
  emilio: Consistency would be good though
  Rossen: So?
  Rossen: We have resolution for original post
  Rossen: suggest to open new issue for the 2nd thing
  Rossen: We can record info there and give iank and emilio time to
  Rossen: We can come back to this later
  Rossen: Everyone ok with that?
  fantasai: ok

CSS Shapes 1

ellipse() grammar gratuitously inconsistent with radial-gradient()
  github: https://github.com/w3c/csswg-drafts/issues/824

  Rossen: Last issue
  astearns: I have one question about latest comment
  astearns: Jake his example is circle not ellipse
  astearns: We also cover that?
  TabAtkins: Maybe?
  astearns: Does it use nearest/farthest corner?
  TabAtkins: Yes
  astearns: So proposal would both cover circle and ellipse

  astearns: Looking through the issue
  astearns: we want to change both circle and ellipse in basic shapes
            to match radial gradients
  astearns: and I am fine with that
  astearns: Do we also want to retain the facility that the basic
            ellipse function has
  astearns: which is to define an ellipse that is as large as is
            possible for a given reference box
  astearns: If we do this then there will be no breakage with current
            shape ellipses in use
  astearns: but we would also want to add this to the gradient syntax
  TabAtkins: Yeah
  astearns: Fine going either way
  Rossen: Lets pick one
  astearns: Do it all
  <lea> +1
  astearns: Update the basic shape functions and update radial-gradient
  Rossen: Opinions?
  lea: Yes, do it!
  Rossen: Objections?

  RESOLVED: Update the basic shape functions and update radial-gradient

Rossen: And that concludes the list of issues
[meeting end]

Received on Wednesday, 31 August 2022 11:03:51 UTC