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

[CSSWG] Minutes TPAC F2F 2020-10-19 Part I: Republishing tasks, CSS Grid, Snapshot 2020, CSS Sizing 4, Revisiting standardization of the `zoom` property [css-sizing-4] [conditional-3] [highlight-api] [css-grid] [snapshot-2020] [css-sizing]

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 29 Oct 2020 19:23:37 -0400
Message-ID: <CADhPm3vTqY-4pMCFA519zJtA8-n5ey=oM_xPCuCTXQYeH3Q4uw@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.
=========================================


Republishing tasks
------------------

  - New meta-issue for tracking publications until they're published:
      https://github.com/w3c/csswg-drafts/issues/5613
  - fantasai has made a report on which specs are out of date
      http://fantasai.inkedblade.net/style/reports/csswg-status-radar/
  - RESOLVED: Publish WD of sizing-4
  - RESOLVED: Publish CRD of conditional-3
  - RESOLVED: Publish FPWD of highlight-api

CSS Grid
--------

  - RESOLVED: Accept aspect-ratio error changes in css-grid-1 (Issue
              #5615: Fix aspect-ratio errors in css-grid-1)
  - The proposed change in issue #5566 (Resolution of percentage row
      tracks and gutters with indefinite height) would go against the
      guiding principle to keep columns and rows (as well as their
      track) symmetrical. The group wanted to discuss with a few more
      people to determine if there's strong author demand to deviate
      from that principle in this case.
  - RESOLVED: publish a CRD for grid-1
  - RESOLVED: publish a CRD for grid-2

Snapshot 2020
-------------

  - RESOLVED: Add aspect-ratio to the "clear for shipping despite not
              being in CR" section of snapshot-2020 (Issue #5598:
              Clear 'aspect-ratio' for shipping)

CSS Sizing 4
------------

  - RESOLVED: Apply aspect ratio pres hint to img, <input type=image>,
              video, canvas (Issue #5608: How widely should HTML's
              'aspect-ratio' presentational attribute be applied?)

