- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 21 Mar 2024 19:05:11 -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.
=========================================
View Transitions
----------------
- RESOLVED: Make CSSViewTransitionRule readonly (Issue #10011: Make
CSSOM interface read-only)
- RESOLVED: Change use of DOMTokenList to something more appropriate
for readonly interfaces (Issue #10011)
- RESOLVED: Switch to using "types" in all the locations (Issue
#10070: 'type' argument that takes an array of types is
very weird naming)
- RESOLVED: Use "InvalidStateError" when skipping the view transition
due to document not visible (Issue #10101: Which skipping
reason does "View transition page-visibility change
steps" use?)
- RESOLVED: Fix algorithm error, always return transition object
(Issue #10101)
- RESOLVED: Publish CRD of css-view-transitions-1
CSS Scrollbars
--------------
- RESOLVED: No change to spec for non-transparent colors (tests need
fixing) (Issue #9851: How are the specified color used?)
- There were reasons to either pre-composite or ignore
semi-transparent and transparent colors for scrollbars. The group
did not have time to resolve so they will detail out the pros/
cons in issue #9853 (What do (semi) transparent colors mean for
scrollbar-color).
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2024Mar/0018.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins Bittner
David Baron
Kevin Babbitt
Keith Cirkel
Emilio Cobos Álvarez
Yehonatan Daniv
Elika Etemad
Robert Flack
Chris Harrelson
Jonathan Kew
Ian Kilpatrick
Roman Komarov
David Leininger
Vladimir Levin
Rune Lillesveen
Peter Linss
Khushal Sagar
Miriam Suzanne
Bramus Van Damme
Chair: astearns
Scribe: fantasai
Scribe's scribe: TabAtkins
View Transitions
================
Make CSSOM interface read-only
------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10011
emilio: We generally had resolved to make a bunch of new CSSOM
interfaces read-only
emilio: ViewTransition had a weird DomTokenList thing
emilio: I think we resolved to do dynamic changes in a different way?
If so I would prefer if it was read-only.
vmpstr: We've made the types mutable via ViewTransition object
<khush> +1
vmpstr: so I don't think we need to make the interface writeable, so
support change to readonly
<bramus> +1
astearns: Other comments/concerns with making readonly?
ntim: Does this affect anything in View Transitions L1
ntim: Curious if it affects existing implementations
?: This is for opt-in for cross-document transitions, so L2 only
ntim: Ok
<ntim> I removed the css-view-transitions-1 label from the issue :)
emilio: What interface does the CSS rule implement in L1vmpstr
vmpstr: It has an IDL retrieved via API call. There's no CSS at-rule.
emilio: Also DOMTokenList should probably be a FrozenArray or
something
PROPOSED: Make CSSViewTransitionRule readonly
astearns: any objections?
RESOLVED: Make CSSViewTransitionRule readonly
astearns: Should we try resolution for changing DOMTokenList?
fantasai: We can at least resolve that it needs to change
PROPOSED: Change use of DOMTOkenList to something more appropriate
for readonly interfaces
RESOLVED: Change use of DOMTokenList to something more appropriate
for readonly interfaces
'type' argument that takes an array of types is very weird naming
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10070
vmpstr: We have an attribute called 'type' in the opt-in block
vmpstr: the corresponding argument is 'type', which takes an array
vmpstr: issue raised that 'type' refers to an array of items
vmpstr: so bikeshedding issue to figure out what to call these
vmpstr: proposals include 'types' everywhere or using 'typeList'
vmpstr: interested in opinions
khush: I was suggesting to just use 'typeList'
khush: in a different place we resolved on this for CSS transition
rule
khush: several places where this is provided, should be consistent
khush: since we said 'typeList' for CSSViewTransitionRule, let's use
'typeList' everywhere
bramus: It was inspired by being a DOMTokenList, but no longer a
DOMTokenList
bramus: I'm a fan of using 'types', it works in both CSS and JS
<ntim> +1 to bramus
vmpstr: Wrt DOMTokenList, it wouldn't be in CSS object but in DOM it
might be
vmpstr: OK with renaming, but wanted to clarify
fantasai: I'm also a fan of consistency
fantasai: I unfortunately don't have much familiarity with the OM in
general
fantasai: But I remember going with typeList for consistency with
classList, but it's not a list in HTML, it's a
space-separated list of classes
fantasai: I think consistency across objects is important, but it
should be clear that if something is an Array it's an
Array, not a string
fantasai: We don't use much plurals in CSS syntax, it's unusual
bramus: There's some precedent in descriptors
bramus: override-colors, and symbols
fantasai: For those you're expected to give multiple values, you
really wouldn't give just one
fantasai: While for this, in many cases it's a single value
fantasai: So what are the options?
fantasai: CSSViewTransition at-rule descriptor
fantasai: and the corresponding CSSViewTransitionRule object
<khush> There is a summary here:
https://github.com/w3c/csswg-drafts/issues/10070#issuecomment-1997836510
vmpstr: startViewTransition() parameter
vmpstr: And last is ViewTransition object returned by that
fantasai: I have a question, for CSSViewTransitionRule
fantasai: We have something that represents the types as an array
fantasai: Do we also have that as a string? Or just as an array
vmpstr: We only have an array
<TabAtkins> (we don't have a consistent pattern in the OM for this)
fantasai: Is that normal for OM representations of a rule?
TabAtkins: It's not unusual.
khush: The other question is, for CSSVTRule, what type should that
have? Currently DOMTokenList, but could be a string or an
array of strings
vmpstr: And one limitation, the OM one can't be called "type",
because that already exists. And I think that's all the
restrictions.
vmpstr: I propose just "types" everywhere, we can revisit if someone
doesn't like it
<TabAtkins> +1 to this, personally
<bramus> +1
<khush> +1
<ntim> I like types everywhere
<ntim> There's className too if you look at class :D
astearns: proposed to use "types" everywhere. Concerns?
RESOLVED: Switch to using "types" in all the locations.
Which skipping reason does "View transition page-visibility change
steps" use?
------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10101
ntim: Implementing recent resolution to skip transition when document
is hidden
ntim: we didn't define the reason/exception to pass
ntim: Also noticed that the algorithm to prepare the view transition
returns nothing
ntim: in the case where it skips the transition because it's hidden
ntim: Seems it should return the transition
ntim: Seems like a bugfix issue?
khush: I think that was a typo, that algorithm should return
transition
khush: wrt reasonable exception to use, the other spot we use
"InvalidStateError" which seems like reasonable error code for
invisibility
<vmpstr> +1
ntim: sgtm
astearns: anyone else?
RESOLVED: Use "InvalidStateError" when skipping the view transition
due to document not visible
vmpstr: If transition is skipped, algorithm steps should still return
'transition'
khush: It's an error in the spec, should be returning that in al cases
RESOLVED: Fix algorithm error, always return transition object
Publication
-----------
fantasai: Do we need to publish a new CR?
khush: If there's other issues to batch up, can batch up. Otherwise
ok to republish
ntim: I look at ED when I implement, so fine either way
fantasai: It's a problem if the ED is more reliable than the /TR
copy, so let's do a CRD.
astearns: Proposed to update draft with all resolutions and update
CRD of VT1
RESOLVED: Publish CRD of css-view-transitions-1
CSS Scrollbars
==============
How are the specified color used?
---------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9851
florian: Contradiction between spec and tests
florian: Tests are being more specific than the specs
florian: css-scrollbars allows setting color of thumb and track
florian: doesn't say how the color is used
florian: My interpretation was similar to accent-color, browser can
use in a reasonable way
florian: if scrollbar is very plain, then it will be very basic
florian: but if has highlights, shadows, shaping, etc. then it would
tint appropriately
florian: Tests assume flat color
florian: and e.g. transparent means you can't see the scrollbar at all
florian: Either the tests or the spec are wrong, since they don't
agree with each other
florian: Lea opined that it should indeed be like accent-color
emilio: Agree in general, if you specify a color you're not forced to
use just that color
emilio: but if you set both colors to transparent, it should probably
require a transparent scrollbar
emilio: mostly because that's a useful way to e.g. show the scrollbar
on :hover
florian: There's a separate issue on transparency
florian: could consider it a special case or not
florian: If no special case for transparency, then need to figure how
it's special
emilio: I added some of the transparent tests because someone was
trying to go for this effect, and we didn't have it working
on linux
fantasai: I agree with Lea's comment in the issue
<fantasai> https://github.com/w3c/csswg-drafts/issues/9851#issuecomment-1994722439
fantasai: You should use the color to generate a usable scheme that
matches the way the scrollbar is normally styled, and the
color itself should be used *somewhere* (rather than just
variations of it)
florian: Propose resolution that at least if the color isn't
transparent, do what Lea said
astearns: So for non-transparent colors, current tests are invalid?
florian: Right
florian: Means it'll be hard to test, but that's a separate problem
astearns: Proposed no change to spec for non-transparent colors,
meaning current tests are over-prescriptive
florian: Might add a note to highlight this impact, but no normative
change to spec
<fantasai> +1
RESOLVED: No change to spec for non-transparent colors (tests need
fixing)
What do (semi) transparent colors mean for scrollbar-color
----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9853
florian: Spec doesn't say what happens to transparent/
semi-transparent colors if you specify them
florian: You could ignore the alpha channel
florian: or pre-composite against some color, maybe white, maybe
white or black depending on 'color-scheme'
florian: maybe transparent thumb over track is possible, but track is
opaque
florian: variety of possible options
florian: e.g. emilio just mentioned making thumb and track invisible
florian: But what about partially transparent?
florian: Does the non-colored part of the scrollbar also become
invisible?
florian: There's no requirement that scrollbar contains only thumb
and track
florian: but in the past, and in some systems still, scrollbars could
have up/down buttons as well
florian: Do these become invisible as well?
florian: Which options seem reasonable?
florian: Lea commented that alpha channel shouldn't be ignored
florian: suggested pre-composing against white/black
florian: or 'canvas', is equivalent to black/white?
emilio: Not necessarily
flackr: Color used for thumb makes sense to apply to other buttons
flackr: maybe make that explicit?
flackr: For transparency, I can see use-cases for semi-transparent
thumbs
flackr: maybe make them look frosted or something
flackr: maybe keeping their transparency to some extent allowed
flackr: but I don't think the rest of the scroll controls should be
made more transparent
flackr: UA should be free to make it clear that the scroll thumb is
there
flackr: to be interacted with
emilio: I also have a preference to not special-case transparency
emilio: let stuff be semi-transparent as much as the UA can deal
with it
emilio: Is there a good reason to not do that?
florian: Here, we're charging to supply both the foreground and
background, and thereby ensuring good contrast
florian: They need to know if the alpha channel will be ignored,
composed against black/white, or against content below?
florian: Whichever one we choose, needs to be consistent so author
can choose properly contrasting colors
<ntim> +1 to "as the UA can deal with it", some system frameworks may
not support it
fantasai: I agree with everything florian said
fantasai: Additional point, let's say you decide to honor the color
*and* transparency
fantasai: And on one system they use black scrollbars, just an oval
on a rectangle, flat color, no distinguishing features
fantasai: If you make both thumb and track transparent, it's invisible
fantasai: But on another system there's an aqua effect, 3d with some
shading
fantasai: That shading will exist on a fully transparent bar
fantasai: So on that page the scrollbar will still be visible, just
"clear"
fantasai: So I think we need some kind of consistency so when an
author gets one effect vs the other...
fantasai: So if they dev on Mac OS 2001 it looks good, but Mac 2011
you can't see anything at all...
fantasai: So whether it's visible and has enough contrast varies
depending on style, if you honor transparent colors
fantasai: So we need to make sure an author working on one platform
can know whether their styles will make a visible or
invisible scrollbar, on all platforms
PaulG: I brought up with APA, they offered to help with the language
PaulG: and ensuring contrast/affordances etc.
PaulG: Consistency helps everyone, but even if not consistent, APA is
comfortable going forward as long as articulated
florian: Given fantasai's argument, that pushes us towards
precomposing, to get you reliable colors
florian: You could still end up with white-on-white and
black-on-black and have that be visible with shading and
invisible otherwise
florian: but if doing foreground and background are the same, you'll
have issues on some platforms -- most platforms currently
emilio: I think we should at least specify that if you provide 0
alpha channel, then the whole thing is transparent, because
that's a reasonable use case
florian: why? why not use other ways of making invisible
emilio: Same as having any element invisible
emilio: Use case was showing scrollbar on :hover without layout
shift. You can do with scrollbar gutter nowadays but still
useful to not have to do any layout to show a scrollbar
emilio: I don't think we need to specify semitransparent colors super
deeply
emilio: forcing you to compose on a flat color, that's a bit weird.
emilio: E.g. on linux/firefox you only show thumb. Track is mostly
transparent.
emilio: I think we should leave the rendering of most of these
semitransparent colors up to UA and how they can provide a
good scrollbar with what they get
fantasai: If we want invisible scrollbars, have a keyword for that.
Transparent won't guarantee invisible scrollbars
emilio: I don't feel super strongly, but fading a scrollbar by
animating alpha channel is nice
fantasai: If scrollbar is shaded, it'll animate from clear to purple
or whatever, it just won't actually be invisible because
the shading will be there
emilio: I don't think current platforms do shading
emilio: If fully transparent is actually invisible, then the
animation would work in such a platform
kizu: Maybe this could be considered alongside another issue, 9855
about the track and overlay scrollbars and setting colors
kizu: If we could require UAs to make the thumb and track to always
have contrast, we should do it
kizu: and then we might make an exception for completely transparent
scrollbars for authors that want to make it completely
invisible but still take space
kizu: I'm not sure if we want to provide this use case, or always
want hidden scrollbars [missed]
kizu: Issue with making this a special case is that it might not work
for UAs for transitions, if you want to have scrollbar appear
if UA chooses to precompose colors against some other colors
kizu: if we precompose completely invisible, at zero it disappears
immediately. That's maybe an issue
florian: I'm open to a variety of option, but what is not reasonable
is to not specify
florian: if the author can't know if precomposed over white or black
or actual element background, they can't ensure their colors
provide contrast
florian: because they don't know what their colors mean
florian: so we can't allow one or the other, we have to pick one.
florian: Emilio is leaning towards "don't precompose"
florian: Another question in another issue about whether you're
required to paint the track at all in overlay scrollbars,
hoping to keep separate
flackr: Desire that you see things the same suggests an alternative,
require that we use the opacity from the color for the rest
of the painting even if it is shaded
flackr: Unsure if that's ideal, but would allow things to fade
consistently
flackr: but maybe if fully transparent don't want it to hit test
either
flackr: so maybe separate property
<ntim> Some system frameworks don't support alpha, so if we specify
anything I'd rather have it be simple
fantasai: If fading the scrollbar is something people really want, we
should have scrollbar-opacity that controls it all,
including the parts the author isn't coloring
fantasai: Lots of things potentially in a scrollbar that potentially
aren't under author control
fantasai: But downside of making it transparent when not hovering -
if the element has focus but not hovering, and someone
assuming it's only scrollable when there are scrollbars,
someone using a different mechanism won't know it's
scrollable
emilio: Similar thing with accent-color, and e.g. Chromium ignores
alpha channel, Firefox tries to deal with it, and unsure
about WebKit
<ntim> AppKit doesn't support changing scrollbar colors, so neither
does WebKit
florian: Answer might be the same, but for accent-color, it is
different because in that case the author is only providing
one color -- UA is charged with providing good contrast
florian: but for scrollbars, the author needs to ensure contrast
florian: Either UA ensures contrast, or we specify how the colors
composite so the author can know whether they get good
contrast
astearns: I think I'm convinced that we should not try to solve the
fully-transparent case with scrollbar colors because there
are other bits of the scrollbar which may not be under
these colors' control
astearns: I find that logic compelling
florian: If we go that way, then do we specify semi-transparent
colors to be pre-composed? I think these two go together...
astearns: Yes, but less convinced about that
astearns: Anyone want to argue for ignoring alpha channels in
scrollbar colors entirely?
florian: What you propose seems reasonable, may be other options
<ntim> pre-composing is hard because we don't know what background
to use
astearns: 2 options are ignoring or pre-composing
fantasai: Lots of points brought up in this discussion, might be good
to list the good options and pros/cons, and resolve later
Received on Thursday, 21 March 2024 23:05:45 UTC