[CSSWG] Minutes New York F2F 2022-08-01 Part IV: Allow <textarea> to be sized by contents; Media Queries [css-ui] [mediaqueries]

  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.

Allow <textarea> to be sized by contents

  - iank summarized his proposal to add a new property (textarea-rows:
      auto | <number>) for issue #7542 (Allow <textarea> to be sized by
      contents) as well as explaining the previous proposal and its
    - There was general consensus that the previous proposal was
        problematic, but several questions about the new proposal.
        - The new proposal is specific to a single element and that
            felt overly limiting.
        - There needs to be discussion around handling of different
            fonts and changing line heights.
        - Scrollbars would also add complexity and more discussion is
            needed on handling.
    - Discussion will continue on GitHub on how to handle the issues

Media Queries

  - RESOLVED: For the purposes of propagating prefers-color-scheme to
              the embedded page, if `color-scheme` is `normal` and
              there's no `color-scheme` meta tag, the propagated scheme
              is the preferred color-scheme of the embedder document
              (Issue #7526: Clarify propagated preferred color-scheme
              on SVG images with color-scheme: normal and no
              color-scheme meta tag)
  - RESOLVED: Context-dependent color scheme propagation works for
              iframes (including cross-origin) unless specifically
              restricted (Issue #7493: Should prefers-color-scheme in
              iframes be context-dependent?)


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

Scribe: fantasai

