[CSSWG] Minutes Telecon 2021-09-22 [css-box] [css-writing] [css-shadow-parts] [css-color-adjust]

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

  - RESOLVED: margin-trim applies to flex and grid containers also
      (Issue #3255: Should margin-trim apply to flex or grid
      containers?)
  - There was difference in the behavior expected by authors and the
      implementation behavior for issue #3256 (Should margin-trim have
      a 'floats' value?). Conversation will continue on github to
      gather the use cases in order to determine the best solution.
  - RESOLVED: margin-trim determines which sides to apply to as
              described in #6643 (Issue #6643: Switch margin-trim to
              boolean indicating sides rather than types of boxes to
              trim)

Writing Modes & Shadow Parts
----------------------------

  - There are several test cases outlined in issue #6609
      (Directionality inheritance into Shadow DOM) that need to be
      reviewed to see if the behavior the tests describe is correct.
      fantasai offered to review, but anyone interested should also
      look at the github issue and provide feedback.

CSS Color Adjust
----------------

  - The proposal for issue #5469 (Should forced-colors override
      border-image?) is to continue leaving border-image as-is and add
      language to explain the rationale and that it's limited to
      border-image.

===== FULL MINUTES BELOW ======

Agenda: https://lists.w3.org/Archives/Public/www-style/2021Sep/0011.html

Present:
  Rachel Andrew
  Rossen Atanassov
  Christian Biesinger
  Oriol Brufau
  Daniel Clark
  Emilio Cobos Álvarez
  Elika Etemad
  Robert Flack
  Simon Fraser
  Megan Gardner
  Daniel Holbert
  Brian Kardell
  Jonathan Kew
  Ting-Yu Lin
  Peter Linss
  Morgan Reschenberg
  Cassondra Roberts
  Miriam Suzanne

Regrets:
  Tantek Çelik
  Chris Harrelson
  Dominik Röttsches

Scribe: fantasai
Scribe's scribe: florian & rossen

Agenda/Scheduling
=================

  fantasai: Just wanted to suggest taking the first 3 issues in reverse
            order

TPAC
----

  Rossen: TPAC sessions are coming up soon
  Rossen: Please add Agenda+ TPAC as needed
  Rossen: We'll assume Agenda+ F2F is also for TPAC, but if specific
          ones for TPAC please tag appropriately
  <astearns> all overflow from today will go in as well

CSS Box Model
=============

Should margin-trim apply to flex or grid containers?
----------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3255

  miriam: margin-trim is designed to remove margins at the edge of the
          box that are inside the box
  miriam: e.g. you have h1 inside section, but don't want margin on the
          h1 because section already has padding
  miriam: or ...
  miriam: That happens most often in block dimension, can also happen
          sometimes in inline dimension
  miriam: We were looking through issues around it
  miriam: One issue was whether it applies to flex or grid containers
  miriam: And idea is to let it apply to both of them
  jensimmons: sgtm
  florian: Haven't thought deeply, but wfm

  Rossen: Does this have an affect on alignment?
  fantasai: Only to the extend that if you only trim alignment on one
            side of the box, you'll have alignment on the rest
  Rossen: So margin-trim is pre-alignment
  fantasai: For instance, things would not longer be centered if you
            trim on some sides
  Rossen: Might check if this is desired effect, but sounds good to me
  Rossen: Anyone else?
  Rossen: Any objections?

  RESOLVED: margin-trim applies to flex and grid containers also

