W3C home > Mailing lists > Public > www-style@w3.org > January 2023

[CSSWG] Minutes Telecon 2023-01-18 [css-contain] [css-view-transitions] [css-text-4]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 18 Jan 2023 19:55:45 -0500
Message-ID: <CADhPm3sTJZq8CQWo=xKDAbakfH=wvNqhoLeQ74xnpPuYwnFKjA@mail.gmail.com>
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 Contain

  - On the call there were two new options raised to address issue
      #7551 (Inconsistent handling of known and unknown features
      jeopardizes backward compatibility):
      - Each queried feature could evaluate to different container.
      - Attempt to match the queries against each possible container.
          If the container *can* match a given query, good; if not, it
          evaluates to unknown.
  - The group wanted to add examples to evaluate the two options so
      discussion will return to GitHub.

View Transitions

  - RESOLVED: Adopt suggested change to rename to `updateCallbackDone`
              (Issue #8144: domUpdated isn't the right term)

CSS Text

  - Discussion will return to github for issue #616 (Hyphenate only
      overflowing words?) to discuss if hyphenate-limit-zone could
      cover the use case.
  - The initial thought was it would be possible to use
      justify-content instead of text-group but there was a need to
      confirm the compatibility before going that route (Issue #5703:
      Re-use justify-content instead of text-group align?).


Agenda: https://lists.w3.org/Archives/Public/www-style/2023Jan/0006.html

  Jake Archibald
  Adam Argyle
  Tab Atkins
  David Baron
  Oriol Brufau
  Tantek Çelik
  Emilio Cobos Álvarez
  Yehonatan Daniv
  Luke Dary
  Elika Etemad
  Robert Flack
  Mason Freed
  Megan Gardner
  Paul Grenier
  Chris Harrelson
  Daniel Holbert
  Brad Kemper
  Jonathan Kew
  Rune Lillesveen
  Peter Linss
  Jonathan Neal
  Cassondra Roberts
  Jen Simmons
  Alan Stearns
  Miriam Suzanne
  Bramus Van Damme

  Chris Lilley
  Lea Verou

Chair: astearns

Scribe: bramus

CSS Contain

