- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 11 May 2022 19:16:29 -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.
=========================================
CSS Backgrounds
---------------
- RESOLVED: thin, medium, and thick will be defined as 1px, 3px, and
5px respectively. (Issue #7254: Specify exact pixel
values for border-width: thin, medium, thick)
Values, Backgrounds, Animations, Transitions, fill-stroke
---------------------------------------------------------
- More research needs to be done on current behavior and complexity
to change implementations prior to reaching a decision on issue
7164 (How to handle linked list-valued properties?)
CSS Overflow
------------
- RESOLVED: Always require inline-end padding to be added against the
inline-end alignment edge for block/flow layout when it's
a scroll container, thus matching the tests. (Issue #129:
Clarify padding in overflow content)
CSS Pseudo
----------
- RESOLVED: Accept the proposed PR. [
https://github.com/w3c/csswg-drafts/pull/7222 ]
(Issue #7101: Highlight pseudos and emphasis/underline
properties)
Filter Effects 2
----------------
- More testing is required around filter and backdrop-filter to
determine a resolution for issue #455 (backdrop-filter and
visibility)
CSS Lists
---------
- The Safari and Blink teams need to investigate the web compat of
solving issue #7227 (counter-reset in UA sheet causing some
compat issues) without magic
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2022May/0004.html
Present:
Rachel Andrew
Tab Atkins Bittner
Delan Azabani
David Baron
Oriol Brufau
Tantek Çelik
Daniel Clark
Elika Etemad
Robert Flack
Simon Fraser
Jonathan Kew
Chris Lilley
Peter Linss
Alison Maher
Ben Mathwig
Eric Meyer
François Remy
Jen Simmons
Alan Stearns
Miriam Suzanne
Bramus Van Damme
Lea Verou
Regrets:
Chris Harrelson
Scribe: emeyer
CSS Backgrounds
===============
Specify exact pixel values for border-width: thin, medium, thick
----------------------------------------------------------------
Github: https://github.com/w3c/csswg-drafts/issues/7254
TabAtkins: Was noticed that we still leave the keyword thicknesses
undefined. But all browsers agree on widths at 1px, 3px,
5px.
TabAtkins: Not sure of the exact history, but absent that, the widths
are very consistent and don't see a good reason to leave
them undefined.
fantasai: Maybe it was that these were like font-size keywords and
left open to interpretation. We should maybe recommend but
not require specific widths.
<fantasai> My suggested wording was “For Web compatibility, it is
recommended that these keywords be mapped to 1px, 3px, and
5px, respectively.”
TabAtkins: On the other hand, we specify a lot of things that could
be adjusted by e-readers. I don't know that this needs to
be left undefined.
TabAtkins: I argue we should go stronger than suggested.
dbaron: This is one of those things that was left up in the air in
CSS1, and I don't remember a proposal to define more
precisely. I support the precise definition.
fantasai: If everyone else agrees, that's fine.
RESOLVED: thin, medium, and thick will be defined as 1px, 3px, and
5px respectively.
Values, Backgrounds, Animations, Transitions, fill-stroke
=========================================================
How to handle linked list-valued properties?
--------------------------------------------
Github: https://github.com/w3c/csswg-drafts/issues/7164
TabAtkins: Issue 4431 asked to turn box-shadow into a shorthand. Very
reasonable. Because it's a list-valued property, we'd have
to make all longhands the same. It was brought up by
dbaron that whenever you have these groups of longhands
and have to sync up all the values, it's problematic for
implementations.
TabAtkins: What exactly are the reasons, and to what degree should we
be avoiding them? This touches on some things being
proposed and probably coming, like Toggles. It would be
good to know how careful we need to be.
dbaron: I'm most familiar with an implementation that no longer
exists, so this may be questionable input, but my experience
was that it was a LOT of code to implement these.
dbaron: Given that, it's not a that strong a preference. It's a case
where you can get properties where 90% of the work is
parsing, not implementation on the other end.
<lea> syncing up list-valued longhands is also a problem for authors.
This does not match a human's mental model about this at all
TabAtkins: Do you recall if it was a particular type of syncing up,
or if it was all equally hard.
dbaron: I think it was they were all equally difficult and yet things
were sufficiently different that you couldn't coalesce.
TabAtkins: We should get input from people working on extant
rendering engines. Anyone on the call that knows about
that?
astearns: Doesn't sound like we have current implementation
experience here on the call. Lea did mention a problem for
authors.
lea: When authors think about list-value properties, they think of
each thing as a unit. They think, I want this image at this size
in this place, and the syntax forces them to do things in a way
they don't think about it.
<fremy> +1 leaverou
TabAtkins: Agreed.
lea: Right, this makes sense with single values.
TabAtkins: We're asking if it's okay to expand for things that are
list values.
florian: When used with a single value on the list, it's useful to
break up. Authors can help by defining custom properties
that define certain combinations.
TabAtkins: That's partially true. Authors can work around the present
situation, and that's good. But forcing them to work
around a lot when we could take that need away isn't great.
TabAtkins: If we can avoid this being necessary in common cases, that
would be great.
astearns: The issue is whether we're going to more closely specify
computed values of list values.
Sebastian: It's not completely defined yet but most or all
list-valued properties base their logic on the definition
for background. So they're just referring to that and
still differ on implementation. Even within one engine.
astearns: The difference is something we need to address even if
implementation difficulty is a problem. I'm wondering
whether we can get to a resolution about that specific
difference and then people can start implementation to give
feedback on difficulty.
TabAtkins: I'd like to have an idea of the matrix of current
possibilities.
fantasai: The main question is are the lists truncated or extended at
compute time or use-value time? Specification says
use-value. It was suggested this might be easier if compute
time was used. The difference in behavior will affect
inheriting, which most of these properties don't do, and
might affect result of getComputedStyle.
fantasai: I don't think it would be a problem to switch over to say
list-matching happens at computed value time, but don't
know if that would make implementation easier.
astearns: We need to clarify what the current implementations do, how
difficult it would be to change, and what we'd like to do
in general at computed value time. We should take it back
to the issue.
CSS Overflow
============
Clarify padding in overflow content
-----------------------------------
Github: https://github.com/w3c/csswg-drafts/issues/129#issuecomment-1113489051
iank: Browsers have been very inconsistent about when something is a
scroll container to apply block- or inline-end padding.
iank: Chrome very slowly has been moving towards end padding in both
inline and block directions in block layout mode.
<iank> https://wpt.fyi/results/css/css-overflow/scrollable-overflow-padding.html?label=master&label=experimental&aligned&q=css-overflow
iank: I added an exhaustive set of tests that's linked in the
comment. This test creates a zero-area div and then relposed
out of the way, but that zero area div is used to push padding
out in either inline or block direction is various writing
modes.
iank: As I was reading back through the issue, there was a conception
that there are two cases that should behave the same. If you've
got inline content that's very long in a scroll behavior, it
should behave the same as if it's been wrapped in a div. But
the div isn't intrinsically sized and won't push parent padding
out.
astearns: The test cases you're talking about are supported by spec
text?
iank: Yes.
florian: We have a conceptual agreement that adding the padding would
be good, but there might be web compatibility issues because
if scrollbars show up where they didn't used to be, that
could be a problem.
iank: The spec text has written down our current behavior. We're
shipping that behavior now.
<TabAtkins> spec text: "Including this padding is optional for block
containers in the inline axis if align-content is
normal." with a note saying "hopefully this isn't
optional, we're waiting for web compat"
fantasai: Do we want to tighten up the spec now, or wait to tighten
it up once there's field data?
astearns: Has there been enough time to evaluate web compatibility?
iank: We think so. We shipped the “scary” behavior a couple of months
ago and got zero pushback.
florian: If other implementers are happy with it, would be happy to
tighten the spec now.
dholbert: This sounds fine to me, speaking from Firefox's
perspective. Having the Web-compat concern removed makes
this pretty straightforward.
smfr: Seems reasonable.
RESOLVED: Always require inline-end padding to be added against the
inline-end alignment edge for block/flow layout when it's a
scroll container, thus matching the tests.
CSS Pseudo
==========
Highlight pseudos and emphasis/underline properties
---------------------------------------------------
Github: https://github.com/w3c/csswg-drafts/issues/7101
delan: Highlight pseudos have a restricted subset of applicable
properties. Not all properties in the text-decoration spec
start with text-decoration-*. Question originally was, can we
add those and make them applicable. I initially thought we
should. fantasai and rego have mentioned most of the
text-emphasis-* properties shouldn't be applicable.
delan: Maybe only text-emphasis-color should be applied. That's where
we are now.
astearns: I'm a little worried that the proposed patch is still a
little vague. Should we be very specific about what can be
applied?
fantasai: I don't think we should be very specific, because as more
things are added elsewhere, user agents should be free to
add them here. I think the proposed wording is good enough
for now.
<tantek> +1 fantasai
delan: In general, we're happy with all the properties related to
line decorations being applicable?
fantasai: Right.
delan: So it's the emphasis marks that are contentious.
smfr: Are we avoiding properties that can cause ink or layout
overflow?
delan: Ink overflow yes, layout overflow no.
fantasai: Ink overflow doesn't trigger scrollbars. We want to avoid
anything that could cause scrollbars.
delan: So actually ink overflow no, layout overflow yes. Sorry, got
those backwards.
astearns: Ink overflow is okay, layout overflow is not okay. We could
have a note in the specification saying that's how we
determine the list of properties.
delan: We sort of do say that about the layout, but we could be more
explicit about ink overflow.
<iank> changes in layout overflow implicitly effects layout.
astearns: The bit we have about not affecting overflow layout is
sufficient, I think.
RESOLVED: Accept the proposed PR
<fantasai> fwiw spec says “The highlight pseudo-elements can only be
styled by a limited set of properties that do not affect
layout and can be applied performantly in a highly dynamic
environment—and additionally (to ensure interoperability)
whose rendering within the required area is not dependent
on the exact (UA-determined) bounds of the highlight
overlay.”
Filter Effects 2
================
backdrop-filter and visibility
------------------------------
Github: https://github.com/w3c/fxtf-drafts/issues/455
emilio: Browsers are weird and inconsistent about backdrop-filter,
which we hit when starting our own implementation.
emilio: We haven't found content with visibility: visible in the
backdrop in the wild, but we should be clear about what
should happen.
smfr: My mental model is that you generated a bitmap the size of the
element with the filter and render the content. So you end with
a texture with transparent around the edge and then use that to
composite with the backdrop.
smfr: So to my thinking, the Safari behavior looks correct, minus the
toggle bug.
emilio: Doesn't that mean you should render the whole thing even when
the backdrop filter is hidden?
smfr: That is a bit weird, I guess.
smfr: I think we'd be willing to change to what you suggest.
emilio: I think determining the visibility by the element the filter
is on is simpler, rather than rendering the whole thing.
emilio: Are there other filters that depend on the background behind
the element? For most stuff you end up filtering transparent.
smfr: mix-blend-mode is the only one I can think of.
smfr: I think the way forward is to test with the filter property and
maybe propose that visibility hidden will always hide the whole
backdrop.
dbaron: For what it's worth, I think of visibility: hidden as a
paint-time effect. It should be mostly independent of this
compositing things.
dbaron: It's sort of inherited and controls whether things are
painted or not.
emilio: That's what Gecko did, but breaks sites that are set to have
backdrops hidden.
emilio: I'll add some links to examples.
smfr: To dbaron's point, it's like saying it's basically opacity: 0
but affects hit testing.
<emilio> https://bugzil.la/1765862 is the Gecko bug ftr
astearns: Sounds like we need more information and will need to do
testing around filter as well as backdrop-filter. Take back
to the issue?
<flackr> filter seems to be applied from visibility: hidden element
in chrome: https://jsbin.com/jegijet/edit?html,css,output
<dbaron> I was saying I think it's like a middle ground between
color:transparent and opacity:0
<dbaron> (I might have been muted when I said it)
CSS Lists
=========
counter-reset in UA sheet causing some compat issues
----------------------------------------------------
Github: https://github.com/w3c/csswg-drafts/issues/7227
emilio: This is about pages that do their own counters and adding
them makes things add oddly. Not many examples of this, but
we found some.
emilio: I tend to think there should be a magical reset, which is
unfortunate, but there are things you wouldn't be able to do
otherwise.
TabAtkins: Elika had two objections. 1: this wouldn't be overridable,
as it is now. If you mention a counter, it gets reset.
There's no way to do a no-op. But we got lucky here. We
could allow `none` as a counter-reset value alongside
integers, which would mean “don't reset the counter”.
TabAtkins: 2: this triggers on specific HTML elements with no CSS
reason for it. We'd like to avoid that if possible. I'm
okay with some weird rules, especially around lists, but
Elika strongly believes that's a problem.
fantasai: I think we should avoid it if we can. How strong of a web
compatibility problem is it?
<jfkthame> +1 to fantasai
fantasai: So that's a question for the Safari and Blink teams.
<iank> I'd need Rune to comment.
smfr: No info at the moment from the WebKit side.
astearns: Who should we ping at WebKit?
smfr: I'll be the conduit.
<fantasai> Question is, can we get Blink and WebKit to align with
Firefox on this, or do we really need to introduce this
magic into the Web platform
astearns: So we're taking this back to the issue for more information.
astearns: It might be good to outline the possible ways forward for
this there as well. If someone could add a summary after
minutes are posted, that might help.
<florian> reminder: please go vote for the MQ3 proposed corrections:
https://www.w3.org/2002/09/wbs/33280/mediaqueries-3-proposedcorrections-2022/
Received on Wednesday, 11 May 2022 23:17:09 UTC