W3C home > Mailing lists > Public > www-style@w3.org > August 2021

[CSSWG] Virtual F2F 2021-07-29 Part II: CSS Variables, CSS Flexbox, CSS Fonts 5, CSS Overflow [css-variables] [css-flexbox] [css-fonts-5] [css-overflow]

From: Dael Jackson <daelcss@gmail.com>
Date: Mon, 16 Aug 2021 18:16:59 -0400
Message-ID: <CADhPm3vv7ZO3vgnsD9kH=RDG1jOBjQAus0nxJHCN2=h4Jp_A7A@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 Variables
-------------

  - RESOLVED: Computed value preserves specified value (accept proposed
              spec) (Issue #5685: Custom properties and serialization)
  - RESOLVED: Registered properties same as normal property (whatever
              that ends up being) (Issue #5685)

CSS Flexbox
-----------

  - RESOLVED: Accept proposal and remove note (Issue #4311: Should
              definite flex-basis make the main size definite?)
  - RESOLVED: Specify current behavior (clamp the orthogonal box, not
              propagate the clamping to block children) (Issue #4221:
              Orthogonal column flex containers)

Fonts 5
-------

  - RESOLVED: Add a `incremental` to the `font-technology` values
              production as described on the PR (Issue #6063:
              @font-face supports incremental)
  - RESOLVED: Add this keyword in fonts-4 as well (Issue #6063)

CSS Overflow
------------

  - RESOLVED: Close with no change (Issue #3417: Selective
              overflow:hidden)

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

Agenda: https://github.com/w3c/csswg-drafts/projects/20


CSS Variables
=============
Scribe: fantasai

Custom properties and serialization
-----------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/5685

  TabAtkins: Question about precise details of earlier resolution about
             serialization of custom properties
  TabAtkins: Previously resolved to serialize back exactly as specified
  TabAtkins: to avoid compat issues
  TabAtkins: where authors would put content into custom properties
             that wasn't properly parseable with CSS rules
  TabAtkins: So if re-emitted with normal CSS normalization, changes
             content
  TabAtkins: e.g. UUIDs sometimes interpreted as scinot
  TabAtkins: Question also is, does this apply to computed values?
  TabAtkins: In issue, it's reasonably interop that computed values are
             also preserved as specified
  TabAtkins: except that var() functions are substituted
  <TabAtkins> --y: /* baz */;
  <TabAtkins> --x: /* foo */ var(--y) /* bar */;
  TabAtkins: Here serialization of --x is three comments in a row
  TabAtkins: I've put this in the spec
  TabAtkins: Want to make sure rest of group agrees

  TabAtkins: Also side issues, wrt non-custom properties containing
             var()s
  TabAtkins: whether those preserved or not
  TabAtkins: and then registered properties
  TabAtkins: With regards to computed value of custom properties,
             though, is that preserved exactly aside from var()
             substitution?
  astearns: Cycles?
  TabAtkins: Handled separately
  emilio: We resolved recently that white space is trimmed
  TabAtkins: Yes
  TabAtkins: by Syntax spec
  emilio: Aside from that, the rest should be preserved
  <TabAtkins> spec text:
https://drafts.csswg.org/css-variables/#serializing-custom-props

  fantasai: If we're not preserving in computed values it won't inherit
            correctly; you could manage in serialization but why would
            you if you have to preserve it anyway
  TabAtkins: Unless objections, can resolve?

  RESOLVED: Computed value preserves specified value (accept proposed
            spec)

  <TabAtkins> color: /* bah */ var(--x);
  TabAtkins: Next part is non-custom properties using var()
  TabAtkins: Here's an example. Normal serialization rules of color
             wouldn't preserve comment
  TabAtkins: Does this need to be preserved as well? Gecko does, but I
             don't think Chrome does
  TabAtkins: Chrome serializes this as var(--x)
  emilio: If it doesn't then what does it do?
  Rossen: Probably all comments are dropped for performance
  Rossen: only tokens are kept
  Rossen: Would have to go back and specify serialization
  emilio: When talking with Chrome about this, they don't keep original
          serialization but the list of tokens that was parsed, and
          probably they dropped comments
  emilio: when serializing need to be careful, insert comments in some
          cases to preserve tokenization
  emilio: In Gecko we preserve
  emilio: input as-is
  emilio: same rules as custom properties
  emilio: We do trim white space
  emilio: Other than that we keep the whole input as-is
  TabAtkins: That doesn't seem to apply when there's not a var()
  TabAtkins: Only do it when there's a var()?
  <heycam> I think it makes sense for this to work the same way as
           custom props themselves
  emilio: That and environment variables yes

  fantasai: So I don't understand
  fantasai: In the example, if you use red instead of var(), the
            comment doesn't get serialized
  fantasai: Why would it get serialized if you replace red with var()?
  fantasai: I would find that surprising
  emilio: Because you need to substitute first in order to
          tokenize (???)
  emilio: If you red there, you know the exact syntax
  emilio: keywords in colors are special, we do preserve that in
          specified value
  emilio: We keep an rgba value
  emilio: and keep the ident for legacy reasons
  TabAtkins: She's saying that, for any other normal property, when you
             serialize, you serialize out the ?? value
  TabAtkins: No direct relation to what author put in
  TabAtkins: It's unclear why you're referencing substitution as a
             reason to keep comments
  TabAtkins: This is pre-substitution
  TabAtkins: post-substitution
  TabAtkins: ...
  emilio: Other than actual values, we have uncomputed values which are
          strings
  emilio: We could keep lists of tokens, but is kind of tricky
  emilio: but if we define something other than what author put in,
          need to define how to serialize
  fantasai: Still don't understand why keeping the comment
  emilio: If using actual color, it gets parsed
  emilio: Things that need substitution aren't parsed
  fantasai: Still isn't making sense to me

  Rossen: If we have substitution rules defined, would you align?
  emilio: Yes
  Rossen: Tab, would you want to specify?
  TabAtkins: Both behaviors are allowed by syntax right now
  TabAtkins: Can preserve comments or toss them
  Rossen: Do we have any compat risk?
  TabAtkins: Doubt it
  Rossen: Do we need to worry about this issue?
  Rossen: Or just say it's allowed?
  TabAtkins: It's a CSSOM issue at this point
  emilio: Willing to have interop on this
  emilio: Would like to understand what chrome and webkit do
  emilio: because need to preserve some stuff, but not others
  emilio: If you put a UUID into a variable, do you actually serialize
          integers?
  emilio: Do you have same problem as custom property?
  TabAtkins: If you put UUID into a custom prop and then it goes into
             normal prop and somehow ends up valid
  TabAtkins: then specified doesn't matter because didn't do
             substitution
  TabAtkins: Computed value doesn't matter because substituted already
  TabAtkins: ...
  emilio: Is it useful to have consistent behavior for custom
          properties and normal properties?
  TabAtkins: I think our answer is we parse into token stream, throw
             out comments, reserialize (and have some errors in cases
             which needs comments re-inserted)
  TabAtkins: Could fix those bugs
  emilio: Do you also toss the comments?
  emilio: If you keep number token with integer on it, or do you keep
          1e3?
  TabAtkins: I don't remember
  emilio: That's the interesting bit. If you serialize what author put
          in, ff is more consistent
  TabAtkins: OK, I'll open a new issue on CSSOM

  fantasai: For consistency, what I'd expect is that non-custom
            properties are consistent with themselves as much as
            possible, and customs are self-consistent
  fantasai: And once you do a substitution that can be consistent with
            the original serialization rules...
  fantasai: But outside of that substitution, I wouldn't expect
            behavior to change, just because a keyword was swapped for
            a var()
  fantasai: Seems weird from a user pov
  <astearns> +1 to fantasai
  TabAtkins: OK, I'll open a new issue on CSSOM

  TabAtkins: Registered properties with a syntax, should act the same
             as a normal property
  TabAtkins: I assume that's uncontroversial
  emilio: Yes

  RESOLVED: Registered properties same as normal property (whatever
            that ends up being)

CSS Flexbox
===========

Should definite flex-basis make the main size definite?
-------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/4311

  dgrogan: Note in 9.8 ...
  TabAtkins: That note should not be adding any conditions ever
  dgrogan: Suggestion is to make this note normative and expanding
           cases where flex item can have a definite size
  dholbert: This is issue that biesi brought up last meeting
  dholbert: I wanted to check what Firefox did
  dholbert: I did follow up, and we do agree with the behavior that
            cbiesinger and dgrogan are proposing
  TabAtkins: This has nothing to do with the note
  TabAtkins: This issue is about a flexible flex item with a definite
             flex basis
  dgrogan: That note is inaccurate
  dgrogan: Definition of definite is you don't need to layout to get
           its size
  dgrogan: but many cases here has auto min size
  dgrogan: If we go with this idea in the spec issue, can just get rid
           of the note
  dgrogan: I think we're all on board with the idea behind this

  dgrogan: Do have question about a corner case
  <dgrogan> https://jsfiddle.net/dgrogan/4r9npf3z/3/
  dgrogan: The flex basis is 'content', but the height of ??? is
           definite
  dholbert: You're talking about 'height: definite'
  dholbert: In that case height property is ignored.
  dholbert: Only affects flex item if 'flex-basis: auto'
  dgrogan: Child of the flex item with percentage
  dgrogan: resolves against containing block
  dgrogan: "percentage is calculated with respect to the height of the
           containing block. If not specified explicitly, computes to
           auto."
  dgrogan: doesn't trigger behaves as auto clause
  dgrogan: I suspect this is minor editorial oversight
  dholbert: This is just CSS2 believing that only 'height' property can
            affect height
  dholbert: whereas in flex layout, there's other factors

  astearns: So additional normative change that cbiesinger suggested,
            sounds like we're in agreement to spec
  TabAtkins: We will add 4th condition to definiteness of flex items,
             that definite flex basis always make corresponding axis of
             flex item definite
  TabAtkins: Consequently can remove the note
  astearns: further comments?

  RESOLVED: Accept proposal and remove note

  <br duration=12m>

  scribe: emilio

Orthogonal column flex containers
---------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/4221

  fantasai: So originally if you have a horizontal document with a
            section with vertical text, and that box is a block
            container, we apply this implicit height on it so that the
            line of text doesn't become super-long
  <TabAtkins> quote from the issue: If you have a column flexbox that
              is orthogonal to its parent, and whose flex items are
              parallel (not orthogonal), per spec we pass the parent's
              infinite available block size to the flexbox's inline
              size, which then passes to the flex item, giving the flex
              item an infinite available inline size without the flex
              item itself being orthogonal.
  <TabAtkins> <!DOCTYPE html>
  <TabAtkins> <div style="display: flex; writing-mode: vertical-rl;
              flex-flow: column; border: 40px double;">
  <TabAtkins> <span>foo foo foo foo foo foo foo foo foo foo foo foo foo
              foo foo foo foo foo foo foo foo foo foo foo </span>
  <TabAtkins> <span>foo foo foo foo foo foo foo foo foo foo foo foo foo
              foo foo foo foo foo foo foo foo foo foo foo </span>
  <TabAtkins> <style>
  <TabAtkins> span { border: orange solid 40px;; }
  fantasai: So in flex and grid you have a bunch of items so you don't
            really have this need to restrict the height of the flex
            container for readability, just its items
  fantasai: You could just allow it to get tall
  fantasai: but it's kinda simple when you're setting up the orthogonal
            flow to apply the restriction without looking at whether
            its a block, which is what impl seem to do
  fantasai: So the question is do we want to cap the height of the
            orthogonal box, or the height of orthogonal blocks?
  fantasai: The other question is whether we do want to change
            behaviors if we choose the latter
  TabAtkins: At least impls are interoperable on clamping flex
             containers
  TabAtkins: The flex container gets the ICB clamping as is currently
             spec'd
  florian: I suspect there's no reason to change, the viewport size is
           an arbitrary measure
  florian: If we have interop I don't see a huge motivation for changing
  TabAtkins: That was our thoughts as well
  TabAtkins: We should probably spec the interop
  TabAtkins: Probably some small tweaks in flexbox+writing-modes
  fantasai: I think mostly writing-modes

  RESOLVED: Specify current behavior (clamp the orthogonal box, not
            propagate the clamping to block children)

  fantasai: The most common situation where I'd expect this to show up
            is if you have a vertical-text table (because you can put
            more content)
  fantasai: If you have a vertical-wm table in an horizontal document
            you prevent the table from growing
  florian: Only when max-content > icb height, not min-content right?
  fantasai: Right, is shrink-to-fit on the viewport

CSS Fonts
=========

@font-face supports incremental
-------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/6063

  myles: So the w3c has a web-fonts WG. For the past year or so it has
         been working on tech to make fonts progressive
  myles: Similar to how you load an image over a slow internet
         connection you get an image incrementally
  myles: The goal is to be able to load the part of the font that's
         necessary to draw the relevant text, but be able to draw that
         text before the whole font is downloaded
  myles: It wouldn't look blocky like images, it's more about slicing
         into glyph ranges etc
  myles: It's not possible on fonts right now because you need data
         from all over the file, so we're solving that
  myles: There's a behavior change for content, e.g., if you style a
         contenteditable div with these fonts typing might need to fall
         back to another font
  myles: so we think it should be opt-in
  myles: The best way I think would be via the supports keywords in
         @font-face
  myles: so the proposal is to add a new keyword to the
         `font-technology` production
  myles: to say that it supports incremental
  <fantasai> https://www.w3.org/TR/css-fonts-4/#font-face-src-parsing

  florian: Is it worth looking at the other possibilities?
  myles: The alternative would be "use a lot of js"
  florian: Nope

  emilio: One thing you mentioned is it may depend on the content being
          styled
  emilio: I don't see a great way to make it depend on the element
  emilio: Maybe you want your contenteditable...
  emilio: I don't have a better proposal
  emilio: Might be worth looking into this being allowed per element
  myles: so right now the strategy that we think makes the more sense
         is to annotate the font loads and not the elements
  myles: It'd be cool if the browser knew whether there was going to be
         dynamic content or such
  emilio: Isn't it like a will-change: content?
  emilio: We have precedent for will-change:not-a-property
  flackr: Yes there is
  myles: Do you think we should only annotate the element, or *also*
         the font-face?
  emilio: I think the font-face makes sense too
  myles: Ok so I think we can talk about these separately - could you
         open an issue?
  emilio: Sure

  flackr: Curious about how this interacts with font-display
  flackr: Do we consider a partially-downloaded font ready for use?
  myles: I don't know the answer to that, do you think that's a blocker
         for this?
  TabAtkins: Probably not

  RESOLVED: Add a `incremental` to the `font-technology` values
            production as described on the PR

  fantasai: Question: do we want to add this keywords to fonts-4 or
            fonts-5?
  fantasai: None of the stuff in 4 is implemented is it?
  myles: The metrics override is in 4 I think?
  fantasai: The override metrics is in 5 but the supports keyword is
            in 4
  fantasai: so I think we should move the new keyword to 4 or move the
            whole supports thing to 5, since nobody implements any of
            the other values either it seems
  myles: No strong opinion
  astearns: Given we have a PR, maybe let it land in place, tweak later?
  fantasai: It's a commit, right?
  myles: Yes
  myles: There's no argument against what you're saying so it's fine

  RESOLVED: Add this keyword in fonts-4 as well

CSS Overflow
============

Selective overflow: hidden
--------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3417

  florian: So the issue was raised about two topics but I want to focus
           on one
  florian: There's someone who wants some amount of things to escape
           overflow: hidden
  florian: The one I want to talk about is focus outlines
  florian: because not seeing them is an accessibility issue
  florian: There are various situations where this can happen
  florian: One is you have a scroller
  florian: Another is where the thing is completely hidden
  florian: The problematic one is where the thing getting focus is
           completely visible
  florian: in the UI spec we say that UAs have a fair amount of
           flexibility
  florian: I don't think UAs take advantage of that
  florian: but that's the question
  florian: The issue was also hinting about positioned elements and
           such, but we've talked about those
  florian: but for outlines there's no great conclusion

  Rossen: How are focus outlines different from other outlines?
  florian: They have different purposes
  florian: There's a special value that can be different,
           `outline-style: auto`
  florian: If you change it you are on your own but `outline-style:
           auto` is intended to provide that flexibility
  Rossen: On windows we don't have "native" outlines
  Rossen: They're made to look and behave as similar to the ones in
          the OS
  Rossen: but they're not native
  Rossen: They're native to the browser, and yeah there's a
          default-ua-styled outline
  Rossen: but (a) I don't believe this is any different than any
          outline from outline handling point-of-view
  Rossen: (b) if other outlines are specified by the user (e.g. excel
          has multiple focuses etc)
  Rossen: In all these things there's no "native" outline, it's
          overridden by the app
  Rossen: How would we know they're used as focus indicators to give
          them this kind of behavior?
  Rossen: So [restates]
  Rossen: It'll be difficult to try and categorize these two buckets
          and give them different behavior
  Rossen: so I'd like this behavior to apply to both outlines
  florian: But outlines can be decorative and that'd have no reason to
           escape overflow
  florian: so we'd need a different property or such
  Rossen: If you want a different outline value that the UA can use for
          its focus outlines, then that's reasonable
  florian: I'm not saying we should do that, but if we do then we
           should probably not make it automatic

  emilio: Agree with Rossen. outline:auto can be special. Focus
          outlines can look similar to carets - browsers currently
          agree on what clips carets
  florian: Difference with caret is that it's inside the thing, not
           around it
  florian: so you won't clip the entirety of the caret usually
  florian: but yeah not sure it changes the main point

  <dbaron> One thought, though, is about clipping of outlines on
           elements that are clipped...

  flackr: Two things. If we decided not to clip outlines, there'd be a
          bunch of edge cases with partially-clipped elements
  flackr: I'm concerned about getting that right from an aesthetic POV
  flackr: Can we modify the clip box? Providing an extra space for that?
  astearns: In some cases you don't know the dimensions of the outline
  flackr: Yeah, won't solve all cases
  Rossen: That was my idea with the optional outline value
  Rossen: Would be per element, would expand the clipping bounds
  Rossen: You have the ability of today (clipped) and the new thing
  emilio: That would still cause the issue flackr raised - should not
          show the whole outline and not the button in a scroller

  dholbert: I have an adjacent scenario which is `contain: paint`
  dholbert: If we are going to fix this in overflow: hidden, should it
            also escape `overflow: clip` and `contain: paint`?
  dholbert: and would it break `contain: paint`?
  flackr: It would but for what it's worth you can expand the clip area
          of `contain: paint` (`overflow-clip-margin`)
  dholbert: Yeah, but assuming these outlines are sorta
            implementation-defined it seems hard

  astearns: Do you want a resolution for this? It seems there's
            consensus on making this opt-in, but work on all outlines
  florian: Yeah, that's enough discussion I think

  smfr: I'm concerned about implementation complexity if we need to
        track different bounds for outlines
  smfr: I think I've heard "only outlines would be painted outside the
        clipping area", but maybe that's not the case?
  florian: We weren't describing precisely describing how it'd work
  smfr: This is a source of incredible complexity for implementers

  Rossen: I'd like to amend what I said, which is a compromised first
          step would be to at least consider the "special" areas as
          scrollable overflow
  Rossen: In the specific use case here (something positioned and
          overflow: hidden, then it's there)
  Rossen: having these outlines add to the scrollable overflow would be
          enough
  Rossen: The second layer of having these outlines escape I agree is
          very complex
  smfr: The commenter was asking about escaping overflow: hidden, not
        scrollable overflow right?
  fantasai: Making them scrollable overflow will cause layout changes,
            and you probably don't want that

  smfr: We should make easy for authors to add the relevant padding
        around things
  ???: Do native platforms have the same issues?
  smfr: Yes
  smfr: Another usecase of the proposal was tooltips, isn't there a
        different proposal for that? anchored-positioning?
  florian: Do you have links for that?
  smfr: I think gregwhitworth was working on that
  <smfr> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/CSSAnchoredPositioning/explainer.md
  <smfr> melanie and others

  astearns: Can you summarize and talk to the original proposer?
  florian: We can close now and re-open if the OP is not satisfied

  RESOLVED: Close with no change

  astearns: It was interesting to go through the options and
            strike-through all of them
  florian: Yeah I thought it was better on a call than letting it
           linger for a couple years
Received on Monday, 16 August 2021 22:18:40 UTC

This archive was generated by hypermail 2.4.0 : Monday, 16 August 2021 22:18:41 UTC