W3C home > Mailing lists > Public > www-style@w3.org > November 2020

[CSSWG] Minutes TPAC F2F 2020-10-23 Part I: CSS Multicol, CSS Grid, CSS Position, CSS Logical Properties [css-multicol] [css-grid] [css-position] [css-logical]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 4 Nov 2020 09:51:26 -0500
Message-ID: <CADhPm3tM6uME9Uio-oX0X-2NXQiWbaq+RTCBJV3ozq7hxO3DNA@mail.gmail.com>
To: www-style@w3.org
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.

CSS Multicol

  - RESOLVED: Containing block chain goes straight from spanner to the
              multicol container
  - RESOLVED: Publish a new WD of multicol after these edits have been

CSS Grid

  - After discussion on issue #5566 after the call on Monday there was
      a proposal to resolve that percentage of row tracks and gutters
      of grid with indefinite height to auto for tracks and 0 for
  - There was an objections to this in favor of symmetry between
      tracks and gutters so more outreach will be done to those
      working specifically on layout.

CSS Position

  - RESOLVED: Add a hidden pseudo-class for this purpose, in order to
              solve styling issue while leaving open the possibility
              of HTML improving its API (Issue #4645: <dialog>
              positioning should be describable in CSS)

CSS Logical Properties

  - RESOLVED: Inheritance of logical properties inherits the
              corresponding logical property on the parent (Issue
              #3029: Order of inheritance vs. mapping in logical


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

  Rachel Andrew, Fronteers
  Rossen Atanassov, Microsoft
  Tab Atkins-Bittner, Google
  Christian Biesinger, Google
  Mike Bremford, BFO
  Oriol Brufau, Igalia
  Tantek Çelik, Mozilla
  Daniel Clark, Microsoft
  Emilio Cobos Álvarez, Mozilla
  Jon Davis, Pearson
  Elika Etemad, Invited Expert
  Brandon Ferrua, Salesforce
  Megan Gardner, Apple
  Brian Kardell, Igalia
  Chris Lilley, W3C
  Ting-Yu Lin, Mozilla
  Alison Maher, Microsoft
  Myles C. Maxfield, Apple Inc.
  Manuel Rego, Igalia
  François REMY, Invited Expert
  Morgan Reschenberg, Mozilla
  Florian Rivoal, Invited Expert
  Jen Simmons, Apple, Inc.
  Alan Stearns, Adobe
  Miriam Suzanne, Invited Expert
  Lea Verou, Invited Expert
  Greg Whitworth, Salesforce
  Fuqiao Xue, W3C

Scribe: TabAtkins

CSS Multicol

Containing block of column spanners
  github: https://github.com/w3c/csswg-drafts/issues/5612

  rachelandrew: Good details in the issue
  rachelandrew: We don't have interop
  rachelandrew: If you have abspos in a column spanner, not clear the
                what containing block should be
  rachelandrew: Three different options currently
  rachelandrew: In the issue it came down that probably either #2 or
                #3 would be most likely, either viewport (WebKit and
                EdgeHTML) or the column spanner itself
  rachelandrew: I suspect authors would assume the spanner is the
                containing block, or at least would want that ability
  rachelandrew: Option 1 is problematic anyway
  rachelandrew: In gecko it would be harder to implement option 2
  rachelandrew: So it's between 2 and 3, viewport and spanner

  fantasai: I think option 3 is a little weird - it doesn't have relpos
  fantasai: Unless there's something particularly interesting
            happening on, like transform, elements don't trap abspos
            unless they're relpos
  fantasai: So while I'm totally fine with skipping the fragmenting
  fantasai: I think it would be weird to stop at the spanner and
            not go up to the multicol itself if *that* has relpos
  fantasai: and otherwise fall up to the ICB
  iank: Chrome broadly agrees with that
  florian: I was thinking as well
  Rossen: EdgeHTML as well, the spanner is nothing special, you just
          walk the ancestor chain as normal until you find a
          positioned element
  florian: That's a little different from what fantasai described, I
  florian: If you have a relpos parent of the spanner, if you go by
           ancestry in the tree, that would capture the abspos
  florian: fantasai was talking about skipping past that straight to
           the multicol, to avoid fragmentation issues
  iank: Part of the problem is that the spanner isn't really
        positioned in flow, it's positioned by the multicol, so option
        2 is kinda in that direction
  fantasai: I think from an author's perspective, yeah, skipping from
            spanner to multicol would make the most sense since the
            spanner isn't fragmented
  fantasai: That's option 2, yeah; option 3 makes the spanner the
            containing block regardless of its 'position', which seems
  fantasai: So the containing block chain should go spanner ->
            multicol -> normal ancestry from there
  florian: I'm confused, option 2 says viewport
  astearns: If you read the text it goes into more detail
  fantasai: There's no relpos in the example, that's why it goes up to

  TYLin: I think option 2 is best, Gecko is buggy in edge cases
  astearns: So it sounds like option 2 has consensus, containing block
            chain goes spanner -> multicol and then normal from there
  astearns: objections?

  RESOLVED: CB chain goes straight from spanner to the multicol


  rachelandrew: I'd also like to publish
  chris: I suggest you put "Wide Review" in the SOTD, that serves the
         same purpose as Last Call used to
  <fantasai> https://www.w3.org/Guide/documentreview/
  fantasai: And issue review requests, documented in ^^^
  chris: If you need help, let us know
  iank: As an fyi, google/microsoft are working on a new fragmentation
        engine, which is why these issues are coming up now. we might
        find more; we'll file as we do
  astearns: So any objections to publishing a new draft?

  RESOLVED: Publish a new WD of multicol after these edits have been