Inconsistent handling of known and unknown features jeopardizes
    backward compatibility
  github: https://github.com/w3c/csswg-drafts/issues/7551

  miriam: Discussed before but implementers have been pushing back
  miriam: Issue that in CQ we are just looking to see if it resolve to
          true or false but that something to resolve against
  miriam: In that finding container step we look at question ask: if
          looking for width we are looking for container with inline
          size set
  miriam: height block size, both
  miriam: Problem if when asking for width or height, it can resolve
          true even though half of it is recognized
  miriam: Feels fine for now, as it could become recognized later
  miriam: as we add queries it not only changes if it resolve to true
          or false but also which container to look at
  miriam: causing possible backwards compat issue
  miriam: where something resolves differently whether its recognized
          as a query feature or not
  miriam: Some vendors have shipped, so changing now is a breaking
  miriam: would love to resolve sooner than later
  miriam: Resolved previously was to split on the or [missed]
  miriam: Browsers said that would be difficult and not logic to split
          on or
  miriam: other directions with unknown query feature can match

  astearns: There is no container that can anSwer all sides of the
  miriam: Yes
  miriam: Width or unknown would then not resolve
  miriam: Width or height would also not match

  oriol: Agree that there are problems with or. what if you have
         negated and seems strange
  oriol: Also want to consider third option to consider: could be
         possible that each queried feature could evaluate to
         different container
  oriol: that is what we do with container units
  astearns: Not sure I understand
  oriol: For example at container rule "width > 100px and height
         > 100px"
  oriol: Parent that only has inline size will be able to match
         height. Other parent would match the width query
  oriol: Might be confusing though.
  oriol: just wanted to list for completeness
  oriol: Fine with 2nd option: if feature not recognize, just resolve
         as unknown
  miriam: In the or case it could resolve on one side of the query
  oriol: We would resolve each feature against the nearest container
         that supports it and if there is an unknown feature that we
         do not support by any ancestor then it would resolve entirely
         to unknown
  bramus: A unknown is then false?
  oriol: It does not apply the rule
  oriol: it only becomes false at the top level
  <TabAtkins> (I'm strong against resolving a single query against
              multiple elements.)
  astearns: Option 3 would allow to keep previous resolution
  astearns: Would get past implementer objection?
  oriol: What are the objections? probably third option more complex
         than option 2. haven't considered if easy to implement or not
  <dbaron> I do feel that it's strange that @container (width > 100px)
           { @container (height > 100px) { ... } } is different from
           @container ((width > 100px) and (height > 100px)) { ...},
           and I think oriol's option 3 fixes that... but it's also
           strange on itself, and maybe we should be thinking about
           use of container names as the "good practice" and these
           being sorts of error cases.

  florian: I understand option 3 and find it interesting in the
           abstract. Fairly hard time deciding whether that is
           confusing to authors or opens up a new and maybe convenient
  florian: Opens up extra possibility
  florian: would need examples to back up any reasoning

  TabAtkins: In the discussion with Antti he was having a different
             view of option 1?
  TabAtkins: Rather than looking at query and using that as a
             prefilter for containers to look at, we instead will look
             at each possible container and if the query can be
             resolved against that we will do that, otherwise unknown
  TabAtkins: In the case "width or height" will work on inline-size
             container because container can handle a part of that
  TabAtkins: but if you do "width and height" this would fail because
             of the 1 unknown
  TabAtkins: that was option 1, right?
  miriam: No, don't think so but that could work
  TabAtkins: Don't really understand what Antti's understanding is so
             I can't comment on what it might mean
  TabAtkins: but what I said is what I voted for
  miriam: That would work, as does oriol's proposal
  miriam: I don't see problems with oriol's proposal and potentially
          does match author intent
  TabAtkins: Disagree with that. You almost certainly want both
             conditions to match against same element, not a parent
             higher up
  * astearns agrees single container evaluation makes more sense
  TabAtkins: (mentions dbaron‘s note)
  TabAtkins: While you may want to target 1 element, you almost never
             want to target 2
  <bradk> +1 to what Tab said
  TabAtkins: While you might sometimes want to write nested queries
             and target the same element both times, you probably
             never want to write a single query and have it target two
             separate elements

  dbaron: Trying to understand option 1. it seems very strange to me
          that you would take a query "height or width" and then
          evaluate against 1 part of that against 1 element and ignore
          the 2nd part of the query
  dbaron: Seems strange. would expect to evaluate against a single
          element that answers to all parts
  TabAtkins: That's the compat issue: unknown query
  florian: no element
  miriam: option 1 may have been poorly written
  miriam: I think tab's and oriol's could work
  miriam: 1 container or loosen that?
  dbaron: Could tab clarify?
  <TabAtkins> So then my proposal: attempt to match the queries
              against each possible container. If the container *can*
              match a given query, good; if not, it evaluates to
              unknown. (Unknown queries are always unknown.) Then if
              the top-level result is unknown, move to the next
              possible container.
  <TabAtkins> So (true or unknown) will match, (true and unknown) will
              fail to match (and stop), (false or unknown) will
              continue looking.

  fantasai: RE 1 container or 2: it does seem weird that combining
            […]. if you wanted to match against single container we
            have explicitly type argument right?
  miriam: No, we don't
  fantasai: Ok, all implicit
  fantasai: If we had explicit type then author could define
  dbaron: auto-finding parent based on query might be bad idea. It
          should search using name or nearest
  miriam: That creates other problems such as style queries where we
          determined that you usually want direct parent so elements
          are style container by default so that you can query nearest
          but we don't want them getting in the way of size queries.
          Going with nearest is going to be fragile.
  TabAtkins: My proposal is going to match nearest that can possibly
             match. in worst case its going to be […] right away.

  astearns: I see couple of ways forward
  astearns: Resolve on tab's reworking of option 1 or take back to
  <dbaron> I'm OK with Tab's proposal.
  astearns: Anyone need more time to review?

  oriol: Not sure if I understand proposal; what does it mean that
         container matches query?
  TabAtkins: It means that you satisfy the conditions to potentially
             match. Mainly that you have right container type.
  oriol: How do the binary operators work?
  TabAtkins: If you aren't capable of matching, then evaluates to
             unknown. e.g. inline size vs width and height, one will
             be true/false and other unknown. if finale result at top
             level is unknown: skip and move up tree. if true/false:
             use that.
  TabAtkins: true + unknown = skip
  TabAtkins: true and false = false

  florian: I would like to go back to issue and throw some examples in
           issue to compare Tab's option and Oriol's

  dbaron: Weird consequence of tabs proposal: nested containers: inner
          one has inline and outer one haas both containmenbts. there
          is going to be a point where you switch from using inner one
          to outer one. that jump seems pretty weird
  dbaron: I guess we need to work through examples
  dbaron: ... to see if it does backwards jumping or not
  astearns: OK. let's take back to issue
  <fantasai> I believe with Tab's logic you might choose different
             containers depending on whether you support 'unknown'
  miriam: Other part of this: do we need use counters as this is
  astearns: Good idea. put it in issue.

