- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 22 May 2024 19:18:00 -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 Overflow
------------
- RESOLVED: Close the issue, adding a note to the ink overflow
definition about platform and rendering differences
(Issue #8649: Specify extent of ink overflow)
CSS Viewport
------------
- RESOLVED: Leave open, bring back in the upcoming F2F (Issue #7767:
Add a meta viewport parameter to control ICB layout
behavior for interactive overlays)
CSS Flexbox
-----------
- RESOLVED: Change minimum size of flex items to be the larger of
min-intrinsic and transferred size (Issue #6794: Change
content-size suggestion to min-intrinsic instead of
min-content?)
Anchor Positioning
------------------
- There was concern that the proposal in issue #10315 (Alignment
shouldn't interfere with sizing) would cause poor behavior in a
majority of cases. However, the proposal in issue #10316 (should
alignment safety consider the containing block?) could address
that concern. The group will return to issue #10315 later after
folks have had a chance to read and discuss issue #10316.
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2024May/0016.html
Present:
Rachel Andrew
Tab Atkins-Bittner
Kevin Babbitt
David Baron
Keith Cirkel
Emilio Cobos Álvarez
Yehonatan Daniv
Elika Etemad
Robert Flack
Mason Freed
Chris Harrelson
Daniel Holbert
Brian Kardell
Jonathan Kew
Ian Kilpatrick
Roman Komarov
Una Kravets
Alison Maher
Khushal Sagar
Alan Stearns
Miriam Suzanne
Stefan Zager
Regrets:
Chris Lilley
Lea Verou
Chair: astearns
Scribe: emilio
Scribe's scribe: fantasai
CSS Overflow
============
Specify extent of ink overflow
------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8649
szager: Trying to summarize the discussion:
szager: IntersectionObserver v2 uses ink overflow rects to determine
visibility
szager: view transitions use it too
szager: It was brought up to me that ink overflow is a bit
under-specified
szager: which can cause interop issues
szager: My personal agenda was to enable IOv2
szager: for everything except text, the extent of ink overflow is
pretty straight-forward
szager: A couple places didn't call out it in the spec
szager: so I wrote a few PR
szager: but text is the really different one
szager: When laying out text we're subject to font selection / glyph
shaping, web devs understand that different platforms give
different results
szager: you can access the layout geometry via APIs and
getBoundingClientRect()
szager: on inlines etc
szager: Ink overflow is different, it's magic and not observable
szager: I wonder if we can help developers get a hand on this
szager: given we now have APIs which kind of expose ink overflow
extents directly, it seems weird not to expose them
szager: I know that some of my PRs are not up to the standard in the
spec. I'm not super-engaged on getting them landed but I
think we should do the best possible for developers
florian: You submitted 3 prs, for text, text-decoration, and for
backgrounds
florian: it seems you want (1) define ink overflow better
florian: which seems useful
florian: I haven't reviewed all the PRs, but the text PR isn't about
defining it
florian: it's author guidance about how to reason about it
florian: so that's less obvious to me that it belongs in the spec
florian: You made some arguments which I didn't understand before
florian: but this looks more like devrel etc
florian: If there's agreement that this should be in the spec then we
should work more of it
florian: but as is the PR is not definition of ink overflow, more
like author guidance
chrishtr: Just to bring it back to what I think should be the main
resolution
chrishtr: Is ink overflow well-specified enough for those use cases?
florian: Not sure that's relevant because the PRs doesn't define
anything
chrishtr: I agree with it being more dev guidance
chrishtr: If it's well defined let's close the issue and we can put
developer guidance elsewhere
emilio: I think the differences in text ink overflow are unlikely to
cause substantial web compat problems for the APIs we're
exposing right now
emilio: I don't think defining ink overflow for text is a blocker for
the occlusion stuff
emilio: nor for View Transitions
emilio: The differences are relatively minor, and also happen even
within the same browser across different platforms.
emilio: If you only test Chrome on Windows, Chrome on Mac is different
emilio: I don't think the ink overflow extents for text are likely to
break use cases for intersectionObserver v2
emilio: same for View Transitions
emilio: I don't think it can cause realistic compat issues
emilio: Not necessarily well defined
emilio: but it doesn't matter much
emilio: One thing Stefan was asking was about exposing the ink
overflow rects more
emilio: I think authors should generally not care about ink overflow
emilio: devtools could point out if needed
chrishtr: Sounds like you think we could close the issue as "good
enough"
emilio: Depends on the goal of the issue
chrishtr: for existing use cases that need it
emilio: text ink overflow maybe needs better definition
chrishtr: Open a new issue, add some examples
khush: We're using this definition in one spot for view transition
khush: but not Web-observable
khush: Want to clarify that view-transition we are using it at one
spot but it hasn't been a compat issue because it's not
observable at all
khush: because the area is managed by the browser
khush: but we want to use it for a feature where visibility with the
viewport is handled with ink overflow instead of border box
khush: that technically would expose it
khush: and you could measure it moving a div 1px at a time
khush: but for the use cases we want I think it's ok
florian: No strong view on whether what we have is good enough
florian: for view-transitions or intersection-observer
florian: predictable for authors is one thing, easy to compute for
browsers is another
florian: Glyphs are not the kind of infinite thing you need to
approximate
florian: It could be very expensive to compute where a glyph ends
<fantasai> Definition of ink overflow
https://www.w3.org/TR/css-overflow-3/#ink
florian: it's where the text ends, which you can compute, even though
it might not be easy
florian: so I don't think it's badly defined
szager: All browsers need to compute it already
[missed]
fantasai: I was on the queue to say what florian said, I don't think
text ink overflow is ambiguous
fantasai: if there's an actual ambiguity then we should fix the spec
fantasai: otherwise it's not ambiguous
fantasai: I don't think an API to expose it would be a good idea
fantasai: because of that issue
astearns: I think what I'm hearing is that what's currently in the
spec is good enough for current use cases
astearns: so propose to close unless spec is ambiguous
emilio: Ambiguity is not so much the spec definition, but the fact
that the same text in the same font may generate different
ink overflow on different platforms due to shaping and
rasterization
emilio: Might be worth pointing out in the spec
emilio: so that people defining APIs that depend on ink overflow can
take that into account
emilio: Doesn't have to be long, just a paragraph, that says it'll
differ across platforms and rendering engines
emilio: for Khush's proposal about exposing more directly, file a
different issue
emilio: idk to what extent that can increase fingerprinting surface
emilio: That's a good reason why someone might measure a div pixel by
pixel
emilio: not something you really want to expose, maybe it's exposed
on canvas already
emilio: worth more thinking
fantasai: If you want a note saying this can differ due to different
factors then happy to do that
chrishtr: Sounds great, thank you for volunteering
RESOLVED: Close the issue, adding a note to the ink overflow
definition about platform and rendering differences
CSS Viewport
============
Add a meta viewport parameter to control ICB layout behavior for
interactive overlays
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7767#issuecomment-2109901056
emilio: Added to draft, but never got WG review
emilio: Discussed adding meta viewport to control effect of keyboard
on layout / visual viewport
emilio: I recall Jen presenting use cases for different things.
emilio: There are use cases for resizing either layout or visual
viewport.
emilio: That changes things like fixedpos
emilio: This viewport meta key allows you to configure that behavior,
as well as via JS virtual keyboard API.
<astearns> changes we are discussing:
https://github.com/w3c/csswg-drafts/pull/7826/files
emilio: The tl;dr is, there are use cases for different behaviors
emilio: existing meta tag seems like the right place to configure this
emilio: Are people OK with this? Gecko is implementing, Chromium may
have shipped awhile ago, unsure about WebKit status
<TabAtkins> Looks good to me, personally.
fantasai: This is the first I'm hearing about it. Recall discussing
the problems, but don't recall resolving on adding this
feature.
iank: We made a switch to iOS behavior, but had compat issues, and
needed to provide a toggle for the various behaviors.
emilio: Gecko and Blink used to resize the layout viewport for the
keyboard
emilio: and iOS didn't
emilio: but sometimes could e.g. in webview
emilio: For Gecko to align with WebKit and Blink, we are also looking
at implementing this
emilio: because use cases for other behavior
emilio: so this seems like reasonable place to opt into this
iank: It's served us pretty well when we did this change.
fantasai: I can't represent WebKit's position on this
fantasai: From my perspective it's not amazing that somebody edited
it without bringing it up and now everybody is shipping it
iank: We did bring it up for discussion
fantasai: interactive-widget doesn't show up in the mailing list
fantasai: Just saying, let's avoid that kind of situation in the
future
astearns: It sounds like there was discussion in the PR
astearns: which isn't great
astearns: three different things we could do I guess
astearns: (1) leave issue open, bring it back in the f2f
astearns: (2) accept PR, belatedly, open new issues if needed
astearns: (3) ack that we didn't follow process, rip it from the
draft and opt in again
<TabAtkins> +1 to 1
chrishtr: +1 to 1
<chrishtr> https://github.com/WebKit/standards-positions/issues/65
RESOLVED: Leave open, bring back in the upcoming F2F
CSS Flexbox
===========
Change content-size suggestion to min-intrinsic instead of
min-content?
----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6794#issuecomment-2117951367
iank: This is regarding auto min size on flex items and aspect-ratio
iank: Blink is more or less consistently dropping the aspect-ratio
iank: other browsers are sometimes dropping it
iank: Blink has been on the receiving end of a bunch of web dev bug
reports
iank: This situation isn't good for web devs
iank: haven't seem bug reports for the other engines
iank: as such I think we would do a change to respect aspect-ratio
iank: we can add a bunch of tentative tests about this behavior
iank: Proposal would be max(transferred-size, min-intrinsic size)
<dholbert> (in the min() expression)
<TabAtkins> I'm happy to take the change, I'll just have to spend
some time digesting exactly what it is. But if we're
getting compat issues and webdevs are preferring one
behavior, let's do it.
fantasai: I'm the same as Tab here
fantasai: TabAtkins and I would like to spend some time on this
issue, but if there are compat issues...
iank: Yeah I'm going to try changing blink and add tests
fantasai: I think I understand the proposal now
fantasai: I think it makes sense?
astearns: should we resolve on accepting this change tentatively?
<chrishtr> +1 to accepting the change
iank: What's going on is web devs really hate it when the
aspect-ratio gets dropped
iank: I think proposed resolution would be to change the AMS of flex
items to be max(min-intrinsic-size, transferred-size via
aspect-ratio)
fantasai: ok, got it
emilio: Do we understand what Gecko and WebKit are doing?
iank: I understand, it's complicated
iank: WebKit and Gecko are inconsistent between row/column axes, and
aren't consistent in when transferred size is applied. They are
inconsistent between column / row and how the transferred size
is getting applied
iank: everyone is super inconsistent
emilio: If you could write it up, I'd be curious
iank: My intention was to write out a suite of testcases for this
behavior
iank: that should show what's happening
iank: Issue is that Web Devs are running into behavior where Webkit/
Gecko are consistent in honoring aspect ratio and Blink isn't
emilio: So your proposal would be breaking changes for all three
engines
emilio: right?
iank: Yes, because we're all inconsistent. And inconsistent across
axes. Basically everyone is bad.
iank: We're probably the most consistent, but not what web devs expect
iank: so that's where we are
emilio: Ok, this sounds good. We'll look at tests. On paper sounds
reasonable.
iank: Given lack of bug reports on other engines, not worried
astearns: Proposed resolution to change minimum size of flex to be
the larger of min-intrinsic and transferred size
PROPOSED: change the AMS of flex items to be max(min-intrinsic-size,
transferred-size via aspect-ratio)
RESOLVED: Change minimum size of flex items to be the larger of
min-intrinsic and transferred size
Anchor Positioning
==================
Alignment shouldn't interfere with sizing
-----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10315
fantasai: The current anchor-center definition changes the available
size for sizing the abspos to the largest rect that can be
centered wrt the anchor that fits within its inset area
fantasai: so if your anchor is in the center on the screen you have
all the regular stuff
fantasai: but if you're in the edge of the screen you have a little
bit of space
fantasai: Alignment never affects the avail space
fantasai: this would be a first
fantasai: Alignment takes the box and avail space and aligns it
fantasai: I think that's what we should do for anchor-center
fantasai: If the author wants to resize the anchor we should provide
keywords in the inset or what not properties to enable that
fantasai: so I think the anchor-center kw should say "size the box in
this container, and move it as close to the desired
alignment without overflowing the container"
TabAtkins: This is novel for alignment
TabAtkins: but that's not needed for existing alignment values
TabAtkins: This isn't true for anchor-center
TabAtkins: if half your size is larger than the distance to the
closer edge
TabAtkins: then you overflow if you stay centered
TabAtkins: In particular if you fill the cb then you're almost
guaranteed to overflow
fantasai: That's not what I'm proposing though
TabAtkins: Right, two possibilities
TabAtkins: (1) is the current behavior
TabAtkins: which has this edge case but looks good pretty good if
you're in the middle
TabAtkins: Looks better than growing to the full size and align
TabAtkins: (2) is what you suggest
TabAtkins: This was what the spec originally said
TabAtkins: but the sliding behavior needs to be available to more
than anchor-center
TabAtkins: Bikeshed does this for left-aligned anchors for example
TabAtkins: but whatever you do it can't be locked to anchor-center
TabAtkins: When we come up with something that does the sliding, it
should disable this shrink-avail-size bit
TabAtkins: so I wrote the spec the way it is because it looks better
in the majority of cases
TabAtkins: You can kinda fix this with min-size (though it's not
perfect because you'd overflow)
TabAtkins: but when we have the sliding bit then it should work just
fine
TabAtkins: If we do the sliding I'm concerned about doing it too
early before knowing what it'd look more generally
<fantasai> una made a visual of this issue in
https://github.com/w3c/csswg-drafts/issues/9960#issuecomment-1944518084
iank: We do have changing of avail space in inset-{axis}: auto in rtl
iank: there are cases where this happens
fantasai: yeah static pos...
fantasai: I see what your concern is
fantasai: there's another issue I filed that should get us there
fantasai: I feel strongly that alignment should not change sizing
fantasai: My suggestion is that maybe we defer this issue, we have a
chat about the other issue
fantasai: if we have a system that works then we can come back to
this issue
fantasai: I'd much rather give authors control about this
TabAtkins: What's the other issue?
fantasai: #10316
<kizu> +1 to fantasai that align should not resize things, I had
cases in my experiments where this behavior was not what I
wanted, and I almost would always prefer sliding behavior
(which _sounds_ like something close to how `position: sticky`
could work)
TabAtkins: happy with that
TabAtkins: there are slight tricks we could do to minimize the
TabAtkins: bad case here
TabAtkins: but we can chat
astearns: Let's leave open and come back after TabAtkins and fantasai
have discussed the other one
Received on Wednesday, 22 May 2024 23:18:32 UTC