- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 29 Oct 2020 19:23:37 -0400
- 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