Should margin-trim have a 'floats' value?
-----------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3256

  miriam: Question is should floats be able to do margin-trim
  miriam: It seemed to us that floats that are at the edge of the box
          that have a box that would impact the box should be
          considered the same as any other margin against the edge of
          the box
  miriam: There might need to be special definitions to define
          precisely when floats are impacted
  miriam: but don't need ability to control separately

  florian: I think we need some amount of independence
  florian: Antenna House Formatter has proprietary controls
  florian: for e.g. controlling the margin between two floats
           differently from margin between float and edge of the page
  florian: when being particular about layout of complex documents with
           floats
  florian: (not floats as substitute for grid, but actual floats)
  florian: then you do want that kind of control
  florian: Float to float margins and float to text margins are often
           different
  florian: Some amount of float margin trimming explicitly is needed
  miriam: I was thinking if we think of the trim as coming from the box
          edge, we could maintain the exclusion box of the float with
          the margin so if it's pushing anything else that margin is
          still there, but it's trimmed as far as the box is concerned
  miriam: That seems to make sense to me
  miriam: and that wouldn't need manual control

  iank: Should this just apply to in-flow elements?
  iank: That seems to be the main use case here
  iank: ...
  florian: What would apply then? If I do want to trim the margins of a
           float
  florian: for the purpose of not pushing other floats apart, it would
           work, but if not, then we'd need another property
  iank: It's a bit hard for me to reason when we don't have
        particularly strong use cases one way or another
  iank: use case described seems to be for in-flow children
  iank: Consider the out of flow position case, not intending to act on
        that
  iank: floats seem in-between to me
  miriam: If the section that the float is in is wrapping the float
  miriam: e.g. is a block formatting context root
  miriam: then I would expect the float the behave as in-flow wrt that
          box
  miriam: The margins on the float would be pushing the size of the box
          which is exactly what we're trying to avoid here

  fantasai: I think that it makes sense to apply trim to floats. You
            want to have a solid control of the vis edge of the new
            box. Considering a section with content and float that has
            margin, done so content doesn't clash. If on top however
            you want to trim it so that it doesn't get displaced
            compared to rest of content.
  florian: You need to trim all such margins. It makes sense to trim
           all of margins as well as inline.
  iank: For that specific case I don't think trimming the float is
        warranted
  iank: e.g. suppose you put 5px margin around the float, then want
        that to stay all around
  fantasai: Not sure you want that margin necessary. Mostly vis content
            is what you want to align to. If you want to get the edge
            of flow and text to align so you can put a margin around
            you can. That way if float comes later in flow it has it
            but not at the top.
  fantasai: You can also skip using it. Use selectors for these first
            elements to remove margins etc.
  jensimmons: I think it could be confusing if margin-trim works
              sometimes and not other times
  jensimmons: "it counts if it's an image in a float, but not if ..."
              It's a lot to keep in your head
  <emeyer> +1 to @jensimmons point

  Rossen: I'm closer to iank's opinion here... generally speaking,
          float layout is not inline layout
  Rossen: They take part during inline layout, however in all
          implementations floats are kept separately based on whether
          left or right float alignment
  Rossen: and float layout is wrt all floats themselves
  Rossen: We go to great extent in float algorithm in CSS2 to avoid and
          minimize the dependency an inline content and floats as much
          as possible
  Rossen: Position of float wrt content ...
  Rossen: seems odd
  Rossen: because even a float that comes in the beginning of the
          content, that more or less guarantees part of first line
  Rossen: That float can be left or right
  Rossen: and really left margin doesn't make sense for right float and
          vice versa
  Rossen: seems very specific to make that an automatic behavior by
          layout algorithm
  <iank> e.g. https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=9645

  fantasai: This is about trimming margins on content of all other
            layouts - block, flex items, grid items. etc.
  fantasai: Should also trim floats
  fantasai: Also not sure why concerned about inline layout, this isn't
            inline layout
  Rossen: Floats are out of flow
  fantasai: Yes, they're taking out of their original position, but
            they're in-flow in the sense that they affect the content
            around them, unlike abspos
  Rossen: Floats create geometry for laying out content around it
  Rossen: Their placement takes place ahead of inline content around
          them
  florian: You talked about inline margins
  florian: Discussion is about block-start margin of the float being
           trimmed
  florian: If you want to put a 1em margin around your floats to avoid
           the text of your float crashing against the surrounding text
  florian: it doesn't necessarily mean you want your float to be 1em
           from the start of the block
  florian: There's nothing to crash into above it
  florian: It does depend on the document, but there are cases here
  florian: Elika gave explanations already, did you want scans of books
           or something?

  miriam: I would follow up with with what Jen said
  miriam: There are interesting discussions from impl point of view
  miriam: But from author point of view, not making sense
  miriam: If I have a box and I want to trim the margins at the edge of
          the box
  miriam: I would expect it to trim all the margins at the edge of the
          box
  miriam: I wouldn't expect some difference because one is floated or
          not or whatever
  miriam: ...
  miriam: Also margin-trim is only applied at the box edges. It doesn't
          affect how content is flowing together
  miriam: It determines what happens when I have a box and a float
          inside it or a paragraph or a header inside of it
  miriam: I trim the margins when they are at the box edge, and those
          are the only margins I'm trimming
  florian: I support miriam's position. If you simplify the value space
           and exclude one of them, you can still have individual
           control by using selectors
  iank: Apply to out of flow elements?
  miriam: I would expect to things that impact the size of the box
  florian: wrt abspos, whatever
  Rossen: For purposes of computing scrollable area, they do affect
          layout as an inline margin would
  Rossen: Behavior that we just described with abspos element that has
          large margin bottom, would still create a large scroller with
          visibly nothing below

  iank: Other thing I wanted to ask...
  iank: Example where using margin-trim is desirable but also
        margin-trim is desirable
  iank: How would I get that back, if it does apply to floats?
  <iank> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=9645
  miriam: I think you would either use padding, or you would not use
          margin-trim in that case
  miriam: If you want different impact on different elements, you would
          do it manually instead of using margin-trim

  iank: Other question is, now that we have nesting, it's very easy to
        implement effectively margin-trim now
  iank: Does the use case for margin-trim become less due to this?
  fantasai: Margin trim is going to effect all elements very simply,
            but with selectors you'd need to drill down to descendants
  fantasai: margin collapsing makes that complicated
  fantasai: That's why we don't do it on table cells with selectors,
            and why it'd be good here too
  iank: If I want margin on the float and not the in-flow, then what do
        I do?
  fantasai: Then don't use margin-trim
  fantasai: Isn't that the same question as with multiple items at the
            top row of a grid? at that point you can't use margin trim
  iank: It is common to want margin on the float and not the rest of
        the content
  fantasai: I think the reason you often see margin on floats and not
            in-flow content that's supposed to align is because in-flow
            content isn't visibly flush
  fantasai: but we're working to make that possible, so you won't need
            to add margin to the float to make it look like it's
            visually aligned with the in-flow content
  iank: I don't think that's entirely true...
  iank: but maybe we should discuss in the issue
  miriam: I don't entirely understand your example, Ian.
  miriam: I would expect padding on the content
 <iank> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=9646