CSS Grid

Resolution of percentage row tracks and gutters with indefinite height
  github: https://github.com/w3c/csswg-drafts/issues/5566

  rego: We discussed on Monday, asked for feedback
  rego: Rachel had some comments
  rachelandrew: The reason I'm seeing percentages in use is because
                people are putting a grid component in an older layout
                that uses percentages, because that's how we did
                things with floats or even flexboxes
  rachelandrew: And people generally only cared about columns, then
  rachelandrew: I like staying with the symmetry, but I don't know
                whether authors really expect symmetry. Probably more
                important that Flex and Grid behave similarly, so I'd
                be generally okay with the change.

  astearns: Can you summarize for a resolution?
  rego: resolve percentage of row tracks and gutters of grid with
        indefinite height to auto for tracks and 0 for gutters

  Rossen: Gonna be the shining voice on the hill
  Rossen: Symmetry was an important part of grid and made it what it
  Rossen: We're trying to break that principle here. I object to this
  Rossen: But before I do that I want to go back and understand what
          the current interop is
  Rossen: Because we don't have a 2d layout system that we can have
          precedent with
  Rossen: We can only have interop between the Grid impls themselves
  Rossen: So are we talking about interop with 1d layout systems like
          Block and Flex, or between the UA impls?
  astearns: Is there a consensus across impls yet?
  rego: There are no track interop, there's interop on gutters.
        Firefox would have to change track, but Mats says he wants to
  rego: With regards to Rossen's other issues, I don't know about that.

  astearns: Rossen, do you have a plan to bring people around to your
  Rossen: Not as part of this call.
  Rossen: Issue is, what's the pressing issue? Why do we need to
          resolve now? Take it another way - we've discussed this in
          the past many times, another fix is to get rid of percentage
          in gutters.
  fantasai: Far too late for that
  Rossen: But not too late to break grid, apparently?
  fantasai: Percentages in gutters works just fine between columns,
            and people are using them
  fantasai: This is just about between rows (and in an indef height)
  fantasai: So what we need is interop between browsers. And right now
            we have interop on the behavior you want for gap between
  fantasai: But we don't have interop for sizing tracks
  fantasai: Chrome/webkit have one behavior, the one you wanted iiuc,
            Firefox has another behavior
  fantasai: This is causing problems because we have impls behaving
            differently, so rego wants to fix that.
  fantasai: So either Firefox has to change their behavior for tracks,
            or Chrome/WebKit has to; one of those has to happen, then
            we have interop
  fantasai: And if Chrome/WebKit changes behavior, we should make gaps
            behave the same way as well, which is further change
  fantasai: We could theoretically go either way, but we need at least
            one group of people to switch their behavior.

  florian: One step I didn't follow - if Chrome/WebKit align with
           Firefox, that would mean percentage on gaps and tracks
           don't work the same?
  fantasai: Yeah, which is why the issue says if we do that we should
            also switch the gap behavior, even though we currently
            have gap interop.
  fantasai: I think that percentage gaps between rows are rarely used
            so their behavior isn't a big issue, it's mainly just a
            cleanup step to keep them consistent.
  fantasai: It's really about which behavior we end up with for row
  Rossen: So if current impls impl % row-gaps behavior the same, it's
          essentially the same behavior that they need for row tracks?
  Rossen: I'm curious about the new Chrome Grid rewrite, which
          behavior is currently there
  Rossen: It seems like it's the symmetric one, right?
  rego: I dunno if the new grid impl has this behavior done yet
  <iank> not currently implemented yet afiak.

  Rossen: What I see currently is that Chrome/Firefox/WebKit have same
  rego: For gutters, yes. For tracks Firefox has the different behavior
  rego: Firefox resolves percentage rows to auto, and that's not
        following the spec, it's alone in that behavior
  rego: So if we keep the spec as is, only Firefox has to change.
  rego: This proposal would take Firefox's behavior, so the other
        browsers would change.
  rego: When I did back-compat analysis, there were three pages that
        did better in Firefox and only 1 that did worse
  rego: But Chrome/WebKit aren't getting bugs reported on this,
        despite the lack of interop

  astearns: So sounds like we won't have agreement here
  rego: Should ask the layout people about things
  rego: And Mats
  astearns: Yeah he said yes one way, should see if he's okay with the
            other way
  astearns: So we'll table this for now

