[CSSWG] Minutes Telecon 2021-04-14 [css-scoping] [css-display]

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


  - @scope work will be done in the next level of CSS scoping; miriam
      will be added as an editor

CSS Display

  - RESOLVED: Have display:math behave as mrow and ping a11y to see if
              that's an issue (Issue #5388: math/inline-math (whether
              display:math on a non-MathML context should be more
              inline or block))
  - RESOLVED: We are interested in defining all the math display types
              necessary for MathML layout to not be element-dependent
              (Issue #5866: MathML individual display types)

  - There were three possible paths forward in handling
      <display-legacy> parsing (Issue #5575: Should <display-legacy>
      values be aliased at parse time?):
      1) Alias at parse time
      2) Define the new and old values as 2 independent values with
          same behavior so they always parse differently
      3) Do in between where some APIs return old and some return new
          if you specify new values
  - Most of the debate was between options 1 and 3:
      - Those arguing for option 1 believed it would be the easiest
          for authors to understand.
      - The argument for option 3 is it allows newer APIs to return
          the new values but prevents changing the return of older
          APIs when a new value is used. This would prevent breakage
          when using scripts that do not accept the new values.
  - More data about possible breakage will be added to the issue in
      order to further conversation.


Agenda: https://lists.w3.org/Archives/Public/www-style/2021Apr/0000.html

  Rachel Andrew
  Adam Argyle
  Tab Atkins-Bittner
  David Baron
  Christian Biesinger
  Mike Bremford
  Oriol Brufau
  Tantek Çelik
  Emilio Cobos Álvarez
  Elika Etemad
  Simon Fraser
  Megan Gardner
  Daniel Holbert
  Dael Jackson
  Sanket Joshi
  Brad Kemper
  Jonathan Kew
  Chris Lilley
  Peter Linss
  Alison Maher
  Tess O'Connor
  Morgan Reschenberg
  Florian Rivoal
  Cassondra Roberts
  Jen Simmons
  Alan Stearns
  Miriam Suzanne
  Lea Verou
  Greg Whitworth

Scribe: dael

  astearns: We're a little light but should start
  astearns: Welcome felipeerias, thanks for joining
  astearns: One change to the agenda, scrollbar topics, 6 & 7, will
            postpone to next week
  astearns: Any other changes people would like to suggest?

CSS Scoping

  astearns: Housekeeping- miriam reminded me we had resolved to start
            work on the scoping proposal and to write spec text
  astearns: Didn't decide where it should go. New draft? In a present
            draft? Thoughts?
  fantasai: @scope?
  TabAtkins: Yeah. I think in scoping spec
  fantasai: Or cascade 6. Might fit better there
  TabAtkins: I don't think I agree. It's not directly about cascade
  fantasai: About specificity and which elements something applies to.
            People think in context of cascade and not in
            terms...scoping is all about shadow dom
  TabAtkins: Didn't used to be. I think confusing if scope rule not in
             scoping spec
  fantasai: Fair. Then scoping next level
  TabAtkins: Fine with it in current level. Nothing pressing to
             scoping pass cr
  fantasai: I'm not. I think what's in scoping is a lot more solid.
            Want a line between super experimental
  astearns: Does scoping need update anyway?
  fantasai: Yep. And it's mainly shadow dom which should be in cr
  astearns: Argument to put in current so we have better chance to
  fantasai: @scope rule should be newer draft. Current level should go
            to CR soon, and if there's anything blocking that we
            should be working on it. We can always pub a FPWD of
            anything we want
  astearns: Proposal is add miriam as editor to next level of CSS
            Scoping and have them work up spec text in an ED which
            will become FPWD
  astearns: Sound good?
  miriam: Sounds great

CSS Display