Revisiting standardization of the `zoom` property
-------------------------------------------------

  - The group preferred not to create a specification for the zoom
      property as it exists now, though if it is required for
      comparability they're willing. However, there was interest in
      working on a new replacement for the zoom property that behaves
      in more expected ways. (Issue #5623)

===== FULL MINUTES BELOW ======

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

Present:
  Rossen Atanassov, Microsoft
  Tab Atkins-Bittner, Google
  L. David Baron, Invited Expert
  Christian Biesinger, Google
  Mike Bremford, BFO
  Oriol Brufau, Igalia
  Tantek Çelik, Mozilla
  Emilio Cobos, Mozilla
  James Craig, Apple
  Elika Etemad, Invited Expert
  Javier Fernandez, Igalia
  Brandon Ferrua, Salesforce
  Megan Gardner, Apple
  Brian Kardell, Igalia
  Philippe Le Hégaret, W3C
  Daniel Libby, Microsoft
  Chris Lilley, W3C
  Ting-Yu Lin, Mozilla
  Peter Linss, Invited Expert
  Alison Maher, Microsoft
  Myles C. Maxfield, Apple Inc.
  Cameron McCormack, Mozilla
  Theresa (Tess) O'Connor, Apple
  Morgan Reschenberg, Mozilla
  Manuel Rego, Igalia
  François REMY, Invited Expert
  Florian Rivoal, Invited Expert
  Devin Rousso, Apple
  Jen Simmons, Apple
  Alan Stearns, Adobe
  Miriam Suzanne, Invited Expert
  Lea Verou, Invited Expert

Scribe: heycam

Republishing tasks
==================

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

  fantasai: We are super behind on keeping ourselves up to date on TR
            pages
  fantasai: as of Sep 13 the Process has been updated, so no longer
            any reason to be out of date
  fantasai: I created this issue to make sure we get around to
            actually making the publications we resolve on
  fantasai: Houdini is mostly not published, for several years
  fantasai: open request for Sizing
  fantasai: Any other people who want to request publication, agenda+
            and add to this issue
  fantasai: then we can use this issue to track whether it got
            published

  fantasai: At astearns's request, I made an "estimated publication
            badness chart" covering all our specs
  <fantasai> http://fantasai.inkedblade.net/style/reports/csswg-status-radar/
  fantasai: (If you want to edit this file it's in a GitHub repo)

  fantasai: There are lots of specs that need publication!
  fantasai: It's causing confusion for other groups, like a11y
  fantasai: Publishing is easy. If you're confused on how to do it,
            ask in IRC or make ChrisL/xfq do it for you.

  astearns: Based on fantasai's analysis of things that haven't been
            updated on TR, I've started reaching out to editors to see
            if we can get the ones that are (in some cases) nearly a
            decade out of date published

  fantasai: The one thing without resolution that needs it is sizing-4
  <fantasai> https://lists.w3.org/Archives/Member/w3c-css-wg/2020OctDec/0015.html
  fantasai: That's a WD

  RESOLVED: Publish sizing-4

  fantasai: cascade-3 is blocked on various Proposed Rec things

  chris: conditional-3 has the oldest one I think, 2013
  chris: it's getting there, should we get an updated CR on that?
  fantasai: CRD? we can do that

  fantasai: Process 2020 has two types of CR publications
  fantasai: The official snapshot, that goes through approvals etc.
            Then there's Candidate Rec Draft, which updates similar
            to a WD, automatic via Echidna with no approvals.
  fantasai: A CRD has to represent WG consensus, as much as a CR.

  Rossen: Any delta between what would be in the CRD and what is
          currently in broad horizontal review?
  fantasai: Yes. There a bunch of changes since the last CR.
  Rossen: Do we have to go and review all the changes?
  fantasai: No, purpose of CRD is so you don't have to do that, or the
            DoC.
  fantasai: Have to list changes since the last CR, and have WG
            consensus on material different from the last CR
  florian: Goal is equivalent in quality to CR, but less process heavy
  chris: Just need a resolution, if nobody objects, it's WG consensus

  RESOLVED: publish CRD of conditional-3

  florian: Back when Tess was an editor, we were going to have an
           event handler section in highlight-api
  florian: The rest of the spec is not final, but it's FPWD-ish
  florian: Proposing we publish it as is
  florian: There's a placeholder in the ToC for event handling
  florian: but having live material live off /TR for years is not
           good, so let's publish it
  Rossen: who are the authors?
  <hober> +1
  hober: editors will be Megan, Florian, Sanket
  florian: I will fill that in, then work with Megan/Sanket to get
           issues resolved after publishing

  RESOLVED: publish highlight-api as FPWD

  fantasai: Just want to note that env and scroll-animations also have
            no FPWD
  Rossen: As Alan pings authors, we'll follow up with the env folks

CSS Grid
========

Fix aspect-ratio errors in css-grid-1
-------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5615

  fantasai: There was a commit which attempted to clarify interaction
            of aspect-ratio and grid item sizing
  fantasai: that introduced an error into the CR, which I fixed
  fantasai: I'd like to verify the fix with the WG
  fantasai: and republish grid-1 and grid-2 with the correction
  fantasai: as a CRD

  Rossen: is there a commit diff we should be looking at?
  Rossen: or just that PR that you linked there
  <fantasai> https://drafts.csswg.org/css-grid-1/#grid-item-sizing
  fantasai: commit I linked, that shows the fix to the problem, but
            the resulting text needs to be reviewed
  Rossen: We resolved for this change that will be different from
          flexbox, right?
  fantasai: This one wasn't supposed to be a change, just a
            clarification
  fantasai: can grab a diff against the older version
  <fantasai> https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2FTR%2F2017%2FCR-css-grid-1-20171214%2F&doc2=https%3A%2F%2Fdrafts.csswg.org%2Fcss-grid-1%2F#grid-item-sizing
  <fantasai> https://github.com/w3c/csswg-drafts/commit/ee91993c92ba7d119a6b89c64667094511d67272

  Rossen: any comments or objections to accept this diff?
  oriol: I think it's a good change, because there was a sentence
         saying that for stretch the rules would be modified to follow
         aspect-ratio. but impls were not doing that
  oriol: so if you have stretch, aspect-ratio is not taken into account
  oriol: so I think removing this sentence is good
  <florian> I was hoping oriol had reviewed this. Given that he has, I
            feel confident it's fine :)

  RESOLVED: accept aspect-ratio error changes in css-grid-1

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

  rego: This is an old discussion
  rego: This is about how we resolve percentage row tracks/gutters
  rego: with a minimum height
  rego: We resolve to intrinsic height that we compute
  rego: That causes overflow in many cases
  rego: and makes it more complicated, and no interop
  rego: In Firefox it is doing the old behavior. percentage tracks
        resolve to auto
  rego: I was proposing here to change again, and get interop in this
        case
  rego: and then also change how gutters work, which Firefox does do
  rego: We have been discussing for a long time, checking compat
        issues, we already had a use counter for percentage tracks,
        also for gutters
  rego: checking the results, grid tracks where 0.03% of page views
  rego: That's going down, to not count 1 row with 100%
  rego: We analyzed the pages from that, only 1 broke
  rego: With gutters, the usage is very low. 0.003% of page views
  rego: 40 pages, only 1 broke
  rego: So this change will align us with flexbox, and get interop in
        the tracks part that we don't have right now

  Rossen: We did discuss this in the past, in the context of flexbox,
          grid and gutters. Every time the discussion goes around and
          comes back to one of the main points/principles for grid
  Rossen: which is to hold the behavior of rows and columns, and row
          gutters / column gutters, to be symmetric
  Rossen: Strong desire for this
  Rossen: Strong pushback against things going against this principle
  Rossen: Don't want to re-litigate that
  Rossen: so why should we change it for this one?
  rego: It will break that principle. The reasons we should change are
        in the top of the issue
  rego: It usually causes overflow when people use it
  rego: It requires worse perf in track sizing
  rego: and we don't have interop
  rego: but I agree it will break that principle
  Rossen: Would like to hear from more people. Personal preference to
          hold on to that principle
  Rossen: It's an easy slippery slope to get on
  Rossen: Yes there are expectations when they compare other 1D layout
          systems like block and flexbox.
  Rossen: With this particular one, I think we should hold a high bar
          in keeping that principle going forward

  jensimmons: I haven't heard much about this kind of stuff at all
  jensimmons: Feel like authors haven't quite grasped grid fully yet
  jensimmons: Lack of compat is a problem, would like interop asap,
              even if the behavior feels a bit buggy
  jensimmons: and stop using percents for gutters anyway
  jensimmons: so in some ways I don't really care about this, since
              they shouldn't be using percentages
  Rossen: I think the data agrees with your observations, few cases in
          the wild
  Rossen: doesn't feel like it's strongly motivated
  miriam: That's my experience as well

  fantasai: I think it'd be good to hear from mats and rachel
  fantasai: if nobody else had anything else to add, could defer to
            hear from them

  Further discussion deferred to hear from Mats and Rachel.

Publication
-----------

  Rossen: in the meantime we can publish grid-1 and grid-2 as CRDs
  Rossen: any objections to publishing a CRD for grid-1?

  RESOLVED: publish a CRD for grid-1

  Rossen: and for grid-2?

  RESOLVED: publish a CRD for grid-2

Snapshot 2020
=============

Clear 'aspect-ratio' for shipping
---------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5598

  fantasai: Do we want to add aspect-ratio to the snapshot?
  fantasai: Suitable for shipping in impls yet?
  cbiesinger: The intent to ship has been approved
  cbiesinger: so we are planning to ship in the next version
  heycam: We are also making good progress, will be ready in the
          coming months
  fantasai: This wouldn't be CR, needs more work before that
  fantasai: We add it to snapshot-2020 in the "not CR but cleared for
            shipping" section
  <fantasai> Discussion is about adding to
             https://www.w3.org/TR/CSS/#CR-exceptions

  heycam: Issue status?
  fantasai: Think most have been resolved
  fantasai: Tab and I did a triage recently
  Rossen: Will we reach CR if we go through these issues?
  fantasai: sizing-4 is a WD

  RESOLVED: add aspect-ratio to the "clear for shipping despite not
            being in CR" section of snapshot-2020

CSS Sizing 4
============

How widely should HTML's 'aspect-ratio' mapping be applied?
-----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5608

  TabAtkins: Emilio brought up in the HTML spec that it would make
             sense to make the aspect-ratio attribute integration from
             width/height setting intrinsic size, to being them
             setting an intrinsic ratio pres hint via 'aspect-ratio'
  TabAtkins: I wrote the spec text for it
  TabAtkins: Domenic asked which elements it should apply to
  TabAtkins: Previous spec text applied to img specifically
  TabAtkins: (side discussion about <picture>)
  TabAtkins: but there are other elements that we do use width/height
  TabAtkins: video, possibly embed/object
  TabAtkins: canvas, <input type=image>
  TabAtkins: First question, does it make sense to widen the spec text
             from the previous img/picture only, and if so, which
             elements should we expand it to?
  TabAtkins: I think we should, and go with fantasai's list
  [ fantasai's list excludes embed/object ]
  TabAtkins: embed/object applying an intrinsic ratio doesn't always
             apply)

  jensimmons: To remind everyone, this is about improving the
              experience for users while the page is loading
  jensimmons: The intention is that it has no affect on layout after
              these assets have loaded
  jensimmons: Once an image has loaded, it should get the same layout
              it would've had
  jensimmons: Should work the same way for video
  jensimmons: they do have an intrinsic aspect ratio
  jensimmons: Should apply to any HTML element where this is true
  jensimmons: So does not apply to a typical iframe, since they don't
              have intrinsic aspect ratio
  jensimmons: It's also true that embed/object can sometimes have an
              intrinsic aspect ratio
  jensimmons: but if there are complications it's not critical

  emilio: I agree with this
  emilio: When we initially implemented this for img, we still didn't
          have the compat requirements
  emilio: I think this is pretty reasonable

  florian: Makes a lot of sense to me
  florian: Given the text you're replacing didn't apply to these
           things, is the compat story different for img and the
           things that are like it?
  florian: Or it all falls into the same bucket?
  emilio: When we did it for img, we override the aspect ratio, but
          people put wrong values
  emilio: the auto value is like a low priority hint
  emilio: I think the compat impact is going to be extremely low
  florian: canvas loads a bit differently from these other things
  florian: you don't load an external file
  TabAtkins: intrinsic size is based on the backing store
  florian: Script controlled? and so if the script hasn't run yet it's
           a similar situation?
  myles: It's based on the attributes on the element
  TabAtkins: you're right
  TabAtkins: but it would still be consistent with images
  florian: Less useful but still doesn't hurt

  Rossen: In the case of picture/srcset, does it come from the first
          image?
  emilio: I think it would be the actual <img> inside the picture
  emilio: but there's another PR to make width/height apply to src
  emilio: There's no precedent for other elements' attributes
          affecting intrinsics
  TabAtkins: But that's being discussed elsewhere

  <TabAtkins> img, input type=image, video, canvas

  RESOLVED: apply aspect ratio pres hint to img, <input type=image>,
            video, canvas

  <br dur=10min> (back at :10 after your hour)

Revisiting standardization of the `zoom` property
=================================================
  scribe: myles
  <astearns> github: https://github.com/w3c/csswg-drafts/issues/5623

  dlibby: Last time this was discussed as 5 years ago. The zoom
          property came from IE. It was picked up by webkit / blink.
  dlibby: It's a bit hacky tbh in the way it's implemented. multiplies
          the used values by a factor. Comes with a factor of bugs.
          Gecko doesn't implement it, so they've been running into
          compat issues
  dlibby: There have been attempts to implement in terms of transform
          / transform-origin. It fixed some content, but didn't fix
          everything
  dlibby: We should try to standardize this. What appetite is there
          for documenting existing bugs / odd behavior vs trying to
          fix them.
  dlibby: Broader context: From MS, there are a few properties that
          have been looking at zoom as a low-cost way of zooming in on
          a webkit. They use it and get good results, and haven't had
          to re-architect their app / change their layout structure.
  dlibby: Others' thoughts?

  emilio: I made my comment in the issue. I would not be a fan of
          standardizing the current behavior. It's extremely wrong.
  emilio: There's a bunch of quirks that exist for compat. I only
          found out by chance. Like zoom affecting intrinsic sizing of
          some elements but not others, or zoom:0 = zoom:1, because
          why not. It feels to me like the property is really odd b/c
          it's a property that affects the computed style of pretty
          much all lengths, including font-relative, which is terrible.
  emilio: It's one of the biggest compat issues we have to fix. But we
          might break more content than we fix. If it was me, I would
          try to remove it from Chromium. But that's not a big
          [missed]. That may require Chromium implementing
          -moz-transform, which isn't great. it's a mess. I would be
          skeptical standardizing this as-is right now.

  astearns: I don't think there would be much utility in documenting
            the existing weirdness in CSS-space. I would be much more
            interested if someone had a solution they wanted to have
            implementations move toward. Something that was
            interoperable and didn't have quirks

  florian: I agree the current thing is messy, but it's used. If you
           want to write a browser that works with the web, you need
           this thing. That's what the usage data tells us. It's being
           used, it should be known how it works.
  florian: I am not sure it's only being used for its primary purpose.
           Maybe it's used *for* its quirks. Maybe it depends on its
           quirks. I believe they no longer care strongly about this,
           but Bloomberg used it where they could have used transforms,
           because font-rendering was different, and this is a quirk,
           that was desired by Bloomberg. If we can't get rid of it,
           we should write down what it is

  emilio: I would argue that you don't necessarily need to implement
          zoom to render the web. There's content that either depends
          on .... I think it would be interesting to disable the
          property in Chrome and see what breaks and what works in
          Firefox. The 2 solutions are prefixed -moz-transform + no
          zoom, or zoom + no -moz-transform
  emilio: You don't want double-scaling which sucks
  florian: Is -moz-transform cleaner?
  emilio: -moz-transform is an alias to transform.
  fantasai: Would Chrome be able to remove zoom and add -moz-transform
            as an alias of transform to handle compat?
  dlibby: That might be worth exploring. The behavior is not identical
          between a scale transform and a zoom. To pursue something
          that would provide similar functionality sounds like there
          might be some interest in doing something like that from the
          group? Or at least no clear opposition? But that's an
          interesting experiment in Chromium - understanding the
          impact of turning off zoom.
  dlibby: I don't know if there's precedence, though. I'd have to
          consult with others. The idea is interesting.
  florian: There is precedence for setting in stone things with odd
           names with vendors in them. Maybe not -moz- specifically
           though.
  fantasai: It would be better for the web if we did that because it's
            one less quirky weird unspecified thing that needs to be
            embedded in the platform, if it's just an alias. If we can
            have a zoom feature that does what people want, it would
            be a good way forward. If legacy zoom can't be removed, we
            have to spec it.

  fremy: One question: The zoom property can, if you have grid + some
         elements, the zoom property, zoom:200%, it not only scales
         the element but also changes the size of the tracks.
  florian: It is layout-affecting transforms.
  fremy: You can't achieve that with transform
  florian: Layout-affecting zoom is useful and we should have a
           feature that does that. However, the way that legacy zoom
           affects layout is weird. Can we remove the weird one, or do
           we have to spec it
  fremy: Can we redefine how zoom works that's sane?
  fremy: Can we look at this? What is the minimum amount of things
         that makes zoom useful and sane, but are more powerful than
         transforms.
  fremy: If you don't know what all the tricks are, it's scary to
         implement, but if we all agree on something similar and that
         works, it's a safer bet than something nobody understands
  florian: If we could do this, that would be good. I believe we had
           looked and concluded we couldn't change it. It's strange,
           but the sites we looked at relied on its weirdness
  astearns: right.

  jensimmons: For a long time I've thought one of the things that was
              not exciting about transforms and motion-path is none of
              them affect sizing / calculation, especially for
              calculating flow. If you make something bigger or move
              it over, it doesn't affect anything around it. It's an
              interesting space. Zoom is one of the qualities we might
              want to look at about making transforms affect sizing
              and layout. I hate when the answer to a small problem is
              "let's make something incredibly complicated" but that
              feels like the right direction.
  jensimmons: zoom is unspecified and has total lack of interop.
  jensimmons: It was trying to do everything in one property. We
              should break it down and say "actually what we really
              want is have layout-affecting transformations" or "maybe
              there should be alternative ways that fonts should be
              rendered"
  <dbaron> I think we had a working group resolution to pursue
           layout-affecting transforms. :-/ I remember an extensive
           discussion of it in a meeting -- and I remember SteveZ was
           there.
  <jensimmons> btw, I made this demo while listening to see what's
               different between zoom & transform scale:
               https://codepen.io/jensimmons/pen/gOMMJMz

  heycam: To follow-on from jensimmons, I'm curious dlibby what the
          specific things that these authors are trying to get out of
          it, and why regular transforms were not sufficient.
  dlibby: One of the compelling use cases was outlook web access to
          zoom in the reading pane for your emails. These emails were
          coming in with arbitrary styles / content / sizing, so
          enabling just that section, but no horizontal overflow, zoom
          gave them a low-cost way of doing it. "hey it could work" it
          keeps the layout constrained in the inline direction.
          They've been happy with results in Safari and Chrome and
          Edge so far. That's the main use case.
  dlibby: There were a few other use cases that were less compelling.
  dlibby: This one is the most compelling to me.

  emilio: If you're zooming arbitrary content, zoom doesn't work.
          Percentages don't get scaled. Which is one of the quirks of
          the zoom property. I guess for email it kinda works because
          most emails are fixed sizes, but that's a very specific use
          case to justify adding this with the existing quirks.
  smfr: Safari's command-plus zooming behavior is built on top of the
        zoom property. Makes images and text bigger while reflowing.
        Transforms aren't what you want.
  emilio: Control-plus in gecko affects the CSS px scale. and viewport.
  myles: We also have that zoom
  smfr: That's what we have, it changes the size of css px
  emilio: command-plus is interoperable, it just changes the size of a
          CSS px. But it's complicated / messy, maybe it's a mix of
          the two.

  <dbaron> https://lists.w3.org/Archives/Member/w3c-css-wg/2007OctDec/0267.html
           at least recorded an action to post a proposal for
           layout-affecting transforms
  astearns: dbaron posted a link where we wanted to make
            layout-affecting transforms before

  astearns: proposed resolution: avoid specifying zoom as it stands,
            but we will if we have to, and a new proposal about a
            better zoom property would be a good use of time

  [ no objections, assumed RESOLVED ]

  dlibby: Good discussion. Thanks.
  dilbby: This is a clear path forward that ideally does not
          specifying the current behavior.
Received on Thursday, 29 October 2020 23:24:36 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 29 October 2020 23:24:37 UTC