- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 15 Feb 2023 19:07:10 -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.
=========================================
Administrative
--------------
- The team will have multiple two hour calls over several weeks in
lieu of a F2F.
CSS Position
------------
- RESOLVED: stickypos makes a stacking context, just like fixpos
(Issue #1053: position:sticky should create a stacking
context)
- RESOLVED: Clarify that due to the box-tree re-parenting, an
ancestor outside the dialog can't be a fixpos CB for
descendants of the dialog (Issue #8040: Containing block
of dialog fixed position children)
- Diagrams and demos will be added to issue #8040 to help resolve
what exactly is the CB of a fixpos descendant of the dialog.
Publications
------------
- RESOLVED: Publish new WD of Position 3 and Align 3
CSS Color
---------
- The group reviewed argyle's proposal for issue #7937 (Let's
finally settle contrast-color() syntax).
- There were parts that team members were interested in
exploring more such as having short keywords to give some
reasonable defaults.
- The proposal would not allow for multiple algorithms which
could be necessary to accommodate the current wcag
requirements.
- There's a desire to explore the syntax further as well as
other functional algorithms.
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2023Feb/0007.html
Present:
Rachel Andrew
Adam Argyle
Rossen Atanassov
Tab Atkins
David Baron
Oriol Brufau
Tantek Çelik
Emilio Cobos Álvarez
Yehonatan Daniv
Elika Etemad
Robert Flack
Simon Fraser
Paul Grenier
Chris Harrelson
Brian Kardell
Jonathan Kew
Peter Linss
Alison Maher
Eric Meyer
Miriam Suzanne
Lea Verou
Regrets:
Daniel Holbert
Chris Lilley
Chair: Rossen
Scribe: TabAtkins
Scribe's scribe: fantasai
Administrative
==============
Rossen: As said on the private list, no actual f2f for now.
Rossen: Instead the proposal is to have two 2hr calls for two
consecutive weeks, spaced by a day. Wed 2hr, like today, and
the same on Friday.
Rossen: Unless there are alternatives or strong reasons to not do
it, we'll schedule that.
Rossen: Gonna be mid-March, either 8/10/15/17 or 15/17/22/24
fantasai: Does it make sense to do Friday? That's late for Europe
and Japan on a Friday...
Rossen: Yeah, the alternative of not having a day between meetings
would make it harder for more folks.
Rossen: Other chance is not do Wednesday, do Tue/Thu instead
TabAtkins: why not Monday Wednesday?
TabAtkins: I don't have a strong opinion either way, but seems odd
not to consider it
<dbaron> I agree that Friday is problematic for many folks.
<dbaron> (was going to raise that as well)
Rossen: Let's agree on having two 2hr calls on two consecutive
weeks. We'll dial in the exact dates asap on the private list
CSS Position
============
position:sticky should create a stacking context
------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1053
fantasai: Simon raised an issue a while ago that stickypos should
make as tacking context, like fixpos
Rossen: Is there a reason it's not already a stacking context?
smfr: WebKit's been shipping that way for a long time
TabAtkins: Previously, wasn't necessary
TabAtkins: but now in chromium it is
TabAtkins: Wanted to check that we're okay with the change to the
spec
<TabAtkins> Oh sorry, stickypos stacking context isn't in the spec;
fixpos is. So we will still need to make an edit.
Rossen: Objections?
RESOLVED: stickypos makes a stacking context, just like fixpos
Containing block of dialog fixed position children
--------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8040
smfr: If you have fixpos inside a dialog, and dialog is on top
layer, what's the containing block of the fixpos?
smfr: Dialog can be abspos *or* fixpos itself
smfr: If dialog is abspos, what's the fixpos behavior when the user
scrolls the document?
smfr: If dialog has a transformed ancestor, does that affect the
containing block for the fixpos descendant?
smfr: Both of these are impacted by whether the dialog itself is a
CB for the fixpos
smfr: The top layer is kinda viewport-like
chrishtr: Is there interop on this or not?
emilio: I think we don't enforce dialog to be a fixedpos dialog, but
we want to
emilio: the containing block chain is pretty weird otherwise
emilio: or at least we need to spec that any fixedpos inside the top
layer are also in the top layer
emilio: otherwise, breaks the assumption that the containing block
... the in-flow content is laid out before the fixedpos
emilio: so unclear how the hypothetical positions work if you don't
at least define that they go in the top layer as well
emilio: in that case might want to make the dialog a containing
block as well, much easier
emilio: don't see the point to have a fixedpos and not want it in
the top layer
<chrishtr> I don't think chromium makes dialog a containing block
either
fantasai: I think making it in the top layer makes sense
fantasai: I can imagine that you might not want the dialog to be a
fixpos CB
fantasai: because you might actually want something outside the
dialog wrt the viewport, while having the dialog open. Can
definitely imagine that
emilio: At that point we've given a special way to put something in
the top layer...
TabAtkins: what's the concern about putting in the top layer? dialog
is already there
emilio: It might be fine, I need to think more about it
chrishtr: Seems like it'll be okay to me
chrishtr: The fixpos goes in the top layer, and if the dialog
scrolls the fixpos won't scroll with it
chrishtr: That seems doable and not problematic; I assume that's how
browsers would automatically work
smfr: What do you mean by "in the top layer"?
chrishtr: z-order
smfr: This is about CB, not painting order
chrishtr: Right, if the fixpos has a transformed ancestor within the
dialog, that'll trap the fixpos as normal. If the
transformed ancestor is outside the dialog, it won't
affect it - it's specified as re-parenting in the
rendering tree.
smfr: So if you have a nested set of position:fixed do they all go
in the top layer?
chrishtr: top layer is just re-parenting and stacking context, it
doesn't affect the CB
chrishtr: Maybe we should make some demos and come back to the group
Rossen: Sounds reasonable
Rossen: Ok let's collect some examples in the issue
emilio: I think there's consensus that a transformed ancestor of the
dialog isn't a CB for the fixpos, due to the re-parenting.
proposed resolution: Clarify that due to the box-tree re-parenting,
an ancestor outside the dialog can't be a fixpos CB for
descendants of the dialog
<emilio> +1
<fantasai> wfm
<masonf> +1
<chrishtr> +1
RESOLVED: Clarify that due to the box-tree re-parenting, an ancestor
outside the dialog can't be a fixpos CB for descendants of
the dialog
(Still unresolved: what exactly the CB of a fixpos descendant of the
dialog is.)
Publications
============
github: https://github.com/w3c/csswg-drafts/issues/6900
fantasai: We'd like to publish Position 3 with the stickypos change
we just resolved.
fantasai: Also publish Box Alignment
fantasai: Some of the issues we fixed crossed between these specs.
Rossen: Objections for new WD of Position 3 and Align 3?
<fantasai> https://drafts.csswg.org/css-position-3/#changes
fantasai: We did a substantial number of fixes to the staticpos
section, I'd definitely encourage people to look at that.
<fantasai> https://drafts.csswg.org/css-position-3/#abspos-insets
fantasai: Right now we still have an old-style "two versions" of the
spec - rewritten and non-rewritten. Probably want to drop
the non-rewritten soon, so if people can review the
rewritten is correct it would be great
fantasai: Particularly #abspos-insets, most of the changes are in
that section
<fantasai> https://drafts.csswg.org/css-position-3/#abspos-layout is
also a major part of the replacement (but less changes
lately)
fantasai: So requesting to repub, and hopefully in next repub we can
drop the old section
Rossen: Not hearing objections
<astearns> +1 to publish
<fantasai> https://drafts.csswg.org/css-align-3/#changes
Rossen: no objectiosn to Align 3 pub
RESOLVED: Publish new WD of Position 3 and Align 3
CSS Color
=========
Let's finally settle contrast-color() syntax
--------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7937
lea: The primary problem we couldn't settle on was what to call
foreground/background. We resolved to distinguish them in the
syntax but couldn't decide on names
lea: foreground/background too long, fg/bg too cryptic, others
suggested front/back, fore/back
lea: There's a table of the options
lea: And should we have a default if the keyword isn't specified?
Probably with bg as the base color, which'll be the most common
case? Or should we require the keyword?
fantasai: I think I'm strongly in favor of it being mandatory, so
people will pay attention
lea: Advantage of making it options is that only the fg word
actually matters so we can just pick a good name there. can
also be longer since it's not typed as much
argyle: That's my proposal - make it optional and have the whole
foreground keyword, since it's the exception.
<argyle> https://observablehq.com/@argyleink/contrast-color
argyle: This is the interactive explainer, syntax is right under the
demo
<argyle> https://www.irccloud.com/pastebin/mO4ENSCC/
Rossen: If you need to present visually, our next zoom meeting will
be next month
[more presentation chatter]
argyle: Bunch of examples in this observable document later
argyle: The current spec isn't far off from excellent, I think, so
my important bits in my counter proposal:
argyle: First, doesn't require a color list
argyle: Lot of presenting to devs and using it myself, I often don't
care about the final color
argyle: It'll find the first color that passes for you, in the same
hue, in whatever contrast algo you're using
argyle: Further my proposal builds in the contrast MQ pref
argyle: So if the user prefers more contrast and the page is
rendered without a color list, or an explicit contrast pref
in the function, the browser will take the user's preference
by default.
argyle: This potentially eliminates several MQs for authors to have
to worry about
argyle: If an author *does* write a specific target score - "Weber
2" or whatever - they're actually potentially excluding
users.
argyle: So if someone does want to handhold the contrast today, they
have to write several MQs to set things correctly in several
circumstances. My proposal folds it all in by default.
argyle: Color list is still important, if you *do* want it, but you
don't need it a lot of the time.
argyle: As said earlier, it defaults to "background". You can click
it to foreground and see it change the syntax to include the
keyword.
argyle: In most cases I've done I'm starting from a background, it's
just the most common.
argyle: Also have a "max" contrast target
argyle: If I just pass a starting color it'll get the max-contrast
color (white or black)
<astearns> "color: contrast-color(#eee / max);"
argyle: There's also options matching the contrast MQ - "more" or
"less"
argyle: Without having to specify exactly a contrast algo.
argyle: The contrast algo is auto by default, I know that's
controversial
argyle: Here's a demo
<argyle> https://codepen.io/argyleink/pen/RwgzJXV
argyle: I'm writing a codepen with light/dark and low/medium/high
contrast
argyle: You should be immediately overwhelmed
argyle: Just a lot to write
<argyle> https://codepen.io/argyleink/pen/eYKmMmN
argyle: This demo is what I've seen people instead already do
argyle: Hand-managing oklch deltas in each MQ. Slightly automated,
better than WCAG 2 but not perfect. But it works today and
gets light/dark and low/medium/high contrasts
argyle: My proposal today would make both of those demos a one-liner.
argyle: Looks at user pref and auto-discovers what colors they
should get
<argyle> contrast-color(Canvas)
argyle: This one-liner gives you light/dark and low/med/high contrast
argyle: Current proposal requires authors to write a longer
function, and repeat it several times.
argyle: so "auto" as the algo complements the author's desire for
not having to make a choice. browser can just do what's bet.
argyle: If there's no auto target there's no way to give up choice
argyle: So to summarize, my proposal doesn't require a color list,
defaults to background, offers less/more/max contrast
keywords, has an auto contrast keyword
argyle: It starts simple, *can* do everything currently in the spec,
but doesn't require all the complexity immediately.
lea: We all like sensible defaults, but there were several issues
with default algorithm that were discussed ad nauseam
lea: WCAG 2.0, the current default, is just bad. There are better
algos, but there are patent/licensing issues
lea: In our experiments in Color.js the other contrast algos listed
in the proposal don't actually give good results either
lea: So I don't think they're needed
lea: I like the idea of integrating this with the preferred
contrast MQ
lea: Unclear what it does exactly - same keywords, or does the MQ
value actually affect the function?
lea: minor comment - I find the identifiers side-by-side kinda hard
to read, like "abca max"
lea: Nothing making it clear that they're tied together - current
syntax makes the algos functions so you're sure the args are
related
lea: Also not sure what "more"/"less" correspond to mechanically
lea: I do like the idea of having background be the default
lea: Not sure we need "background" keyword at all then
argyle: yeah, wcag2 is bad, apca3 is still not producing good
results yet, still a few years out
argyle: If we wait for optimal it'll never ship
argyle: I think auto sets it up to grow and for users, if they have
a pref, they can specify it
argyle: I think most people won't even look past wcag2 being bad
argyle: so it's hard for us
argyle: Say apca comes out and is stable, firefox flips to that, it
would be neat to see it upgrade over time
argyle: I just don't like baking in a bad choice
argyle: I also agree nobody really knows about the other algos, yeah
argyle: So MQ syntax, what is more/less? I had to invent this in my
demo - what is more/less in each algo?
argyle: I have a table in my proposal mapping them to particular
values in each algo.
argyle: we'll have to figure this out anyway, for the MQ
<lea> Btw our experiments with these other algos (for black/white
only): https://colorjs.io/apps/blackwhite/
<TabAtkins> +1 to the simple keywords that correspond to *some*
reasonable values for the algos, I really like that
<argyle> contrast-color(#eee / max apca)
argyle: You commented that this looks a little weird
argyle: I think this reads really nice personally
argyle: I want max contrast from apca
argyle: If you do change the algo to something else, you're saying
"here's my bg color, here's the target score"
argyle: --and hopefully you always use auto, anything else can
exclude users with particular prefs--
<lea> I also like "more" or "less"
<lea> just remembered, there's also the issue of allowing multiple
algos (e.g. a good one + wcag for legal requirements), this
syntax cannot grow to accommodate that since params and algos
are on the same level
lea: I wrote in IRC what I was gonna say
lea: In prev discussions several WG members were skeptical about an
auto algorithm that can change
lea: We'll freeze in practice anyway
lea: The other issue is that we might want to allow multiple algos
that all need to pass - specify a "good" algo but also a
"legally required" algo. Current syntax doesn't accommodate
this, since the algo specifiers are on the same level as the
algo name itself
lea: I do like the more/less keywords fwiw
<argyle> contrast-color(#eee / 60 lstar)
argyle: You're right, I can't do multiple algos right now -
"60 lstar, and 4 wcag"
<lea> contrast-color(#eee / 60 lstar 5.4 wcag2) makes no sense
fantasai: I think this exploration was very helpful
<lea> +1 to this exploration being very helpful!
fantasai: I do think there are problems with the proposal
fantasai: Really do need to keep the target amount a functional
argument
fantasai: Both good for reading and for parsing
fantasai: functional notation lets us extend the new algos with
whatever we need without ambiguity
<argyle> functional notation is an easy change
<lea> (note that functional notation can also have an argument-less
syntax, where we omit the ())
fantasai: I have concerns about auto picking colors to minimum
acceptable contrast
fantasai: "pick the right contrast" is usually not the minimum
acceptable
<TabAtkins> (we can also have some simple args to the "default" algo
not require mentioning the algo)
[missed]
fantasai: If we do color ranges, should probably have ability to do
ranges of any color, not just the bg hue
fantasai: maybe default it to the bg hue
fantasai: Back to syntax, you're having a color, then a slash, then
a list of colors
fantasai: Some disagreement in earlier proposals about where the
algo goes, I find your syntax choice interesting and think
it reads nicely
fantasai: wrt fg/bg I'm pretty strongly against allowing one of them
to be defaulted. I do think that needs to be an explicit
choice
fantasai: but I think we can do that without being too wordy if we
put it into the function name - contrast-foreground() and
contrast-background()
<fantasai> https://github.com/w3c/csswg-drafts/issues/7937#issuecomment-1431751840
fantasai: And I think we need to tackle these problems individually
fantasai: auto algo? No, we already resolved that.
fantasai: function algos? etc. we can address those one by one.
<lea> unclear if contrast-foreground(red) is declaring that red is
the foreground or asking for a foreground color where red is
the background
<TabAtkins> Yeah I think that's confusing too
Rossen: We'll continue discussing in issue.
Received on Thursday, 16 February 2023 00:07:52 UTC