- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 22 Feb 2023 19:31:14 -0500
- 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 Contain & Sizing
--------------------
- RESOLVED: content-visibility: auto forces contain-intrinsic-size
to gain an auto value, and we'll define that auto value
for contain-intrinsic-size so it works with all the
current values, and then make sure that the last
remembered size is forgotten when contain-intrinsic-size
changes (specifying where in rendering step it happens)
so we can deal with the cases that Rob brought up.
(Issue #8407: Behavior of slightly offscreen content
having `content-visibility:auto` and
`contain-intrinsic-size` when UA margin around the
viewport is 0)
CSS Text
--------
- RESOLVED: Rename `text-space-collapse` back to
`white-space-collapse` (Issue #8273: Renaming
text-space-* to white-space-*)
CSS UI
------
- RESOLVED: outline-style: auto outlines, if influenced by an author
color, are influenced by outline-color, which itself
gets a new initial value keyword 'auto' which computes
to 'currentColor' when outline-style is not auto and
otherwise represents the 'accent-color' (Issue #7761:
Tweaking outline-style: auto colors)
- Tests will be run to define exactly what implementations do
currently for issue #7700 (Align canonical order of `outline`
sub-properties with `border`) to help drive a resolution.
===== FULL MEETING MINUES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2023Feb/0011.html
Present:
Rachel Andrew
Tab Atkins
David Baron
Tantek Çelik
Emilio Cobos Álvarez
Yehonatan Daniv
Elika Etemad
Robert Flack
Simon Frazer
Mason Freed
Paul Grenier
Chris Harrelson
Daniel Holbert
Chris Lilley
Peter Linss
Alison Maher
Eric Meyer
Alan Stearns
Miriam Suzanne
Bramus Van Damme
Regrets:
Lea Verou
Chair: astearns
Scribe: dbaron
astearns: Hoping to get dates for extra meetings nailed down this
week, but don't need meeting time for it.
astearns: Any changes to agenda?
CSS Contain & Sizing
====================
Behavior of slightly offscreen content having `content-visibility:auto`
and `contain-intrinsic-size` when UA margin around the viewport
is 0
-----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8407
jihye: This issue is related to `content-visibility: auto` and
`contain-intrinsic-size`.
jihye: It's an edge case. It's a problem for both Firefox and Chrome.
jihye: If the UA margin is set to 0, and the content is specified
with `content-visibility: auto` and
`contain-intrinsic-size`... if this content is slightly
offscreen, as a result the content flashes.
jihye: I would like to have a resolution on 2 major questions:
jihye: 1. Is this kind of flashing reasonable... what is the
expected result? Flashing or stable?
jihye: 2. If the result should be stable, what is the final result
that is shown?
jihye: My opinion is that for (1) the result should be a stable
layout because I understand the purpose of
`content-visibility: auto` with `contain-intrinsic-size` is
to improve rendering performance, so this kind of flashing
result decreases performance. I think stable layout is better.
jihye: My opinion for (2) is that I want to pursue a way that
improves rendering performance, so keeping the offscreen
element offscreen would be a reasonable result, but I'm not
sure how to define that. So I discussed this the github issue
with Oriol, and we discussed whether we can define a new
description of "maybe relevant". I'm not sure how to define
this, need more opinions.
Oriol: I agree we should try to achieve a stable layout... when
setting content-visibility to auto we could say
contain-intrinsic-size automatically gets the auto keyboard.
(missed) So it would keep a stable size and stop flickering
between two sizes.
Florian: I think it's a good solution, satisfies the expectation
that Jihye had.
TabAtkins: I support Oriol's proposal as well.
Oriol: Then there's a detail: the `auto` keyword of
`contain-intrinsic-size` can only be mixed with lengths, but
the initial value is `none`. So we'd need to add the `auto
none` combination.
TabAtkins: Want to look into the spec, but initially that sounds
reasonable.
emilio: 2 questions: (1) In principle it doesn't seem useful to have
it behave as non-`auto` (or `none auto`??)... but is there a
use case that people may be using. (2) Allowing `auto none`
feels a bit odd but I guess it's all right? If ??? then we
wouldn't completely lose that length.
astearns: Sounds like we would lose the length at computed or used
value time
emilio: I'm a bit concerned about people using lengths. IIRC, `auto`
is supported along with lengths, so you can specify a length
and remember a size as if it was laid out.
oriol: You can't specify `auto` alone, it's `auto` mixed with a
length.
emilio: So if you specify `contain-intrinsic-size` and a pair of
lengths, we'd turn it into `auto` and pair of lengths, but
not just...
chrishtr: I think upgrading to `auto` with a length is better, that
way author can provide placeholder sizing before first
render.
emilio: They can do it manually if they don't specify `auto` and
then we wouldn't touch it, but the idea is to do this
automatically.
chrishtr: contain-intrinsic-size: width height would be the same as
contain-intrinsic-size: auto width height.
emilio: Agree that's desired.
oriol: If author specified 10px 20px, it would become auto 10px 20px.
emilio: That seems worth clarifying before resolving, but SGTM.
astearns: So only in the case where it's set to `none` it would
become `auto none`.
astearns: ... so that's why we need to add it to the grammar.
oriol: Yes, we need to allow this combination so we can upgrade to it
emilio: Behavior differences between none and 0?
oriol: Mostly the same, but with grid-template properties or
multicolumn they can differ
TabAtkins: There's a note in the spec where setting explicit
intrinsic inner size can be different than having no or
one child
emilio: Seems reasonable to allow auto mixed with none
chrishtr: To other question: I don't know of use cases for not
having `auto`. If we had it in original spec, we probably
would have made it the default.
chrishtr: Want to point out possible web compat risk, not sure if
it's a big deal.
emilio: I think as long as we don't suppress the author specified
sizes if there are any, we should mostly be fine.
emilio: But I could imagine someone working around this weird
behavior by expecting the items offscreen to collapse, and
collapsing ...
chrishtr: I think it's worth trying
flackr: I can think of a use case: you're rotating your device, so
you as an author know general shape of elements will be
dramatically different from last remembered size... so might
want to reset to contain-intrinsic-size rather than
remembering the size in that case.
TabAtkins: That produces an observable difference-- that's the
flicker case we're already trying to avoid?
flackr: Isn't flicker avoided by scroll anchoring?
flackr: That is, isn't the flicker avoided by scroll anchoring
keeping elements anchored to their position onscreen?
vmpstr: They are, but you can construct cases where it doesn't work
like in the issue example
flackr: But if you can ? cases that are ? portrait-like or
landscape-like, you can ???
vmpstr: Setting contain-intrinsic-size to new values should
presumably (not sure) reset the last remembered size?
emilio?: I don't think it does.
?: we should do that
flackr: That addresses my use case.
<TabAtkins> "At the time that ResizeObserver events are determined
and delivered, if an element has a last remembered size
but does not have contain-intrinsic-size: auto, remove
its last remembered size."
chrishtr: So if a style change occurs that changes value of
contain-intrinsic-size it will blow away the last
remembered size until it renders again?
flackr: SGTM
<chrishtr> sounds fine
emilio: I think that's reasonable but we need to define precisely
when that forgetting happens.
emilio: I think we already had some interop issues there... Oriol
can probably confirm.
<TabAtkins> We can definitely add to that condition to make it
forget upon a value change, yeah.
astearns: Sounds like we're coming to agreement, that the resolution
should be that content-visibility: auto forces
contain-intrinsic-size to gain an auto value, and we'll
define that auto value for contain-intrinsic-size so it
works with all the current values, and then make sure that
the last remembered size is updated in the right place so
we can deal with the cases that Rob brought up.
chrishtr: Sounds like everything to me
jihye: Sounds good to me.
dbaron: (substitution of text)
chrishtr: and specify where in rendering step it occurs
RESOLVED: content-visibility: auto forces contain-intrinsic-size to
gain an auto value, and we'll define that auto value for
contain-intrinsic-size so it works with all the current
values, and then make sure that the last remembered size
is forgotten when contain-intrinsic-size changes
(specifying where in rendering step it happens) so we can
deal with the cases that Rob brought up.
CSS Text
========
Renaming text-space-* to white-space-*
--------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8273#issuecomment-1404619129
fantasai: This issue... a long time ago we had a
`white-space-collapse` which together with `text-wrap`
were longhands of `white-space`.
fantasai: XSLFO folks complained that, since we organized the value
space to be simpler than XSLFOs, complained about naming
collision, so we renamed (but less clear)
fantasai: 2 decades later, someone asked to rename back,
confirmation from Liam Quin and Murakami-san that it's OK
to rename back to the more easily understood name.
astearns: Implementation status of text-space properties?
fantasai: As far as I know, nobody.
astearns: So good time to rename
astearns: Any concerns with going back to `white-space-collapse`?
RESOLVED: Rename `text-space-collapse` back to `white-space-collapse`
CSS UI
======
Tweaking outline-style: auto colors
-----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7761
emilio: This about whether `outline-style: auto` respects or not
`outline-color` and/or `accent-color`. Behavior is all over
the place. WebKit allows neither. Blink uses
`outline-color`, Gecko uses `accent-color`.
emilio: Reason I think Gecko behavior is preferable is 2 reasons:
`outline: auto` using the `outline` shorthand resets
`outline-color` to `currentColor`, which seems wrong at
least 99% of the time. and (2) it's more consistent with how
form controls work, so using accent-color makes more sense
to me.
<fantasai> +1
emilio: If we go with `outline-color` I'd at least like `outline:
auto` to not expand to `outline-color: currentColor`
florian: I think I agree -- some arguments seem stronger than
other, but agree in net. `auto` outline could look like
lots of things -- on some platforms it may follow the
accent and on some platforms it may not. So if it respects
any color it should probably be accent-color, but on some
platforms it may not respect anything and just stick to one
specific thing. So I think say "if you're going to be
influenced by any property, it should
florian: be accent-color, but whether and how you do that is
platform-dependent.
masonf: Clarify: is proposal to change initial value for
outline-color to accent-color, or ???
emilio: Allow the accent-color computed value to change the
rendering of the auto-style outline... no default value
changes involved.
<chris> this seems untestable, so it is *allowing* things but not
constraining them
masonf: My initial reaction was that accent-color was for form
controls, and now this applies to everything on the page. It
doesn't feel like an accent to me.
masonf: I'm wondering if there's another way to fix the problem, but
I don't have a well thought out solution. But one thing I
put on the issue was wondering if we could change
`:focus-visible` UA styles to only be `outline-style: auto`
so it doesn't reset the color.
florian: `outline` is sometimes used for decorative purposes but
usually for focus indicator... and focus indicator usually
matches form controls. On Mac OS changing system accent
color changes focus indicator, so going after accent color
makes sense.
<fantasai> Yeah, if the focus outline isn't a shade of gray, it's
generally the accent color
masonf: As an author you can achieve that without line-color:
accent-color, no?
florian: You could, but as specified (and I Think implemented),
setting outline: auto sets outline-color to currentColor,
so if that starts influencing the color that's odd.
smfr: I think I agree with masonf... like to hear from web
designers, maybe jensimmons... should outlines be controlled
by accent-color. accent-color is author controlled but system
highlight color is user controlled. So concerned about using
accent color.
* fantasai notes that jensimmons has a conflict at this hour, so
can't be here
emilio: Would you be similarly concerned about using outline-color?
smfr: yes
florian: That's what I was saying about specifying: saying that if
you're influenced by *any* color it should be accent color,
but you don't have to be.
smfr: I think I'd choose accent color in that case, but want some
more feedback about whether that's the right thing. If
accent-color not specified, fall back to outline-color?
emilio: Gecko falls back to system accent color.
smfr: Sounds better than falling back to outline-color.
emilio: ... Accent-color is a hint so you're allowed to ignore it.
emilio: I think allowing customizing outline appearance is nice,
auto outline has a11y benefits. But if WebKit wants to do
something different... accent-color seems like the right
property to allow you to choose.
chris: I agree with smfr that the crux is author control versus user
control. This seems to be adding an allowed behavior to a
list of unspecified behaviors, so it seems to be making what
people already do spec compliant. Not clear if it's allowed,
or if it's advice. Are we suggesting, or is it do whatever
you want, but did you forget about this one?
emeyer: Thinking of this as an author, it's a little weird to me
that setting outline-style: auto would fall back to a color
from a property that doesn't have the word outline in it.
But the behavior probably actually makes more sense. I
wonder if instead of defaulting to currentColor it makes
sense for outline to default to whatever the system keyword
is. But that might require too much change in browsers?
emeyer: I set my outline to be auto, but the color is not my
outline-color. Unless you know it comes from accent-color,
might be difficult to work out why. But maybe it's the
preferred behavior so not too many authors will run into it
as a problem. But if default value of outline-color could be
the system color that seems preferable to me, but don't know
if it's reasonable.
emilio: Changing the default of outline-color seems not feasible.
Changing the expansion of `outline: auto` seems potentially
feasible, but that would still make `outline-style: auto` do
something relatively weird.
emilio: I think not honoring `outline-color` is slightly better...
but then we can get into user versus author choice question
that chris and smfr raised.
florian: I was initially supporting emilio's proposal, but I'm
wondering now because of user vs. author thing, yes, the UA
can disregard that and display the system colors... could
have a setting. But if we think about user style sheets, if
we influence the style of the outline with the
outline-color property, a user could have a !important
outline-color... but they're ok with accent-color... then
there's no easy override for user sheets.
emilio: The focus ring on form controls when natively styled do
follow accent color, so that would create an odd behavior in
my opinion.
florian: User sheet that says "my focus ring really needs to be X
because otherwise it's an a11y problem"... ?
<chris> https://w3c.github.io/csswg-drafts/css-color-4/#css-system-colors
chris: In color 4, highlight and accent color are both described as
backgrounds. If we agree on this, I can change the
description there. We don't have anything in the
non-deprecated system colors which is an outline color.
<chris> while currentColor is a text color
fantasai: I was going to go back to emeyer's comment about changing
initial value of outline-color... I don't think we can
change it, because when outline-style is not auto we can't
change it, but we could change the initial value of
outline-color to be some kind of auto value that computes
to currentColor if outline-style is not auto and computes
to accent-color if outline-style is auto.
<masonf> +1 to that proposal. That gives the default behavior Emilio
wants, but the author/user control over the outline.
<florian> [fantasai's suggestion would deal with the concern I
expressed]
fantasai: Multi-level fallback... look at outline-color, then if
it's the initial value the UA will look at accent color.
But if you set outline-color to something else specific
you'd get that. It's a possible solution, not sure if
good. It works around compat stuff and allows both
outline-color and accent color to influence.
emilio: Not opposed to fantasai's proposal...
emilio: I was going to mention about chris's background versus
foreground color -- at least some browsers (Blink and Gecko)
do paint 2 outlines when you do outline-style: auto so you
are guaranteed to show some outline even if it matches the
background.
<chris> ah we are back to the stripes function
PaulG: Does anyone know ... I was under the impression that
accent-color had something to do with high contrast mode.
Would then specifying outline-color be a problem because then
high contrast mode it would not change?
emilio: There are in the sense that if you specify a non-auto
outline-color that isn't the system color it would not
change... but I think that's the expected behavior.
Similarly if you specify accent-color: <
something-not-a-system-color>. Unless you specify
forced-color-adjust: none.
masonf: I don't think accent-color is the mechanism through which
high contrast is influenced.
PaulG: Comfort level for a11y reasons: if someone makes a codepen or
something to demonstrate how it would work, should be tested
in high contrast mode, to see which settings a user might
use, and to preserve choice.
masonf: I just wanted to say I also like fantasai's proposal. Wanted
to address 1 question emilio raised: I think under that
proposal if you had outline-style: auto and outline-color:
auto, the UA could paint the high-accessibility... 2 rings
with white outside and color inside -- I believe we could
still do that in that scenario.
emilio: I think that's why accent-color seems like a better fit --
it doesn't override the color completely, but says you
should render the outline *using* this color, but not
completely using this color. You have outline-style: solid
for that.
florian: You can't guarantee that it's a single color -- could be 2
lines, gradient, etc.
masonf: Remains the case with fantasai's proposal -- with
outline-style: auto can still do those things.
emilio: Seems weird to use outline-style: non-auto (?) and allow
color to ???
masonf: The part I liked was that you could say `outline-style:
auto` and provide a color and still get the
high-accessibility ring.
emilio: Can get that too with accent-color.
masonf: But then they're not separate, could change color as moving
around page to controls with different accent color.
emilio: ?
masonf: outline-color seems more explicit
emilio: If the outline applies to form controls then they're not so
independent anymore.
fantasai: Example: say someone made accent color red for invalid
controls and green for valid controls, but want focus
outline to be consistent color throughout the page. Can't
do that with only accent-color and not outline-color.
Default to accent-color makes sense, but see benefit to
controlling independently.
<florian> +1 again to fantasai
masonf, emilio: that's fair
<masonf> +1 to auto
fantasai: should new initial value keyword for outline-color be
auto, normal, or something else?
<masonf> +1 to automagic
florian: auto... it doesn't seem normal.
<bramus> +1 auto
<tantek> +1 auto
<fantasai> PROPOSED: outline-style: auto outlines, if influenced by
an author color, are influenced by outline-color, which
itself gets a new initial value keyword 'auto' which
computes to 'currentColor' when outline-style is not auto
and otherwise represents the 'accent-color'
proposed resolution: add a new auto keyword to outline-color, that
means currentColor when outline-style is non-auto and means to
use the accent-color when outline-style is auto.
florian: oh, current initial value of outline-color is invert...
?: Does anyone implement that?
?: no, but Opera 11 did.
fantasai: I think we should explicitly change the initial value.
RESOLVED: outline-style: auto outlines, if influenced by an author
color, are influenced by outline-color, which itself gets
a new initial value keyword 'auto' which computes to
'currentColor' when outline-style is not auto and
otherwise represents the 'accent-color'
astearns: I think it would be very useful to have a couple of
examples of how one might use the different properties for
different purposes and why we have the fallback the way we
do
emilio: There's the question of what the new initial value should
compute or resolve to... I think it should compute to auto
like caret-color... but maybe it should resolve to the
accent-color keyword? That can be a followup question, as
long as well-specified. Maybe we can resolve to auto but not
sure we can get away with that -- pages might expect rgba()
values back.
emilio: We can probably wait to resolve on this.
Align canonical order of `outline` sub-properties with `border`
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7700
TabAtkins: Guillaume noted that despite similar value spaces, the
outline and border have a different order of the value
definition grammar, and since we generally follow value
definition order when serializing.
TabAtkins: fantasai notes that in CSS2 the grammar order wasn't
implied to have a meaning.
TabAtkins: since we do rely on the grammar order for things it would
make sense to align them
TabAtkins: Aside from that possibility, I think it's reasonable to
align the 2, more likely to follow what border does.
TabAtkins: I think we should resolve to make outline's component
order match border's component order.
<fantasai> Note that at least two people filed this issue, since we
have a duplicate
dbaron: In the past I was always concerned about the model of
defaulting to the syntax in the value definition
dbaron: I think in general it is worth explicitly testing impls to
see what they do and then coming back
<emilio> +1 dbaron
dbaron: Partially I'm guessing impls don't formally follow the spec
right now
dbaron: They were implemented before we created this rule, and
probably haven't updated
dbaron: So probably tests might show some accidental compliance
anyway
astearns: Would you like to test then resolve? Or okay to resolve
first and use tests to verify?
dbaron: Probably good to get tests first, but should be fine to
resolve async once we do.
<tantek> +1 on getting tests first, this has been implemented long
enough ago that it's worth gathering that data first
astearns: Sounds good, let's see if we can resolve async once we
have the data
<emilio> Pretty sure firefox is internally consistent (`color`, then
`style`, then `width`)
<fantasai> It is not in fact consistent
* fantasai drops a testcase into the issue
<fantasai> the engines are all interoperably following the
inconsistent grammar definition order
Received on Thursday, 23 February 2023 00:31:56 UTC