CSS Position
  scribe: florian

<dialog> positioning should be describable in CSS
  github: https://github.com/w3c/csswg-drafts/issues/4645

  TabAtkins: There's a discussion in HTML about fixing the dialog
             element to use CSS instead of being a hack
  TabAtkins: They realized that there's a big difference between
  TabAtkins: when it's opened normally vs as a modal
  TabAtkins: It's based purely on which js method you use to open it
  TabAtkins: so we need some way to distinguish, and a pseudo class
             seems most natural
  TabAtkins: The proposal is :modal
  TabAtkins: Seems good to me, but we need to make sure we don't want
             to use it for something else

  leaverou: Feels like defining a pseudo class to work around a
            problem with the API
  leaverou: Seems to me that there should be a modal attribute
  leaverou: Don't see why we need to fix it in css
  <fantasai> +1
  <miriam> +1
  <brandon> +1
  leaverou: Seems weird that you need to use JS, and cannot do it in
            markup, when you can already use the `open` attribute to
            open it in a non-modal way
  emilio: Toggling the attribute is not the same as calling dialog.open
  emilio: It's bad, but that's the way it is
  <emilio> https://github.com/whatwg/html/issues/5802
  iank: It is a strange API, don't want to add more attributes to it
  <leaverou> if the API is messy, maybe it needs more work before we
             add things to CSS for it?

  gregwhitworth: If this is so bad, and is so confusing, why are we
                 duck-taping this?
  iank: Many sites use it, so there's a big compat risk
  iank: We aren't happy with how the modal works today, and we're
        willing to change
  iank: ... to make it describable in css
  iank: If we were doing it from scratch today, we'd do it differently
  smfr: modal go in a magic layer of over the page
  smfr: ...
  iank: ......
  smfr: I would like to define the top layer to be used by other
        elements, it could be used here
  smfr: I suggest to use UA stylesheet rules to also describe the
        top-layer behavior of the modal dialog

  scribe: fantasai

  iank: Broadly speaking, this is what the HTML pull request does
        today. It adds one new pseudo-class, :modal, and removes all
        of the special-case rendering logic
  iank: and replaces it basically with one additional UA stylesheet
  iank: What gives me confidence in this approach is that this is what
        Gecko does today, using an internal pseudo-class
  iank: One thing it doesn't describe, broader issue, is how does the
        "top layer" work.
  iank: Tab has previously wanted to explain how that works somewhere
  iank: This fixes all the special-casing text that was there
        previously, except fixing top-layer
  iank: Moves us significantly closer

  bkardell: There are a few proposals going back to 2014/15 or so
  bkardell: to explain top layer
  bkardell: not in CSS
  bkardell: but there's prior attempts that exist that are worth
            looking at

  fantasai: Going back to Lea's point, why isn't this an attribute on
            the element?
  fantasai: We could do all this in the UA stylesheet keyed off an
            attribute, wouldn't that be more consistent?
  fantasai: Maybe removing/adding modal doesn't do anything because
            it's really the show()/hide() methods and how they sync
            with [open] that's important...
  iank: The open attribute is very special and strange
  iank: Wouldn't want to add anything like that
  emilio: Adding/Removing the open attribute doesn't fire the relevant
  emilio: dialog element is expected to be used via JS APIs
  emilio: already weird that it has this reflection already
  <gregwhitworth> iank, emilio and it wouldn't be web compatible to
                  add those linkages?
  emilio: ...

  astearns: Her proposal is to add a new modal attribute, not to
            re-use open
  leaverou: Can the issues be fixed?
  emilio: Tangential to this
  emilio: Removing [open] doesn't fire the right events and fix the
          behavior currently
  emilio: it's not great
  emilio: Might want to fix it, but it's a separate issue

  gregwhitworth: I agree fixing them is a separate issue, but not
                 separate wrt this discussion
  gregwhitworth: because I like what leaverou is proposing here
  gregwhitworth: In order to make dialog more cohesive, I think we
                 should go back and fix it
  gregwhitworth: Is there a massive web-compat problem with making
                 open do the right thing and fire all the events?

  iank: There's a few other pressures here
  iank: I would be concerned with any compat change around that area.
        Been there for a long while.
  iank: Took us 6 months to do compat analysis just for this change
  iank: and it's a bit pressing
  iank: and with any major compat change, the window closes the longer
        it exists
  iank: Yes, we can potentially fix open and how that work, yes we can
        add modal, but that would take a long time
  <leaverou> it seems to not have shipped in Gecko or WebKit, how
             popular can it be? https://caniuse.com/?search=dialog

  emilio: My other concern with magic attributes that fire events is
  emilio: DETAILS fires an event even when you parse it
  emilio: and we only realized about DETAILS way too late
  iank: I don't think having an attribute API for dialog is a good idea
  iank: I would push back against adding a modal attribute on that
  gregwhitworth: Then, channeling Rossen from Grid, I think we should
                 be going for symmetry
  gregwhitworth: Not fixing open maybe but get rid of it

  astearns: This discussion seems to be opening wider and wider. Maybe
            kick over to Open UI?
  astearns: to discuss pseudo vs. attribute vs. no attribute?
  iank: If we want to get rid of Chrome's special dialog behavior
        here, we can only do this for another few months
  iank: People will be relying on dialog, and will rely on our
        behavior. So would like a decision now.
  iank: At the request of this group and other browser vendors, did a
        lot of compat analysis
  iank: ...

  <leaverou> re: webcompat, <dialog> is used in <0.005% of websites
             (6000 in HTTPArchive):

  emilio: My other bit about why I think modal attribute is not a
          great idea is that it breaks how the JS APIs structure
  emilio: Whether modal pseudo-class applies depends on how you open
          the dialog
  emilio: but you could toggle modal attribute while the dialog is open
  emilio: At the point you can toggle modal, ...
  [minutes clarification: what Emilio is saying here is "If we can
      toggle the modal attribute, then there's no reason for two
      different JS APIs to open the dialog"]
  emilio: I think that [having a sane model for how these attributes
          would behave and fixing the JS API] would be great
  emilio: but fixing dialog positioning is important, would rather not
          get side-tracked

  fantasai: So I agree with iank we should fix the styling issue for
            compat reasons asap
  fantasai: Clearly, it will take a while for a modal attribute -
            maybe that's still a possibility
  fantasai: One option is that we intro a new pseudo class that
            everyone can use while that's debated
  fantasai: Other option is to do one internally the way that FF is
            doing, not exposed to the Web
  fantasai: then we can decide whether to move forward with
            pseudo-class later

  TabAtkins: We seem to have fairly broad implementer agreement that
             they likely don't want to add modal
  TabAtkins: Going back, we could maybe pursue removing open attribute
  TabAtkins: so that's a possibility for us

  leaverou: Adding a modal attribute is just a possibility. Could
            alternately add a value to open
  leaverou: open=modal
  leaverou: But goes back to ???
  leaverou: Introducing HTML elements that can't be used without JS is
            an issue
  leaverou: Shouldn't we fix this generally?
  <leaverou> It sounds like the same arguments apply to <details> as
  <leaverou> Is the direction we want to go to be adding interactive
             HTML elements that can't work without JS?!
  <leaverou> shouldn't these issues be addressed instead of giving up
             on HTML attributes altogether?

  emilio: leaverou, and gregwhitworth, would you be opposed to
          defining a hidden pseudo-class, so we can move forward with
          the styling issue without changing the public API of this?
  emilio: It's nice to expose the pseudo-class from the UA stylesheet
  emilio: but also fine with keeping it internal
  emilio: and address the open/modal attributes separately from this
  <iank> i can live w/ that as well.

  astearns: So proposed solution is to add a hidden :modal
            pseudo-class for now.
  florian: Do we need to define that a hidden pseudo-class exists? Do
           we need to spec anything?
  TabAtkins: no
  emilio: Define in HTML spec using prose instead of a pseudo, but
          that's fine
  astearns: We'd spec as browser-internal thing, and then if it proves
            out, then we write spec text to expose it
  leaverou: Is a hidden pseudo-class simply undocumented or actually
            unusable by authors?
  TabAtkins: Only usable in UA style sheet
  gregwhitworth: I think it's a good compromise.
  gregwhitworth: Deals with compat issue, but leaves the door open to
                 improve the API
  gregwhitworth: Maybe worth noting it somewhere?
  iank: We'll be adding this to the HTML spec , most likely way to
        specify this
  iank: is to define the :modal pseudo-class and define that it's only
        usable in UA stylesheet
  iank: maybe call it :-internal-modal
  <TabAtkins> Yes, this is the correct way to do it

  RESOLVED: Add a hidden pseudo-class for this purpose, in order to
            solve styling issue while leaving open the possibility of
            HTML improving its API

Logical Properties
  scribe: TabAtkins

Order of inheritance vs. mapping in logical properties
  github: https://github.com/w3c/csswg-drafts/issues/3029

  fantasai: Probably best to look at this diagram at the bottom
  <fantasai> https://github.com/w3c/csswg-drafts/issues/3029#issuecomment-712953765
  fantasai: We've got a set of logical props and physical props
  fantasai: So if we have ltr parent and rtl child
  fantasai: ltr parent has some set of properties on it that give it
            margins on either side
  fantasai: and the child has specified "margin-start: inherit"
  fantasai: So what does that mean
  fantasai: From the parent's left margin (the parent's start) or the
            right margin (the child's start)?
  fantasai: Currently impls map start/end to a physical side on the
            child, using the child's writing mode, then inherit from
            the parent's corresponding physical margin
  fantasai: The other possible behavior, which is possibly better, is
            that the child inherits its start value from the start
            value of the parent
  <myles> <div id="outer" style="padding-left: 20px padding-right:
          30px;" dir="ltr">
  <myles> <div id="inner" style="padding-inline-end: inherit"
  <myles> </div>
  fantasai: Note that by the time we have computed values, which is
            what we inherit, the left&start margins are set to the
            same value, and the right&end are set to the same,
            regardless of how they were specified

  florian: We don't have any property that is logical & inherited
           where this shows up without you explicitly saying
           'inherit', right?
  fantasai: Right, not so far.
  fantasai: But if we did, I suspect we'd want the start margin of the
            child to inherit from the start margin of the parent, not
            from the matching physical side
  fantasai: That's my suspicion, at least
  fremy: That's also my assessment
  fremy: If you wanted to inherit the right margin, you'd have said
         "margin-right". If you say margin-start, you want the start
  fremy: If you had text-indent, you want the text-indent value,
         whether it's ltr or rtl.
  <fantasai> fremy, that's a good example

  myles: We're positive on this change to have the writing mode
         resolved based on the parent, not the child, for inheritance
  myles: Two reasons for this
  myles: fremy gave an argument from the author's perspective
  myles: But I think the user wants it too - if they're reading a book
         where paragraphs have a padding on one side, and one
         paragraph is on a different writing mode, the padding should
         probably flip sides
  myles: Second is that it makes logical props more of a first-class
  myles: This means inheritance doesn't "prefer" physical props, you
         inherit what's specified, so that logical properties are more
         of a first-class citizen
  myles: That's good for the world and authors, but also good for impls
  myles: Right now our code is a little more complicated than it could
         be to make it prefer physical props

  astearns: I'm assuming, r12a, that you're okay with this proposal?
  r12a: Yes, I think I suggested this in the first place, so I'm happy
        with it
  proposed resolution: inheritance of logical properties inherits the
    corresponding logical property on the parent

  emilio: A bit skeptical that this is easier to implement. You only
          store one value in the computed style, a physical one
  emilio: So this breaks some computed-style optimizations
  emilio: When two properties map to one value, you have to choose one
          or the other, and right now impls agree with using the
          physical one, which they store in the style
  emilio: So this means you have to add a pass after applying
          declarations, to know if your writing mode is different, you
          should inherit them differently
  astearns: So you're saying the impl may be more difficult than
            stated, but are you objecting?
  emilio: I think it would be unfortunate, especially given current
          interop, but I don't think I have an objection until I try
          to implement and it's gross
  myles: So you mentioned that we only store one set of values. That's
         true; neither proposal requires us to store multiple values
  emilio: Right, but when you inherit a style you have a copyable part
          of the style which is what inherits
  emilio: All impls separate inherited data and non-inherited
  emilio: So if any of them come from a logical prop, you'll need to
          do the work and inherit it specially with the writing mode
          of the parent
  emilio: So it breaks the simple "pointer bump" impl
  myles: I agree that would be an issue if this was a common thing
  emilio: Right. So I think maybe you're just moving a special case
          from one place to another, but...
  astearns: So, any objections?

  RESOLVED: inheritance of logical properties inherits the
            corresponding logical property on the parent

  <br until=":30">
Received on Wednesday, 4 November 2020 14:52:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:17 UTC