Allow <textarea> to be sized by contents
  github: https://github.com/w3c/csswg-drafts/issues/7542

  iank: Form control elements all have some default intrinsic size,
        inline axis and block axis
  iank: The way they calculate this is sometimes extra fun
  iank: sometimes just a static number, e.g. radio/checkboxes
  iank: The way that textarea works, it will more or less read the rows
        attribute and multiply that by the lh unit (effectively)
  iank: this is not fallback or anything like that
  iank: Since the dawn of time, people have wanted textareas to
  iank: a lot of libraries that do this
  iank: most people want to show some minimum amount of rows
  iank: and then let it grow
  iank: I filed this issue, what's the best way forward with this
  iank: I wasn't previously aware we discussed this 4-5 years ago
  iank: I don't think proposed solution is the best, but can go from
  iank: Was that enough background?
  * fantasai thinks it was great
  iank: I can sort of go through the previous proposal, and concerns
        with it
  iank: I've also got an alternate proposal

  iank: Previous proposal was to use the min-content/max-content and
        presumably fit-content keywords on the height
  iank: when you specify this, you would flip the intrinsic size to
        calculate based on the rows
  iank: to being based on content instead
  iank: I have a few issues with this
  iank: It creates a slightly weird inconsistency, currently on form
        controls there is an algorithm for calculating intrinsic size
        of form controls
  iank: if you say height: auto; height: min-content; or height:
        fit-content, should behave same
  iank: Other issue is it's difficult to feature-detect
  iank: it also makes it difficult for layout algorithms, when flexbox
        or grid ask for min-content size of something, do we take into
  iank: very subtle

  iank: The final thing is that, and we can debate this, there's a
        valid path forward
  iank: a lot of the time you don't actually want it to be the exact
        height of the content
  iank: 2 reasons
  iank: 1, you want space for placeholder
  iank: 2, you kindof want it to work the same as the lh unit
  iank: If you set min-height: 2lh
  iank: max-height: 4lh
  iank: you want the content, the intrinsic size, to be based on the
        number of lines times the lh unit
  iank: When you're typing and you fall back to a different font, can
        create a visual glitch
  iank: I'll pause there ...

  iank: My proposal is to add a new property, e.g. textarea-rows: auto
        | <number>
  iank: You typically don't want to reserve space for the placeholder
  florian: I'm confused about the proposal. I presume auto is the
  TabAtkins: no?
  TabAtkins: Then what's the default?
  iank: On the textarea, you have textarea-rows: 2
  iank: and then preshint mapping that maps rows attribute to this
  florian: Thanks, that helps
  iank: Today we have textarea-rows: <number> only
  iank: and rows attribute would get mapped to this property
  florian: That makes more sense, thanks

  TabAtkins: I agree with your reasoning against the older proposal to
             use max-content
  TabAtkins: max-content messes with our existing algorithms, and the
             fact that you do want this to be a multiple of lh
  TabAtkins: I was convinced by your arguments, so I support adding
             this property with the auto value
  iank: I should also say that we can bikeshed the name, this is a very
        basic name
  florian: This new property is alternative to using height with
           fit-content, but you'd use it in combination with min-height
           / max-height with lh?
  TabAtkins: If that's what you want to impose, yes
  iank: It's useful even if you don't support lh unit
  iank: Currently looking at doing both atm

  scribe: TabAtkins

  fantasai: I don't really like a new specialized property to a single
            element, when we could get the same effect with a generic
  fantasai: I think the feature detection problem is one we have for a
            lot of things
  fantasai: That's not a reason to invent a new property every time
  fantasai: In terms of other things being multiples of lh vs actual
            height, I think that's interesting
  fantasai: Do we actually want that multiple-lh size? or fit X lines?
  fantasai: If we want strict line-to-line heights, can we figure out
            how to do that with the css-inline or step-sizing
  fantasai: If so we can apply it to other elements besides text area

  fantasai: Other point wrt min/max content sizing
  iank: Discontinuity that height:auto and height:fit-content won't
  fantasai: I don't think that's a discontinuity - *usually* auto maps
            to a content keyword
  fantasai: but on some elements it maps to a fixed number
  fantasai: that's fine, auto can map to anything
  iank: Today auto doesn't map to a fixed number
  iank: because the way most form elements work is that min/max-content
        returns a number, and auto maps to one of those
  fantasai: Yeah but for some elements auto maps to stretch
  iank: Yeah that's fine
  iank: so like what happens when you do min-height:min-content;
        height:auto; on the textarea?
  fantasai: min-height would look at the number of lines in the box and
            come up with a height
  fantasai: and then auto would represent what it currently does
  iank: Which is fit-content
  fantasai: Is it? isn't it a fixed number of lines?
  iank: For us and other engines, that's what fit-content means, yes
  iank: if you say height:min-content today on a form control, it'll
        return a form control algo
  fantasai: So your concern is the backwards incompatibility of
            specifying a content keyword to have this behavior, rather
            than today's behavior
  iank: I was considering if it was a compat problem, it's probably
        not. It's more how the engines work is that auto maps onto two
        things - stretch or fit-content
  iank: and all the form elements behave similarly
  iank: min/max-content is defined by some internal algo; for textarea
        it's rows*lh, basically
  iank: and if you have height:min-content we swap the internal
        algorithm for that

  fremy: A point that convinced me is you don't want to snap to any
         random pixel value, but a proper number of lines. Can't rely
         on that with fit-content
  fantasai: textarea is quite limited; you can't format it, so shouldn't
            have that problem
  TabAtkins: but you can have fallback fonts
  fantasai: Yeah, but we already have problems with line heights varying
            due to that in general
  fantasai: Unsure if that's the reason we should add a specialized new
            property that only works for text areas
  fantasai: We should decide if we want the content to accommodate font
            changes and if we want a consistent line height we should
            be able to say that with text properties
  iank: It's not affecting those line height, it's affecting the
        intrinsic size

  fantasai: If height:auto effectively computed to 40px on a textarea,
            how would that be different from the current situation
            we're in today? Isn't that what's being proposed?
  iank: It's not, auto only maps to stretch or fit-content
  fantasai: That's not true
  iank: Where?
  fantasai: It's whatever we define it to be.
  iank: Right but we don't do anything else today. Today it's just the
  fantasai: I'd prefer to add a new concept to the engines than to
            author-exposed stuff
  fantasai: I'd prefer not having authors have to learn a new concept
            if they don't need to

  iank: What happens for things asking for min-content sizes?
  fantasai: Typically asking for min-content contribution, not size
  fantasai: If auto resolves to an (effectively) fixed value, your
            contribution will be that size

  TabAtkins: It seems 1 point of your objection is about having us this
             be a special-purpose property
  TabAtkins: For sufficiently magic elements, I think it's fine
  TabAtkins: we already have a large number of singe-purpose properties
             from SVG
  TabAtkins: I don't think it's a problem to add them to HTML also

  emilio: One issue when considering whether to change height is that
          the default for textarea is border-box
  emilio: so it may not be right to match content there
  fantasai: We don't have to change that - when you say
            height:max-content, you don't take the size of the content
            and make the border-box that height.
  emilio: I think for most purposes, block-size max-content is auto
  fantasai: auto is treated as intrinsic, rather
  fantasai: like in grid, it's stretch not auto
  emilio: I'm pretty sure we've discussed how intrinsic block sizes
          should behave and I'm 90% sure that our behavior maps
          intrinsic block sizes to auto except in special cases
  fantasai: You're saying they're treated the same way, and you had
            "auto" first so you call it that in the codebase, but
            fundamentally it's the max-content size and "auto" maps to
  emilio: Not convinced. If you do width:min-content and have
          box-sizing:border-box and have padding, do we add padding to
          that width?
  fantasai: Yes, or else it would be broken
  dbaron: I think what's supposed to happen is if you're using width/
          height:intrinsic-stuff, box-sizing doesn't change the size of
          the box

  florian: One thing fantasai was concerned about is that this is a
           textarea-only property
  florian: But theoretically this could apply to any block container
  florian: So if you leave logical properties aside, couldn't this be a
           new set of properties that fit into the sizing property?
  TabAtkins: That's step-sizing

  fremy: Great segue
  fremy: I'm wondering about the issue of scrollbars
  fremy: textarea do overflow, and they get scrollbars which can change
         the lines on the screen
  iank: We don't have have interop
  iank: I think most engines do... something complicated
  iank: Effectively, if you have overflow:scroll, we'll reserve space
  iank: If it's overflow:auto we won't reserve space
  iank: it's like the text area has word-space:break-all on it
  iank: very hard to trigger inline overflow
  iank: If you do manage to trigger it it'll still be like two rows of
  fremy: How do you know in advance what you'll need?
  fremy: Will you get in a situation where if you don't have reserve
         the space it doesn't need a scrollbar?
  iank: This varies engine by engine, but Chrome's behavior we won't...
  iank: [compiles chrome in his head]
  iank: It's complicated
  iank: We'll only ever add scrollbars. That'll typically result in an
        extra row
  iank: but we'll never remove them after that point
  fremy: Makes sense

  dholbert: Going back to needing a special property
  dholbert: One thing not clear to me is why we are reaching for a css
            property rather than an html attribute
  TabAtkins: Whether your item is content-sizable, might depend on the
             layout of the page
  TabAtkins: in some cases, might have the space, but might change
             based on MQ
  TabAtkins: so needs to be in CSS so you can change as needed
  TabAtkins: based on MQ and CQ

  florian: Might have missed part of the discussion but didn't see the
  florian: Can we do this with step-sizing?
  florian: How do we solve this with step-sizing? what's missing?
  iank: Where is step-sizing proposal
  <fantasai> https://www.w3.org/TR/css-rhythm-1/#block-step-size
  <fantasai> https://www.w3.org/TR/css-rhythm-1/#block-height
  iank: Where is this actually counting the number of lines?
  fantasai: You write 'block-step-size: 1lh' and it'll round your block
            to a multiple of 1lh
  TabAtkins: This doesn't address making textarea content-sizable in
             the first place
  iank: There's nothing here that changes the way that the textarea
        calculates its size otherwise
  <fantasai> probably the spec should clarify that the intrinsic sizes
             are also stepped

  oriol: Instead of step-sizing, I also remember in overflow there was
         a max-lines property
  oriol: [missed]
  oriol: What if we had as a pres hint converting the rows attribute
         into a max-lines, and if you want to size the textarea
         according to content, you set max-lines:none
  florian: Haven't totally followed logic, but max-lines in overflow is
           a very different beast
  florian: it's fragmentation, not sizing
  florian: What it does with the number of lines is very different and
           doesn't work here
  florian: as a reminder, max-lines triggers a forced break after the
           number of lines if your container is a fragmentainer
  florian: I don't think we want forced breaks, we want to size things
  fantasai: Also max-lines actually uses the line size, if one line is
            taller it breaks after a whole number of lines
  fantasai: Also it's max-lines, if your block is max-lines:5 but has
            three lines in it, it'll still be 3 lines tall
  [Note: The max-lines property sizes the box to the fragmentation
         point, based on fitting that number of line boxes. The
         continue property is what indicates fragmentation instead of
         overflow. The line-clamp property combines both as a

  <br dur=15min>

Media Queries
  scribe: fantasai

preferred color-scheme on SVG images with color-scheme: normal
  github: https://github.com/w3c/csswg-drafts/issues/7526

  emilio: Previous issue, we resolved that preferred-color-scheme on
          SVG images was going to depend of the color scheme of the
          embedder element
  emilio: What we didn't define is what happened when color-scheme:
          normal and color scheme is unannotated
  emilio: This changes behavior, because used color scheme defaults to
  emilio: No color scheme meta, and color-scheme: normal, used color
          scheme is light
  emilio: so pages that don't annotate it, get light instead of dark
  emilio: I think we need another concept that preserves the preferred
          color scheme of the embedding document
  emilio: I think it's a relatively straightforward fix
  emilio: Philip prefers not to change the behavior
  emilio: I think it's nice that the color scheme would depend on ?
  emilio: same for iframes
  emilio: I agree that having special cases for SVG, I think we should
          behave the same way for iframes
  TabAtkins: Assuming not security blocked, yes
  emilio: So my proposal is splitting used color scheme from preferred
          color scheme
  emilio: propagated preferred color scheme or something
  emilio: so the default when unannotated isn't light, it's the
          embedder's color scheme

  pdr: I think it would be useful to step back and consider
       color-scheme and prefers-color-scheme as two different things
  pdr: color-scheme tells the browser how the author wants, and
       prefers-color-scheme tells us what the OS wants
  pdr: The behavior here is clear, the embedder is asking for color
  pdr: combine them, gets complicated
  pdr: Reason is, you can't make color-scheme follow
       prefers-color-scheme by default
  pdr: some websites are designed to have light scrollbars, flip it to
       dark, it's ugly
  pdr: we can't really ignore concepts are tightly intertwined
  pdr: Given all the issues with SVG and iframe, adds complexity that's
       not necessary
  pdr: just have color-scheme be the browser's color scheme and
       prefers-color-scheme be the OS

  emilio: The reason why I think prefers-color-scheme follow the
          embedder, otherwise it's useless in embedder and in iframe
  emilio: it's not useful to know that OS prefers dark, because you
          don't care about OS being dark, you care about your context
          being dark
  TabAtkins: yes
  TabAtkins: if page said 'color-scheme: dark', SVG should be dark by
  TabAtkins: if they're light, this is a problem
  TabAtkins: We want to fix this breaking case

  emilio: Regarding the point of complexity,
  emilio: in Gecko you already need to have prefers-color-scheme as a
          key in the image tag
  emilio: I think Blink has similar mechanism
  emilio: in terms of complexity, in Gecko it's mostly a one-liner
  emilio: I agree it can be difficult to wrap your head around it in
          the first place, but in terms of implementation complexity
  emilio: it's simple to default to document rather than OS color scheme

  pdr: If you have SVG content, and embedded, it looks different
  TabAtkins: Assuming not cross-origin iframe or other
             security-conscious spot
  TabAtkins: iframe should behave same as image
  TabAtkins: should get color scheme passed through
  TabAtkins: It's only in cases where we want to restrict cross-origin
             communication that we cut it off
  TabAtkins: ....
  TabAtkins: In other cases can exfiltrate, and could do something
  TabAtkins: but in all other cases, want to keep consistency between
             iframe and other ways of embedding SVGs

  pdr: Is there precedent for developers dealing with situations where
       APIs work so differently in cross-origin iframes
  TabAtkins: cross-origin iframes restrict in a number of ways
  TabAtkins: and CSS doesn't pass much info, mainly width/height
  TabAtkins: and we would like to minimize cross-origin info propagation
  TabAtkins: In fact we're doing more cross-origin restrictions with
             (new feature)
  TabAtkins: because so restricted, I doubt very surprising for authors
  pdr: There's SVGs in ads, and they're frequently mixed in
       cross-origin contexts
  pdr: from user's perspective, will be difficult to tell
  pdr: why not specify fully the iframe?
  emilio: There's another issue on that

  emilio: I talked to security folks about this, and the tldr is they
          didn't find anything particularly concerning to make it
          behave the same as SVG
  emilio: It's basically depending on Chrome's security folks to take a
          look to make it behave consistently everywhere
  emilio: use cases where exfiltration is a problem, ...
  emilio: You can't tell if color-scheme is coming from OS or from page
  emilio: if you're loaded in both cross-origin and original context...
  emilio: doesn't seem that problematic
  emilio: It's one bit that we stop passing from OS and start passing
          from the page
  emilio: later in agenda
  emilio: I'm for making all embedding contexts behave consistently in
          this regard

  TabAtkins: I'm operating from idea that we want to lock down
             crossorigin communication
  TabAtkins: but if one more bit is not considered a problem then ok
  emilio: My point is that, we stop exposing one bit from OS and start
          exposing from one page...
  emilio: the only way for embedded page to differentiate is if it's
          also loaded in a different context (top-level or other)
  TabAtkins: As long as we're locking down cases liked fencedframe
  TabAtkins: so long as there is zero ability to coordinate between
  TabAtkins: then I don't care

  astearns: Philip, have your concerns been addressed?
  pdr: Would be happier if not a special case
  pdr: Emilio's proposal is not overall bad

  TabAtkins: Proposal is we propagate used color scheme to all embedded
             contexts regardless?
  emilio: This is about page with color-scheme: normal, no color scheme
  emilio: Instead of propagating used color scheme, we propagate
          preferred color scheme of the document
  emilio: recursively
  TabAtkins: That sounds good
  dbaron: please summarize into IRC!
  <TabAtkins> proposed resolution: when the embedding page doesn't set
              color-scheme (or sets it to 'normal'), we don't propagate
              used color-scheme to embedded pages (they continue to get
              the OS-derived preferences)

  fremy: So idea is on the viewport, if you didn't specify
         color-scheme, you get the value that you get from the meta tag?
  fremy: if you have a web page that does not specify any color scheme
         property, just using default, it will propagate to iframes the
         value that is used in the meta tag
  emilio: Yes, that's how used color scheme already work
  emilio: This case, if on top of that there's no meta, instead of
          propagating 'light', which is the default used color scheme,
          you propagate the preferred color scheme of the parent
  emilio: My thought is that instead of using OS preference, we use
          preference of embedding page
  emilio: it's usually OS color scheme, except when you have nested
  TabAtkins: Ah, so if top level sets color scheme, second level
             doesn't, third level gets the top-level scheme
  emilio: Exactly
  <TabAtkins> proposal: if the embedding page doesn't set a
              color-scheme, it propagates the default color scheme to
              embedded pages (rather than passing its used color scheme)
  <TabAtkins> (this matters for A->B->C, where A sets 'color-scheme'
              but B doesn't. In this case, C will get A's used scheme,
              without B's lack of care (which'll resolve to 'light')
              affecting it)
  <dholbert> TabAtkins: ("default"/"used" might be confusing/ambiguous
             in your wording)
  <emilio> Proposed resolution: for the purposes of propagating
           prefers-color-scheme to the embedded page, if `color-scheme`
           is `normal` and there's no `color-scheme` meta tag, the
           propagated scheme is the preferred color-scheme of the
           embedder document
  <fremy> lgtm
  fantasai: Sounds good to me, let's resolve
  astearns: objections?

  RESOLVED: For the purposes of propagating prefers-color-scheme to the
            embedded page, if `color-scheme` is `normal` and there's no
            `color-scheme` meta tag, the propagated scheme is the
            preferred color-scheme of the embedder document

