[CSSWG] Minutes Fukuoka F2F 2019-09-16 Part I: F2F Scheduling, CSS Contain, rendersubtree, Sizing L4 [css-contain] [css-sizing-4]

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

F2F Scheduling

  - RESOLVED: Igalia meeting time is 10am-7pm
  - RESOLVED: CSSWG meeting Monday 27 April 2020 - Wed 29 April 2020,
              Houdini afterward (pending booking confirmation)
              [Location: Cork, Ireland]
  - Tentatively there will be a late July meeting in NYC

CSS Contain

  - RESOLVED: PR of css-contain-1, dropping style containment (at-risk)
  - RESOLVED: FPWD css-contain-2 being copy of css-contain-1
              (including at-risk features)


  - chrishtr introduced the proposal for a rendersubtree attribute.
      Proposal text:
      Proposed PR: https://github.com/whatwg/html/pull/4862
      Github issue: https://github.com/whatwg/html/issues/4861
  - The 'rendersubtree' attribute controls whether the subtree is
      laid out and rendered or not, in order to allow browsers to be
      more performant and authors to reserve space for an element that
      is not yet loaded. This also introduces an "activation" concept
      which allows the browser to choose to render.
  - Several members expressed concern that this felt more like a CSS
      property. The reason it was not written to be is because the UA
      is allowed to overwrite it.
  - The use case for 'invisible' and not 'activatable' is so the author
      can prevent not-yet-rendered content from being shown. It was
      suggested the default should be 'activatable' since authors might
      not think through all cases of 'invisible' if it's the default.
  - It was suggested to add callbacks for the activation actions so
      authors could listen for the changes.
  - The difference between this and 'contain: all' is that this would
      prevent animations from loading. Meanwhile, the difference to
      'display: none' is that the layout work is still done in this
  - More info at https://github.com/whatwg/html/issues/4861

