- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 27 Mar 2024 19:38:46 -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 Box
-------
- RESOLVED: We will use shaped edge and unshaped edge (Issue #5132:
How to refer to the corner-shaped padding/border/content
edges)
- RESOLVED: Editorial update to level 3 box rec
View Transitions
----------------
- RESOLVED: View Transitions level 2 to public working draft (Issue
#10096: FPWD for CSS View Transitions L2)
- RESOLVED: Use FrozenArray for CSS OM. VT typeset which is setlike
for types attribute. Keep sequence of strings for svt as
is. (Issue #10114: Data type for types in script APIs)
- RESOLVED: Don't deduplicate values in reflections (Issue #10114)
- RESOLVED: Don't drop invalid values in reflections (Issue #10114)
- RESOLVED: Make * optional if you are using a class (Issue #9874:
Consider allowing `::view-transition-group(.class)`
without *)
CSS Alignment
-------------
- RESOLVED: All scroll containers default to unsafe alignment (not
actually unsafe on scroll container) (Issue #10008:
Default safety of scroll containers)
CSS Lists
---------
- oriol introduced proposed syntax to specify the agreed upon
behavior for list-time nesting in issue #9076 (list-item counter
nesting is confusing). There were questions on handling defaults
and if the property should inherit, but the group didn't have
time to discuss further on the call so conversation will return
to github.
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2024Mar/0023.html
Present:
Rachel Andrew
Adam Argyle
Rossen Atanassov
David Baron
Oriol Brufau
Keith Cirkel
Emilio Cobos Álvarez
Yehonatan Daniv
Elika Etemad
Robert Flack
Paul Grenier
Daniel Holbert
Jonathan Kew
Ian Kilpatrick
Roman Komarov
Vladimir Levin
Chris Lilley
Peter Linss
Cassondra Roberts
Noam Rosenthal
Khushal Sagar
Alan Stearns
Miriam Suzanne
Lea Verou
Regrets:
David Leininger
Bramus Van Damme
Chair: astearns
Scribe: keithamus
CSS Box
=======
How to refer to the corner-shaped padding/border/content edges
--------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5132#issuecomment-2016033266
astearns: fantasai asking if this change is okay
fantasai: Edge border - curved edge with border radius or just
rectangle. I added shaped-edge... does this sound good to
people?
fantasai: We originally talked about corner shaped edge but we might
shape more than just corners
astearns: Any concerns?
dbaron: Is an unshaped edge one that is rectangular, or one with a
circular border radios?
fantasai: No border radius with unshaped, just rectangle. e.g. when
calculating float.
RESOLVED: We will use shaped edge and unshaped edge
Publication
-----------
github: https://github.com/w3c/csswg-drafts/issues/6900#issuecomment-2018953613
astearns: 2 publications, 1st one is regular draft. We can always
publish WD. You need editorial update to box level 3?
<fantasai> https://drafts.csswg.org/css-box-3/#changes
fantasai: Minor changes. Subheadings, some terminology.
ChrisL: This is a change to rec. Is it purely editorial?
fantasai: Yep
ChrisL: In terms of process, proposed correction? AC Review?
fantasai: We can just publish, its just editorial
ChrisL: Okay thanks
<fantasai> -> https://www.w3.org/2023/Process-20231103/#revised-rec-editorial
PROPOSED RESOLUTION: Editorial update to level 3 box rec.
RESOLVED: Editorial update to level 3 box rec
<ChrisL> +1
astearns: For level 4 I'd like to get in practice of using wiki
without asking for resolution
astearns: When these 3 were suggested, public WD for level 2 is
first. Should we resolve on level 2 or publish the WD and
resolve in ED?
View Transitions
================
FPWD for CSS View Transitions L2
--------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10096
astearns: View transitions level 2 to first WD. A lot of work on
this. Just went through editorial. Ready to go? Questions?
PROPOSED RESOLUTION: View Transitions level 2 to public draft
fantasai: should probably kick off a wide review
<khush> good idea
astearns: Do we normally?
fantasai: We want early review
khush: Lead time was often months so early is better
<ChrisL> q+ to agree early review
RESOLVED: View Transitions level 2 to public working draft
astearns: a couple of level 2 issues...
Data type for types in script APIs
----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10114
noamr: We reflect types we discussed in JS. We want to finish up
exactly which data types we expose.
noamr: There are 3 of those.
noamr: 1. One that goes in the view transition object, VT types.
Exposed as SetLike - ViewTransitionStateSet.
noamr: Basically exactly like CustomStateSet, a set of strings. It
has side effect of changes types of VT.
noamr: Decide on reflecting only valid events, removes none etc. Or
reflects everything like a set of strings
noamr: 2. CSS OM - readonlysetlike or frozenArray.
noamr: No strong preference. Precedence for readonly setlike like gpu
capabilities, which is readonly setlike<string>
noamr: maybe css om can be simpler like a frozenArray
noamr: 3. What we pass to start view transition, its a sequence. We
maybe don't need at all?
emilio: When you specify duplicate names into cssrule there's
de-duplication? We don't generally do that. If at parse time
I don't care if array or set. If we don't do parse time
de-duplication - I don't think we do - I think there was
precedent but we undid it? If none then we should go with
frozenArray. It's also simpler.
emilio: The rest sounds fine
noamr: We can decide if there's duplication or not
noamr: De-duplication is most convenient and performant to do first
thing but its not... we can make a judgement call on
frozenArray and do dedupe during VT rather than css parse
emilio: That sounds maybe more consistent, like color-scheme, but no
strong opinion. If people are fine... classname is the same
it doesn't get deduped during parse time
noamr: They're deduped in classList right?
emilio: Only if you mutate, not the attribute value
emilio: Either way is fine though, no objections
khush: Invalid values? No question there that invalid items in the
list are dropped at parse time?
noamr: Right. The question is should we remove invalid values added
with JS to the set? Should we throw? or discard? Or add to set
but never match?
noamr: Initial impl is a copy of CustomStateSet, its a set of
strings. Invalid strings wouldn't match because they don't get
into css
noamr: Last thing is - do we need types parameter in
startViewTransition, or regular and mutate later?
fantasai: Conceptually when you set up transition you set up types.
Mutate later while running seems weird
noamr: Call viewtransition then settypes? Some convenience inside
start.
vmptr: Mild preference for keeping param in startViewTransition
khush: Can be a sequence of strings
noamr: Yep
emilio: Seems fine
noamr: frozenArray if duplicated would reflect back as string value,
look like what you put in there.
khush: CSS OM is readonly right? Can't mutate?
noamr: Right but would it dedupe? `foo foo`. One or both?
khush: If in css? Are both going to show up or single value.
noamr: Yes. Also array style like includes or setstyle like has?
khush: ...
emilio: No you get both as string
emilio: We could also go for string. How font-face descriptors work
if you specify lists.
noamr: Also selectors are strings.
emilio: Exposing new interface for that attribute might be overkill,
you need for setlike. FrozenArray and strings, I don't care
either way too much
noamr: String would be most CSSOM like.
noamr: A bit less useful
emilio: In practice you can split
astearns: If precedent for frozenArray, with better dev ergonomics,
happy go with that. We don't need to follow string precedent
noamr: Preference for frozenArray from this discussion
emilio: Not sure if it has precedence in CSS OM but selectors
nowadays would not be plain string, same for other apis
astearns: Specify frozenArray, from impl experience if that is
entirely new thing for cssom. Or push back to string if not.
emilio: Even if completely new I think it's fine
noamr: In chromium not a problem
emilio: css om has observable arrays for mutable stuff so for or
frozen makes sense
astearns: resolution then?
PROPOSED RESOLUTION: Use FrozenArray for CSS OM. VT typeset which is
setlike for types attribute. Keep sequence of strings for svt
as is.
khush: One more thing is we don't dedupe
noamr: Also don't check for invalid
RESOLVED: Use FrozenArray for CSS OM. VT typeset which is setlike for
types attribute. Keep sequence of strings for svt as is.
PROPOSED RESOLUTION: don't deduplicate values in reflections
RESOLVED: don't deduplicate values in reflections
PROPOSED RESOLUTION: don't drop invalid values in reflections
RESOLVED: don't drop invalid values in reflections
emilio: Just that we're not consistent with customStateSet but...
Consider allowing `::view-transition-group(.class)` without *
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9874
vmpstr: We have VT pseudo elements. They take a name param, or
universal selector *. We also added vt classes that specify a
name and set of classes that are written as .foo.bar.
vmpstr: because of the syntax currently specified, universal selector
with class you need to spell out *.foo. We'd like to resolve
to have * optional if you're using class param. Would look
similar to how CSS looks with .class. Other point is that if
we don't have a class, Id prefer to require a * - not
requiring ()
<fantasai> +1 to allowing the * to be dropped
<fantasai> +1 to the proposal
emilio: How are they defined? Selector syntax? Or custom
vmpstr: Custom
khush: Args to pseudo element
vmpstr: Yes, syntax to the arg is specified in VT spec
astearns: You're talking about omitting * if using class? This is not
just optionally omitting but making *.class syntax invalid?
vmpstr: No, optionally
PROPOSED RESOLUTION: Make * optional if you are using a class.
<khush> +1
<emilio> Sgtm
RESOLVED: Make * optional if you are using a class.
astearns: Also omitting parens entirely?
vmpstr: The way the resolution is phrased I'm happy. If its optional
altogether I'd like it to not be optional. This resolution
satisfies that.
astearns: Can scroll go to next week or?
fantasai: No, this one is about alignment property.
CSS Alignment
=============
Default safety of scroll containers
-----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10008
fantasai: Previous issue; when we have alignment applied to block, if
the content is bigger than box it overflows. For flex/grid
containers we overflow in whatever direction
fantasai: We can specify to always overflow to end of container, so
not clipped by scrollbars
fantasai: Content alignment on block containers we decided to do safe
alignment by default. reduce compat impact.
fantasai: Block container that's scroll container has no safety
concerns around accidental clip because ... it'll overflow
fantasai: If I set align-content: end on scroll container should it
end align content so you scroll to end of the content? Or
should we layout same way a non-scroll or block container
where its aligned to start and overflows toward ends
fantasai: I made a demo
<fantasai> https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22align-content%3A%20end%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22align-content%3A%20end%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3Cbr%3ELine%203%3Cbr%3ELine%204%3Cbr%3ELine%205%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22align-content%3A%20end%3B%20overflow%3A%20auto%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3Cbr%3ELine%203%3Cbr%3ELine%204%3Cbr%3ELine%205%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22align-content%3A%20unsafe%20end%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3Cbr%3ELine%203%3Cbr%3ELine%204%3Cbr%3ELine%205%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22align-content%3A%20unsafe%20end%3B%20overflow%3A%20auto%22%3E%0A%20%20Line%201%3Cbr%3ELine%202%3Cbr%3ELine%203%3Cbr%3ELine%204%3Cbr%3ELine%205%3C%2Fdiv%3E%0A%0A%3Cstyle%3E%0A%20%20body%20%7B%20display%3A%20flex%3B%20height%3A%205em%3B%20%7D%0A%20%20div%20%7B%20margin%3A%200.5em%3B%20border%3A%20solid%3B%20%7D%0A%20%20div%3Ahover%3A%3Abefore%20%7B%0A%20%20%20%20%20position%3A%20absolute%3B%0A%20%20%20%20%20top%3A%200%3B%20left%3A%200%3B%0A%20%20%20%20%20content%3A%20attr(style)%3B%0A%20%20%20%20%20background%3A%20Canvas%3B%0A%20%20%7D%0A%3Cstyle%3E
<fantasai> https://software.hixie.ch/utilities/js/live-dom-viewer/saved/12505
iank: Which side is scroll origin on in align end case?
fantasai: align-content: unsafe-end content will overflow to top and
initial scroll position will scroll to bottom so you can
scroll upward
iank: So scroll origin at end
fantasai: So if I set align-content: end instead of unsafe-end do we
want it like unsafe-end or layout like top aligned if
content overflows
fantasai: That's what happens if you're not a scroll container
iank: Implications that safe-end scroll origin at top vs unsafe-end
scroll origin at bottom
fantasai: Right. What should default be?
fantasai: Playing around I thought it was more convenient to say
align-content; end makes scroll container end
fantasai: but can see consistency argument. to layout as non
scrolling.
fantasai: No overflow in those cases. Might look bad. Inclination
when making demos is not requiring unsafe keyword felt more
natural.
iank: That would mean you couldn't... how would you get it to start
from bottom and scroll up? Unsafe end?
fantasai: Safe end content would overflow toward bottom, scroll to
top. Unsafe end content overflows to top and you scroll to
bottom. If you don't specify safe/unsafe what happens?
fantasai: We can be consistent with flex/grid, or block which is
safe-end
fantasai: Want to avoid stuff in an unreachable region. On scroll
container itself you don't have that problem
iank: Weak preference align-content: end starts at bottom and scrolls
upward. For consistency with flexbox. Folks know flexbox works
that way. Might not be webcompat
<rachelandrew> +1
kizu: Ideally I'd like to see safe... author intent won't always mean
we want to see bottom of scroll container
kizu: For block level we might want to think about if we want safe in
css in general. Might be a good idea. Container which could
have title, paragraph, if not enough content user will see
header always, if unsafe as we add paragraphs it'll shift in
which we won't see header.
kizu: Safe is better than to assign position offset.
kizu: Recently I think there was an article about align-content end
in flex aligns to bottom, changing scroll origin
kizu: This was news for a lot of authors. People don't expect this
behavior. Top of box is always at top. Flex is IMO not the same
but webcompat default. Safe way for doing for block I'm for it,
not strongly.
fantasai: Want to point out flex already works this way. There has
been bugs in impls which means content got clipped. Not
been usable behavior until recently.
fantasai: I'd like to hear from authors in group. Align content end
starts scroll at bottom?
fantasai: Not overflow in that direction
fantasai: Consistency arguments in both directions. Scroll containers
in flexbox and grid scroll to bottom with align-content: end
fantasai: Block contains, which aren't scroll container,
align-content: start
fantasai: From authoring it might make more sense to be complicit
with grid/flex.
fantasai: Safety aspect - its not unsafe to start scroll container at
bottom
fantasai: Recently introduced alignment safety for unreachable
content. Not a problem here.
fantasai: If you want the other behavior you can get it by specifying
safe
iank: IME align-content: end in flexbox is super useful. One reason
to explicitly use flexbox. I'd lean to consistency there
astearns: kizu disagreeing? People mention the behavior is unexpected?
kizu: To clarify not unexpected in a bad way. A feature they didn't
know they could use. I'm okay with fantasai's resolution.
<dbaron> I find it a little weird that "safe" undoes an alignment
that isn't actually unsafe.
iank: When I talk to developers they say its amazing
dbaron: If you explicitly write safe it undoes something which wasnt
unsafe? Consistency in what safe means might be valuable
fantasai: I don't think we should change explicit keyword behavior
fantasai: We might want to allow explicit direction when not
overflowing. Don't have that feature yet
PROPOSED RESOLUTION: all scroll containers default to unsafe
alignment (not actually unsafe on scroll container)
dholbert: It's not unsafe if it runs off direction if scrolling is
able to move but what if it runs off in both directions?
dholbert: or offset by 100px to start side or whatever
fantasai: That would be clipped anyway
fantasai: The spec requires scroll up and down. You have to scroll to
a position to align the subject within the container in
both start and end so you can see entire alignment
fantasai: if you position outside of alignment object it'll be off
RESOLVED: All scroll containers default to unsafe alignment (not
actually unsafe on scroll container)
fantasai: In draft. just wanted confirmation
fantasai: Will upload wpts
CSS Lists
=========
list-item counter nesting is confusing
--------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9076
oriol: Something discussed in December. narrow counters
oriol: Still propagated to descendants, not to following siblings
oriol: Agreed to have something like this in December. Details
weren't resolved. Let's do that now
oriol: 1. Syntax to enable this
oriol: First idea something like reversed counters, functional
notation in the counter-reset property.
oriol: takes name of counter as argument
oriol: Maybe not great. How do you handle interactions with counter
that's both narrow and reversed?
oriol: In general narrow counters are better default. Not default
because we didn't have counter set
oriol: Maybe just better to have option to set all to narrow?
fantasai proposed new property counter-scope: narrow
oriol: Need exception for list-item counter to preserve compat with
html ordinals
oriol: List item counter would be magical but it is already
kizu: Given this is obscure issue. counters with list item is not
something authors know or use.
kizu: Few years ago there was a lot of compat issues. Now it's
better. From what I see there's some cross browser issues still
kizu: Can we just set default to work how we expect it to work?
oriol: Problem is blink and webkit html ordinals aren't implemented
using css counters
oriol: according to spec it should be magical
oriol: firefox is doing it as counter but when this change happened
found some websites breaking. Added hacky narrow counters
oriol: We can't change html ordinals to have wide propagation
oriol: some expect to be narrow
oriol: Normal css counters have had this behavior, people rely on
this.
oriol: eg without counter-set property people use counter-reset which
they want propagated to siblings
oriol: conflict between these. Need to keep old behavior for counters
oriol: We want to allow users to be able to switch to html ordinals
kizu: Just for counters without css counters function?
oriol: Assuming html ordinals use magical list item counter
oriol: we need something that works for both cases
oriol: Proposal with new property - counter could be narrow if list
item
oriol: or if property is set to narrow. Allow authors to decide to
opt in to html ordinals
oriol: preserve by default existing in all cases
kizu: Only case is that not many cases for counters list-item. If we
could make default for list types work more as expected but if
not possible its okay
miriam: Curious if proposed property sets the default for all
counters or just the non list item ones?
miriam: If you set wide does it change how list item counters work?
fantasai: No. Counter properties don't effect list item unless named
fantasai: list-item counter would have narrow by default unless you
explicitly set list-item counter to wide.
fantasai: just like counter-reset none
astearns: We're at time. Can we take back to issue?
astearns: Make async resolution?
<dbaron> I wanted to say 2 things:
<dbaron> 1. the reason compat is interesting here is that we had a
CSS feature that was designed to be the underlying mechanism
behind an HTML feature, but there was a long period of time
where *both* features were implemented but without the
underlying-ness. So we have compat concerns about both
features separately, but we also want to make them fit
together.
<dbaron> 2. I'd be interested in seeing what the proposed property
looks like in a little more detail: name, values, is it
inherited, what does it apply to (counters established by
the element?).
<fantasai> Not inherited, applies to counters declared in
counter-reset
<fantasai> just like counter-style
<oriol> I would prefer it to be inherited, even if that's not
consistent with other counter properties
<oriol> So that I can use `:root { counter-scope: narrow }` and let
it inherit, instead of universal selector. Also to avoid
breaking the ::contents pseudo-element that I proposed, or
similar things we might add in the future.
<astearns> oriol: please add that to the issue
<astearns> fantasai: please reply in the issue whether you have a
strong preference and arguments for not inheriting
<fantasai> sounds like we'll need to revisit the issue in a future
telecon :)
<astearns> yep :)
<oriol> Yes I will add the details in the issue
Received on Wednesday, 27 March 2024 23:39:18 UTC