LHS still seems better?

  Rossen: I think this is a great discussion and I certainly want to
          see progress made here
  Rossen: The use cases that I just understood make sense
  Rossen: But I also think we need to do some more careful thinking
  Rossen: Maybe talk through use cases and narrow down what's possible
          and what's not, and try to figure out expectations
  Rossen: so maybe take up again later

Switch margin-trim to boolean indicating sides rather than types of
    boxes to trim
-------------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/6643

  miriam: This one might be tied to previous
  miriam: If there's a reasonable way to apply this to everything
          without being specific
  miriam: we can make margin-trim to make boolean on/off and indicate
          the relevant axes
  miriam: as values of the property
  miriam: e.g. margin-trim: block;
  miriam: most common values are probably all/block/block-start/
          block-end but others might be wanted
  miriam: Basically property would say which sides need trimming
  <emeyer> I can think of many situations where I’d want to trim inline
           margins on floats.
  <fantasai> emeyer, note the property is set on the container not on
             the floats ...

  Rossen: On the face of it, I think it makes sense
  Rossen: but does go back to what it applies to
  Rossen: I don't know if your assumption here about floats is that
          strong
  Rossen: Even if doesn't apply to floats, wouldn't you expect it to
          apply the same way

  florian: Question is if you have choice of whether to apply to floats
           or not, then there's a bit of an explosion
  fantasai: We could make it into multiple properties
  fantasai: but the 3 way choice is the current syntax
  Rossen: ...
  miriam: If we had only none | all
  miriam: then could use this proposal
  miriam: But if need to control what to trim, then need maybe another
          property
  miriam: But if specifying which sides to trim, and then come back to
          whether we need control over what to trim?
  Rossen: Thoughts?
  miriam: Should we take the proposal on control over sides, and then
          come back next week with question of whether to apply to
          floats or not?

  RESOLVED: margin-trim determines which sides to apply to as described
            in #6643

