- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 24 Feb 2021 19:07:00 -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.
=========================================
Media Queries
-------------
- The disagreement about removing prefers-contrast: forced was
focused around users who have defined a color set which would
not qualify as high or low for the forced-colors media query and
therefore would not be detected if prefers-contrast: forced was
removed.
- Firefox will gather data about the colors used so the group
can monitor if the change would cause a negative impact in
experience for these users.
- There was also disagreement as to if reduced visual complexity is
necessary when there are forced colors. There was no data
available about expectations and people had contrasting views on
what is most likely.
- RESOLVED: Remove the forced value from prefers-contrast MQ (Issue
#5433: duplication of `forced-colors: active` and
`prefers-contrast: forced`)
- There was discussion on if the prefers-contrast MQ should be held
back until the group decides how to handle the reduced
complexity and forced color relationship. The group didn't
agree, though, so it will be opened as a separate issue.
CSS Images
----------
- RESOLVED: Bake the smoothing into non-integer changes in current
pixelated value. Add a new value for nearest neighbor
jaggedness (Issue #5837: image-rendering:pixelated
should not force "nearest neighbor" (or similar) when
the scale factor is far from an integer (e.g. 150%))
Scroll Snap
-----------
- RESOLVED: Republish CR-snapshot of Scroll Snap
Ruby
----
- RESOLVED: Add an 'alternate' value which is the initial value
(Issue #5971: Alternating sides for ruby-position)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2021Feb/0012.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins-Bittner
Christian Biesinger
Mike Bremford
Emilio Cobos Álvarez
Elika Etemad
Simon Fraser
Megan Gardner
Chris Harrelson
Daniel Holbert
Dael Jackson
Sankit Joshi
Jonathan Kew
Vladimir Levin
Daniel Libby
Peter Linss
Alison Maher
Myles Maxfield
François Remy
Morgan Reschenberg
Florian Rivoal
Miriam Suzanne
Lea Verou
Regrets:
Tantek Çelik
Chris Lilley
Greg Whitworth
Scribe: dael
Media Queries
=============
duplication of `forced-colors: active` and `prefers-contrast: forced`
---------------------------------------------------------------------
Github: https://github.com/w3c/csswg-drafts/issues/5433
alisonmaher: For a bit of context, chromium has implemented of
prefers-contrast behind flag. Pretty sure FF does as
well
alisonmaher: prefers-contrast: forced is duplication of
forced-colors MQ. Previously agreed to keep for compat.
Do we want to keep prefers-contrast: forced or not?
Strong arguments on both. jcraig summarized them well.
<alisonmaher> In favor of 'prefers-contrast: forced'-
https://github.com/w3c/csswg-drafts/issues/5433#issuecomment-716954048
<alisonmaher> Against 'prefers-contrast: forced'-
https://github.com/w3c/csswg-drafts/issues/5433#issuecomment-716954108
alisonmaher: In favor is it shortens the MQ needed to match any
combo of users and reduces likelihood that authors
overlook users with a different color scheme than less
or more
alisonmaher: Against is it doesn't add any additional benefit and
removing provides more clarity to authors on which to
use and how it works
alisonmaher: I tend toward remove because simplifies and matches
more to prefers color scheme approach which just
matches to dark or light.
alisonmaher: Perhaps a middle ground where we remove but still
capture the users, but not sure what that would look
like.
jcraig: Thanks alisonmaher for the summary
jcraig: One piece not mentioned is there's an assumption that all
forced-color users regardless of match less or more want
reduced complexity. I don't believe it's true. Don't have
evidence, but don't think evidence exists. My hunch is these
people customize and don't have a preference on complexity.
Seems correlation vs causation
jcraig: Suggestion alisonmaher mentioned about a way to match both,
I don't think it's desirable because I don't know of need.
Looked like dlibby commented along the same lines
<jcraig> dlibby's comment:
https://github.com/w3c/csswg-drafts/issues/5433#issuecomment-780191074
florian: Thanks to alisonmaher and jcraig.
florian: I disagree with jcraig this is people tweaking colors
because forced-colors changes the colors of your webpage
and since you don't have full range of colors available a
number of things will break like gradients. force-color
palette is reduced
<TabAtkins> florian is saying exactly what i was going to
florian: because of that I think we fall into needing reduced
complexity
<fremy> I agree with florian
florian: Otherwise, I think priority of consistency applies. For
authors separation is nicer. Slightly shorter syntax is
probably not worth it. Users, though, nice for the small
set of users not to be forgotten
astearns: Any other comments?
[silence]
astearns: Proposal is remove the forced value for prefers-contrast
and de-link the two media queries
florian: I think we've made progress about where there's an issue.
Not sure we agree on the solution
jcraig: On mac and iOS the underlying architecture allows us to use
increased contrast and other settings and would allow a
really high contrast forced-colors in the future. Similar to
Microsoft. Issue we've seen in the past is because Microsoft
is only implementation of forced-colors we don't know end
result will match that exactly
jcraig: We don't have direct plans to do that, but I'd like to see
it.
jcraig: Leaving the forced-colors media feature open and extensible
would allow us to better match variants across
implementations. Shoehorning into prefers-contrast limits
that in the future. I think it would be good to leave
extensible
Rossen: Quick point, chrome is almost done so won't be only one I
presume
jcraig: I'm talking platform, not browser
Rossen: My bad. I thought you were talking about browser
Morgan: I have a follow up. FF has its own version of forced-colors
that we allow on any platform. It's another implementation
same as Microsoft one. There is another sort of platform
impl there.
TabAtkins: In jcraig's earlier comment you seemed to say you should
leave forced-colors more open. Do you think there's
anything we could query for about forced colors beyond on
or not? From our designs there wasn't anything you can
conclude beyond on or not
fantasai: And forced-color limits the palette. You could have
forced-color that's similar to increased contrast which
keeps hue but turns the contrast way up, but that would be
a different feature
TabAtkins: I don't think that's consistent with idea of
forced-colors as we have
fantasai: yeah, forced-contrast mode
jcraig: Speculating on that question. Closest thing I'm aware of is
closed captions have default colors and forced colors.
Similar to user styles vs overwritten user styles where you
can say if media doesn't specify the font then I want it to
be in monospace. If it does specify leave as specified. And
you can override author
jcraig: Closest thing to speculate on is this mixed force-ness where
you may say for caption blocks I want forced, but don't care
about others. Mixing of DOM and elements. All speculation
florian: I think today I'm the only one who explicitly was in favor
of retaining it. I would like a sense of if I'm alone
TabAtkins: In IRC both fantasai and I said we think the same as you
fremy: And I did
astearns: My take is we have two separate opinions and neither side
has convinced the other. My bias is remove until people
can be all convinced it should be there
fantasai: Would create compat problems. prefers-contrast is
triggering...I guess can try, but if triggering on some
cases but not other and we change it. Would be a minority
of cases, I guess
Rossen: Do you have data?
florian: My part it's logic but not data. I suspect Microsoft is
only party with data. We would want to look at the
particular color schemes used by those with forced-colors
which are neither high or low contrast
Rossen: What about data of use removing it and looking for compat
risk?
florian: That's future compat. If we do it one way and switch there
are problems. If we remove it a small minority of users
would have things worse if you follow my logic.
dlibby: Wanted to note we can gather data as we ship to understand
impact. On compat point seems main motivation is for user
and not web author. If seeing harm for users I think that's
more of a concern than compat since those are the users who
want these rules. But data of shipping without value could
be useful
jcraig: I would agree if there's evidence. but florian said it was
based on logic, sounded like speculative logic.
jcraig: Quoting dlibby from the issue, florian said Microsoft would
be one to know. dlibby says [reads]
jcraig: It's about author and user benefit
jcraig: And if this is larger problem in practice we can add, but
removing is more difficult. It sounds like that comment is
in favor or removing now. Fair dlibby?
dlibby: Yes
<jcraig> dlibby from the issue: "We didn't get to this in the F2F
last week, but I agree with the core of @cookiecrook's
argument - I don't think there is strong evidence for the
boolean form of prefers-contrast being used to reduce
visual complexity, and would probably be difficult for
authors to reason about (enhancement in service of
respecting a user preference is much different from
adjusting in response to forced changes to a page's
appearance)."
<jcraig> … "Also, if this does become a larger problem in practice,
we would have the option of re-adding the value, whereas
removing it would be more difficult. Another option (either
now, or if the boolean usage ends up being problematic)
would be always mapping forced colors mode to more or less,
similar to what is done for prefers-color-scheme."
<jcraig> ..."As anecdata, I also ran across this blog post that
expresses some of the same sentiments:
<jcraig> https://kilianvalkhof.com/2021/css-html/prefers-contrast-forced-is-a-mistake/
"
TabAtkins: Not to belabor too much. Idea about unclear author
guidance, the point is there is explicit author guidance.
Anyone with contrast preference you should reduce visual
complexity.
<fantasai> agree with jcraig's last assessment
<fantasai> (and also the point TabAtkins is making now)
TabAtkins: Concern with add later is by then benefit of hey this is
a new feature user guidance is lessened. Would be nice to
have consistent story to say most of the time use
prefers-contrast in boolean and you can listen to more or
less or system pallet, but for overall design boolean
works great
TabAtkins: If we decide we don't want it's not more problematic then
adding in the future. Worst case we say it never matches.
Not great, but we've had it before and can shove in an
appendix
florian: I did feel strongly against removing while we hadn't
reached understanding about the question because felt bad
to users was inappropriate. We do understand the
disagreement now. Still feel strongly, but less bad about
being overruled.
astearns: Can we get a resolution to remove the value and unlink the
features and if there's user data in the future we can
revisit
fremy: Removing the value, we also mean if people enable the high
contrast but set at middle contrast they won't match the MQ.
That makes the feature useless. On windows I would just use
MQ for forced-colors. Or I would have to dup the code. I'm
not sure if value is nes but it makes sense.
fremy: Even if you treat the contrast as people from Apple said, you
want to remove complexity. You want same behavior when using
forced colors
emilio: Can't you just use or?
<jcraig> @media (prefers-contrast) or (forced-colors)
fremy: True, but thing is devs won't test special case. They will
assume prefers-contrast works. Nobody will catch this tiny
use case. That's the key of the issue
astearns: From my PoV, your particular case where someone used
forced-colors to select with no contrast, I would prefer
it did not match prefers-contrast because there is no
contrast. I think it's an argument to delink
fremy: Then maybe name is misleading. We want to use feature to
reduce complexity, maybe name is wrong. Seems it would be
unfortunate
jcraig: Was going to say same. This is core of disagreement. Half
the people think there's an association between people using
forced colors in the window where it doesn't match but they
still want less complexity
<jcraig> "In my opinion, if CSS needs a media feature for
prefers-reduced-complexity or prefers-improved-legibility,
the working group should consider those separately."
jcraig: I get it, but I don't agree it's a match. I also suggested
similar to your suggested fremy ^
jcraig: The contrast features should ONLY be about contrast and
forced-colors should ONLY be about forcing colors. I don't
agree with a 100% correlation
<TabAtkins> Alternate proposal: we drop (prefers-contrast) entirely
for right now while we study the problem more and see if
there's better things to do in the visual complexity
sphere
<myles> +1 to what james just said
fremy: What you said makes sense
astearns: jcraig's suggestion is I think we should consider
separately
astearns: Proposal: Removed the forced value
<jensimmons> I agree with what James just said — the 100%
association between the two isn't best.
<fantasai> jcraig, the reduction in complexity isn't because that's
specifically requested. It's because in a reduced
palette, you don't have the option to use intermediary
colors and you *have to* make changes accordingly
astearns: Will anyone object to removing it?
florian: Can we get a promise to collect data about the cases where
it would be different?
fantasai: What data do you want?
florian: Color schemes people use that would be neither high nor low
and therefore would no longer match. So we can look and see
if we made things better or worse
fantasai: Won't know unless you look at a page
TabAtkins: Since we have requirement that forced-color scheme opts
into more or less, assuming there's a middle ground
collecting data about it is would be valuable
Morgan: Adding probes in FF which should detect browser and platform
<florian> thanks Morgan
astearns: Objections?
RESOLVED: Removed the forced value from prefers-contrast MQ
astearns: TabAtkins' proposal to drop prefers-contrast all together.
Would get in way of collecting data
florian: Not necessarily. Collecting data about user settings, not
sites
TabAtkins: Yeah, data isn't about if MQ is used, how categorization
would work
astearns: I thought it would be useful to have to get set of people
that have chosen a color scheme and have the MQ but
missing out
jcraig: Sounds like a Windows argument. If we drop prefers-contrast
can't implement Apple contrast settings. They indicate a
preference for more contrast. We have a beta implementation
for prefers-contrast:more in WK
TabAtkins: The proposal is we drop temporarily while we think about
problem space of contrast and visual complexity. We can
bring right back when decide separate or don't need to
think about visual complexity. It would be worse if we
ship and then decide should be different.
jcraig: I don't think we've done this quickly. Has taken years to
standardize prefers-contrast values. Just agreed less and
more instead of high and low. Taken years because difference
between Windows, and MacOS, and Android.
jcraig: Reduced complexity has higher association to
prefers-reduced-transparency. I don't know we want to mix
streams, but if you're associating should be
reduced-transparency. Would object to removing
prefers-contrast
TabAtkins: They're all reasonably linked, sure. Concerned we have
large set of prefers options and authors need 6 MQs to
target when there's a potential most people can be well
served by broader MQs. Let the specific ones exist, but I
don't want 10 prefers queries that subtly interact in
ways that are confusing.
TabAtkins: Worried if we don't guard against it. Has taken a while,
but it's because people talk slowly. We can move quickly
if we want
<aja> might want to consider a way to SET prefers-contrast in user
stylesheet
astearns: [reads IRC comment]
fantasai: Can't really set in user stylesheet. Can in user
preferences. We're not going to introduce cycle between MQ
and properties
astearns: And users know how to set browser preferences much more
fantasai: When you have a reduced palette, which happens when you
have increased or reduced contrast or forced colors, you
have to make changes. You don't have intermediary colors.
You have to remove things that require drawing these
colors.
fantasai: Applies with forced-color or change in contrast. Argument
for prefers-contrast triggering isn't that they want to
reduce visual clutter, it's that you have less colors and
need to adapt. You can't use a subtle drop shadow. You
need a solid border or nothing
fantasai: If someone wants a reduced visual complexity category,
that's border and separate.
fantasai: Regards to prefers-contrast, if we want to try without
forced value at first we could. But I agree with TabAtkins
it means we can't teach it when forced-colors is on and
you can loop it into same MQ. Authors won't get benefit of
trigger on both. Forward compat issue won't be that huge
because most people will fall under prefers-contrast.
fantasai: The people that do fall in will have a problem or won't
and we can handle it later. But you don't get author
benefit to teaching the grouping
<fremy> Proposal: (color-reduction: forced | optional) and that is
`optional` when prefers-contrast is set to more or less
astearns: I'd like to close the discussion for this meeting.
TabAtkins if you want to continue the idea can you open a
new issue on GH?
TabAtkins: Sure
<jcraig> thanks for your time discussing this everyone
<astearns> jcraig thanks for joining today
CSS Images
==========
image-rendering:pixelated should not force "nearest neighbor" (or
similar) when the scale factor is far from an integer (e.g. 150%)
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5837
TabAtkins: Image rendering property controls how browses render when
scaling. Smooth or pixelated. pixelated uses nearest
neighbor. Great so long as scaling up by integer multiple
of size. 2.5 times as big and it's terrible
TabAtkins: You don't get consistent line weight. Something could be
2 or 3 px depending on precise details.
TabAtkins: At least 2 people in this issue brought up the problem.
Want to retain pixel-ness but don't want it to look bad.
Minor smoothing okay.
TabAtkins: Proposal is a value that does nearest neighbor scaling
and use smooth scaling to close gap.
<florian> Proposal makes sense to me.
TabAtkins: Use cases seemed reasonable. Canvas-based using pixel art
and you don't want jaggies but you don't want to force
canvas. You want to scale as you can
TabAtkins: Reasonable to me. Happy to add if reasonable to others
fantasai: Overall makes sense. I think we should allow overshoot and
scale down. If you're 2.8px might make sense
TabAtkins: Right. Should test, but we should scale to nearest
multiple and then go up or down smoothly
smfr: Does image-render pixelated apply to canvas
TabAtkins: It's supposed to. It's an image source
smfr: With houdini? That's only way to get it in
TabAtkins: canvas element is an image element. It's a replaced
element with a raster display of content. Intended to be
effected by image rendering
smfr: For a UA to implement it means painting image would be 2
steps. pixelated and then nearest neighbor to destination. Has
cost. Fine feature request, but additional cost
TabAtkins: I think you're right. Are you objecting or should we add
a note about don't use too much
smfr: Note in spec about performance is good
<smfr> image-rendering does not appear to affect canvas
vmpstr: Suggesting to mandate an algorithm or allow a different?
TabAtkins: Pixelated mandates nearest neighbor. This mandates to
nearest int and use whatever smoothing
vmpstr: Yeah. This would add cost
<fantasai> generally people don't use pixelated unless they really
want it, it's not the default
dholbert: I think we have this behavior in spec for scale of less
than 1. You do default image scaling. Nice to harmonize.
dholbert: Also, not clear. Is this proposal for new value or change
to pixelated
TabAtkins: Asked in thread. Authors thought different value. I
proposed merge into default. I could go either way
dholbert: If we did keep pure nearest neighbor, might be nice to
remove <1 special case and have pixelated scaling
separate. You can see as you spec
jfkthame: My understanding of last comment in issue is the
suggestion is this should be what pixelated does and true
nearest neighbor would be new. That makes sense to me.
This would be true pixelated and actual nearest neighbor
would be special
<fantasai> +1 jfkthame
astearns: Then you make current use of pixelated take the harder path
jfkthame: True, but I think it's the better result. Arguable
fantasai: I imagine it's not that common unless you want that effect
TabAtkins: You want for integer. If you use it in between it is
variable.
<fantasai> Comment jfkthame was referring to: “Personally, I agree
with baking this into pixelated. Yes, pixelated should
mean pixelated, but I don't think nearest neighbor
interpolation with 150% scaling ratio looks pixelated:
Squares that vary in size from 1*1 to 2*2 do not look
like pixels. I think it would be better to add a new
keyword nearest-neighbor, which means nearest neighbor.”
<fantasai> https://github.com/w3c/csswg-drafts/issues/5837#issuecomment-776951044
TabAtkins: dholbert where are you seeing scale down? I'm looking at
spec and there is no such difference between up and down
dholbert: I haven't looked at spec for a couple years. It was there
a few years ago. If it's been removed, that's great
TabAtkins: I'll research. not in current ED
astearns: Do you want resolution?
TabAtkins: Add this with caveats discussed in chat
fantasai: New value or adding into pixelated and nearest as new? I
personally agree with jfkthame
TabAtkins: Also agree with jfkthame. If vmpstr and smfr don't think
it would be problematic I would like to do that
astearns: Smoothing only necessary for non-int values?
TabAtkins: Yea
astearns: Proposal: Bake the smoothing into non-int changes in
current pixelated value. Add a new value for nearest
neighbor jaggedness
myles: Flip the names?
fantasai: I don't think so. Last commenter pointed out having a
variety of squares and rectangles representing source
pixels doesn't look pixelated. You want each pixel same
size. I think naming is better where pixelated is same size
astearns: Is that okay myles?
myles: No comment
astearns: Objections?
RESOLVED: Bake the smoothing into non-integer changes in current
pixelated value. Add a new value for nearest neighbor
jaggedness
Scroll Snap
===========
fantasai: Scroll snap- can we republish CR?
<fantasai> https://lists.w3.org/Archives/Public/www-style/2021Feb/0013.html
fantasai: Some issues. Here's a status summary ^
fantasai: If someone wants to insist on a test existing and will
volunteer to write, happy to hold off.
florian: CR-snapshot?
fantasai: Yes. Long time so should do one
astearns: Objections to republish CR-snapshot of scroll snap?
RESOLVED: Republish CR-snapshot of Scroll Snap
Ruby
====
Alternating sides for ruby-position
-----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5971
florian: 3 values; let's focus on over and under. Default is over
florian: If you have 1 layer it goes over. If 2 they both goover and
stack. If want one over one under need selector
florian: People sometimes want to stack, but majority is when you
have 2 layers (3 almost not done) people want one on each
side
florian: Separate selectors is annoying, especially given markup has
anonymous boxes
florian: Proposal is default value is auto or alternate which is
over with 1, over and then under with 2, and continue
alternating with more
myles: Didn't realize proposal is changing initial value. I think we
have ruby in books which is scary.
myles: Separating changing initial value from the new property is
good
fantasai: Don't think you support multi-level
myles: Doesn't effect nested. Multi level ruby in same element only?
fantasai: Yes.
myles: Then, now that I understand, if you tried to give this to use
we would have longer ruby text on top
fantasai: Not sure, haven't loaded it. It's a separate issue from if
you display on top or bottom
myles: General compat concern
fantasai: Yeah. If you don't support multi-level in same ruby
structure
florian: Problem is same no matter if value
myles: If we implement multi level without this we would turn 1
level to 2. With this we would turn it into 1 level above and
1 below
florian: If I remember your current impl, yes
astearns: myles resolve or investigate?
myles: Okay resolve. If things explode we can come back
astearns: Add an alternate value which is the initial value
RESOLVED: Add an 'alternate' value which is the initial value
Received on Thursday, 25 February 2021 00:07:42 UTC