[CSSWG] Minutes Telecon 2024-05-15 [css-anchor-position][css-contain][css-view-transitions]

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

Anchor Positioning

  - RESOLVED: Make position a shorthand of position-anchor and a new
              position-type property. The shorthand resets both (Issue
              #10321: `position-anchor` should be defined as a longhand
              of `position`)
  - RESOLVED: Fix definition of revert-layer's behavior to match the
              general behavior elsewhere (Issue #10319: revert-layer
              should only revert the Position Fallback Origin)
  - RESOLVED: Rename implicit to auto in position-anchor (Issue #10312:
              Initial value of `position-anchor` should be `auto` not
  - RESOLVED: Drop the keyword from the anchor() function (Issue #10312)
  - RESOLVED: If inset-area spans two tracks we'll align toward the
              missing track instead of centering (Issue #10313: Default
              alignments for inset areas are wrong)

CSS Contain

  - RESOLVED: Container queries and units use the flat tree (Issue
              #5984: CQ vs shadow boundaries)

View Transitions

  - There was general agreement on having an 'auto'-like solution and
      an 'attr()'-like solution for issue #8320 (view-transition-name
      determined by element) but not yet agreement on the details for
      the approach. Discussion will return to github to draft up a more
      concrete proposal.


Agenda: https://lists.w3.org/Archives/Public/www-style/2024May/0008.html

  Tab Atkins-Bittner
  Kevin Babbitt
  David Baron
  Emilio Cobos Álvarez
  Yehonatan Daniv
  Elika Etemad
  Robert Flack
  Mason Freed
  Daniel Holbert
  Jonathan Kew
  Ian Kilpatrick
  Roman Komarov
  Vladimir Levin
  Peter Linss
  Florian Rivoal
  Khushal Sagar
  Alan Stearns
  Miriam Suzanne

  Chris Lilley
  Bramus Van Damme
  Lea Verou

Chair: astearns

Scribe: flackr


  astearns: TabAtkins is coeditor of css-ui-4
  astearns: We're likely to have another OpenUI-WHATWG/HTML-CSSWG task
            force meeting next Thursday morning, will post details later
  astearns: With CSS day and other responsibilities, neither Rossen nor
            I will be able to chair first week of June, may have to skip
  <fantasai> +1 I think a lot of us will be busy between CSS Day and
             the Igalia hackfest

Anchor Positioning

`position-anchor` should be defined as a longhand of `position`
  github: https://github.com/w3c/csswg-drafts/issues/10321

  fantasai: In earlier issue we renamed anchor-default to
            position-anchor, motivation was to allow position to be
            shorthand of this and possibly other stuff later. We didn't
            resolve on short-handing relationship. Designing a syntax
            that accommodates everything can be deferred but we need to
            decide whether position reset it now
  <florian> +1
  <kizu> +1
  <masonf> +1
  TabAtkins: Sounds good, we don't have a strong opinion either way

  astearns: Do we need a resolution for both the shorthand and that it
  fantasai: Yes

  emilio: It feels weird that if you had an anchored thing that is abs
          pos, and you want to make it fixed pos you now need to fight
          with the reset on position-anchor. Authors may find that
  fantasai: The current values of static | absolute | fixed | etc
            should probably be their own longhand as well so you don't
            have to have that fight
  fantasai: i.e. we'll have a longhand for those position values
  <iank> Modulo any compat constraints, shorthanding properties which
         have existing since the beginning of time a higher risk than
  emilio: I think people will do position: fixed or position: absolute
          anyways without thinking that it reset but this is fine as a
          proper solution
  fantasai: Our proposal for the longhand is position-type
  TabAtkins: It would be nice to have the additional longhands, I don't
             think this blocks anything. It's slightly awkward but I
             think okay that you need to reset the anchor
  emilio: But you need to define the longhands?
  TabAtkins: Not necessarily. Since it's reset only the other longhands
             don't need to exist
  fantasai: They do need to exist
  TabAtkins: Right, internal property
  emilio: I don't think this works even if it is an internal property
          because shorthands aren't typically included in enumerations

  astearns: There might be a web compat risk?
  emilio: Definitely
  TabAtkins: Is that a general issue we would have with any properties
             becoming shorthands?
  emilio: We have the issue when it becomes a shorthand it stops
          getting enumerated and the longhands become enumerated. We
          don't have the issue that the longhand is hidden so the
          property isn't enumerated
  TabAtkins: Then I propose position-type
  fantasai: Or position-style like text-wrap-style or list-style
  <kizu> +1 to `position-type`
  florian: I like type better
  astearns: Me too

  astearns: At this point, can we resolve on making position a
            shorthand of position-anchor and position-type?
  astearns: And then worry about the enumeration issues later
  emilio: I think this is fine. The big risk is someone enumerating
          styles and copying them over. If we have both longhands then
          it's not as much of a worry
  iank: It's more of a risk for people manipulating styles directly.
        When the enumeration disappears they may be relying on position
        always being in the enumeration
  iank: We've seen this before, most recently white-space, where people
        assume the property will read back the same as the property
        they set
  astearns: Is this something where you would like to wait on the
            decision until we have a compat assessment? Would you
            object to a resolution?
  iank: Taking a resolution is fine, but we might get regressions and
        have to revert and take another resolution
  iank: shorthanding properties that have been around since time
        immemorial carries risk
  fantasai: Can we update the way we handle this to include shorthands
            in enumeration for these cases to avoid the problem?
  iank: I think this may break things even more
  astearns: This might be worth opening another issues to discover
            whether the pitfalls are better or worse
  emilio: If you do this you get redundant properties. We could special
          case some legacy ones, but this is iffy. The order is
          lexicographical if you have cases where a shorthand shows up
          between longhands

  astearns: Okay, let's have a separate issue for enumerating
            shorthands, for this issue the proposed resolution is we
            make position a shorthand of position-anchor and a new
            position-type. The shorthand resets both
  fantasai: And we should add a shorthand syntax that's not resetting
  florian: But that's not urgent

  RESOLVED: Make position a shorthand of position-anchor and a new
            position-type property. The shorthand resets both.

CSS Contain

CQ vs shadow boundaries
  github: https://github.com/w3c/csswg-drafts/issues/5984#issuecomment-1969538606

  emilio: The current behavior of cq and cq units is weird for authors,
          especially the units. For stuff like style queries, current
          behavior is using the regular dom which kind of makes sense.
          But for style queries you really want the flat tree
  emilio: We opened this as a result of another issue filed on the
          units which are right now defined to behave like the queries.
          The original resolution isn't the best for authors, I think
          it's a bit weird. miriam thinks so as well and maybe this is
          worth reverting.
  emilio: Firefox implements what I'm proposing and we haven't run into
          any issues so I think the compat risk is small

  miriam: I've felt strongly from the start that we went the wrong way.
          CQ are very much akin to inheritance in a lot of ways and
          should be treated in that way rather than as selectors in
          terms of relation to shadow dom. They're all about context
          and shadow elements and slotting creates context which should
          be able to be accessed
  TabAtkins: Ultimately I agree [missed]
  kizu: May be worth mentioning named CQ where we cannot assess a named
        entity from outside of the shadow dom
  astearns: Any other comments / concerns?
  emilio: Would be interested in hearing rune's thoughts, can weigh in
          on issue

  Proposed resolution: Container queries and units use the flat tree

  RESOLVED: Container queries and units use the flat tree

Anchor Positioning (Con't)
  scribe: emilio

revert-layer should only revert the Position Fallback Origin
  github: https://github.com/w3c/csswg-drafts/issues/10319

  fantasai: This one is I think an oversight in the spec
  fantasai: revert-layer is defined to revert to author origin but
            that's not how it works
  TabAtkins: Yeah I don't think I had paid enough attention to
             revert-layer, will fix in the spec

  RESOLVED: Fix definition of revert-layer's behavior to match the
            general behavior elsewhere

Initial value of `position-anchor` should be `auto` not `implicit`
  github: https://github.com/w3c/csswg-drafts/issues/10312

  fantasai: The initial value of `position-anchor` is `implicit`
  fantasai: advanced vocabulary, but we probably don't want to expose
            this to authors
  fantasai: Propose to rename `implicit` to `auto`
  fantasai: and then this keyword also shows up in `anchor()` where we
            can rename it to `auto` too or just drop it because I don't
            think it's necessary
  TabAtkins: We should just drop it, if you omit it you get that
  TabAtkins: I generally want to make sure that implicit behavior is
             specifiable, but not necessary
  florian: Seems more consistent to how we name things

  RESOLVED: Rename implicit to auto in position-anchor
  RESOLVED: Drop the keyword from the anchor() function

Default alignments for inset areas are wrong
  github: https://github.com/w3c/csswg-drafts/issues/10313

  fantasai: Initial value for align/justify-self is normal
  fantasai: generally depends on context to an appropriate behavior
  fantasai: For inset-area we try to make the default alignment for the
            area useful
  fantasai: so if you're in the center track we center
  fantasai: If you're on the edge we align toward the area
  fantasai: If you're spanning into two tracks
  fantasai: and there the default is anchor-center, but that's
            generally not what you want
  fantasai: The usual thing is to align towards the track you're
  fantasai: it's easy to center if needed

  kizu: Tested right now, I think it works well when the anchor is
        smaller than the positioned element
  kizu: When the anchor is bigger it looks better with anchor-center
  fantasai: Typically in that case you keep aligned to one edge and
  kizu: Can we define anchor-center to try not to shrink to the center
  kizu: Only if it's not fitting shifted it'd work better
  TabAtkins: Tracked on a different issue
  TabAtkins: not on the agenda this week
  kizu: No objection then

  TabAtkins: No objection from us either
  TabAtkins: What kizu described was the originally what I wanted
  TabAtkins: but I deferred the shifting
  TabAtkins: because I wanted to fix it more generally
  TabAtkins: So tl;dr agree with the change
  TabAtkins: Also our impl actually matches that resolution because
             engineers misread the conditions
  PROPOSED: If inset-area spans both of the tracks we'll align toward
            the missing track instead of centering

  RESOLVED: If inset-area spans two tracks we'll align toward the
            missing track instead of centering

View Transitions

view-transition-name determined by element
  github: https://github.com/w3c/csswg-drafts/issues/8320

  vmpstr: Unique names for transitions is cumbersome because authors
          need to come up with a bunch of unique names
  vmpstr: Various proposals
  vmpstr: One is to have view-transition-name: auto / from-element
          which matches with element identity
  vmpstr: so as long as it doesn't change it works nicely
  vmpstr: but it doesn't work with cross-document transitions
  vmpstr: and also for frameworks that might replace the dom nodes
  vmpstr: Another proposal is `element-uuid()` but it's effectively the
          same as above, just more explicit
  vmpstr: Another one is `attr()`, which would work for cross-document
          view-transition and frameworks
  vmpstr: My proposal would be to do both
  vmpstr: leaving attr for more advanced use cases

  fantasai: I think doing both (`auto` / `from-element` and `attr()`)
            makes sense
  fantasai: there was another idea in the thread which needs more
  fantasai: right now we restrict view-transition-name to be unique
  fantasai: if it's not it gets ignored or something, it's an error
  fantasai: in a bunch of cases, let's say you're shifting items after
            inserting into a list or so you don't necessarily want to
            number them all
  fantasai: if we could have multiple names and we could number them
            somehow automatically that might help
  fantasai: but that might be doable in addition to these things

  emilio: My main concern is how likely is it for someone to use from
          element and not realize it doesn't work for cross document?
  emilio: From where I stand it seems obvious it doesn't work, but
          requires some internals knowledge
  emilio: Just a mild concern, not blocking.
  fantasai: View transitions has been focused on the fact that you have
            "pages", and you're changing pages from one page in a web
            app to another one
  fantasai: but lots of transitions authors can do are single-page
  fantasai: and sometimes view-transitions is the best tool
  fantasai: For those cases this element identity stuff it's not an
  <ydaniv> +1
  emilio: For those use cases this is fine, it just feels like it might
          be confused
  emilio: or worse the browser could accidentally have a same pointer
  emilio: I guess that's just a bug

  flackr: My comment is somewhat related
  flackr: While I agree that attr() should be supported
  flackr: if the common case is an identity
  flackr: maybe we can roll it into `auto` in-some cases
  flackr: So if element has an `id` attribute then `auto` would take
  flackr: or an ancestor one or something
  <fantasai> interesting
  vmpstr: We still need to define for the `auto` cases
  vmpstr: We still need some identifier that an author can see
  vmpstr: I think the element's uuid is a good choice there
  vmpstr: but we haven't thought too much about it
  <fantasai> -1 to uuid
  <fantasai> if the author wants to reference it they should give it
             a name
  <fantasai> using the id attribute
  <vmpstr> it's about the param in ::view-transition-group(param) etc,
           not sure what to put there, or leave it as "auto"?

  astearns: I think the automatic number is interesting but has a
            different set of failure modes that it probably could be a
            separate issue
  astearns: I wanted to push back a bit, it seems a bit of a smell that
            people don't want to put unique names in css so we make
            them put it on the markup?
  fantasai: A lot of times you have these unique ids already
  fantasai: so you might as well just reuse them
  <fantasai> I like flackr's idea of having `auto` take the ID if it
             has one, and fall back to element identity matching

  emilio: Just want to confirm, allowing attr would make this id
          mutable in some interesting ways. I guess we have a well
          defined point where we collect them so it doesn't add much
          complexity, right?
  khush: I imagine it's similar to attribute changes requiring
         recomputing style
  emilio: My point is, if the mutation happens after we start the
          transition, then presumably it shouldn't count? This detail
          probably needs to be mentioned
  khush: This is called out already for view-transition-name as it's an
         issue already for name changes
  emilio: Sounds good
  emilio: The auto thing seems like it could use a bit more work since
          as vmpstr mentioned the name is exposed in the css. My slight
          preference is to resolve attr and figure out auto later
  emilio: Happy to also resolve on auto and resolve the details later

  khush: +1 to fantasai, attr() is useful where you already have unique
         names for your items without having to use JS
  khush: The other thing is, I think we'll have an easier time
         resolving on attr()
  <flackr> +1 as well, css is often in a separate file and not unique
           per element
  khush: For auto / from-element vs element-uuid
  khush: there was an example where element-uuid could be used to name
         an ancestor or child of an element rather than auto
  khush: auto would only allow to set the id on that element itself
  khush: One other point was that anything that ties with element
         identity it doesn't work for MPA
  khush: We might want to just ignore the name altogether for MPA
  khush: so it's harder to miss
  khush: but I think we should probably resolve on attr() and work on
         the other details on transitions

  astearns: I wanted to ask whether it'd make sense to make
            from-element only work on SPA and reserve auto for
            something that can work eventually on MPA
  astearns: So resolve on from-element for now, and opening an issue on
            an additional auto which does something along the lines
            that flackr was suggesting
  vmpstr: I don't mind the idea but I'd like a different name that
  vmpstr: I'd prefer a different id
  vmpstr: because from-element seems you're reading something from the
          element rather than using the element itself

  TabAtkins: Can we take it back to the issue? random() has similar use
             cases and we should make sure they're in sync

  flackr: For auto / from-element it was mentioned that this is exposed
  flackr: Is that necessary?
  flackr: Are there other ways we could do it?
  vmpstr: We can hide it by using auto
  vmpstr: We don't currently have the same parameter in the view
          transition pseudos I don't think it's a problem
  vmpstr: The reason we added view-transition-container is similar
  vmpstr: so I think we can hide it
  flackr: I think you can expose the initial style without a name
  khush: Web animations might be weird because you get a list of
         pseudos and can't differentiate it
  khush: Any place the name would have appeared then it'd be replaced
         with auto
  flackr: That's one possibility
  flackr: maybe there are others
  flackr: worth exploring
  khush: We use ua css to put styles, we need to figure out how the UA
         css would work
  flackr: Right, but that can be an implementation detail
  fantasai: I like flackr's suggestion of auto pulling the id if it has
            an ID and otherwise uses other way of identity
  fantasai: I agree we don't want to expose randomly generated IDs into
            author CSS
  fantasai: They can given it a name if they need to target something
  khush: attr() didn't ship for reasons
  fantasai: Let's draft some more concrete proposal
  fantasai: and come back
  vmpstr: Vague resolution is fine and we can come back with details

Received on Wednesday, 15 May 2024 23:38:11 UTC