[CSSWG] Minutes Telecon 2024-03-27 [css-box][css-view-transitions][css-alignment][css-lists]

  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.


  - RESOLVED: We will use shaped edge and unshaped edge (Issue #5132:
              How to refer to the corner-shaped padding/border/content
  - 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.


Agenda: https://lists.w3.org/Archives/Public/www-style/2024Mar/0023.html

  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

  David Leininger
  Bramus Van Damme

Chair: astearns

Scribe: keithamus


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
  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

  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

  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
  fantasai: No overflow in those cases. Might look bad. Inclination
            when making demos is not requiring unsafe keyword felt more
  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
  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
  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

  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
  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
  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
  <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
  <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