- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 31 Aug 2022 07:03:10 -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: 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())
===== FULL MEETING MINUTES ======
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
resource
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
150?
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
there
emilio: We also do that
emilio: check the actual video, check the poster, and then the
fallback
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
fit-content
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
discuss
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