W3C home > Mailing lists > Public > www-style@w3.org > October 2020

[CSSWG] Minutes TPAC F2F 2020-10-20 Part III: CSS Sizing, CSSOM View, Logical Properties & CSSOM [css-sizing] [cssom-view] [cssom] [css-logical]

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 29 Oct 2020 19:38:54 -0400
Message-ID: <CADhPm3s+xiDU8QzquOu+uqQPNfc3Nu1LQ9dZMBkq29-xrykA3A@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 Sizing

  - RESOLVED: Adopt a property to solve the requested property and
              values from issue 4585 (Use cases for explicit
  - RESOLVED: Accept edits made (Issue #3973: Why was min-content,
              etc. redefined to do nothing in the block axis)
  - RESOLVED: Accept proposed edits to cyclic percentages in
  - RESOLVED: Rename term "intrinsic size" of image with "natural
              size" (Issue #4961: Distinguish intrinsic size's two
              definitions with two terms)
  - RESOLVED: Republish WD of css-sizing-3 (and start CR process after


  - RESOLVED: Add emilio as editor of cssom-view

Logical Properties & CSSOM

  - RESOLVED: During serialization, each logical property group is
              considered, and shorthand values can be emitted instead
              of the longhands only if the all the longhands of the
              same mapping logic are present and consecutive (ignoring
              all properties that are not in the group). Otherwise,
              the shorthand is not used when serializing the
              properties in the group. (Issue #3030: Interaction of
              shorthands and logical properties)


Agenda: https://wiki.csswg.org/planning/tpac-2020#agenda-schedule

CSS Sizing
Scribe: Tantek

Use cases for explicit intrinsic-size
  github: https://github.com/w3c/csswg-drafts/issues/4585

  <fantasai> https://github.com/w3c/csswg-drafts/issues/4585#issuecomment-701595999
  fantasai: We created this issue to collect use-cases for control
            over over intrinsic sizes of boxes
  fantasai: We have 3 maybe 4 behaviors collected now.
  fantasai: One is Web-compat behavior,
  fantasai: another is zeroing out the min-content contribution of
            scroll containers,
  fantasai: another one is zeroing out the min-content contribution
            when there is a percentage size or max size in that axis
  fantasai: Someone wanted to have a box that had the same behavior as
            a replaced element
  fantasai: They were able to replicate a lot with our aspect ratio
  fantasai: but this is a quirk of how replaced elements behave that's
            unrelated to aspect ratios

  fantasai: Question to the working group, do we want to design a
            property to switch between these different values?
  fantasai: Second question to working group, are there are other
            cases we should add to this?
  Rossen: Opinions?
  (awkward silence)
  Rossen: Do we care enough about this? Or we can also move on if
          there is not enough interest here
  Rossen: There was interest here. In terms of behavior what do we
  Rossen: dbaron also dumped a bunch of mozilla bugs that were a good
          indicator that we need to look into solving this
  Rossen: I don't see anyone on the queue or engaging
  Rossen: Shall we close the issue with no change?

  cbiesinger: I would really like to have this property
  cbiesinger: The second part was requested by me because I know some
              people who want to use this on their websites
  cbiesinger: to set the min-content to zero to act like replaced
  cbiesinger: Seems like useful behavior to get the regular size
              normally but when you shrink the window you can shrink
              the element with it
  cbiesinger: That's my case for it
  fantasai: Proposed resolution: define a property to switch between
            these behaviors and hope someone comes up with sensible
  Rossen: better than the ones currently in the issue

  jensimmons: I also think this is a really good idea
  jensimmons: I can see... it's sort of an advanced feature ...
              authors need to wrap their heads around sizing period.
              it requires understanding how layout works first.
  jensimmons: To me the big use-case is you have multiple grid items
              in a grid track, and the track itself is going to be
              based on something in the track, and you can say don't
              base it on the headline, base it on something else
  jensimmons: you set its intrinsic size to 0 or 100px
  jensimmons: That could be very powerful
  jensimmons: The columns will be the size of the content in it,
              except not this content or this content
  Rossen: Thank you. Other opinions or objections to adopting such a
          property. Name and value names tbd
  Rossen: I see some nodding of heads
  Rossen: no objections

  RESOLVED: Adopt a property to solve the requested property and
            values from issue 4585

Why was min-content, etc. redefined to do nothing in the block axis
  github: https://github.com/w3c/csswg-drafts/issues/3973

  Rossen: cbiesinger you opened this one
  Rossen: and you also added it to agenda+
  cbiesinger: I did?
  Rossen: On Jan 22
  cbiesinger: Oh that was a while ago lol
  cbiesinger: Why are we discussing today, wasn't it addressed by a
              recent edit?
  TabAtkins: Yes it was
  TabAtkins: making sure others are ok with the edit

  cbiesinger: I can summarize
  cbiesinger: In the block axis the ..[missed].. and fit-content take
              the same value as auto
  Rossen: Sounds reasonable
  cbiesinger: It lets you get the min height auto behavior from
              flexbox and grid
  cbiesinger: and ... ratio in other contexts
  <fantasai> at one point the spec defined min-content/max-content/
             fit-content to behave the same as 'auto' in the block axis
  <fantasai> the edits changed that to say that the min-content and
             max-content sizes in the block axis are as defined by the
             layout model, defaulting to max-content behavior
  <fantasai> more or less
  Rossen: Any other opinions?
  Rossen: Or objections to accepting the edits?

  RESOLVED: accept edits made

Cyclic percentage concept should not exist
  github: https://github.com/w3c/csswg-drafts/issues/3010

  fantasai: This was less of a change in behavior, and more of a
            change in how it was explained
  fantasai: Determining whether a percent is cyclic is itself a bit
  fantasai: but not all percents are cyclic
  <fantasai> https://github.com/w3c/csswg-drafts/issues/3010#issuecomment-672335319
  fantasai: We tried to draft a clarification ^
  fantasai: We wanted to know if that would make the spec acceptable
  fantasai: We're trying to get this spec to CR soonish

  Rossen: Ok
  Rossen: Special resolution is defined after this paragraph?
  Rossen: This clarification is pretty good actually
  Rossen: Any other opinions or feedback?
  dbaron: The new text looks good to me
  fantasai: Yay!
  Rossen: Hearing no objections

  RESOLVED: Accept proposed edits in

Distinguish intrinsic size's two definitions with two terms
  github: https://github.com/w3c/csswg-drafts/issues/4961

  fantasai: We've been using intrinsic size to refer to two different
  fantasai: One is the size of a replacement element
  fantasai: The other concept is referring to the min-content and
            max-content sizes, which always exists for any box, they
            are determined in some manner
  fantasai: We need two different terms for this
  fantasai: The HTML spec uses the term natural width and natural
  fantasai: We were thinking to replace the use of intrinsic size as
            it applies to the inherit size of a replaced element with
            natural size
  fantasai: and keep intrinsic size to mean the other
  <heycam> +1 for aligning terms across specs

  florian: With the new dfn, the intrinsic size of a replacement it
           would be the natural size and 0 otherwise?
  fantasai: No it can lack an intrinsic size
  florian: I don't understand
  fantasai: You have to distinguish between whether you are taking
            about a min-content and a max-content size
  fantasai: When the natural size of something does not exist, there
            are rules for determining a non-zero min-content size

  myles: Is this purely a rename or behavior change?
  fantasai: Purely terminology in the spec

  cbiesinger: This is only for replaced elements but, don't you need a
              terminology for non-replaced elements with an aspect
              ratio because the regular min and max content size will
              be affected by the aspect ratio, but you also need a way
              to refer to the original min and max content size
              because you need that for min-size auto
  fantasai: I see what you're talking about, haven't thought about
            that yet

  heycam: We should check what the HTML spec says
  heycam: and I did, and they return 0 for images that have no natural
  heycam: I just want to make sure we don't have any confusion by
          using the same terms
  fantasai: I think the DOM APIs can return 0 when there is no natural
            size, even though we consider undefined distinct from zero
  TabAtkins: Do the DOM APIs refer to it any other way other than the
             camelcased form?
  heycam: No it refers to JS properties

  florian: HTML spec says natural size is intrinsic size.
           This is confusing / not good
scribe: fantasai
  fantasai: Their spec is using 'intrinsic size' because that's what
            our spec (css-images-3) uses.
  fantasai: When we update our specs, we'll make sure HTML updates
            their terms to match also

  Rossen: Hearing mostly support for having this clear distinction
  Rossen: Are we leaning towards also accepting the proposed names
          here, "natural size"?
  <florian> +1
  fantasai: 2 votes in favor from rachelandrew and SimonSapin on GH
  <bkardell> +1
  <bkardell> actually this confused me quite a bit last year
  <bkardell> I remember having exactly this conversation with tab in
             toronto trying to figure it out
  Rossen: I don't see anyone not liking it. Any objections?

  RESOLVED: Rename term "intrinsic size" of image with "natural size"

  Rossen: Seems like everything on Sizing 3
  Rossen: Alan has an editorial issue to talk about


  Rossen: With everything we resolved, do we need to republish
  fantasai: Yes, and
  fantasai: That closes all the major issues on this spec, so we'd
            like to issue a last call for comments and start preparing
            for CR
  astearns: So resolution to publish after all these edits are in?

  RESOLVED: Republish WD of css-sizing-3 (and start CR process after


  astearns: emilio just volunteered taking on cssom-view at least on
            the issues he raised

  RESOLVED: Add emilio as editor of cssom-view

  <smfr> thank you emilio!
  <myles> emilio is the best

  astearns: Note that emilio also has editorship of cssom, and
            probably needs help

CSS Logical Properties
  scribe: tantek

Interaction of shorthands and logical properties
  github: https://github.com/w3c/csswg-drafts/issues/3030

  fremy: Main issue is that in CSS spec it defines how to serialize
         properties, contains a lot of tricks to merge declarations
  fremy: e.g. if you set all four border properties, the rules merge
         it to a single declaration
  fremy: When I looked at the logical properties, this is not as easy
  fremy: Even if you have all four, you cannot always merge them into
         a single property
  fremy: It means you have to detect this case (e.g. inline-start) and
         do something smart
  fremy: logical and physical properties
  fremy: Proposing a couple of rules to the serialization steps
  fremy: to only merge all four if they are of the same type
  fremy: While we were looking at this, a few more updates
  fremy: e.g. dbaron proposed if you set the margin property on the
         style attribute
  fremy: There is no reason to keep the margin-inline properties
  fremy: the logical ones
  <fantasai> (because they have all now been overridden)
  fremy: proposal: make sure that the grouping would work
  fremy: making sure when you set things you override property

  emilio: Gecko has the concept of logical property groups
  emilio: We added it to the spec
  emilio: This concept already exists
  emilio: e.g. border-inline-start:10px; border-start:20px;
  emilio: Gecko will do the right thing
  emilio: The concept is already in the spec. This is an obvious bugfix
  <Rossen> See the refs for
  fremy: The link sounds like exactly what I'm proposing that seems

  fantasai: We should make sure ... interleaved ... then that can be
            folded into a shorthand
  fantasai: The other part of your proposal, if a shorthand is set,
            then you can drop any previous declarations that set any
            property in that logical property group
  fremy: That sounds correct to me
  <emilio> https://drafts.csswg.org/cssom/#set-a-css-declaration is
           already using this concept
  <emilio> We should use it from serialization

  Rossen: Do we not have this currently specified? The part you just
          added fantasai? In terms of the behavior?
  fantasai: I think in terms of how everything is supposed to behave
            like cascade, etc. is defined. This is about CSSOM
  Rossen: So this is going into CSSOM then? mostly?
  fantasai: I guess so. emilio and I will work it out
  Rossen: Any other opinions?

  emilio: I need to look a bit more closely at the replace all the
          physical longhands
  emilio: because there are more complex cases
  emilio: e.g. shorthands that only override two properties
  emilio: Like the serialization stuff when stuff is interleaved,
          that's good
  emilio: The replace of the existing physical properties, that may or
          may not be confusing
  fantasai: I think they are two separate proposals that happen to be
            in the same issue
  Rossen: Can you separate them for resolutions?
  <fantasai> First proposal from fremy: During parsing of a css
             declaration block, shorthands (like margin and all)
             expands only to the set of longhand (grouped by mapping
             logic: so either logical or physical) required to
             describe their value, and by default resort to use
             physical properties if both sets are possible. Note that
             they can only expand if they do not contain var()
  <fantasai> Second proposal from fremy: During serialization, each
             logical property group is considered, and shorthand
             values can be emitted instead of the longhands only if
             the all the longhands of the same mapping logic are
             present and consecutive (ignoring all properties that are
             not in the group). Otherwise, the shorthand is not used
             when serializing the properties in the group.
  Rossen: Please read the first one, which is about the behavior
          specifying, and how declaration blocks behave between
          shorthands and longhands and logical properties
  fantasai: Looks like I'm finding more pieces of it
  fremy: The first one I assume every browser already does that
  fremy: it's not clear from the spec, but I assume that should work
  <fantasai> Third piece from fremy: When removing a shorthand
             property, all the longhand associated with that shorthand
             should be removed, regardless of their mapping kind.
  <TabAtkins> +1, all sound good
  <fantasai> Fourth piece from dbaron: appending a shorthand property
             could set all of its constituent shorthands of one
             mapping logic and also remove all of the constituent
             shorthands of the other.

  Rossen: Any objections to accepting this first proposal
  emilio: Question, we are talking about shorthands that map to both
          physical and logical properties? but those do not exist in
          browser today
  fremy: It's possible, back them we had proposal for margin, I don't
         know if we still have that
  fantasai: We never figured out a syntax that was appropriate
  fremy: That was mostly to make sure that case worked
  fremy: I don't think it's wrong to add this even if we don't have
         the mechanism
  emilio: Not saying it's wrong, just possibly confusing

  fremy: Mostly the loop needs to be modified
  <fremy> https://www.w3.org/TR/cssom-1/#serialize-a-css-declaration-block
  Rossen: Wanting make sure everyone is comfortable with accepting
          this change
  <emilio> yeah, +1 for the serialization change, that's
           unobjectionable imo
  Rossen: Without delaying people too much, any objections or wait
          till Thu morning?
  fremy: For me both is fine

  RESOLVED: During serialization, each logical property group is
            considered, and shorthand values can be emitted instead of
            the longhands only if the all the longhands of the same
            mapping logic are present and consecutive (ignoring all
            properties that are not in the group). Otherwise, the
            shorthand is not used when serializing the properties in
            the group.
Received on Thursday, 29 October 2020 23:39:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:16 UTC