Sizing L4

  - RESOLVED: Add proxy-width/height/inline-size/block-size with
              values legacy | auto | <length> (Issue #4229:


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

  Rachel Andrew, Fronteers
  Rossen Atanassov, Microsoft
  L. David Baron, Mozilla
  Amelia Bellamy-Royds, Invited Expert
  Christian Biesinger, Google
  Brian Birtles, Invited Expert
  Oriol Brufau, Igalia
  Tantek Çelik, Mozilla
  Emilio Cobos, Mozilla
  Emil A Eklund, Google
  Elika Etemad, Invited Expert
  Jihye Hong, LGE
  Koji Ishii, Google
  Sanket Joshi, Microsoft
  Brian Kardell, Igalia and Open JS Foundation
  Eugene Kashida, Salesforce, Observer
  Rune Lillesveen, Google
  Chris Lilley, W3C
  Peter Linss, Invited Expert
  Stanton Marcum, Amazon
  Myles C. Maxfield, Apple
  Cameron McCormack, Mozilla
  Nat McCully, Adobe
  Chase Phillips, Google
  Florian Rivoal, Invited Expert
  Dominik Röttsches, Google
  Devin Rousso, Apple
  Peter Rushforth, Natural Resources Canada, Invited Expert, Observer
  Hiroshi Sakakibara, Beyond Perspective Solutions(BPS)
  Simon Sapin, Mozilla
  Dirk Schulze, Adobe
  Markus Stange, Mozilla
  Alan Stearns, Adobe
  Aleks Totic, Google
  Matt Woodrow, Mozilla
  Fuqiao Xue, W3C

Scribe: fantasai
Scribe's Scribe: florian

F2F Scheduling

  Rossen: January is already in the books
  Rossen: Jan 22-24 hosted by Igalia
  fantasai: Should we resolve on Rego's suggestion to run 10-7pm?
  florian: Reason was local schedules, restaurants don't open until

  RESOLVED: Igalia meeting is 10-7

  Rossen: Dates from Apple?
  astearns: Tess said she's trying to reserve April 27-30
  astearns: Don't have an update on if she succeeded
  Rossen: Just want to try to sort it out asap, so people who are on
          tight schedules can finish their scheduling for the spring
  skk: Will there be a Houdini meeting?
  Rossen: Not in Spain, in April there will be one

  Rossen: Possible Summer locations are Kyoto, France, NYC
  Rossen: Anyone up for sponsoring F2F meeting?
  florian: France is a misunderstanding, can't offer to host in
           France, but can host in Kyoto but not in July+August
  Rossen: NYC would put two consecutive in USA
  astearns: Maybe. April might be in Ireland
  Rossen: So looking at July 20-24 or July 27-31, last two weeks of
  <birtles> July+August is also Olympics in Tokyo, so not a good time
            to visit Japan
  dbaron: That is not the ideal time for Japan, not only because it's
          warm but also Tokyo Olympics are then

  hober: I have dates!
  hober: Did we want to have Houdini, also?
  hober: I have three days confirmed, 4th not confirmed yet
  hober: Booked for Monday 27 April - 29, in Cork, Ireland
  Rossen: Sounds great

  RESOLVED: CSSWG meeting Monday 27 April 2020 - Wed 29 April 2020,
            Houdini afterward (pending booking confirmation)

  Rossen: Back to summer
  Rossen: Who was offering to host in NYC?
  dbaron: Think it was Una (Google)
  TabAtkins: We can probably do it
  Rossen: Ok, check about it and let us know
  <dauwhe> +1 to NYC for a meeting where I won't be jetlagged :)

  TENTATIVE: End of July 2020 in NYC

CSS Contain

  Rossen: Proposed to publish a PR of CSS Contain 1
  <dbaron> https://drafts.csswg.org/css-contain/issues-2019-cr.html
  <dbaron> https://drafts.csswg.org/css-contain/implementation-report-2019-09
  <dbaron> https://drafts.csswg.org/css-contain/annotated-2019-09-05.html
  <dbaron> https://github.com/w3c/csswg-drafts/labels/css-contain-1
  <dbaron> https://drafts.csswg.org/css-contain-1/

  florian: Afaict, it's complete
  florian: All tests pass in 2 browsers, except those which depend on
           other less-mature specs
  florian: So I think we are ready for PR
  florian: One more note, all tests pass if we don't count the at-risk
  florian: style containment is not implemented properly anywhere
  florian: but that's why we marked it at risk
  florian: So my request is to drop it, go to PR, and publish FPWD of
           Level 2 which just contains that feature
  Rossen: So PR version will have 3.3 dropped from Level 1

  Rossen: Objections on resolving to publish PR of CSS Contain 1 with
          dropped section?
  dbaron: Is the state of style containment that implementations are
          shipping support and not passing tests, or not shipping
  eae: Combination of both
  florian: Chrome ships a buggy one, and Gecko doesn't ship iirc
  heycam: We don't recognize the value
  smfr: Are the two implementations blink and gecko?
  florian: Yes
  Rossen: Hearing no objections,

  RESOLVED: PR of css-contain-1, dropping style containment (at-risk)

  florian: For Level 2
  florian: if we add new features, need fpwd, but if not adding a new
           feature can go directly to CR

Sizing L4

  github: https://github.com/w3c/csswg-drafts/issues/4229

  <astearns> explainer:
  chrishtr: Posted a new explainer
  chrishtr: content-size is a new CSS property
  chrishtr: If 'contain: size' is specified, content-size is treated
            as intrinsic size of contents
  chrishtr: Proposing that be able to set intrinsic width/height
            passed to intrinsic sizing algorithms
  chrishtr: Reason we believe it's useful is that you can use it when
            a subtree is not yet ready or you don't want it to have
            its own layout
  chrishtr: can express a placeholder sizing for it
  chrishtr: Allows communicating that placeholder sizing, so that flex/
            grid/table/etc can take that into account
  chrishtr: If we've skipped rendering as an optimization, dev can use
            to communicate placeholder sizing

  SimonSapin: Would this property apply without 'contain'?
  chrishtr: When you don't have 'contain: size', no
  chrishtr: Only applies when 'contain: size'. Reason is that
            'contain: size' causes no competing intrinsic size
  chrishtr: 2nd reason is that it fits neatly with render subtree
            attribute proposal
  florian: Can you expand on the second point? I'm not familiar
           with that
  florian: In isolation proposition makes sense, but not sure why it's
           not coupled with a more generic intrinsic size feature
  TabAtkins: One reason was that, as chrishtr said, that means you
             have competing information. We don't think that's useful
             to have two sources of truth there
  TabAtkins: Seems like only time you need to provide a better
             intrinsic size is when you're contain sizing already
  dbaron: I'm skeptical of that
  dbaron: I think there are a bunch of cases, where intrinsic sizing
          doesn't provide good results and devs might want to
          provide it
  dbaron: Talked about some of those cases in the past
  dbaron: Some cases devs want to override only in one dimension
  TabAtkins: Bad behavior of intrinsic scrollers maybe?
  TabAtkins: flexboxes blowing up
  dbaron: Didn't have that in my head, but sure
  TabAtkins: That's intriguing
  AmeliaBR: Also cases we've had where certain modes cause things to
            collapse down to zero, and might be better not to
  AmeliaBR: Lots of cases there might be a demand for it

  AmeliaBR: Wrt naming, 'content-size' might be interpreted as size of
  AmeliaBR: Also, if there is a limitation, should be good reasons
            for it
  TabAtkins: Yes, happy to come up with better name

  TabAtkins: Cases that fantasai and I identified where boxes get too
             big in intrinsic sizing, and currently don't have a way
             to opt into better behavior
  TabAtkins: In some cases can inflate intrinsic size, others might be
             able to shrink
  TabAtkins: good idea

  fantasai: Support florian and dbaron, this should probably be a
            generic mechanism
  fantasai: The value space would be legacy | auto | <size>
  cbiesinger: What is the difference between legacy and auto?
  fantasai: scrollers collapsing to 0 or not
  fantasai: If inside a flex item, there is an overflow:scroll pre
            element with a very long line, the min-content size is the
            size of the very long line, that makes the flex item be
            very large, even though we could just have made it into a
  [ this is https://github.com/w3c/csswg-drafts/issues/1865 which
      seems unfixable ]

  TabAtkins: Semantics are still a bit funky, if you provide a size
             wouldn't do anything unless you're contain: size
  fantasai: Well, I think it would
  dbaron: I would also note that there are cases where intrinsic
          sizing provides sizes that are too small, e.g. in cases with
  fantasai: If you specify an explicit size here, that takes over and
            you ignore the content
  TabAtkins: Could do that... was wondering if you wanted to max them
  AmeliaBR: Doing a max or min doesn't work if we want to accept both
            use cases of dealing with cases where intrinsic size is
            too big or too small
  AmeliaBR: Just say if you specify a value, you wanted to override

  chrishtr: All these examples that were alluded to but not explicit,
            please write into issue

  fantasai: Based on discussion, this doesn't go into contain, goes
            into Sizing level 4

  Rossen: Anything else on this topic
  TabAtkins: Discussion was good
  chrishtr: Point Florian raised about, what are you talking about wrt
            render subtree
  chrishtr: Maybe wait until we talk about that
  chrishtr: but 5min background on render subtree, though it's on the
            HTML spec
  chrishtr: Package, how they fit together matters, so just want to
  Rossen: We can put that topic next
  chrishtr: Just want to give an overview of what it is, what use
            cases are, how it functions
  chrishtr: so can get some feedback
  <chrishtr> Explainer that contains rendersubtree:

  Rossen: So content-size, or whatever we're going to call it, will go
          to size level 4
  Rossen: Any objections to add it?
  TabAtkins: Maybe call it intrinsic-size
  fantasai: Nobody wants to spell that
  TabAtkins: true
  fantasai: There was a suggestion that this be split into width/
            height not one property for both dimensions
  fantasai: Seems to be the proposal is foo-width/height/inline-size/
  iank: legacy as initial value?
  PROPOSAL: Add proxy-width/height/inline-size/block-size with values
            legacy | auto | <length>

  RESOLVED: Add proxy-width/height/inline-size/block-size with values
            legacy | auto | <length>

CSS Contain

Contain level 2

  florian: We could go CR directly, but we might want to change things
           so maybe fpwd is better
  florian: Some suggestions, e.g. single-axis contain, etc.
  florian: Might want to add

  RESOLVED: FPWD css-contain-2 being copy of css-contain-1 (including
            at-risk features)


  chrishtr: I posted a link to an explainer earlier
  <chrishtr> Explainer that contains rendersubtree:
  <chrishtr> https://github.com/whatwg/html/pull/4862
  chrishtr: PR for spec idea

  chrishtr: render-subtree attribute is an attr you can put on any
            HTML or SVG element
  chrishtr: Has one or more keywords that are space-separated
  <bkardell> ... or mathml?
  chrishtr: ex. rendersubtree=invisible
  chrishtr: What that means is that it is invisible, but takes up
            layout space
  chrishtr: and also is designed so that UA doesn't need to do any
            render work for that subtree
  chrishtr: No heuristics to figure out whether needs to render that
  chrishtr: You load a web page
  chrishtr: bunch of content not on screen atm
  chrishtr: You want that page to load quickly, not have extra layout
  chrishtr: not load external resources
  chrishtr: etc.
  chrishtr: for stuff that's not on screen right now
  chrishtr: Common because scrolling is common on web, and large

  chrishtr: What does attribute do when set to invisible?
  chrishtr: First, it applies layout, style, and size containment
  chrishtr: Layout containment is good, content below can't escape
            layout of the element at the root of the subree
  chrishtr: Size containment for similar reasons:
  chrishtr: don't need to know layout to compute layout of the page
  chrishtr: so don't need to do layout, don't need to paint it,
  chrishtr: not painted to screen and not hit-testable
  chrishtr: so don't need to do any work as UA to process that DOM
  chrishtr: it is present, but doesn't cause any work
  chrishtr: That's the core value-add of the 'rendersubtree=invisible'

  chrishtr: Other values you can add
  chrishtr: If you say that rendersubrree is invisible and
            activatable, what that means is that UA is allowed to
            mutate that attribute to be empty string
  chrishtr: to render the content
  chrishtr: e.g. wikipedia, stuff below the fold
  chrishtr: wikipedia makes as activatable
  chrishtr: and invisible
  chrishtr: When user or a11y API wants to look at that content
  chrishtr: or user wants to do find-in-page operation
  chrishtr: and UA notices the content is below the fold off-screen
            content browser would be able to cause the content to
  chrishtr: which has effect of causing it to render
  chrishtr: and script can observe the mutation of the attribute
            through a mutation observer
  chrishtr: Takes some action to help
  chrishtr: or in simplest cases, content is just rendered
  chrishtr: Important because lots of UA algorithms not controlled by
  chrishtr: e.g. a11y, anchor link navigation, tabbing between
            focusable elements
  chrishtr: scroll-int-view operation, find-in-page

  chrishtr: Finally, two additional keywords
  chrishtr: One prevents external resources from being loaded
  chrishtr: image wouldn't be loaded until whole-loads keyword is
  chrishtr: avoids blocking network pipeline for stuff below the fold
  chrishtr: Useful for feeds of info like fb, twitter, also for page
            with lots of images off-screen
  chrishtr: This is a lazyloading feature similar to what chromium is
            trying to ship
  chrishtr: Finally, web component element upgrades
  chrishtr: If you have custom elements defined in your registry,
  chrishtr: if element was registered, runs create callback
  chrishtr: Allows dev script to participate in rendering the custom
  chrishtr: but if elements are off-screen, then cost isn't desirable
  chrishtr: dev would prefer not to run script until content is
  chrishtr: Way this fits in with content-size is that if you set the
            render subtree attribute to 'invisible'
  chrishtr: has containment
  chrishtr: therefore content-size would take over sizing of
            unrendered content
  chrishtr: This way, when content is subsequently rendered via UA
            action or dev activation
  chrishtr: layout doesn't jump around
  chrishtr: contain: size is only applied when invisible
  chrishtr: When not invisible, then it will no longer have
            'contain-size', automatically uses actual size
  chrishtr: Intrinsic size without size containment might be
            compelling enough to drop this connection, but that's what
            we were thinking

  chrishtr: 'display: none' doesn't help for off-screen content
            because it doesn't take up layout space
  chrishtr: 'visibility: hidden' doesn't stop layout, and also can be
            overridden by descendants, so have to render through the
  Rossen: 'display: none' + 'contain: size"
  chrishtr: display: none box is gone
  chrishtr: rendersubtree=invisible, the box is still there, only its
            contents are gone
  chrishtr: You could have e.g. a spinner rendered in the element, or
            a pseudo-element, but don't actually render the subtree

  smfr: What's the behavior when element with visible subtree changes
        to invisible
  chrishtr: If you just add `rendersubtree="invisible"` to element
  chrishtr: it'll apply contain: style layout size
  chrishtr: and not render the contents
  chrishtr: but element itself will still read
  chrishtr: Script can still read style, could cause layout thrashing
  smfr: So toggle from visible to invisible ...
  smfr: does it give you a stale value?
  chrishtr: Will do the work to get you the right value
  chrishtr: Doesn't cause it to render, but has to do calculations
  smfr: Seems a bit magic, like a hack
  smfr: Seems like maybe it should be a CSS value, e.g. new keyword to
  chrishtr: If it was a CSS property, would be weird if UA overrides it
  chrishtr: Made it a attribute so UA can remove automatically
  smfr: Worried about circularity about activatable
  smfr: e.g. user hits Cmd+F to start a find
  smfr: I think you have to bring in the subtree in order to search it
  smfr: because have to e.g. check for 'display: none'
  chrishtr: Don't have to show on screen, but have to compute style
  smfr: Activatable has side-effect of removing the attribute?
  chrishtr: If you try find in page, UA will do the work necessary to
            compute the display: none part of pipeline
  chrishtr: If it matches query, would activate the subtree
  smfr: Worried there are some things that are not specified that end
        up affecting the activation behavior
  smfr: Spec says activation depends on UA behaviors, different
        browsers will have different activation policies if we don't
  chrishtr: Explainer lists which actions cause activation
  chrishtr: Scrolling doesn't, JS scrollIntoView does, a11y access does

  Rossen: We have built up quite a queue

  florian: Maybe I missed something, one part I'm confused about
  florian: what's the use case for invisible without activation?
  florian: I think author will probably miss some important cases if
           it's not activatable
  florian: Also, feels like it's something like a delayed or sync
           value for visibility
  florian: You're allowed to delay, but once on screen please show
  florian: Most benefits when combined with contain,
  florian: but conceptually could be separate
  florian: You're allowed to load the assets later
  florian: wouldn't need to override the value, just permission to do
           it later
  florian: maybe that covers requirement for running scripts?
  florian: Rest feels like it could be in CSS somewhere along the
           lines that smfr was talking about
  florian: Would like to also know why have a version that's not
  chrishtr: Suppose you have content that is not fully loaded, don't
            want to show to user. That's why you don't want it to be
  chrishtr: Wouldn't be visibility: hidden because not performant,
            layout subtree still applies
  myles: If you want to leave space for it, you can set visibility:
         hidden for it, will leave space
  myles: If you do want the pop, can set display: none
  florian: Would combine visibility: hidden with contain, to reduce
  TabAtkins: Will have jumping because the content hasn't loaded either
  florian: But would use 'contain' and 'content-size' as well
  florian: Why needs an HTML attribute
  TabAtkins: Doesn't allow us to not do layout
  TabAtkins: Which is a problem if wanting to load 10,000 nodes worth
             of content
  florian: So would want 'visibility: ...', which would allow delaying
  TabAtkins: Recall reason chrishtr just said about having invisible
             but not activatable
  TabAtkins: Element is in state where it's waiting for stuff to load
  TabAtkins: don't want to allow activation until finished

  AmeliaBR: Had same question
  AmeliaBR: but final comment, might want to consider making
            activatable the default
  AmeliaBR: Authors might *think* they know when to activate, but
            haven't considered things through very well
  AmeliaBR: so suggest to make default activatable, author has to
            explicitly request non-activatable
  <AmeliaBR> e.g. `inert` version for non-activatable
  myles: Might be problematic to have elements callback in
         unpredictable order?
  chrishtr: Can use this feature to automatically activate content
            which is below the fold, or not even actually visible
  chrishtr: e.g. tabbed UI or content hidden behind a ? that can be
            opened by the user
  chrishtr: e.g. details element
  chrishtr: Still want user to be able to find that content and
            navigate to it
  chrishtr: currently, that's not really possible
  chrishtr: e.g. you have content in another tab of the ui, or
  chrishtr: nm, another reason for activation

  heycam: two things: one, want to echo what smfr said
  heycam: I feel like behavior when subtree isn't rendered seems like
          CSS kind of feature
  heycam: Recognize that overriding the style value of some property
          doesn't feel great
  heycam: but otherwise feels like some new 'display' value, like
          'display: placeholder' which only generates frame and not
  heycam: Some kind of solution where it's somehow reflected in CSS
          property display would be nice

  heycam: 2nd point was about automatic activation behavior
  heycam: have you considered solution where you have strict callbacks
          for events for these types of activation behaviors?
  heycam: so dev can choose to catch events and decide whether to flip
  chrishtr: So suggesting that script should be able to observe
  heycam: Wondering if that's a design that you've considered
  chrishtr: Did consider that design
  chrishtr: and prototyped in chromium
  chrishtr: The event for this, which we called activate event, wasn't
            in spec proposal
  chrishtr: but makes sense and is convenient to add
  chrishtr: Technically can be implemented with mutation observer, but
            might be inconvenient

  heycam: One advantage of that might be that you could then have a
          new display property value that does the actual work of that
  heycam: and let the author change the value of that property
  chrishtr: So tell dev that "I would like to activate this, please
            help me out"
  chrishtr: problem is default behavior is not good
  heycam: Author specifying 'display: placeholder', on you to complete
          the solution

  chrishtr: Comments about flipping default activation, should make it
            easy as possible to adopt feature without unintentionally
            breaking accessibility
  TabAtkins: copy-paste two-line activation script on every page that
             uses this feature
  TabAtkins: that's not so great
  TabAtkins: If they don't want it to activate, they can use the don't
             activate value, and have that work as intended

  TabAtkins: Back to display values, while I wouldn't fight too hard
             if we decided to add a display subproperty
  TabAtkins: but doing none-typed things in 'display' itself is
             problematic because lose typing
  TabAtkins: this is really bad
  chrishtr: Want UA to be able to activate for you
  chrishtr: with recent testing with partners etc, does seem to be a
            use case for controlling things with a style sheet
  chrishtr: Sometimes convenient to do via CSS
  <TabAtkins> aka you can't set "display:flex" on the element without
              paying a *lot* of attention to specificity, or else
              you'll accidentally override the hide-contents value

  <fremy> @chrishtr: added some notes over here:

  fantasai: Same concern as AmeliaBR about making the activatable
            version the default
  fantasai: It would also be good to have the attribute map to some
            css construct, instead of having the HTML do its own magic
  chrishtr: Less magical means harder to cleanly spec, and some use
            cases are lost

  myles: I see the readme and whatwg pull request, how do I comment?
  chrishtr: I think the pull request has a corresponding issue in
            whatwg, good place to ask questions
  chrishtr please paste the issue

  SimonSapin: Similar to 'display: none', but different in that only
              contents are hidden
  SimonSapin: How is this different from 'display: none' on children?
  TabAtkins: Text content that are direct children can't be styled
  TabAtkins: but also 'display: none' implies a lot of things
  Rossen: Animations, do they run on your subtree?
  chrishtr: No
  Rossen: So that's also same as display: none
  chrishtr: Subtree boxes do have CSS boxes
  chrishtr: Conceptually are laid out, just don't need to do work
            unless forced by script

  mattwoodrow: What is additional constraint that we get over
               'contain: all'
  mattwoodrow: Couldn't UA optimize by not rendering anyway?
  chrishtr: It's an explicit API
  chrishtr: rather than combo of CSS values
  TabAtkins: off-screen 'contain', animations still run
  TabAtkins: You will fall down accidental performance cliffs
  mattwoodrow: So it will block animations?
  TabAtkins: Among other things, yes

  bkardell: I could be misreading this and not understanding, but
            sounds like the intent is for the UA to actually change
            the attribute?
  chrishtr: Yes
  bkardell: Is there a precedent for doing that?
  TabAtkins: There's one precedent
  bkardell: Think there's been 1000 times that's been suggested, and
            push to not do that
  TabAtkins: One precedent: details
  TabAtkins: For similar reason to details, nice thing about directly
             manipulating attribute than a hidden state
  TabAtkins: don't need to expose a new way to report actual value
  TabAtkins: and don't need to expose to CSS using custom selector
  TabAtkins: just use regular attribute selector
  TabAtkins: As long as attribute value is easy enough to work with,
             and this one will be simple,
  TabAtkins: there are usability benefits that come with this for free
  cbiesinger: Value attribute of input?
  TabAtkins: Those don't change

  Rossen: OK, thanks for introducing topic, chrishtr !
  Rossen: People wanting to participate, please do so at links provided
  <chrishtr> Issue for rendersubtree: https://github.com/whatwg/html/issues/4861

  <br duration=25min>

Received on Friday, 4 October 2019 22:51:19 UTC