[CSSWG] Virtual F2F 2021-04-08 Part II: CSS Values, CSS Text, Fill and Stroke, CSS UI, Overflow, CSS Fonts [css-values] [css-text] [fill-stroke] [css-ui] [css-overflow] [css-fonts]

  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 Values

  - RESOLVED: Adopt an 'inherit' function to values-5 (Issue #2864:
              inherit() function: like var() for parent value, for any
  - It was noted that making this work would require us first to have
    100% interop on value serialization across all properties, which
    is a large project, and will take a lot of time and effort.

CSS Text

  - RESOLVED: Update spec to alias at compute time (Issue #6156: Same
              behavior or alias for text-justify: inter-character and
              text-justify: distribute)

Fill and Stroke

  - RESOLVED: CSS stroke-width on text will resolve percentages
              against 'computed font-size' size (Issue #6116: Should %
              stroke widths be relative to the viewport for CSS?)


  - RESOLVED: This feature should be solved with an attribute rather
              than a CSS value (Issue #5998: appearance: base to
              enable interoperable styling of controls/components)
      - gregwhitworth will create an issue about adding a mechanism in
          CSS to determine if this feature is enabled


  - RESOLVED: We propagate scrollbar-gutter from the root to the
              viewport (Issue #6079: viewport propagation of
  - RESOLVED: Scrollbar-gutter does not propagate from <body> (Issue
  - RESOLVED: No future properties should propagate from <body> to the
              ICB or viewport (Issue #6079)
  - RESOLVED: Deprecate any existing use of body propagation (Issue

CSS Fonts

  - RESOLVED: font-optical-sizing: auto references the used font-size,
              accounting for 'size-adjust' and 'font-size-adjust'
              (Issue #6190: Clarify font-optical-sizing behaviour
              under size-adjust)


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

Scribe: dlibby

CSS Values

inherit() function: like var() for parent value, for any property
  github: https://github.com/w3c/csswg-drafts/issues/2864

  leaverou: Numerous request to extend var() to arbitrary properties,
            can't do this generally due to cycles. Seems to be a less
            powerful pattern that may be possible
  leaverou: We can use it to get the value from the parent
  leaverou: Should we do work to pursue this? I volunteer if consensus
            that it is a good idea
  leaverou: I can point to many use cases, in case they are not

  emilio: Seems implementable, but we want it to work like var() at
          the token level
  emilio: You need to define for each property how it serializes,
          etc.. it's a lot of work
  leaverou: Would be equivalent to the token sequence
  emilio: But what sequence? font-stretch as an example. You need to
          get interoperable serialization for all properties
  leaverou: Don't you need that anyways?
  emilio: Yes, just pointing out it is a lot of work
  Rossen: This is indicative of how long it might take to implement
  emilio: Seems fine to implement
  [What emilio is saying is that as a prerequisite to this,
   we need to get interop on serialization of all properties,
   which is something we don't have yet.
   This requires a bunch of spec work, QA work, and
   implementer follow-up to fix all the inconsistencies.
   So it is not a small task.]

  castastrophe: For container queries, computing ancestors comes down
                to a 'contract' as things are flagged as cascading
  castastrophe: Can we use a similar mechanism (!inherited) to
                indicate such a pattern
  emilio: I don't think that is necessary, as long as you inherit with
          the same property, you already need the complete ancestor
  TabAtkins: Shouldn't need that since there is no circularity

  smfr: Concerned about implementation complexity vs. usefulness. In
        the example, you could say inherit z-index to a font property
  leaverou: There are use cases that you have to use a mixture of
  emilio: This would be implemented via existing serialization rules,
          so this doesn't explode, you don't convert between
          properties, use serialization syntax, then reparse token
  leaverou: In most cases you'll probably end up with an invalid

  Rossen: Hearing consensus on what we want to achieve, but some
          warning on how long this might take
  Rossen: Any other points on the topic?
  leaverou: proposed resolution - add an inherit function to values-4
            to get the value of parent properties

  RESOLVED: Adopt an 'inherit' function to values-5

CSS Text

Same behavior or alias for text-justify: inter-character | distribute
  github: https://github.com/w3c/csswg-drafts/issues/6156

  florian: In CSS text, we say that text-justify: inter-character has
           an old name of distribute and has same behavior. Should
           these be aliases? Conceptually this makes sense and is what
           implementations do.
  florian: Firefox implements as an alias where distribute serializes
           to inter-character
  fantasai: Distribute was implemented in IE5.5 or so. Computing in
            Firefox demonstrates web compatibility, maybe we should
            go with that behavior
  florian: Not 100% clear if aliased at parse time or computed value
           time, but it's being converted

  emilio: We do it at computed value time, but wonder if we should do
          at parse time
  florian: Compute time is easier to spec, parse time can work also.
  emilio: We alias a lot of properties at parse time
  florian: For values, I'm not sure if it is well specified what it
           means for a parse-time aliasing
  emilio: The only difference is when querying specified style.
  florian: We can spec Firefox behavior, or we can change to spec to
           desired behavior.
  emilio: Given that we have a lot of parse-time aliasing, maybe
          better to go in that direction.
  fantasai: Parse-time aliasing is not actually spec'd so we should
            figure out where that would go.
  emilio: [provides example of linear-gradient and
  Rossen: This is a good precedent to clean up and specify
  fantasai: Suggest that since existing implementation computes, we
            should update spec to match implementation. Separately we
            should define how aliasing works.
  fantasai: At that point, if Gecko wants to change text-justify to
            use the aliasing mechanism, we can do that in a separate
  emilio: Sounds good to me
  florian: We should not leave the spec as-is, either spec what is
           happening today or what we want in the future
  florian: proposed resolution - update spec to match Gecko

  RESOLVED: Update spec to alias at compute time

Fill and Stroke

Should % stroke widths be relative to the viewport for CSS?
  github: https://github.com/w3c/csswg-drafts/issues/6116

  smfr: Noticed that % stroke-width are relative to viewport, this
        seems unexpected that it would change when resize window
  smfr: I would expect it to map to line-height or something more local
  Rossen: Didn't we have something in the SVG spec that was
          disambiguating properties that derive from SVG viewport,
          what happens in CSS
  smfr: I don't recall
  heycam: transform-box has all the keywords and how they map in
          non-SVG contexts. We can probably use the same mapping
  Rossen: In most cases resolving to containing box
  heycam: That's right
  Rossen: May or may not be expected here
  <fantasai> heycam, https://www.w3.org/TR/css-box-3/#keywords ?
  <heycam> fantasai: that's it
  <heycam> so 'border-box' according to that definition

  smfr: Context: filed this when noticing some odd webkit code, not
        high priority
  Rossen: I'd like to align behaviors that is coming from SVG, and how
          to map the concepts when they come to CSS
  Rossen: Continue to use the escape hatch for weirdness in the future
  miriam: Consistent translation from SVG makes sense. I associated
          with text-decoration-thickness which resolves against em

  fantasai: There's not a good reason for text stroke width to
            reference containing box, but resolving against font
            metrics makes sense, and we should do what is useful if
            there are no webcompat concerns
  fantasai: re: diverging from SVG behavior, would be beneficial for
            conceptual clarity rather than trying to stay consistent
            in an unclear manner
  fantasai: Not sure if percentages on stroke-width on text in SVG is
            common, maybe we can switch SVG as well?
  fantasai: More compat concerns but can't imagine that authors were
            intentionally using it as it is currently spec'd
  Rossen: Worth getting data
  fantasai: Agreed for SVG, we should probably just do it for CSS

  heycam: You can use stroke-width on non-text
  heycam: Hopefully we can do it across SVG
  fantasai: Might be more risk, not sure we can change all the behavior
  fantasai: We should have percentages resolve against 'font-size',
            and inherit as a percentage, as it does for text decoration

  Rossen: proposed resolution - for CSS stroke-width on text will
          resolve percentages against 'computed font-size' size

  RESOLVED: CSS stroke-width on text will resolve percentages against
            computed font-size


  scribe: Myles

appearance: base to enable interoperable styling of controls/components
  github: https://github.com/w3c/csswg-drafts/issues/5998

  gregwhitworth: The context is that we're trying to start down the
                 path of standardizing form controls and components.
                 We'll need an agreed-upon DOM and styles.
  gregwhitworth: Last time I presented on this, I presented about the
                 base appearance keyword and the pseudo element for
                 checkbox. I want to de-tangle them. I've had requests
                 for input type=range
  gregwhitworth: I want to move forward with the base keyword.
  gregwhitworth: For more context, the base keyword would be a toggle
                 that informs the browser that you want to have a
                 standardized dom and styles for a given element. That
                 would allow you to style interoperably.
  gregwhitworth: UAs want to provide their own defaults. Authors need
                 to opt-in.
  gregwhitworth: I'm looking for feedback: questions, thoughts.

  emilio: If we want this to change the shadow dom that UAs create,
          this is better as an attribute, despite that option sucking.
  emilio: For gecko, it's kind of okay to create a lot of dom during
          layout. It's not amazing. I'd like to get rid of that
          mechanism. Blink generates the shadow dom at the DOM level,
          not depending on layout.
  emilio: Making CSS changes affect DOM for them, I suspect it would
          be more of an issue.
  emilio: Conceptually, it feels wrong
  gregwhitworth: Sure. I'm primarily .... not that that's bikeshedding
                 .... I want to get at the more meta-issue. If
                 implementors say they prefer the attribute, I can
                 bring this to WHATWG. I'm asking if this group
                 accepts standardized styles and standardized DOM
  emilio: I'm definitely okay in getting more interop in form controls.
  emilio: This detail probably matters.
  emilio: Can chrishtr weigh in?
  emilio: Is CSS the right place for this toggle?
  <tantek> +1 emilio

  hober: My understanding is that we're also pretty reluctant to add
         more mechanisms in CSS that cause DOM to get created.
  hober: So, I think, this does seem like a problem we should be
         trying to solve. An attribute would be less weird.
  hober: ... on the implementation side of things.

  florian: In addition to the implementation complexity, I have 2
           other reasons for why attributes are probably better.
  florian: 1. If we got with a CSS property with a single base
           keyword, we need to introduce it simultaneously on all the
           elements that accept it, or have a bunch of values so
           people can detect their way into doing the right thing.
           That problem isn't true if we do it as an attribute.
  florian: 2. Depending on whether an element is base or not base, you
           want to style it differently. If you cause it to be base or
           not base through CSS, then you can't select on it.
  <tantek> +1 florian about what you want to style differently
  florian: The UA stylesheet needs to be different for a regular
           checkbox vs a base checkbox, if the switch is in CSS, all
           that solves itself if the switch is done via an attribute.
  florian: We have multiple things pointing in this direction. All of
           these work better if we got with an attribute vs a CSS
  fantasai: Just to throw a wrench into that, florian, you want to
            style them differently based on the attribute, but also on
            whether or not the browser supports that attribute
  florian: We should have an attribute an attribute AND a pseudo-class.
  fantasai: We can also add an @supports query.
  fantasai: We need a way to answer the question "is this implemented"
  florian: The base pseudo-class would mean "is it present AND
  florian: pseudo-classes are simpler
  <fremy> +1 to the pseudo-class suggested by florian
  <tantek> +1 to considering pseudo-class

  fantasai: For style vs content vs behavior, this belongs more in CSS
            than HTML. But emilio and florian gave good arguments for
            why it might have to end up in HTML regardless.
  fantasai: If we add appearance: value, I would go for appearance:
  <tantek> in general I'm opposed to any extension to the 'appearance'
           property, but that's a lower level concern
  <heycam> `input[type=checkbox]:custom`

  Rossen: Most of the conversation leans toward attribute.
          gregwhitworth, does that work?
  gregwhitworth: I want a resolution, as ammunition for going to WHATWG
  gregwhitworth: Also for adding styles to checkbox. I'm looking for a
  florian: 2 resolutions: 1. to use an attribute, and 2. to add a
  fantasai: proposed resolution: This functionality be pursued as an
            attribute, and CSS adds a mechanism to detect an element
            in this mode in a browser that has support for it
  gregwhitworth: I'm fine working on that BTW
  <fantasai> "CSS Working Group recommends that"

  bkardell: Wouldn't existing "define" work?
  bkardell: The "define" pseudo-class
  bkardell: should work
  bkardell: I guess not, because it's already defined. Never mind
  emilio: It almost works, because you can't extend form controls. But
          maybe you can. If you can, then it doesn't work
  gregwhitworth: I don't want to go down that rabbit hole
  emilio: It seems cleaner to use a different thing

  Proposed resolution: This functionality be pursued as an attribute
      instead of a CSS property, and CSS adds a mechanism to detect an
      element in this mode in a browser that has support for it
  <bkardell> it would already be true, is the real problem I think
  florian: I support the resolution as it stands. But I would also
           support a more specific resolution: the mechanism is a
           pseudo-class. @supports would be awkward. Pseudo-class
           would make it easy. If we do a pseudo-class, we have to
           figure out which element you're testing against. Would look
           like a selector
  fantasai: Yeah, this is element-by-element
  florian: It's also applied element-by-element
  fantasai: yeah.
  fantasai: I guess that what it's going to have to be. I can't think
            of a name that makes sense
  florian: We should match the name that HTML sues
  bkardell: Can it be 0 specificity?
  gregwhitworth: Can we figure this out after I open the issue?
  bkardell: Yes.
  fantasai: I support gregwhitworth investigating whether or not it
            should be 0 specificity
  Rossen: We were leaning toward using an attribute. Second
          resolution: Adding a mechanism to detect the state of the
          feature. Is this right?

  RESOLVED: This feature should be solved with an attribute rather
            than a CSS value

  <fantasai> [I would like to note that it's not great that, in order
      to change the styling of the form element, it's necessary to
      change the markup. But it seems we're constrained by practical

  ACTION gregwhitworth: Create an issue about adding a mechanism in
      CSS to determine if this feature is enabled


viewport propagation of scrollbar-gutter
  github: https://github.com/w3c/csswg-drafts/issues/6079

  chrishtr: When you apply properties on the HTML or body elements,
            under certain conditions, it gets propagated to the root
            element's scroller. Does this apply to scrollbar gutter
            properties? Proposed: yes.
  Rossen: This is reverse propagation thing for overflow and direction
  fantasai: Overflow doesn't inherit so it's less bad
  fantasai: I absolutely hate body propagation rules in CSS. They
            should die. But the web depends on them. I don't want it
            to propagated from the body to the viewport.
  fantasai: But we do need to specify that it propagates from the root
            to viewport.
  <tantek> +1 fantasai
  emilio: Right. The scroll-snap stuff, and the thing that allows you
          to do smooth scrolling, those don't propagate.
  chrishtr: If the user puts overflow on the body, and <missed> then
            they're just out of luck?
  florian: They should put it on the root instead.
  florian: Putting things on HTML instead of body causes no problem.
           It's confusing if you've put it on body and it works, but
           you want to put other stuff on body but it doesn't work
  <tantek> +1 florian, can we deprecate putting it on body so it's
           still "supported" but warned in CSS validators?

  Rossen: Let's go back to the actual issue here
  Rossen: There's a proposal here about scrollbar-gutter.
  Rossen: For better or worse, we have behavior today that does the
  Rossen: Can we make that work for scrollbar-gutter as well
  florian: There are 2 potential resolutions. The first is required.
           Propagate from the root to the viewport is required.
           Whether or not we ALSO propagate from the body is
  <tantek> +1
  fantasai: Let's resolve that we propagate from root to viewport
  Rossen: Any objections?

  RESOLVED: We propagate scrollbar-gutter from the root to the viewport

  Rossen: Now what about body?
  Rossen: It still works everywhere. I think our mutual feelings are
          the same.
  fantasai: We're not saying that it should stop working on overflow.
            We're saying we shouldn't add more properties to that list
  emilio: There was a huge discussion years ago in gecko and other
          browsers. Gecko only propagates overflow and .....
  florian: Overflow, background, and principal writing mode (i.e.
           writing-mode and direction) writing mode
  emilio: Browsers do different things. Fancy new properties don't
          propagate. Let's leave it as it is. Not propagate from body
          to root.
  <tantek> +1 emilio
  emilio: A lot of other properties don't either
  iank_: Overscroll behavior does.
  emilio: Scroll snap does
  emilio: Those only work on the root

  <tantek> can we instead introduce an informative WARNING about
           depending on <body> propagation? (i.e. that devtools could
           flag for example)
  <fantasai> tantek, I'm happy to warn about it for the properties
             which currently do propagate (overflow/background/
             direction/writing-mode). But I *do not* want to add more
             properties to that list.
  <tantek> fantasai, 100%

  emilio: If UAs want to add a warning, if you detect you have a body
          that's not scrollable and it has scroll properties, they can
          log them to the console, that would be helpful, but let's
          not add more propagation
  Rossen: It's less worse to put your custom scroll bar ... is to not
          have the appropriate space for it, so you're risking to have
          some broken UI experience in this case
  florian: If you apply a property and it doesn't do what you want
           then you fix your code

  heycam: I was going to ask what the specific list of scrollbar
          related properties is that currently propagates from body to
          the viewport. I don't want to end up in a situation where
          some scrollbar related things propagate but others don't. If
          scroll snapping and scrollbar color and scrollbar width
          don't propagate, then that's good
  chrishtr: I'm okay with the not body thing.
  chrishtr: That shortens the conversation
  Rossen: I'm okay with this.
  Rossen: Anyone else want to keep it?
  Rossen: Objections?

  RESOLVED: Scrollbar-gutter does not propagate from <body>

  <tantek> can we generalize that to any future scroll-*?
  fantasai: Tantek is asking "can we generalize ..."
  <tantek> yes please fantasai
  fantasai: The proposed resolution is "don't propagate anything else
            ever from BODY to viewport"
  chrishtr: Do we need a resolution for scrollbar-width and one other?
  emilio: Those already don't propagate
  Rossen: I think that was the generalized proposed resolution that
          fantasai said
  Rossen: "Anything outside of overflow, direction, and background
          should not propagate from body"
  florian: In addition, we need to propagate some things from HTML to
           the viewport
  florian: Otherwise you can't change the scrollbar width
  Rossen: I'm talking about <body>
  florian: We should open a new issue about which things need to be
           propagated from :root and are missing

  fantasai: Proposed resolution: no future properties will propagate
            from <body> to the ICB
  <tantek> +1
  chrishtr: I'll open a new issue about scrollbar-width on the HTML
  Rossen: No new objections
  <fantasai> chrishtr, the spec already defines this
  <fantasai> chrishtr, see
  <fantasai> chrishtr, no need to open an issue...
  <chrishtr> fantasai, great!

  RESOLVED: No future properties should propagate from <body> to the
            ICB or viewport

  <tantek> even current properties that don't say they propagate too
  fantasai: Tantek said something in IRC
  tantek: proposal: deprecate, or add a warning, to any existing use
          of body propagation. This would enable CSS validators and
          dev tools to warn and flag when they depend on that behavior
  emilio: I don't feel strongly. but sure.
  emilio: Dev tools can warn for whatever without anything in the spec
  emilio: We warn for stuff that doesn't apply. Saying "this is bad
          and you should feel bad" is not good
  fantasai: I'm fine with deprecating and making that a statement so
            it can make its way to author-facing materials
  fantasai: Deprecating settings values on <body> with the expectation
            it propagates up to root
  florian: Making it officially bad. "please don't do this"

  RESOLVED: Deprecate any existing use of body propagation

CSS Fonts
  scribe: fantasai

Clarify font-optical-sizing behaviour under size-adjust
  github: https://github.com/w3c/csswg-drafts/issues/6190

  chrishtr: Question of size-adjust interaction with
  chrishtr: The proposed resolution is to use font-optical-sizing of
            the used font size
  myles: Of course

  RESOLVED: font-optical-sizing: auto references the used font-size,
            accounting for 'size-adjust' and 'font-size-adjust'

CSS Display

Should <display-legacy> values be aliased at parse time?
  github: https://github.com/w3c/csswg-drafts/issues/5575

  [There isn't time left on the call to discuss]

  <astearns> fantasai: add a comment with your proposed resolution
  <fantasai> proposed resolution: resolve at computed value time, not
             at parse time, so that specified value is how you
             specified it

Received on Monday, 24 May 2021 22:58:22 UTC