math/inline-math (whether display:math on a non-MathML context should
    be more inline or block)
  github: https://github.com/w3c/csswg-drafts/issues/5385

  astearns: Has been waiting on math people to weigh in. afaict all we
            need to deal with is display:math on non-MathML
  fantasai: Decided it should be inline
  fantasai: Issue from Mozilla is having it behave different if in
            MathML context or not is not great. Not difficult to impl
            but more tricky because context sensitive. Not necessary
            for any reason.
  fantasai: Mats asked for it to behave like mrow regardless of if on
            math element or not
  emilio: And discussion of if need >1. Supposed to be magic depending
          on element. If not might need more than one
  florian: Assume behavior of making it an math which doesn't contain
           math is well defined?
  iank: Yeah, triggers mrow layout algorithm
  iank: In simple terms layout things on a row and I think baseline
        align all
  iank: I think MathML defines internal types fine. Sometimes mrow if
        it has more children than expected.
  iank: I think not having talked to the MathML people I think I am
        supportive of adding each display type as FF folks suggest.
        Seems consistent with everything else. Would like to hear
        other thoughts.
  iank: Also works with polyfill story
  fantasai: Two issues. One is display:math outside mathML is mrow
            behavior. Second is add more display types per mathML

  plinss: I think we have precedent to just rely on display property.
          I would like to see all math in layout not rely on semantics
  plinss: Have it default style
  iank: If you put display:grid on mrow it has an internal layout type
        of grid algorithm. Have consistency there
  florian: Do we need to check with a11y people, a11y tree, to see if
           the way the build right now will break? My understanding is
           for some things they build from box rather than element
           tree. We should check. I don't know
  florian: We've been accused of being careless about this in the past
  florian: I hope it doesn't. In theory I support plinss
  plinss: Agree worth investigating. Might justify a bug on AT. We can
          evaluate when we find out answers

  astearns: Sounding like consensus to have display:math always behave
            as mrow
  fantasai: Outside MathML context and unless otherwise specified
  astearns: Proposal: have display:math behave as mrow and ping a11y
            to see if that's an issue

  RESOLVED: Have display:math behave as mrow and ping a11y to see if
            that's an issue

  astearns: Separate issue for other math display types?
  fantasai: I believe there is

MathML individual display types
  github: https://github.com/w3c/csswg-drafts/issues/5866

  astearns: Is there consensus to resolve that now or postpone to
            future meeting?
  iank: I would like to ask people more familiar with MathML
  iank: Does seem like consensus in this group
  astearns: Dim recollection is mathML asked for the display types and
            Igalia folks thought it too many
  iank: My recollection too.
  astearns: Math WG just spun up. Maybe we can ping them on this
  astearns: I'll take an action to send this along

  plinss: I'm in favor of more display types. Maybe not 100, but 2 or
          3 with other properties to control sub-behaviors. Early
          design philosophy in Gecko. I don't want layout and design
          tied to semantics. I want it all in css
  iank: Quite probably quite a few, 5 or 6. Makes sense because
        distinct layout algorithms.

  <bradk> These would be display-inside?
  <fantasai> bradk, some of them might be more like internal table
             display types, have to check
  <bradk> @fantasai I see. Thanks

  florian: Are these things only useful in context of math? Or are
           they potentially useful in general? In favor either way
  plinss: If we give tools people will have create ways to use them.
          People will find fun ways to display content we didn't dream

  iank: mtable has display:table and display:tablecell so this
        normalizes to that behavior.
  iank: display:mrow there might be. We should give that power
  <florian> +1
  emilio: Agree. If we want to style math with css using display we
          have to do all or none. SVG does no such thing, it's its own
          box type. I like the direction of exposing all MathML
          display types
  astearns: This will go into issue. I'll ping the new math WG and
            come back

  fantasai: I'd like to propose we take a resolution. csswg believes
            this is the right direction to go and we propose that to
            math wg. Useful to capture we're on the same page
  astearns: Unless anybody has reservations?
  astearns: Proposal: We are interested in defining all the math
            display types necessary for MathML layout
  astearns: as individual display types or separate properties in css
            that let us control the variations

  RESOLVED: We are interested in defining all the math display types
            necessary for MathML layout to not be element-dependent