Should prefers-color-scheme in iframes be context-dependent?
  github: https://github.com/w3c/csswg-drafts/issues/7493

  astearns: Should prefers-color-scheme in iframes be context-dependent?
  TabAtkins: yes
  TabAtkins: Proposed resolution is that we propagate used color scheme
             to embedded documents, regardless of cross-origin status,
             by default
  emilio: Not used color scheme exactly, like before
  TabAtkins: However we define propagation, we do the same for iframes
  dholbert: Is there a term for the actually used color scheme?
  TabAtkins: The actually rendered one is the "used color scheme"
  TabAtkins: Not quite in all cases - see previous issue
  emilio: But that's not what we want to propagate
  emilio: In the case of a page that doesn't specify a color scheme, we
          *use* light, but the preference is context-dependent and
          could be dark
  astearns: So the thing we resolved on in the last issue, happens in
            all embedding contexts
  TabAtkins: Unless otherwise specified
  TabAtkins: There are some embedding context we will restrict this
  astearns: Objections?

  RESOLVED: Context-dependent color scheme propagation works for
            iframes (including cross-origin) unless specifically

  astearns: Thanks everyone for patience with breaks etc.
  astearns: Tomorrow afternoon will be color and stuff
  astearns: We're done for today

Received on Tuesday, 30 August 2022 00:00:56 UTC