- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 30 Sep 2020 19:30:22 -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.
=========================================
accent-color
------------
- The request in issue #5480 (Should interoperability be a goal for
the `accent-color` spec?) is to select between two approaches:
- Option A: The proposal for Option A is the full proposal. This
includes the normative section, the Motivation and Intent
section, and the non-normative examples section. Link to
full proposal:
https://github.com/mfreed7/accent-color/blob/master/proposal.md
- Option B: The proposal for Option B is just the normative
section, with the 4th paragraph referring to "interop"
removed.
- There was also another proposal put forward in issue #5544 (make
accent-color: <color>+ a list of alternatives, not complements)
which didn't slot neatly into either Option A or Option B,
though it was a bit closer to Option B.
- On the call there wasn't clear agreement between Option A and
Option B. Some of this was due to the new proposal and some due
to a general desire to not be too vague or too specific but
finding that hard to fit desire into the current binary choice.
- Discussion will continue on GitHub to further clarify that the
Option A and Option B are not final selection of language but
instead a general direction as well as how issue #5544 should be
considered in this discussion.
CSS Scroll Snap and Scroll Anchoring
------------------------------------
- RESOLVED: scroll-snap overrides scroll-anchoring for behavior
heuristics (Issue #4830: Clarify the interaction between
snapping and scroll anchoring)
Scroll Snap
-----------
- RESOLVED: Close no change based on reasoning in
https://github.com/w3c/csswg-drafts/issues/4037#issuecomment-538060075
(Compat between webkit and blink/gecko regarding
"implicit" scroll boundary snap positions)
CSS Content
-----------
- RESOLVED: 'auto' value of quote to be based on parent language
(Issue #5478: Quote character choice must depend on
surrounding language, not language of the quotation)
- RESOLVED: Add 'match-parent' keyword [to quote property] (Issue
#5478)
CSS Color Adjust
----------------
- RESOLVED: Colors assigned due to forced-colors mode are not
interpolatable (Issue #5419: Clarify expectations re
forced-color mode, system colors, and transitions)
CSS Text
--------
- RESOLVED: Defer the behavior of discarding line breaks adjacent to
ambiguous characters to L4 of css-text (Issue #5017)
CSS Overflow
------------
- iank is leading an effort to slowly see how much of the currently
incompatible behavior for scrollable overflow (Issue #129:
Clarify padding-bottom in overflow content) can be resolved in
the way authors would expect without causing issues for web
compatibility. The plan is to make incremental small changes
over the next few months and then report the results back to the
group.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2020Sep/0030.html
Present:
Rachel Andrew
Adam Argyle
Tab Atkins-Bittner
Rossen Atanassov
Christian Biesinger
Mike Bremford
Tantek Çelik
Daniel Clark
Emilio Cobos Álvarez
Elika Etemad
Brandon Ferrua
Simon Fraser
Mason Freed
Chris Harrelson
Daniel Hobert
Dael Jackson
Brian Kardell
Jonathan Kew
Ian Kilpatrick
Una Kravets
Daniel Libby
Peter Linss
Alison Maher
Theresa O'Connor
Anton Prowse
François Remy
Melanie Richards
Florian Rivoal
Jen Simmons
Greg Whitworth
Zheng Xu
Regrets:
Amelia Bellamy-Royds
Chris Lilley
Miriam Suzanne
Lea Verou
Scribe: dael
accent-color
============
Should interoperability be a goal for the `accent-color` spec?
--------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5480
Rossen: Based on last week's discussion we want to discuss the
accent-color topic one more time and see if this is
something we should pursue and how
Rossen: We're going to cap this to 10 minutes. If we cannot come to
consensus we'll push back to GH until consensus there.
Rossen: I want to have chrishtr or masonfreed summerize outcome
they're looking for and ask group if consensus. If none I
want clear constructive feedback.
<masonfreed> https://github.com/w3c/csswg-drafts/issues/5480#issuecomment-697747055
masonfreed: Make it crisp. Looking for resolution for A or B in link
above
masonfreed: Looking for a direction, interop vs hint. Interop is
full proposal as presented. B is a striped down version
with no normative text or guidance on how to do
accent-color. A or B with a link in the thread.
Rossen: Questions or feedback?
florian: Seems to be a linked issue from fantasai is a variant C.
It's closer to B but not identical.
<fantasai> https://github.com/w3c/csswg-drafts/issues/5544
florian: That one ^
florian: If fantasai is on maybe she can explain. It should be part
of conversation.
fantasai: We have accent-color list of color but use of colors is
not clear. Explains primary, tertiary accent colors. If
you pick a bunch of colors of the rainbow you have no idea
how they're used. In general noticed platforms have 1
color so multiple maybe not needed. Do have problem about
where ever color is we don't know how used with respect to
background color.
fantasai: We allow UA to adjust luminance.
fantasai: My proposal is define accent-color to be a list of
alternative. You expect to pick a bunch of colors and UA
picks the one with correct amount of contrast. Rather than
make it be about different usage but about which has right
contrast
<fantasai> https://github.com/w3c/csswg-drafts/issues/5480#issuecomment-682242811
fantasai: I think overall my take that TabAtkins comment ^ is the
key piece of the design
fantasai: [reads it]
[comment:
The goal should be only and exactly enough specification to
ensure that authors can use the property without
browser-specific hacks, such that if an author makes it look
good on one browser, they won't make it unreadable on another.
Anything more is overly restrictive, anything less means the
feature is useless.
]
fantasai: The idea is the UA should be able to do what it feels is
appropriate and we shouldn't pin down on how to use the
color but should make sure there's enough contrast.
fantasai: I think going in direction of allowing UA to use color in
what pieces it wants and make multi color be about right
contrast helps us get there
masonfreed: I didn't see that other issue, I apologize. Sounds like
option B-lite. Less interop than option B. For purpose
of today is that a vote for option B and we go on and
define option B more concretely if that's as the way
group wants to go?
fantasai: Maybe? I think so?
Rossen: Are we ready to vote out option A? Does anyone want to
keep A?
Rossen: Sounds to me like variants of B but if that's what group
favors lets move on with additional details to break down B
into more details.
masonfreed: I should say Chromium favors A. However we really want
this so we would accept B.
fantasai: Looking more I think my proposal is a really a different
thing. Both A and B define accent-color. As to how much
detail that's a different thing.
masonfreed: Level of detail is the question for today.
fantasai: I would go with B for details. A lot of specific cases in
A should be examples. Here's an example of how you could.
That makes spec clear on intent without providing
restricting guidance
<fantasai> I don't have any objection to adding informative sections
*as examples*. But Proposal A is written as specific
guidance, which I don't agree with.
Rossen: We have 2 more minutes on this. If we can't resolve we'll go
back to GH
jensimmons: I can't shake feeling that it seems like 2 things being
debated. One is should we include a lot of non-normative
text and an attempt to have a lot of info in spec.
That's A vs B.
jensimmons: Title of the issue and some comments feel more like if
you agree we're putting in non-normative text you also
agree current text is what we end up with. Then we get
stuck.
jensimmons: What TabAtkins described is threading the needle so it's
not overly descriptive but not useless and
underspecified. If we're trying to call now to include
text or not if we can unwind from demand about
incredibly descriptive...we're getting stuck because
they're being conflated.
masonfreed: Let's go back to the issue. Post says they're open for
discussion and further details but first question is
large direction of A or B.
Rossen: sgtm. Don't want to resolve on A or B, just on thread.
Rossen: Thank you masonfreed
CSS Scroll Snap and Scroll Anchoring
====================================
Clarify the interaction between snapping and scroll anchoring
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4830
Rossen: Do we have a proposal? Who wants to introduce?
fantasai: I think this is a question of what wins between snapping
and scroll-anchoring. I think scroll-snap wins. Not sure.
I was looking for feedback from WG.
Rossen: To make sure I got it, is the question which of the two
prevails if I have scroll-snapping and scroll-anchoring?
fantasai: That's my interpretation. emilio filed it.
argyle: Updating a comment on the thread. Been building with
scroll-snapping. Should target be similar to anchoring?
Trying to clarify. Page will scroll to hash in URL?
smfr: Scroll-anchor is page maintain scroll position in face of
content changes
argyle: So similar to scroll-snapping maintaining position on resize
and things like that.
smfr: Yes
argyle: I guess I'm confused as to what this is trying to clarify.
smfr: Let's have emilio summarize
emilio: I filed this before we defined for layout to resnap. If we
always resnap after layout I don't think there's an issue
argyle: Have an issue where you refresh vs hit page first time what
wins, target or scroll position. How many nested scrollers
are restored. Sounds like this is more pointed then that case
smfr: Question for emilio: Does snapping and anchoring have
different ends states? If snapping is in place and scrolling
you snap to something. Does scroll anchoring yank you away?
emilio: I guess ideally it shouldn't. I wonder if there are edge
cases where scroll position is collapsed and so on
emilio: I could have added more details to the issue originally when
this was in my head
Rossen: Do we move on at this point? Sounds like there is no issue
anymore
* fantasai proposes resolving that snapping overrides
scroll-anchoring heuristics and put that in the
scroll-anchoring spec
emilio: I'll try and look and reopen if I find something
<argyle> https://web.dev/snap-after-layout/
<argyle> https://drafts.csswg.org/css-scroll-snap-1/#re-snap
Rossen: Back to original question as to which overrides, snapping or
anchoring. fantasai supposes snapping is favored over
anchoring. Do we have this explicitly? If not it's good to
be explicit so there's stable expectations for authors
Rossen: Are you suggesting this because we don't have it specified?
fantasai: Seems emilio got confused so might as well clarify
Rossen: Anyone who believes we should favor anchor? Objections to
scroll-snap overriding scroll-anchoring for behavior
heuristics?
RESOLVED: scroll-snap overrides scroll-anchoring for behavior
heuristics
Scroll Snap
===========
Compat between webkit and blink/gecko regarding "implicit" scroll
boundary snap positions
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4037#issuecomment-590372507
Rossen: Reopened with additional thoughts
<fantasai> https://github.com/w3c/csswg-drafts/issues/4037#issuecomment-538060075
fantasai: Proposal is close no change based on majid's reasoning
based on ^ comment
<fantasai> per that comment, close as no change
fantasai: Means WebKit needs to fix to not have implied start and
stop points. That's how I propose to close.
Rossen: I see smfr added a tracking bug?
smfr: This is on my radar and fine
Rossen: Objections to close no change?
RESOLVED: Close no change based on reasoning in
https://github.com/w3c/csswg-drafts/issues/4037#issuecomment-538060075
CSS Fonts
=========
@font-face overrides for superscript/subscript metrics
------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5518
Rossen: Is this ready or continue in GH based on recent activity?
fantasai: Defer to myles
Rossen: myles doesn't seem to be on the call. Given activity in GH I
suggest we continue there and bring this next week
Resize Observer
===============
Should "resize loop error notification" be a warning instead of
an error?
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5488
fantasai: I didn't know what to do but seems like we should do
something
Rossen: Anyone had a chance to look at this and propose behavior or
take a stance on warning vs error?
iank: Not sure downgrading completely to warning is correct. I have
heard webdev uncover real bugs in production. Requires thought
iank: I think this requires a little bit of thought about how to
approach this
Rossen: Let's continue in the issue then
Rossen: Once you're ready tag it again and we'll look
CSS Content
===========
Quote character choice must depend on surrounding language, not
language of the quotation
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5478
fantasai: The question raised is we have an auto keyword for quotes
property. Richard points out the set of language quotes
you want to use is the set of the parent, not the
element's language
fantasai: Do we want to resolve to define auto value of quote to
choose based on parent's content language rather then
element's content language?
Rossen: Comments?
<tantek> wow I thought we solved that with the Q element back in the
day
<fantasai> tantek, this is how the Q element is implemented
<fremy> this seems to make sense
faceless2: Works for me and I see Richard's point. Good issue.
tantek: Agree as well. I thought we did that in IE5 Mac for Q
element. We should look at Q element
fantasai: Q element is defined in CSS terms. So we need to fix our
spec.
Rossen: Objections to resolve auto value of quote to be based on
parent language?
RESOLVED: 'auto' value of quote to be based on parent language
fantasai: Second part of issue
fantasai: If you have quote within a quote you will typically use
quotation style of contextual language not immediate
parent.
<fantasai> https://github.com/whatwg/html/issues/3636#issue-316269336
<fantasai> But Lucy replied: “Embrassez George de ma part et
dites-lui, ‘Embrouille’”
fantasai: Previously when didn't have auto some discussion on how to
do that with selectors and ^ have examples
fantasai: auto inherits as itself. No way to get that behavior of I
am using the quotation marks of my context.
fantasai: Can get the behavior but need keyword like match-parent.
text-align has that to use same resolved alignment as
parent
fantasai: We added match-parent which says look at my parent value
and if it's physical inherit. Logical resolve and inherit
fantasai: Can do similar here where if my parent value is similar to
quote inherit. If it's auto, resolve that to a string and
set my computed value to that string and it inherits
through.
<AmeliaBR> Quotes already need to keep track of nesting, so can't
auto have a behavior that if this is a nested quote, use
the same language quotes as the outer level?
florian: Would that be what match-parent does? I think you want to
match style but not string.
fantasai: Nesting if from open/close quote
florian: Yes, yes.
fantasai: Keeping track of nesting we don't have to worry about
here. Nesting levels is handled by counters built into the
content property and UA is responsible to choose correct.
fantasai: Do we want to add a match-parent keyword?
<florian> I think we do
Rossen: I see one support on IRC
Rossen: Other thoughts or reasons why we shouldn't?
jfkthame: Unclear. Is match-parent in UA stylesheet or authors
expected to do?
fantasai: I don't know the answer. If want behavior where using
quotation language of context it's easy in UA stylesheet.
q q { quotes: match-parent; } should get correct behavior.
If we want that in UA stylesheet I'm less sure but I leave
that to i18n and WhatWG. This makes it possible to do
florian: Seems that if we want q element to be able to have the
range of behaviors needed to use it properly we should do
this. If we believe people don't use q element maybe we can
skip, but if we want it to be useful we should do this.
faceless2: Then we should do it. I think it's a useful property
Rossen: Hearing people leaning toward the optional keyword
match-parent.
Rossen: Thoughts of objections to adding match-parent keyword?
RESOLVED: Add 'match-parent' keyword
<florian> figuring what selectors to use to solve this q problem
correctly used to be seriously hard. auto and match-parent
make it so much easier.
CSS Color Adjust
================
Clarify expectations re forced-color mode, system colors,
and transitions
---------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5419
Rossen: I know AmeliaBR sent regrets. Seems consensus on issue.
alisonmaher can you summarize?
alisonmaher: General issues are specifically when you change
forced-color-adjust to auto or none do we trigger
transition. If to or from are forced we would not
trigger transitions is the proposal
<fremy> sounds like the right call to me
TabAtkins: Simplifies impl and happy to have in spec
Rossen: Also support. Makes behavior predictable
<AmeliaBR> no need to wait for me: my opinion was “please pick what
works best for implementations & spec it!”
emilio: Other than display is the precedent for such a thing?
TabAtkins: There's a couple of non-interpolatable properties. Some
have values that cannot be interpolated though others can.
emilio: This is different. This isn't about interpolatable but about
if triggers transitions on other arbitrary properties
TabAtkins: Yes. If the stuff is forced or not controls if other
properties can interpolate certain values. That is novel.
Seems easier on our implementation to handle it.
emilio: Why?
TabAtkins: Don't know. Rune would have more details
emilio: To me seems it would make...this would need to be a special
case
Rossen: Implementation aside from user or author PoV which behavior
would you prefer?
emilio: If author has specified BG transitions I don't see why it
shouldn't?
Rossen: How about if in middle of transition you go to or from
forced colors. You're going off a cliff for expected. But
continuing to transition means some things change. These are
dissonant to me.
emilio: To make sure I understand saying that changing forced-color
adjust stops in progress particular property values?
TabAtkins: Not quite. Any colors coming from forced-color mode don't
interpolate. In general it's forced vs not and that's
outside the property.
emilio: Agree with Rossen similar that stopping transition when
element stops making boxes makes sense it does make sense
when you change to stop animations and transitions. I need
to look deeper into implications.
Rossen: We do have a resolution on animations.
fremy: An example of why don't want to transition colors: When in
forced-colors the backplate is on top of text. Will disappear
when set to none. Previous text color contrasts backplate so
you don't want text color to transition because it's a
completely different background. Text could disappear for a
few seconds. I think stopping transitions makes the most sense
emilio: Could make argument with a bunch of different property
combos, right? Not just forced-colors.
Rossen: Is this something you want to object emilio, discuss more?
emilio: Is the proposal colors from forced-colors and colors don't
interpolate?
TabAtkins: Proposal: Colors assigned due to forced-colors mode are
not interpolatable
emilio: I won't object. I need to look more
emilio: When you revert a property and it goes to color from UA
sheet I assume that counts as assigned because forced-color
mode?
emilio: You have forced colors. That can cause you to revert some
properties to UA level. If you use a color; it's not just
default colors you assign but also the ones you get when
revert to a value from UA stylesheet. They shouldn't
interpolate. But same as if author spec revert
TabAtkins: Should have been from set of forced system colors so yes
emilio: I don't know. Feels awkward resolution. I would be curious
about constraints that simplify this in Chrome
<TabAtkins> https://github.com/w3c/csswg-drafts/issues/5419#issue-677260327
lays out some initial thoughts, from Amelia, and
subsequent comments from Alison and Rune
emilio: I won't object.
Rossen: If you have a better proposal and want to re-open please do.
Rossen: Let's make progress now.
Rossen: Objections to colors assigned due to forced-colors mode are
not interpolatable
RESOLVED: Colors assigned due to forced-colors mode are not
interpolatable
CSS Text
========
Discarding Line Breaks Adjacent to Ambiguous Characters
-------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5017
fantasai: Proposal was defer to L4
Rossen: That's an easy proposal
Rossen: Any reason not to defer?
Rossen: Not hearing any reasons
Rossen: Objections to defer the behavior of Discarding Line Breaks
Adjacent to Ambiguous Characters to L4?
RESOLVED: Defer the behavior of Discarding Line Breaks Adjacent to
Ambiguous Characters to L4 of css-text
Rossen: Issue has a lot more to discuss so I encourage re-engagement
on github
CSS Overflow
============
Clarify padding-bottom in overflow content
------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/129
iank: Introduction for this
iank: Broadly we have been investigating scrollable overflow
problems in blink. Lot of inconsistent tests and inconsistent
implementations.
iank: Including child margin plus scrollable padding is what devs
want, we believe. Inconsistent between layouts and directions
iank: 2 calculations. You take post transform rectangle of child and
add to scrollable. This is interoperable. Second is this
issue. Take pre-transform rectangle and add its inflow bounds.
Use that to determine where padding edge goes.
iank: We think the model works. How webcompat is it is the question.
iank: Think we should aim for what webdevs want but stop when web
incompat. Prepared to slowly switch on various behaviors to
get closer and closer. May hit a case where can't go further
due to compat.
fantasai: Totally in favor. Great to get to where authors want. Less
likely to have problems with newer layouts flexbox and
grid. More problems with older like block where trying not
to add scrollbars when not necessary. Triggering when
scrollbars appear is where will find problems
iank: That's where we expect. We're going to do this slowly over 3-4
months and can report back success. For block in inline
direction if there weren't going to be scrollbars previously
we may not add padding but if there would be we add padding.
Might end up with that which is a bit strange.
Rossen: Sounds like a good proposal. Should we resolve for flex and
grid and think about block more?
fantasai: I think we resolved on flex and grid
Rossen: I think so too. Don't want to hold them waiting on block?
iank: If we agree on direction we can report back on each step what
was not web-compat. We'll start with flex probably. Report
back. DO resolution on broad model now and web compat
resolutions later maybe
Rossen: Proposal is for flexbox and grid? Want to make sure I'm
going for right resolution
<fantasai> current spec - https://www.w3.org/TR/css-overflow-3/#scrollable
fantasai: Spec requires this for flex and grid, optional for block
with an issue about web compat
iank: Leave as is and in a few months I can come back with web
compat data.
iank: Tentative agreement we want to go that direction is good
florian: sgtm. We've been blocked on web compat data so let's get
the data.
Rossen: Then this is everything for today
Rossen: Thanks and next week we're APAC time
Received on Wednesday, 30 September 2020 23:31:23 UTC