Discussion about the block cross-folding screen
  github: https://github.com/w3c/csswg-drafts/issues/5882

  fantasai: I had brought this up. It looks like need discussion. I
            don't have a proposal. I think I proposed for F2F
  astearns: Yeah, even for virtual F2F we need something to go on
  astearns: By my reading this is about what to do with text elements
            since we do have split and mask capabilities for images
  fantasai: No, screen folding. Different ways to handle the effect.
            One is where you move the boxes apart. Another is mask so
            stuff appears. Need to expose to author so they don't put
            content inside the fold
  fantasai: If impl creates a gap and cutting content, need no content
            in gap. When there's masking there is content in the gap
            and author needs to know. Need to make adaptable so author
            can layout. Means conveying information.
  astearns: I don't see MS people on call who are working on this stuff
  astearns: Maybe we kick back to issue
  fantasai: Yeah, needs a proposal

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

  fantasai: Question of if new display types, we have things like
            inline-block. Now that we have separate keywords we have
            inline-display-flow-root is same as inline-block. Defined
            as same. When you do getComputedStyle wanted to return
            inline-block because shortest serialization
  fantasai: Should this be handled at parse time. I think no, author
            should get what they specify. I think rachelandrew and
            others have had value in talking as outer and inner
            display type. If we merge in APIs harder to conceptualize
  emilio: Much easier to do at parse time for impl. Don't feel super
          strong. Seems unfortunate display won't compute as
          specified, but I guess okay
  oriol: While FF does at specify value time, chromium does this for
         combinations and they are considered to be different. It
         preserves specified keywords

  florian: emilio, does it make it awkward for impl long term
           complexity or just when you write
  emilio: Probably fine. Once it computes it's okay. oriol your
          comment is slightly different. inline-math should be just
  fantasai: Agree with emilio that's a different concern
  oriol: Then it should be different if eq possibility one is legacy
         css2 and other is new?
  emilio: That's why I prefer just alias at parse time. Each has a
          serialization and you're done
  emilio: A bit unfortunate that you say inline-flow-root and get back
          inline-block. But that's what you get in the computed styles
  fantasai: I propose we continue to define newer values as computing
            to legacy keywords but not process any earlier
  emilio: That's more complicated. New thing to old thing. Ideally
          want other way around
  emilio: So you just worry about inner and outer display value
  fantasai: You want to compute to the new ones but resolved is older?
  emilio: Serialize as the [missed].
  fantasai: Reasonable that resolved value for getComputedStyle is
            legacy. Need that for compat.
  emilio: That does change the behavior of the Houdini APIs.
  emilio: We probably don't mind
  emilio: If we want computed style map to return the new thing and
          then resolve into the keyword is the way to go
  emilio: Sooner you alias the better
  fantasai: From author PoV system is easier to understand with 2
            value keyword. If it's just a parse time alias that's
            helpful but could get a bit confusing. If we can get away
            with it being 2 keyword values in Houdini that's reasonable
  emilio: Then what does specified style do? 3 values we expose; spec,
          computed, resolved
  emilio: What Gecko impl is computed and resolved are same, serialize
  emilio: Moving the legacy thing to computational stage...that's okay
          but we also change behavior of Houdini API
  emilio: More work to basically keep the new values in the specified
          style, return old in computed, return new in Houdini. You're
          uncomputing what you computed. Fine. A bit more annoying
  fantasai: TabAtkins or rachelandrew?
  emilio: If we can get away with keeping parse time alias. Serialize
          to legacy. I don't know
  emilio: Prefer if each combo had single serialization. Only
          getComputedStyle exposes legacy. But that's breaking change
          for specified.
  emilio: Maybe only Houdini exposes new
  TabAtkins: No opinion either way

  astearns: Other opinions?
  rachelandrew: I think as fantasai said from author PoV the two
                values are understandable and confusing if you get
                back something other than expected.
  rachelandrew: Prefer we keep the 2 value all the way through if
                that's possible
  emilio: That's another proposal. May be okay. But inline-block and
          inline-flow-root compute to different thigns but behave same
  iank: I feel like serialization should go to legacy if they can
  iank: Worried about the web compat here
  emilio: Right. If you keep as specified it's nice if you're in
          control. But you prevent adoption. If you use jquery and it
          expects a return of inline-block and it starts returning
          inline-flow-root because you used it in your style sheet,
          you can't use it because scripts break
  fantasai: That's an argument to not introduce new display types
  fantasai: It's a new display type with same behavior. If your
            scripts break it's a problem with your script
  emilio: Perhaps. But you cannot say in our css codebase we'll only
          use new display types because they break stuff.
  emilio: I don't have super strong opinion. Can implement whatever.
          Least complex is parse time
  <jensimmons> I'm a bit lost. I'd love for us to compute to the new
               syntax. Get the world of Authors to move on.
  iank: I think I'm with emilio. From maintenance PoV and being a
        previous webdev this would be somewhat concerning. You don't
        always controls what people are setting display types to.

  astearns: Resolve these return most backwards compat serialization
            except houdini and houdini has 2 value?
  iank: You mean typedOM API?
  astearns: Yep
  emilio: Should be fine
  emilio: Should also be fine to match computed style either way. As
          long as same value serializes to the same thing it's fine.
          Backwards compat trumps. Up to chrome if they want existing
          users of inline-grid to have breaking change

  jensimmons: I understand if there's a compat problem, but I would
              love to see us for sake of authors compute and return
              new syntax. I'd love to be able to teach new syntax.
              Thinking about where will we be 5 years from now. Having
              to continually teach the old syntax and why? Always a
              fan of clear the decks and move forward
  jensimmons: I think new display values with 2 parts are so elegant,
              don't want the old to stick around
  astearns: Which is why I want new to return the 2 value. But we
            serialize to least backwards compat for a reason

  fantasai: Could decide this is new independent value. Has same
            behavior but don't compute to each other. We've got 3
            possible options:
  fantasai: 1) Alias at parse time.
  fantasai: 2) 2 independent values with same behavior
  fantasai: 3) Do in between where some APIs return old and some
            return new if you specify new
  fantasai: Seems first 2 are most elegant. For sake of authors I vote
            1 with jensimmons and rachelandrew
  <miriam> +1
  emilio: I'm okay with saying that. Basically question is how much
          work does adopting this become. Script authors need to care
          about both values. That's great for authors of css but not
          great for authors of script
  iank: With emilio. I don't think this is great to go down for script
        dev that queries style
  astearns: Yeah, if we go with independent values it could slow
            adoption because not compat
  fantasai: I'm not convinced it would be compat problem
  iank: From what I've seen on getComputedStyle and display I think
        there's a significant chance of people accidentally breaking
        and not realizing it
  astearns: Option 3 would not be alias at parse time because need to
            preserve values for TypedOM?
  <bradk> I’m also leaning towards option 3
  fantasai: Can't do it at parse. Variations on option 3. One would be
            2 independent values but have getComputedStyle do an extra
            computation to return old version. We do all kinds of
            extra lift for getComputedStyle.

  astearns: Do people have objections to the version 3?
  fremy: Small question based on minutes. Why can't we do option 3 at
         parse time? I don't understand. They're exactly the same.
         inline-block will always be same 2 values in Houdini.
  fremy: I have one serialization for getComputedStyle. You always
         have 2 value in Houdini. Never get 2
  emilio: That how we impl it probably. Have same value but serialize
          differently for TypedOM
  fantasai: If you put something in specified style do you get 2 value
            or 1?
  emilio: Legacy serialization
  fantasai: .style.display do I get inline-block?
  emilio: You would get inline-block
  fantasai: What's point of having weird in typed OM?
  emilio: It's the one place where we can not go to legacy
  emilio: You have issue of script authors having to care about both
          values if you don't
  fantasai: But if you do inline-list-item they need to handle. We
            keep adding display values
  fantasai: We add them all the time. If script doesn't handle new you
            have to tell the person that my script only handles the
            old ones. If you're putting limits on script you have to
            negotiate with user. I don't see why this is a particular
  emilio: There's a lot of code that won't update
  fantasai: Sure, and when using them don't use new things
  emilio: Problem is, people are not going to be able to use new
          display values. Moving backwards compat from browser to
          author. That's fine
  florian: Seems we have same problem in many areas. Script for colors
           there's may ways to spec red. They all look the same. But
           we don't serialize LAB space back
  emilio: Take all hsl and serialize as rgb for that reason
  <TabAtkins> Note that we *only* serialize the older color forms to
              rgb(). Newer forms, even ones that are absolutely
              equivalent to rgb(), stay as they are.

  astearns: Not hearing consensus
  astearns: Does anyone want to try coming up with something we agree
  emilio: Won't object if we serialize the new thing, but I don't
          think it's best
  astearns: iank you had concerns?
  iank: I don't think it's the way we should go
  astearns: And others don't think we should be cutting off new
            display types at serialization time
  astearns: Any way we can get evidence of compat problem?

  fantasai: TabAtkins points out [reads IRC] so to bring florian's
            question back, why do you think this applies to display
            and not color
  TabAtkins: We have new color forms that are equivalent to rgb but
             don't serialize. We color turn color into rgb but want to
             keep in same form. Only older turn into rgb.
  emilio: I have same concern. It's common for script to just parse
          rgba output
  iank: With color example there are scripts that will add a11y
        dynamically and insert a color. I had similar concerns there
  iank: I think less bad because breakage is more minor in that case.
        There's a lot of scripts that will check if display is
        inline-block do something
  fremy: Talking about inline-style or getComputedStyle? I think
         getComputedStyle everything is rgb serialization
  chris: Thing about rgba is the spec says regardless of how you spec,
         rgb or rgba, rgb can get an alpha, but if it's 1 it's thrown
         out. Only reported if not 1
  chris: Clarifying
  <chris> Serialization of rgb() or rgba() only reports non-unity alpha
  leaverou: Comment about scripts that parse rgba, that ship sailed.
            Not every color can be rgba so scripts need to support
            other forms. Shouldn't be a concern. With typed OM
            hopefully devs wouldn't parse colors manually anymore
  astearns: I think color discussion is a little far afield. Scripts
            dealing with display values. I would hope scripts with
            display values would have an i don't know what this is
  <chris> Sure, people seemed to be arguing by analogy though so I
          wanted to be sure the analogy was accurate

  florian: I think we need data for compat argument. If we show up we
           can say doing serialization might break things. In theory
           all sorts of things could break. Do they?
  fremy: We have a rule of serializing to old if we can, I don't think
         we need to prove every instance that there is web compat, we
         can safely assume there is and not break things for the sake
         of it.
  florian: At computed time, yes. Not at specified
  emilio: Isn't that general serialization rule?
  florian: I don't think so. Am I wrong?
  fantasai: When defined to be equal, we do. If defined to equivalent.
            It will serialize to shortest. Debate is do we define to
            be same at computed or specified value time.
  fantasai: One proposal is they're distinct and different. We do that
            in other places. We have places in css with same behavior
            but serialize independent
  iank: Quick search, jquery uses this. Likely some cases will break
  astearns: Can you put references in issue iank?
  iank: Not exhaustive. Just a litmus test
  astearns: Nearly out of time. I suggest iank puts his in the issue.
            Others search and add to the issue. We can see what would
            break and come back at a later date
  astearns: Sound alright?

  astearns: Thanks everyone for calling in and we'll talk next week

Received on Wednesday, 14 April 2021 23:42:01 UTC