- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 8 Jul 2020 18:58:26 -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.
=========================================
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
list
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
overflow-block:optional-paged)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2020Jul/0003.html
Present:
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?
[silence]
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
WD.
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:
https://drafts.csswg.org/css-color-5/#changes-20200303
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
aspect-ratio
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
constraint.
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
be.
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
possible
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
summarize?
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
fully
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
specs
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
difference.
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
height
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
direction
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
paged.
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