View Transitions

domUpdated isn't the right term
  github: https://github.com/w3c/csswg-drafts/issues/8144#issuecomment-1377651538

  <JakeA> Summary
  <JakeA> View transitions wraps a state change - we attempt generate
          a transition from that state change
  <JakeA> The developer provides a callback where they do that change,
          usually by modifying the DOM in some way. It can be async.
  <JakeA> Sometimes you just want to know when the state change is
  <JakeA> We provided a promise for that,`domUpdated`, which fulfills
          when the promise returned by the callback fulfills
  <JakeA> Anne said "we don't really expose DOM as a term to web
          content", so the name is bad
  <JakeA> So, we need a new name
  <JakeA> Couple of options: `stateUpdated` - avoids using DOM, but a
          bit vague, might be confusing due to frameworks use of
  <JakeA> Vlad suggested that, since the promise resolves along with
          the callback, we name it `updateCallbackDone`.
  <JakeA> I like that, since if the developer does stuff other than
          DOM updating in the callback, the promise name still makes
  <JakeA> Anne is happy with that.

  JakeA: I can take up this one. Posted a bunch of messages above
  <TabAtkins> +1 to suggested name change, it's clear and tied
              directly to what's actually happening, and I think will
              make sense for an author.
  <masonf> `DOMContentLoaded` ?
  JakeA: I guess we are saying: any objections?

  astearns: Not knowing what the callback is named that seems vague.
            What is it?
  JakeA: It does not have an developer visible name. authors pass it
         in as argument
  JakeA: `updateCallback` and then `updateCallbackDone`
  <florian> have not followed deeply, but seems reasonable
  TabAtkins: I like it. Makes sense and matches spec language
  bramus: +1
  astearns: Proposed resolution: adopt suggested change to rename to
            `updateCallbackDone `

  RESOLVED: Adopt suggested change to rename to `updateCallbackDone`

CSS Text

Hyphenate only overflowing words?
  github: https://github.com/w3c/csswg-drafts/issues/616

  <fantasai> https://github.com/w3c/csswg-drafts/issues/616#issuecomment-1368091416
  fantasai: Link to comment
  fantasai: Can you turn on hyphenation but only if it overflows?
  fantasai: We could do this by adding keyword to overflow-wrap or
            hyphens property
  fantasai: hyphens controls hyphenation. values none/manual/auto
  fantasai: overflow-wrap controls what you are going to do with
  fantasai: Want to know if we want this addition and which one we

  astearns: Fine with adding. Slight preference for value in hyphens
  florian: Opposite slight preference for adding to overflow-wrap. But
           on the other hand hyphens prop also related of course
  florian: between line-break/word-break/overflow-wrap, lots of
           properties. [missed] adding extra keyword to that property
           keeps it that way.

  jfkthame: Not sure if this is a good idea. Its a very specific
            property. We already have other properties for authors,
            e.g. hyphenate-limit-zone
  astearns: You propose to setting that property to something close of
            width to only allow hyphenation in overflow cases?
  jfkthame: I think it would have that effect

  jensimmons: Seems like a valid use case.
  jensimmons: I can see people putting this in their default
              stylesheets and turning it on for everything. Not sure
              on how exactly to do it
  fantasai: We should take back and check with hyphenate-limit-zone
  florian: Same
  astearns: Let's take back to issue with jfkthame's proposal

