[CSSWG] Virtual F2F 2021-04-06 Part I: CSS Fonts, Flexbox, Sizing [css-fonts] [css-flexbox] [css-sizing]

  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 Fonts

  - RESOLVED: font-stretch should serialize to a number/percentage,
              not a keyword (Issue #6171: Computed value of font
  - RESOLVED: Add new metrics that can be used to harmonize the font
              size of fonts used in fallback (Issue #6160: Extent
              font-size-adjust to take a pair of values: <metric>
  - RESOLVED: Add font-face descriptor overrides for vertical writing
              modes (Issue #6152: Vertical metrics overrides)
  - RESOLVED: Clarify that font-size-adjust computations will effect
              things in such a way that the descriptor overrides have
              no effect (Issue #6128: How do font-size-adjust property
              and size-adjust descriptor work together?)

Flexbox & Sizing

  - RESOLVED: non-replaced elements with an aspect ratio honor the
              intrinsic size in flexbox for min-height:auto (Issue
              #6069: Interaction of flexbox minimum height and
              aspect-ratio minimum height)


  - Being able to address issue #1771 (Auto-resize iframes based on
      content) would require input and work from the WHATWG as well.
      The proposed solution would be a double opt in approach which
      would support security but get author expected behavior. There
      was interest in pursuing a solution, though not everyone was
      convinced it is a good idea. More use cases outside of the ad
      space may be needed.


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

  Rachel Andrew
  David Baron
  Christian Biesinger
  Mike Bremford
  Oriol Brufau
  Tantek Çelik
  Emilio Cobos Álvarez
  Elika Etemad
  Simon Fraser
  Megan Gardner
  Chris Harrelson
  Daniel Holbert
  Sanket Joshi
  Brian Kardell
  Jonathan Kew
  Ian Kilpatrick
  Peter Linss
  Rune Lillesveen
  Alison Maher
  Myles Maxfield
  François Remy
  Morgan Reschenberg
  Florian Rivoal
  Cassondra Roberts
  Jen Simmons
  Alan Stearns
  Miriam Suzanne
  Lea Verou
  Greg Whitworth

Scribe: fremy

CSS Fonts

Serialized value of font stretch
  github: https://github.com/w3c/csswg-drafts/issues/6171

  emilio: The spec has a note that says that, for compat reasons,
          computation of font-stretch should stay a keyword if it was
          one, instead of the percentage
  emilio: webkit doesn't do that
  emilio: tests either require one or the other, there is no consensus
  emilio: I would like to remove this note
  myles: There is no known issue I was working around
  dbaron: Usually, we try to stick to the most compatible
          representation, for compat
  emilio: Returning the keyword makes it difficult for authors because
          they need to reverse-compute the keywords
  emilio: Font-3 used to report the keyword all the times
  myles: At least in webkit, we implemented font-stretch at the same
         time as the numerical values
  myles: so the span of time where we didn't support numbers for it
         was short
  myles: possibly not even a release
  dbaron: Given that, I think it's fine to break the general principle
  astearns: Ok, so the proposed resolution is to not use the
            font-stretch keywords in serialization
  emilio: And return a percentage
  astearns: Ok, any objection to this?

  RESOLVED: font-stretch should serialize to a number/percentage, not
            a keyword

Extend font-size-adjust to take a pair of values: <metric> <number>
  github: https://github.com/w3c/csswg-drafts/issues/6160

  jfkthame: This was prompted by the discussion about size-adjust
  jfkthame: We want to harmonize when we have mixtures of fonts
  jfkthame: font-size-adjust allows you to use the x-height of the
            font to size things
  jfkthame: This is very latin-centric however
  jfkthame: for example you might want to harmonize the ascent/descent
            of the font instead
  jfkthame: because x-height might be meaningless to my language
  jfkthame: This sounds like a natural extension to me, but I wanted

  fantasai: This makes sense to me
  fantasai: I support the proposal
  florian: Same
  florian: I would like to note that the ascent+descent combination is
  florian: because it depends on the baseline
  florian: It's easier to stick to things that are distances from the
  florian: otherwise you need to add a feature to realign
  jfkthame: I don't propose to adjust the alignment
  jfkthame: just the font size
  fantasai: Yes, e.g. you would need to use ideographic alignment in
            some cases
  florian: Ok, that sounds convincing, you can use vertical-align to
           deal with any alignment problem

  myles: Did we consider IC-height?
  <florian> [IC = Ideographic Character]
  fantasai: We probably want to have logical variants of these as well

  myles: Philosophically this proposal makes sense
  myles: but to change the spec, I will need a list of tokens to
         consider for the first argument
  myles: I might have some opinions on the set
  myles: descent doesn't seem useful for example

  astearns: How often do people use font-size-adjust?
  fantasai: It's not cross-browser so it might be lower than we think
  jfkthame: I found a lot more uses that I expected actually
  jfkthame: but however it often has no effect since it only applies if
            font don't load
  astearns: Are we sure we don't complexify too much?
  fantasai: I think it's fair to support non-European languages better
  fantasai: Some writing systems don't even have opentype metrics yet,
            but at least this would add support for languages for which
            we have metrics
  fantasai: and it provides a design which works to add new metrics if
            they are created later
  astearns: Which browsers support this right now?
  myles: Probably just firefox?
  jfkthame: And behind a flag in chrome
  myles: And webkit would implement when we add the overrides in the
         font description block
  myles: No objection to add, we can discuss the set later
  astearns: Sounds like we have a consensus
  astearns: Any objection?

  RESOLVED: Add new metrics that can be used to harmonize the font
            size of fonts used in fallback

  florian: btw we need to find a way to work with the opentype people
  florian: so we can provide feedback
  florian: I don't have a plan to propose, but there is a community
           group created recently
  florian: I don't know for sure how to engage with the fonts people,
           but it would be nice to figure it out
  astearns: Indeed, the set of metrics can be a good think to ask to
            the opentype people
  astearns: Let's make sure that we don't ping them about bad fonts
  astearns: There are lots of fonts that are reporting wrong metrics
  astearns: and it's not the fault of the committee
  <florian> https://github.com/w3c/font-text-cg/

Vertical metrics overrides
  github: https://github.com/w3c/csswg-drafts/issues/6152

  fantasai: These overrides are applicable in vertical text
            if you rotate the characters
  fantasai: But, for example, ascent and descent are given differently
            depending on the axis
  fantasai: We probably need to add independent values for overriding
            metrics in vertical typesetting modes
  fantasai: because using the horizontal values in vertical writing
            mode doesn't make any sense
  myles: In upright vertical text, the ascent would be horizontal?
  fantasai: Yes, horizontal
  (some pondering)

  astearns: Do we need to support both or a switch?
  fantasai: I think both might be required to be specified at the same

  myles: This proposal would require a different implementation
  myles: This is fine, but this something worth noting
  fantasai: But the font has y values, you just need to override them
  myles: Possibly? But the problems that this solves are less
         important that the horizontal writing mode
  fantasai: I would agree that this is less severe in most cases
  fantasai: because in vertical writing mode the baseline is often the
            middle, and it is fine
  myles: And the CJK scripts don't have diacritics so they usually fit
         in the 1em box
  fantasai: Some cases might still exist

  astearns: Are there arguments to not complexify?
  astearns: If we add this, I would like to view examples
  astearns: because I don't have an idea in mind of what this would do

  astearns: Any objection to add this to the spec at this time?
  jfkthame: line-gap override could be useful too
  jfkthame: No reason this should be left out
  astearns: ok, any objection?

  RESOLVED: Add font-face descriptor overrides for vertical writing

How do font-size-adjust property and size-adjust descriptor work
  github: https://github.com/w3c/csswg-drafts/issues/6128

  jfkthame: The question came up about the interaction between these
            two properties
  jfkthame: The proposed solution in the issue
  jfkthame: is that font-size-adjust takes precedence in a given
  jfkthame: that does erase the changes in the descriptor
  jfkthame: I think this makes sense
  myles: One way of looking at it is that they both occur, but
         font-size-adjust changes things to the same solution
  myles: When writing the spec text, I would go with this
  jfkthame: I think that is true
  <dbaron> (Myles's description makes sense to me.)
  jfkthame: basically the calculations of font-size-adjust cancel out
            any previous adjustment
  astearns: Sounds like we have a general agreement
  astearns: Any objection to this clarification?
  <fantasai> +1 to jfkthame's proposal

  RESOLVED: Clarify that font-size-adjust computations will effect
            things in such a way that the descriptor overrides have no

Flexbox & Sizing

Interaction of flexbox minimum height and aspect-ratio minimum height
  github: https://github.com/w3c/csswg-drafts/issues/6069

  cbiesinger: The aspect ratio spec says that with min-height: auto,
              you compute height using the aspect ratio, and you expand
              to the content height
  cbiesinger: but in a column flexbox, the height is the minimum of
              the transferred height and the content height
  cbiesinger: It's not clear to me which one should win
  cbiesinger: fantasai clarified the aspect ratio version should win
  cbiesinger: but does the working group agree to this?
  fantasai: This is different for replaced and non-replaced elements
  fantasai: because the intrinsic size of replaced elements is not as
  fantasai: so we need to keep that behavior for them
  fantasai: but for non-replaced elements, the intrinsic size is more
  florian: I'm not sure about what the alternative is?
  cbiesinger: width:100px + aspect ratio 1:1 but intrinsic-height:200px
  florian: Ah ok, got it
  cbiesinger: Because it used to be the minimum
  jensimmons: The default of flexbox is that it's shrink then grow
  jensimmons: but the proposal is that for replaced elements, we make
              aspect ratio "work"
  fantasai: Yes, that is the heart of the issue
  <fantasai> [Jen's explanation was that if there's a bunch of
             elements you want to be squares, they will be squares
             unless they contain too much content, in which they grow
             to accommodate that content. That's the behavior we
             specced for block boxes with aspect-ratio; and the issue
             is making sure it works the same for flexbox.]

  astearns: Last week there was more contention
  iank: That was me last week
  iank: I am now fine with this
  astearns: Is the spec edit correct for what we discussed
  fantasai: I think it is correct
  fantasai: but we need to update the spec
  fantasai: Proposal is non-replaced elements with an aspect ratio
            honor the intrinsic size in flexbox
  <cbiesinger> for min-height:auto
  jensimmons: I am seeing a lot of tutorials about aspect-ratio on
              replaced elements
  jensimmons: in particular using object-fit etc
  fantasai: that should continue to work
  fantasai: That is why we don't do this for replaced elements
  fantasai: non-replaced elements have an intrinsic size that depends
            on content, that might not be easy to resize
  jensimmons: The previous text for images would still apply then?
  fantasai: Yes
  astearns: Any objection to keep fantasai's edit in the ED?

  RESOLVED: non-replaced elements with an aspect ratio honor the
            intrinsic size in flexbox for min-height:auto

  <br length=15min />

CSS Sizing
  scribe: fantasai
  scribe's scribe: TabAtkins

Auto-resize iframes based on content
  github: https://github.com/w3c/csswg-drafts/issues/1771

  TabAtkins: Fairly old issue, #1171
  TabAtkins: Originated in HTML in the form of 'seamless' attribute on
  TabAtkins: meant to allow isolating parts of a page, but still lay
             them out as if in the page
  TabAtkins: There were a bunch of issues, dropped from HTML
  TabAtkins: core ideas still requested by people, in various variants
  TabAtkins: We believe there's a useful and safe set of resizing
             behavior that we could expose now
  TabAtkins: that would solve some of the use cases
  <TabAtkins> https://github.com/w3c/csswg-drafts/issues/1771#issuecomment-805117925
  TabAtkins: Core idea is that just the resizing portion of seamless
             is valuable
  TabAtkins: But there are security issues around being able to tell
             the size of 3rd-party content
  TabAtkins: Bare minimum, different sizes of content depending on
             whether the user is logged in or not
  TabAtkins: So should only be allowed to take size of 3rd-party
             content if it wants to allow that
  TabAtkins: Another problem, if 3rd-party page can trigger resizing
             without consent of containing page, can create problems
             as well

  TabAtkins: So proposal is a 2-way agreement on sizing
  TabAtkins: First, outer page needs to opt into resizing based on
             iframe content
  TabAtkins: Suggestion is to use new 'resize' value in 'allow'
  TabAtkins: Then for 3rd-party content, there's a window.resizeTo()
             method which is a no-op in iframes
  TabAtkins: Inner page can request such sizes
  TabAtkins: using this API
  TabAtkins: Whenever inner page wants a resize, triggers an event on
             iframe which bubbles up
  TabAtkins: if not preventDefault, then the iframe changes it's size
  TabAtkins: if cancelled, doesn't change size
  TabAtkins: This allows control over layout behavior across the page

  astearns: Possible scripts using resizeTo() and relying on the fact
            that it does nothing?
  TabAtkins: It's a no-op currently, so don't think so
  TabAtkins: ... [ missed ]
  astearns: Making page decide to allow event or not, already in place
            due to opt-in to resize behavior

  cbiesinger: Nothing sounds like CSS thing
  TabAtkins: Kinda sorta
  TabAtkins: It's a cross-spec thing, does interact with CSS by
             adjusting intrinsic size of iframe
  TabAtkins: Gets into issue of same-origin content

  fantasai: You wanted a 2-way handshake for security
  fantasai: saying resizeTo() gives you 2-way for page consenting
  fantasai: What if that page is already firing resizeTo() and
            expecting it not to have security implications?
  fantasai: I don't think paying attention to resizeTo() would break
            the framed page...
  fantasai: But if they're asking for it and it's currently not
            changing size, the outer page probably isn't expecting a
  fantasai: [clarifying] the issue isn't an attack due to sizing, it's
            a possibly unexpected info leak from the frame'd page,
            leaking the size it wants to size to
  florian: Currently, calling resizeTo() doesn't leak information
  TabAtkins: Could check if stuff in iframes do this currently...
  fremy: It's not about stuff currently in iframes, but a page could
         put *anything* into an iframe
  fremy: which would leak information from that page, which was not
         intended to be in an iframe
  florian: resizeTo() doesn't have an effect on pages that are loaded
           into a window with multiple tabs
  florian: for exactly this reason: it would leak information about
           that page to other pages in the same window
  florian: Opening up this leak through iframes is similarly bad
           (worse maybe)
  TabAtkins: Yeah, OK, we need to think about that more. Maybe needs a
             new API
  <iank> another path would be an additional dictionary argument to
         resizeTo, e.g. window.resizeTo(100, 100, {something: true});
  <fantasai> +1 iank

  florian: In the case where resize does work, thing it affects is the
           natural size, right?
  TabAtkins: Yes. Right now iframes have natural size of 300x150, and
             this would change that
  TabAtkins: Totally controllable, it's the weakest size input possible
  fremy: Do iframes have an aspect-ratio applied to that intrinsic
  TabAtkins: currently iframes do not have an aspect ratio
  TabAtkins: Ability to infer an aspect ratio is an interesting
  florian: As long as we're there, should we specify min size and max
           size separately
  TabAtkins: Interesting. Not unreasonable to consider.

  jensimmons: Curious about use cases
  jensimmons: All I can think of is what ad networks will do, and I
              don't like those thoughts.
  TabAtkins: There's another proposal for 1st-party content, which
             addresses more use cases
  TabAtkins: but even within 3rd-party stuff, currently they do this
             resizing already, just with postMessage back and forth
  TabAtkins: This would standardize that
  TabAtkins: There's also things like Disqus, which does such
             special-case postMessage things
  TabAtkins: which is complicated and no standardized way to handle
             across multiple systems
  TabAtkins: YouTube player, e.g., might want to do this. CodePen
             might want to ask for sizes on its examples. Anything
             that wants to embed, has a reasonable use case for
             wanting to request a particular size and have it
             potentially honored by containing page
  jensimmons: If goal is to reduce jankiness of ad network...
  TabAtkins: That is one goal, but not all of it!

  <leaverou> need to drop off briefly for another call, but I'm very
             supportive of this, and I hope we can find a way to
             implement it in a privacy and security preserving way.

  emilio: How do you react to resize in parent page when using the API?
  emilio: User shrinks the page, need to somehow coordinate between
          both. No auto size, only fixed intrinsic size
  TabAtkins: I don't think there's a reasonable direct analog to block
             auto-sizing ..
  emilio: I guess at that point... You don't really need JS on the
          parent page to get auto height
  emilio: If you require JS on the parent page then it's not great
  emilio: So inner page can send resizeTo() whenever it gets Resize
  emilio: and then containing page doesn't need to do anything ...
  emilio: [missed]
  TabAtkins: Possible this makes it easy enough that it's a concern
  emilio: resize event ... your own resize event
  TabAtkins: I suspect that's something that would show up fairly
  emilio: It only consumes CPU, not while:true. I send a message, it
          resizes me, sends a message back. Code keeps working, just
          uses a ton of CPU
  emilio: It's a bug in the page, but.
  TabAtkins: no-op loops can't happen because if the iframe's
             resizeTo() doesn't change its size, won't get an event
             because size didn't change.
  TabAtkins: Either it'll grow or shrink infinitely, or will jiggle,
             which should be noticeable
  emilio: Concerned about e.g. floating point issues, and rounding
  emilio: I've seen that kind of stuff happen
  <iank> we also already have the "jiggle" problem today with frame by
         frame resize-observers.
  <fantasai> if not causing change in size, then shouldn't cause a

  fremy: Can't put a breakpoint in the main page to figure it out
         because no JS
  fremy: Already have these kinds of bugs today

  smfr: The HTML5 event loop spec is very specific about when resize
        steps happen
  smfr: When we spec this, we need to spec it in terms of that event
        loop spec
  smfr: Nobody mentioned resizeobserver yet
  smfr: It's designed to avoid infinite recursion
  smfr: We might need something here with nested iframes, so don't get
        into crazy infinite resizing
  TabAtkins: Yes, want to handle events in descending order like
             resizeobserver does
  TabAtkins: Need some thought to ensure not creating bad cross-tree
             resizing behavior
  TabAtkins: Not too concerned about page vs iframe vibration, but
             much worse if grandparent grandchild interactions cause
             problem, because then nobody knows what's going on

  fremy: Main question here was, I guess point of allow attribute is
         to allow resize
  fremy: External page wants to allow iframe to resize
  fremy: Not sure I understand point of resize function
  fremy: why not some CSS value that allows resizing by containing page
  fremy: Reason I think about that is that resize takes 2 arguments,
         width and height.
  fremy: Not that interesting to change intrinsic width of iframe
  fremy: Why not say that "I'm fine with my scrollHeight to be
         reported to the containing page"
  <gregwhitworth> +1 to fremy
  iank: scrollHeight isn't always what you want
  fremy: Could be something smarter, max-content maybe
  TabAtkins: Second part of proposal also, about same-origin content
             and no-JS solution

  smfr: Other point, iframe calls resizeTo() and has to provide a
        size. What size should it provide? Does it do
        getBoundingClientRect() on the body or what?
  smfr: Is there some convenient way to get the height of the content?
  TabAtkins: For 1st-party content, making it easy. But for 3rd-party
             content wanted to be more explicit
  TabAtkins: But maybe we can reduce that restriction

  TabAtkins: 2nd part of proposal is about same-origin content
  TabAtkins: Right now, minimum solution still requires some JS on the
             framed page (not containing page)
  TabAtkins: but for same-origin content, there's a certain degree of
             implicit trust we can rely on
  TabAtkins: and might not require auditing
  TabAtkins: For this, I propose that on a 1st-party iframe, or
             something that's srcdoc
  emilio: srcdoc is not ?
  emilio: data URIs are
  TabAtkins: sorry, I'm thinking about sandbox
  TabAtkins: In my original proposal, I had a new property that could
             be set on the root element to set the requested intrinsic
             size for each axis (auto | <length>)
  TabAtkins: Page could opt into ? via 'from-element' keyword,
             providing fallback length
  TabAtkins: fantasai later suggested the page could just set an
             explicit width/height on the HTML element
  TabAtkins: Possibly we don't need to mint a new property, can just
             take from the root element
  TabAtkins: If that's problematic from existing, maybe mint something
  TabAtkins: but either way, that'll allow getting the size without JS
  TabAtkins: Just set allow=resize, and inner page does whatever it
             needs to do
  TabAtkins: and those sizes automatically communicate back and forth
  TabAtkins: Acts like an element, no JS required
  <TabAtkins> https://github.com/w3c/csswg-drafts/issues/1771#issuecomment-805117925
  fremy: That only works in 1D, right? You can't do both dimensions
  fremy: Then you wouldn't get the resize
  fremy: If you get width + height, wouldn't know you need more space
  TabAtkins: If you set both to auto, you'll need to rely on outer
             page to set your width...
  fremy: ah, ok, make sense
  iank: I don't think that width/height on HTML will work, because
        people do set an explicit width on HTML and use e.g. auto
        margins to center
  iank: HTML is not the root, bit of disconnect
  iank: Likely for auto behavior, might want something like scrollWidth
        /scrollHeight as was discussed
  iank: There's a little bit of danger here
  <fremy> +1 to scrollWidth/scrollHeight (adjusted if necessary)

  iank: You might get content that, if you have a fixed-position
        content that rises to ICB, and has height 120%, could create
        an infinitely-growing iframe that way?
  iank: I'm not too concerned about that
  TabAtkins: Yeah, need to think about loop detection...
  fremy: We can set a threshold, if you fire too many resize events in
         a certain amount of time don't allow it or whatever
  iank: That might block some valid use cases. E.g. comment expansion
        might want to animate growing
  <gregwhitworth> resizeObserver has the same error handling

  gregwhitworth: Effectively what you just outlined is something we
                 wanted at Salesforce. All over the web people are
                 using Salesforce but not aware of it.
  gregwhitworth: Would like to see network headers
  gregwhitworth: enable this auto behavior for cross-origin
  gregwhitworth: if a grid with min/max content, how can I lay out my
                 content and pass back my height
  gregwhitworth: I can work it out in JS, but want it automatic
  TabAtkins: Reason restricted right now is trying to be cautious
  gregwhitworth: We could write blog posts about how to do it, but
                 would rather not
  TabAtkins: I would want to have more security eyes on it
  gregwhitworth: ...

  emilio: There is some kind of precedent for this, loading a doc and
          sizing it intrinsically, which is SVG
  emilio: Even if the SVG is not an actual image, if you have an
          object tag with SVG source, that's actually a document
          that's ...
  emilio: in FF and Chrome at least, that size is intrinsic to SVG's
  emilio: it would be good to figure out if there's something that we
          need to learn from that or not
  emilio: that's probably legacy behavior
  emilio: While we were doing site isolation
  emilio: I just wanted to mention that precedent
  emilio: I think those can run script, even if SVG
  TabAtkins: A few people in thread mentioned OBJECT
  TabAtkins: If currently allows that behavior and think it's OK, then
             maybe can allow it
  TabAtkins: I haven't thought about it yet

  fantasai: On the topic of 3rd party sizing info without JS, I think
            it makes sense to allow
  fantasai: If both the container and the inner page have explicitly
            allowed for it
  fantasai: That indicates trust between the two
  fantasai: For doing it declaratively, Ian's point about width/height
            on root not being what we want makes sense
  fantasai: Tab mentioned setting a property giving the behavior
  fantasai: I don't think that's a CSS property, it's more of a
            security handshake
  <gregwhitworth> +1 fantasai
  fantasai: So maybe an attribute on <html> that opts the iframe'd
            page into the behavior
  fantasai: And would let you specify which size you want (scroll
            height, border-box height, etc)
  fantasai: I think the size shouldn't be specified in HTML, should be
            in CSS; but allowing this should be an HTML attribute

  dholbert: Should any page on the internet be able to get that info?
  dholbert: maybe same-origin addresses it
  dholbert: Don't want to allow inadvertent stealing of info from the
  TabAtkins: Right, which was why I initially wanted to disallow it
  TabAtkins: and fantasai was talking about explicit opt-in
  TabAtkins: I think there's some kind of iframing options setting?
  iank: There's ??? HTTP Header which restricts which origins you can
        be embedded in. Most banks etc. use that.
  TabAtkins: Requiring that, reasonable thing to start with
  iank: Would need to set Access-control: allow-origin or whatever

  astearns: Sounds like you got some good feedback, something to work
  TabAtkins: Plan is that parts of this that relevant to CSS would go
             to contain spec
  TabAtkins: and sizing spec
  TabAtkins: to talk about natural size being controllable this way
  TabAtkins: If we do have a new property... probably in sizing? maybe
  TabAtkins: Rest will be pursued in HTMLWG
  astearns: Should CSS part depend on the HTML part being accepted?
  TabAtkins: Sure

  myles: This entire discussion about how / technical considerations.
         Not about whether to do it all.
  myles: Want to make sure that it's not a foregone conclusion that we
         should do this.
  TabAtkins: Decent part of this was sussing out whether there's
             interest in doing this
  TabAtkins: Seems people are interested
  TabAtkins: I suspect discussion in HTMLWG will be more contentious
  TabAtkins: OK to object over there :)
  astearns: But feel free to object over here also, if you think it's
            a terrible idea!
  TabAtkins: We don't have any major internal partners clamoring for
             this, it's an old issue that's a frequent author
             requested, and we found a way to address an important
             part of it

  <br duration=12min>

Received on Monday, 24 May 2021 22:47:26 UTC