- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 11 Dec 2024 19:17:25 -0500
- 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.
=========================================
Adoption of the logo created by the CSS Next CG
-----------------------------------------------
- RESOLVED: WG likes the logo and would like to officially endorse
it, will investigate what that means (Issue #11193)
Publications
------------
- RESOLVED: FPWD of color hdr (Issue #11344: Time for FPWD)
- RESOLVED: FPWD of Display 4
- RESOLVED: FPWD of Overflow 5
- RESOLVED: FPWD of Multicol 2 (as a full spec, not diff)
CSS Scroll Snap
---------------
- RESOLVED: scrollsnapchanging uses the targeted location for
targeted scrolls, but does not predict the destination of
momentum scrolling (uses the current scroll location
instead) (Issue #10838: Should scrollsnapchanging target
the currently visible element during flings)
- RESOLVED: `scroll-initial-target: none | nearest` (Issue #11173:
scroll-start-target: auto doesn't match general meaning
of auto)
CSS Overflow
------------
- RESOLVED: `overflow-clip-margin: content-box` applies to scrollable
boxes (Issue #10745: Should overflow-clip-margin apply to
scrollable boxes?)
CSS Fonts & Viewport
--------------------
- There was interest in addressing the use case in issue #10674 (UAs
inconsistent in how OS font settings affect the default font-size
`medium`) but the group ran out of time before they could reach
agreement on the best approach. Discussion will continue on
github.
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2024Dec/0005.html
Present:
Rachel Andrew
Adam Argyle
Tab Atkins-Bittner
David Awogbemila
Kevin Babbitt
David Baron
Oriol Brufau
Keith Cirkel
Emilio Cobos Álvarez
Yehonatan Daniv
Brecht De Ruyte
Stephanie Eckles
Elika Etemad
Robert Flack
Simran Gill
Daniel Holbert
Brian Kardell
Jonathan Kew
Roman Komarov
Vladimir Levin
Chris Lilley
Alison Maher
Romain Menke
Florian Rivoal
Cassondra Roberts
Jen Simmons
Gaurav Singh Faujdar
Alan Stearns
Josh Tumath
Bramus Van Damme
Scribe: TabAtkins
Scribe's scribe: bramus
Adoption of the logo created by the CSS Next CG
===============================================
github: https://github.com/w3c/csswg-drafts/issues/11193
argyle: Let me share my screen a bit
argyle: We're CSSNext, defining CSS4 and 5 (and 3 right now actually)
argyle: Trying to resolve all the properties and what space they go to
argyle: The CSS3 shield logo is everywhere, it was hot a decade ago
but not now
argyle: not aging or scaling well
argyle: There's a lot of other language logos people are actively
using
argyle: lot of community suggestions
argyle: Eventually we went with a more predictable one
argyle: "we joined the family"
argyle: [shows the logo]
argyle: We found fonts with license issues; JS logo is violating its
font license. We're using an open source font, and a special
color for CSS
<emilio> +1 for rebeccapurple :)
argyle: Logo is rounded corners except one
argyle: Lots of positivity, thought we could bring it up to CSSWG
argyle: The red CSS square logo is used for favicons, maybe update
argyle: (red css logo has contrast issues anyway)
argyle: So hopefully CSS can get past the 3-shield
astearns: Outcome we want is a resolution from csswg to adopt this
TabAtkins: Only feedback in github repo is that logo as presented is
not usable as a favicon
TabAtkins: As long as the 16x16 version works for a favicon works,
I'm in
argyle: Yup, I've posted the new version, it looks nice at 16x16
fantasai: Is there some symbolism to using the top-left corner as
unrounded?
argyle: The original designer just proposed it that way
argyle: Other logos are pointy
argyle: We rounded the corners, but as a flair there's one pinched
corner
argyle: Everyone liked it was more playful than equally rounded, now
it looks more like a speech bubble
argyle: So no big meaning, it was just in the original design
bkardell: Did I hear that we're asking the WG to adopt this?
argyle: More of an endorsement...
bkardell: If we do, then the logo has a w3c relationship. We'll need
to loop in the comms team
argyle: Maybe licensing, too
florian: Agree, we should loop in comms and maybe legal
florian: I think it's pointless to do that if WG isn't interested, so
we should want to adopt it before we check how to. This
conversation is useful
florian: but if we are in support there are probably more steps.
<bkardell> Yes
florian: We can give endorsement (though it's not clear our charter
calls for it). It just won't be the last step
ChrisL: Comm team is already aware.
ChrisL: I've gone back and forth. I've asked if they wanted me to
block or promote, they said no opinion, do what you want
ChrisL: The red one had no formal process, it just showed up one day
TabAtkins: The red one came from John Daggett when he was the editor
of the font spec
TabAtkins: Might have been me that added it
argyle: It does pop
argyle: Closing remarks, this is kinda just a humble offering.
Pleased it's resonated so far
argyle: Whenever someone says "copy this CSS from X", they use the
shield logo, we could do better
<florian> I like it, FWIW
<bkardell> yes, I also personally like it fwiw
argyle: If we do want to make it more official and there's legal
processes, happy to be involved if needed
<ChrisL> I like it too
astearns: proposed resolution: WG likes the logo and would like to
officially endorse it, will investigate what that means
<kbabbitt> +1 I like it
<TabAtkins> +1
<bkardell> 👍
<ChrisL> +1
<florian> +1
<joshtumath> +1
astearns: objections?
<brecht_dr> +1
<ydaniv> +1
RESOLVED: WG likes the logo and would like to officially endorse it,
will investigate what that means
CSS Color HDR
=============
Time for FPWD
-------------
github: https://github.com/w3c/csswg-drafts/issues/11344
ChrisL: I was prompted for this because ccameron has asked for TAG
review of one of the parts, seemed like a good time for fpwd
ChrisL: Spec is in reasonable shape, has some tests. Apparently
chrome is gonna ship the dynamic-range-limit feature soon, so
good reason to have it published
astearns: We already have a resolution to adopt this
ChrisL: Yes, a while ago
astearns: Any concerns or questions?
astearns: Proposed resolution is FPWD of color hdr
RESOLVED: FPWD of color hdr
Publications
============
github: https://github.com/w3c/csswg-drafts/issues/6900#issuecomment-2532334712
TabAtkins: Got 3 drafts already were FPWD.
TabAtkins: First one is display-4. Has two extra additions
TabAtkins: reading-flow is actively being implemented
TabAtkins: Interpolating display is shipped
TabAtkins: Second is overflow-5: all scroll marker stuff from flackr
for carousels. Talked about those at TPAC. Design is
fairly stable, but might need some tweaks
TabAtkins: Finally mutlicol-2 which has column pseudo.
TabAtkins: Let's just put snapping on mutlicol columns
TabAtkins: Might do rows later but don't need to wait for that for
FPWD
TabAtkins: Those are the additions, and I would like to start them
being published
astearns: proposed resolution: FPWD of Display 4
fantasai: sounds reasonable for FP, there's still open issues to work
on, but I think publishing makes sense
astearns: objections?
RESOLVED: FPWD of Display 4
astearns: Next, overflow 5
TabAtkins: Last week Elika mentioned it needed a better intro, I'll
write it before I hit the publish button
fantasai: As long as there's an understandable intro, I think this is
good for fpwd
astearns: So once there's an updated intro, we'll do fpwd of
overflow 5
ChrisL: Tuesday is last day for publication, else it's next year
ChrisL: and there's a form
TabAtkins: Will do those today
RESOLVED: FPWD of Overflow 5
astearns: Last, Multicol 2
rachelandrew: It's currently a diff spec, was gonna copy everything
from multicol 1 so I have the multicol row bit. Should
I do that first?
astearns: It's ok to have a diff spec as fpwd
astearns: Up to editor's discretion
rachelandrew: Not really any changes to 1, just waiting for a test
suite followup
fantasai: I think that would be good
florian: Yeah, multicol 1 isn't changing fast, not much risk of
drift. Also yay, multicol in block direction
rachelandrew: I have a draft.
florian: Me too, happy that yours is probably better developed
<kizu> +1 to yay for multicol in block direction
astearns: So proposed resolution is publish Multicol 2 as full
spec FPWD
RESOLVED: FPWD of Multicol 2 (as a full spec, not diff)
CSS Scroll Snap
===============
Should scrollsnapchanging target the currently visible element during
flings
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10838
flackr: We defined scrollsnapchanging as using the "eventual scroll
position". This makes sense for targeted scrolls, but is
confusing when flinging.
flackr: We'll predict a position far out, but if you change your
scroll velocity the identified item jumps back to the one
currently in view
flackr: Proposing we change the behavior so that targeted scrolls
(where we know the intended destination) that we use that
target (as the spec already says), but for momentum scrolls
we use the current position, as if you're actively scrolling
and we don't know where you'll end up
flackr: This is more intuitive, where the identified item doesn't
jump ahead of your scroll
<TabAtkins> +1, this sounds right. I'd expect indicated element to
gradually move as the fling progresses
astearns: Are you going to be able to tell what kind of things you're
getting back?
astearns: Targeted vs current scroll position?
flackr: API doesn't differentiate, you just get a currentTarget
flackr: For all the use-cases we've been talking about this feels
right, but it's possible we might want something always based
on the current location.
flackr: Doesn't make sense to have something always based on target
location; sometimes you don't have a different target
location.
flackr: But if we eventually wanted one for the currently-in-view
thing even during a targeted scroll, we could add it
astearns: I don't have a particular reason to need it, was just
wondering
flackr: Yeah, for all use-cases we know - carousel, selected UI - it
makes sense to use current or target as I'm proposing here,
depending on type of scroll
astearns: Other questions?
astearns: Summary?
flackr: Proposed resolution: scrollsnapchanging uses the targeted
location for targeted scrolls, but does not predict the
destination of momentum scrolling (uses the current scroll
location instead)
RESOLVED: scrollsnapchanging uses the targeted location for targeted
scrolls, but does not predict the destination of momentum
scrolling (uses the current scroll location instead)
scroll-start-target: auto doesn't match general meaning of auto
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11173
DavidA: scroll-start-target is set on the child of a scrollable
container, that makes the container initial scroll to that
child
DavidA: Got feedback from the TAG that, looking at the name of the
property, the -start could be confusing (it's a logical
direction in other properties)
DavidA: Also the values are none|auto, was a question about --
currently auto means the element is a scroll-start target,
but "auto" usually is used for something more magical
DavidA: so we're looking for a replacement value name
DavidA: For property name, scroll-container-target and
initial-scroll-target are my suggestions. Suggest the
second one
<TabAtkins> (yeah, I like initial-scroll-target)
DavidA: For the values, I'm proposing `none | local`. Proposing local
because it only effects the nearest scroll container.
DavidA: In theory, in future we could expand the scope of the
scrolling target, add "global" or something
flackr: The thinking is that a value which scrolls all ancestors
could explain fragment navigation - that does scroll all
scrollers up to the root
<TabAtkins> (I think I'd prefer something like "self")
<fantasai> https://drafts.csswg.org/scroll-animations-1/#scroll-notation
fantasai: We have scroll() from Scroll Animations. It uses the
keyword "nearest", we should be consistent with that
<TabAtkins> +1
fantasai: For property name, would it make sense to put "scroll"
first, so scroll-initial-target?
DavidA: I think scroll-initial-target is fine too
flackr: Or overflow-initial-target, since most other scrolling
properties are overflow
fantasai: We have a lot of scroll-* prefixes, scroll-padding,
scroll-snap, etc
flackr: Fair, I do like it being grouped with other scrollers. Though
it does go on the child rather than the scroll container
fantasai: Also several scroll-* properties that are, like
scroll-margin
fantasai: I do think these names are better, but we're not clearly
managing that this is set on the item
fantasai: I think scroll-margin and scroll-snap-align are a little
bit indicative, but my initial impression from the property
name is it's set on the scroll container, and takes some
reference to a child
<TabAtkins> (I think scroll-initial-target is reasonably
child-indicative. not 100%, but doable)
DavidA: I was thinking scroll-container-target, but not sure if
that helps
astearns: I think we're converging, at least for now, on
scroll-initial-target. Might come up with something
better
astearns: Shall we resolve on that?
<TabAtkins> +1
<bramus> +1 on nearest
fantasai: And none|nearest for values?
DavidA: Yeah
astearns: So proposed is `scroll-initial-target: none | nearest`
astearns: Objections?
<argyle> 👍🏻
RESOLVED: `scroll-initial-target: none | nearest`
fantasai: Can we have a comment soliciting better ideas?
astearns: Specifically about something that might more obviously
indicate that it's on the child
DavidA: I can write something
CSS Overflow
============
Should overflow-clip-margin apply to scrollable boxes?
------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10745
emilio: Not super high priority, but been agenda for a while
emilio: I don't think you can get the behavior of some of the
built-in form controls regarding overflow clipping without
something like this
emilio: In particular, textarea clips in the content-box in the
inline-axis, input also has something weird
emilio: It seems useful to allow values that make the clip smaller
than the padding box
emilio: Per spec it only applies to overflow-clip right now, but I
think it would be useful on scrollable boxes as well. Was
wondering about feelings on this
flackr: I had the impression that we previously wanted to allow
scrollable content to extend outside the scrolling box
flackr: A bunch of UI interfaces - you don't want the scrollbar
larger, but you want content behind the header, etc
emilio: That seems... maybe doable
emilio: Would need to think more about that impl wise
emilio: At that point you may want to change the scrollbar region
more than the scrolling region itself...
flackr: Yeah, maybe
emilio: But I think the uncontroversial thing would be to allow
things inside the padding box
emilio: Would look cool to allow positive values, but not sure how it
would look with borders/etc
emilio: Maybe that just works?
flackr: Yeah feels like you'd want it behind the border, in front of
background
<TabAtkins> (border is already on top of background)
vmpstr: Question about scrolling with a mousewheel or trackpad
vmpstr: If... if the mouse is in padding area does it scroll the
content?
vmpstr: If the content is outside the scroller, presumably doesn't
scroll
vmpstr: If there's visual information about the content out there, is
that meant to be scrolled by the mousewheel?
emilio: I'd like to avoid discussing positive margin right now
because I haven't thought about it, and it does raise more
questions
emilio: I think for inner, right now Firefox behavior is to scroll
when you're in padding box
emilio: textarea behavior exists now, so we could crib off of that
emilio: but otherwise yeah, good question
TabAtkins: So we are only discussing negative values. Does that mean
positive ones are clamped to 0 at the moment and in the
future we might allow them?
emilio: Yes, most reasonable right now. perhaps in the future we
could add a support keyword
TabAtkins: It's the ability to detect future support that I am
worried about, but I think we have the tools to figure
that out
<fantasai> spec only allows positive values?
<fantasai> https://drafts.csswg.org/css-overflow-4/#overflow-clip-margin
emilio: Currently it's already ignored on scrollable, which has same
issue if we start doing it
emilio: but if we need to we can add feature detection as needed
vmpstr: So positive values grow; we're only discussing negatives that
shrink
astearns: It's possible we'll run into compat issues if people are
over-applying right now?
emilio: Potentially, yes. I think it's unlikely, but I've been wrong
before.
TabAtkins: Can always add an opt-in keyword to the property
emilio: So if people agree, allowing values that shrink the clipping
box for scrollable boxes
emilio: I was just trying to kill the internal mechanism
TabAtkins: Just to clarify, Elika pointed out in IRC that negative
values are invalid. We're *actually* just talking about
allowing the box keywords to work on scrollable boxes,
which can shrink the clip region to smaller than what it
currently is
emilio: It's probably worth having a separate issue for negative
values
emilio: I'll file a separate issue
astearns: So proposed for this issue is to allow
overflow-clip-margin: content-box to apply to scrollable
containers
emilio: Preferred is allow use of overflow-clip-margin on scrollers
that shrink the clipping box
emilio: That is currently just the 'content-box' keyword
emilio: but if we allow negatives, it'll be a more general resolution
astearns: Yeah, but I'd like the shrinking mechanism explored more
specifically before we allow it generally here. tighter
resolution for now
emilio: Fair
astearns: Objections to allowing content-box value to apply to
scrollable containers?
RESOLVED: `overflow-clip-margin: content-box` applies to scrollable
boxes
CSS Fonts & Viewport
====================
UAs inconsistent in how OS font settings affect the default font-size
`medium`
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10674
joshtumath: Back in 2019, issue 3708 the WG discussed having support
for "dynamic type" on iOS
joshtumath: In OS settings changing the font size and having it
reflected in the page
joshtumath: Resolution to have some way to do true font sizes
joshtumath: but at a f2f there was a comment about general consensus
for this done with meta-viewport
joshtumath: A year later this was closed because Safari added a
per-site setting
joshtumath: so wanted to discuss this again
joshtumath: At BBC, had some complaints because some of our apps use
a webview to embed a browser, and there is no controls to
change font size in a webview, you have to get that from
the OS settings
joshtumath: but there's no mechanism for that
joshtumath: Would like WG to consider either adopting a meta-viewport
tag, or some other mechanism
TabAtkins: At the time it was talked about, did we have the env spec?
seems like the correct way to inject this info
keithamus: Last comment was about using env()
fantasai: I'd like to avoid meta-viewport as much as possible for
styling, that's not where that info should go
fantasai: So unless there's a critical reason for it, it shouldn't be
a solution we reach for
fantasai: I think it is reasonable to specify that you want the
system default font size
fantasai: Already have keywords for system-ui font, etc
fantasai: So if we can't reuse 'medium', which seems likely, we can
create a new keyword
<TabAtkins> +1, yeah duh, just a font-size keyword seems right
joshtumath: Want to make sure that anywhere we can enable this is
reflected into MQs with rem units
joshtumath: If you change root font-size that's not reflected in MQs
<TabAtkins> Ah, good point
joshtumath: If I zoom in, that'll affect MQs
astearns: Is that solveable with CQs rather than MQs?
joshtumath: It is, but would be a lot of code changes. Reluctant to
use CQs for everything, still plenty of reasons for MQs
emilio: Yeah, MQ point makes this moot...
emilio: Some OS font settings *are* exposed via system fonts. If you
set `font: dialog` or whatever, they can have different
computed font-sizes depending on OS settings
keithamus: Presumably would want to derive other units - is a keyword
applicable, or want a new dimension?
keithamus: Might want to clamp, for example
TabAtkins: I agree. Both MQ point and what Keith pointed out. Need a
resolvable value, not just a keyword. Don't care if its
env or unit. env seems semantically more appropriate
<fantasai> +1 to resolvable font size
emilio: Re previous point, some OSes don't have a unified concept of
default size, there are different sizes for different UI
elements
emilio: Window, perhaps Linux
emilio: Don't know if we want to account for that
keithamus: If it's a dimension we'd need to specify what the resolved
value is, or what the fallback is
keithamus: If we use env(), can you provide a fallback?
<TabAtkins> yes, env() has a fallback
<bramus> `env( <custom-ident> <integer [0,∞]>* ,
<declaration-value>? ) `
emilio: It does feel a bit weird to have conditionally supported vars
like that...
keithamus: I thought not all OSes would want to define that value..
emilio: More that there's potentially multiple values to expose
TabAtkins: Advantage of env() is we can easily supply a family of
keywords if we want
emilio: Yeah, sorry, having a solution would be great, just pointing
out complications
fantasai: Clarifying - is this one font-size, or a variety?
emilio: That was my point, you put it better
keithamus: What would the variety of font-sizes be?
astearns: I think if we depend on what OSes/browses are offering in
terms of settings
fantasai: Bigger question - what are authors trying to match
fantasai: Definitely paragraph text size, good to match the OS
fantasai: Do we need other things as well?
keithamus: Good point, there's oftentimes a preference for different
sizes based on fixed-width fonts
keithamus: In my system settings there's a bunch
iank: Main use-case here is body/paragraph text, sites are detecting
this in the browser today via interesting means
iank: related to text-auto-sizing
iank: They want to be able to boost paragraph text size for a11y
reasons
astearns: Hearing we'd like to pursue this as an env() that resolves
to a length
TabAtkins: That was answered by MQs and math fns
fantasai: Why env() not a font keyword?
iank: Often the case you'd want to change the height of a box/etc
fantasai: But you could set it on root and use the values
TabAtkins: Not accessible in rems and MQs.
fantasai: We could make MQs respond to user's real default size
TabAtkins: Would be different feature
astearns: We're over time, take it back to the issue
Received on Thursday, 12 December 2024 00:17:58 UTC