Propose 'text-spacing: space-first' (trim-start-except-first-line) as
    a normal behavior
  github: https://github.com/w3c/csswg-drafts/issues/2462

  fantasai: there are new comments on the issue. maybe skip for today?
  florian: I think the comments support it, no?
  florian: Can wait
  fantasai: There are comments that it might not work as well for
  florian: Yeah, but it says 'it is not ideal' but what is ideal?
  florian: Can take a few days to reconsider
  astearns: Let's go on to next issue
  <florian> https://github.com/w3c/csswg-drafts/issues/2462#issuecomment-1367692407
  florian: People who care about this should read from [link] down
  astearns: Please all take a look

Re-use justify-content instead of text-group align?
  github: https://github.com/w3c/csswg-drafts/issues/5703

  <fantasai> -> https://www.w3.org/TR/css-text-4/#text-group-align-property
  <fantasai> -> https://www.w3.org/TR/css-align-3/#align-justify-content
  jensimmons: I can describe
  jensimmons: text-wrap is a property and balance is value for it
  jensimmons: It enables to do balanced text for text that spans
              multiple lines
  jensimmons: text-group in text level 4 is the new property to
              accomplish that use case
  jensimmons: Do we need this new property or should we use
  ntim: Makes sense to reuse justify-content
  ntim: [missed]

  iank: justify-content will start new formatting context, right?
  fantasai: Yes
  iank: So that is one relative difference between the two
  fantasai: We could define it to not do that
  iank: Would align-content be harmonized?
  fantasai: That one needs it
  fantasai: In terms of inline-axis one thing that gets weird when we
            don't create formatting context: what happens when we have
  fantasai: for floats inside the box it's straightforward, but if
            floats are intruding from the parent... it gets weird
  florian: I think it's good to create the formatting context
  florian: Then floats don't do strange things

  astearns: Questions about formatting contexts and floats are
            questions for either new property or the existing property
  iank: Float question falls into two sub questions
  iank: Would make easier if floats don't intrude from outside
  iank: How floats withing that if interacts is another question.
  florian: I think Alan is right that that concern applies to both
  iank: I want to point out formatting context difference.
  fantasai: I think what florian is trying to say: either way since
            neither property is implemented right now, we can decide
            what to do. question applies to both properties
  iank: Slight forward compat risk with reusing justify-content
  fantasai: Less concerned about that
  fantasai: Currently when you have a bunch of line boxes they fill in
            container. We have to tell those boxes to be shortened
  fantasai: and then there is this fun interaction with line boxes.
            Say I have a div and center it. In order for it to be
            centered we have to shorten line boxes. that is
            straightforward if boxes are directly contained by div.
            what if that div contains other divs?
  fantasai: Do we some kind of propagation? do we inherit? do we not
            affect any of the child divs? etc.
  fantasai: With justify-content there is more of a consensus that you
            lay out all children as a unit
  <iank> justify-content creating a new formatting-context is a
         relatively large compat risk IMO
  fantasai: [missed]
  fantasai: so it will not have any effect of centering the text.
  iank: If that list is shortening all the line boxes that [missed]

  astearns: Seems like issue that is going to come up for either
            version of the property
  astearns: Can we resolve on using justify-content or not?
  iank: Compat risk is making justify-content establish a new
        formatting context
  iank: Things suddenly become fc when they were not previously
  florian: Assuming people already use this property
  iank: Exactly
  <fantasai> specifically to blocks that are not already BFCs
  florian: Can we have a use counter to check?
  iank: I think apple folks are more interested in shipping
  astearns: Should prioritize whether we should create new fc or not
            and use that info to decide if we reuse property or go
            with proposed thing
  florian: yes, though we might still be able to go with
           justify-content even if we want a fc depending on the
           compat situation
  astearns: We are at time
  astearns: Let's take back to github
  astearns: Most likely need more discussion on compat issue
Received on Thursday, 19 January 2023 00:56:27 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:15:22 UTC