Writing Modes & Shadow Parts
============================

Directionality inheritance into Shadow DOM
------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/6609

  emeyer: WHATWG triage committee had questions about directionality in
          Shadow DOM
  emeyer: There's been several discussions there
  emeyer: It's summarized in this comment I linked...
  emeyer: I drafted some tests
  emeyer: Wanted to ask CSSWG to confirm if test asserts are correct
  emeyer: and if not to correct that
  emeyer: Summary is if there is explicit dir value on any element
  emeyer: then that value holds sway whether shadow or light DOM element
  emeyer: [...]
  emeyer: So if you set LTR on a shadow host then the slotted content
          will be LTR even if Arabic
  emeyer: but if set auto on the slot, then it will use its inherent
          directionality

  fantasai: What do you mean by inherent directionality?
  fantasai: dir=auto is defined to resolved based on the directionality
            of the first strong character, which is a heuristic and not
            appropriate if you know the actual directionality of the
            content
  fantasai: Are you saying that when slotting content into a shadow
            tree that has set directionality on its own elements, you
            lose the information about directionality that was in the
            light DOM on any slotted content
  fantasai: are you saying that if you slot content with directionality
            into some shadow structure, it loses its directionality?

  bkardell: This is where this is stuck in verbiage. The spec doesn't
            say and in order to write the spec we need to know what.
  bkardell: What we have done is to capture all tests and some of the
            answers. We need csswg to make sure the words being used
            are correct.
  fantasai: Happy to review offline
  emeyer: Brian did great summary of the tests and I have my verbiage
          of what should probably go in the spec
  emeyer: Please take a look, review, review the test correctness and
          we can move on to write it all up.
  fantasai: There's a bunch of discussion on what the behavior should
            be. Lost track of it
  bkardell: This is why we did this through examples and some text.
  <florian> I haven't reviewed the tests, but I believe that the
            summary describes problematic behavior. To be looked into…
  <fantasai> I just want to say that I think it would be very
             problematic if using a component meant that the light
             DOM's directionality got lost whenever that content got
             slotted into the component
  <fantasai> And I believe I said so in the thread a couple years ago,
             though I don't know what's happened in the discussion since
  <bkardell> fantasai: this is why we'd like you to review specific
             tests holistically and tell us where you disagree, and
             what is writeable
  <fantasai> bkardell, I don't think my position has changed compared
             to what I commented in the thread years ago
  <fantasai> bkardell, if there's new information I might reconsider...
  <florian> fantasai's earlier detailed explanation of what ought to
            happen with directionality and shadom dom is at
            https://github.com/whatwg/html/issues/3699#issuecomment-395876573

  <astearns> thanks for all of the test-writing!

CSS Color Adjust
================

Should forced-colors override border-image?
-------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/5469

  [Rossen reads Alison's comment:
      There is special logic in the spec
      ( https://drafts.csswg.org/css-color-adjust-1/#forced-colors-properties )
      for handling background-image in Forced Colors Mode:

      background-image computes to none unless the original value
      contains a url() function

      Perhaps it would make sense to do something similar for
      border-image to override gradients.

      (I could see the argument for overriding a url() in the case of a
      border-image since they're more likely to be used in a decorative
      capacity, although I'd also lean toward keeping those in case
      they carry semantics.)
  ]

  fantasai: The question in the issue was, does the concern that caused
            background-image to not be overridden also apply to
            border-images, or are we just assuming that they should
            behave the same?
  fantasai: This question was not answered.
  Rossen: We had a ton of feedback about background-image, problem to
          override them
  Rossen: But no feedback about border-image
  fantasai: Why should you not override border-image?
  Rossen: Because we never overrode them, so never got feedback about it
  Rossen: Our preference is to leave border-image the same way
  Rossen: since we never got any feedback over the years
  Rossen: so don't want to change
  Rossen: If we start overriding border-image today, it would be a
          change
  florian: So might be fine but we don't know for sure
  Rossen: Problem is it will affect tail end of the Web
  Rossen: So our proposal for this issue is to keep it that way
  Rossen: Is that reasonable?
  fantasai: Yes. We just needed some rationale that was specific to
            border-image

Received on Wednesday, 22 September 2021 23:43:42 UTC