- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 12 Jan 2022 19:15:12 -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
--------------
- Next week's meeting will be an extended session from 8-10amPT
CSS Color 3
-----------
- RESOLVED: Republish CSS Color 3 REC as editorial update (Issue
#6910: CSS Color 3: Proposed Changes)
CSS Containment 3
-----------------
- There wasn't a clear preference for issue #6870 (Spec syntax for
size queries) on the call. People are encouraged to engage on the
issue to reach a decision.
- RESOLVED: Boxes default to style containment, syntax of 'container'
and @container preamble is name / type (Issue #6393:
Provide a syntax to query a specific container-type)
CSSOM View
----------
- RESOLVED: Work on solving these use cases for an isVisible API and
revisit in a future call (Issue #6850: add
Element.isVisible[toDocument] to detect if element is
visible in the document)
CSS Color 5
-----------
- RESOLVED: Add color-extract() to Color 5 and continue work (Issue
#6937: color-extract() function to extract individual
color components)
- RESOLVED: Close no change (Issue #6938: Make all color components
in Relative Color Syntax optional)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2022Jan/0005.html
Present:
Rachel Andrew
Adam Argyle
Rossen Atanassov
Tab Atkins Bittner
David Baron
Oriol Brufau
Tantek Çelik
Emilio Cobos Álvarez
Elika Etemad
Simon Fraser
Megan Gardner
David Grogan
Chris Harrelson
Dean Jackson
Brad Kemper
Jonathan Kew
Una Kravets
Vladimir Levin
Chris Lilley
Ting-Yu Lin
Peter Linss
Alison Maher
Morgan Reschenberg
Jen Simmons
Miriam Suzanne
Lea Verou
Regrets:
Delan Azabani
Scribe: fantasai
Scribe's scribe: florian
Administrative
==============
Rossen: Reminder, long-form meeting next week
Rossen: We'll go one hour earlier
Rossen: and for two hours
Rossen: 8am Pacific - 10am
Rossen: Will work with Tab to set up Google Meet so we can have
videochat
florian: Can you please put it into the WG calendar
florian: W3C has a calendaring system, we should use it
CSS Color 3
===========
CSS Color 3: Proposed Changes
-----------------------------
https://github.com/w3c/csswg-drafts/issues/6910
chris: We published an updated REC that includes 4 candidate
corrections
chris: Been up for review for a few months
chris: Minor things like removing 'Media' lines in propdef tables
chris: Main uncertainty is whether HSL is defined by pseudo-code or
if the pseudo-code is informative
chris: my interpretation is the latter
chris: We did have a bug report that the JS in the examples was
wrong, so fixed that
chris: and I added the JS from Color 4 to Color 3
chris: My assertion is that everyone knows what HSL is, and defined
by a paper (which is paywalled, but still)
chris: So my interpretation is the code is informative
chris: If we can agree as a group that all of those changes are not
substantive, we can just republish the thing
chris: otherwise have to do full AC review
fantasai: All the things I noticed when reviewing was editorial
changes, so just republish
<dbaron> Publishing sounds fine to me too.
Rossen: Any other opinions?
RESOLVED: Republish CSS Color 3 REC as editorial update
CSS Color Adjust L1
===================
github: https://github.com/w3c/csswg-drafts/pull/6731
fantasai: Don't remember why this is on agenda
fantasai: Snapshot us updated, and I think we have a resolution in
place?
chris: There was a new issue, significant change, do we need a
separate resolution?
<fantasai> change -> https://github.com/w3c/csswg-drafts/pull/6731/files
fantasai: We need a resolution to accept the change
Rossen: Ok, since Tab and emilio aren't around, let's review this
next week
CSS Containment L3
==================
Spec syntax for size queries
----------------------------
github: https://github.com/w3c/csswg-drafts/issues/6870
una: Written similar to MQ that could write width/min-width to query
for a size
una: but this was removed from the spec
una: requires size() function
una: My suggestion is to keep the bare parens syntax
una: as well as size() function
una: Easier for developers because similar to MQ
una: Think devs would be confused if it doesn't work like MQ
miriam: So anything in parens that's not a function, would be a size
query
miriam: I'm OK with that, we went with consistency in the first draft
fantasai: I don't think we should have two syntaxes
fantasai: Either have a function, or don't have a function
una: I prefer not using the functional notation
una: I think it's clear enough without
miriam: The function is there to be consistent with / distinguish
from style queries
miriam: both can be querying 'min-width' as a size or 'min-width' as
a property
una: If someone has mental model of familiar tech like MQ, will
likely try that syntax first for container query
una: querying size will be a popular technique
<iank> what does it look like when you combine size & state/etc?
fantasai: Anyone have an opinion?
jensimmons: I agree with all three people
fantasai: But what does that mean?
jensimmons: Doesn't mean anything
Rossen: Should discuss in issue maybe? Get a stronger opinion?
miriam: I'd like it if people put their opinions in the issue. Has
been open, not many comments.
Rossen: Ok, so pls add your opinions, and we'll come back to this
next week
Provide a syntax to query a specific container-type
---------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6393
miriam: Really wanted a way to query which type of container
miriam: e.g. find nearest inline-size container
miriam: Already the query has two parts to it
miriam: Can query a specific named container
miriam: and then main query list is what queries against that
container
miriam: so adding to preamble ability to filter by container type
miriam: In the discussion fantasai suggested that we could matched
the syntax of the container shorthand property
miriam: Currently that syntax requires a type, and then slash, and
then any number of names
miriam: That could work, but in our initial formulation the container
type is required to establish a container
miriam: which is why it's first
miriam: but for queries, seems that putting name first makes sense
miriam: since most people will be querying name, not type
miriam: Also discussion that all boxes can be style containers
miriam: which would make type container
miriam: make a style container
miriam: In that case, we could start with names in container property
miriam: and if you wanted to make a type of container without a name,
would have to start the value with a slash
Rossen: Any opinions?
<miriam> this comment lays it out:
https://github.com/w3c/csswg-drafts/issues/6393#issuecomment-988216116
miriam: Comment summarizes the proposal
miriam: 3 resolutions
miriam: 1. Make style as the default container type, all boxes can
take
miriam: 2. Changing 'container' property syntax to name / type
miriam: 3. Changing @container preamble to match
florian: I think we should take all 3, only make sense if we take
them all
Rossen: Any objections to resolving on all 3?
RESOLVED: Boxes default to style containment, syntax of 'container'
and @container preamble is name / type
Rossen: Do we need to republish soon?
miriam: Need to make some changes first
CSSOM View
==========
add Element.isVisible[toDocument] to detect if element is visible in
the document
--------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6850
chrishtr: ...
chrishtr: Need to do this to determine that things properly displayed
chrishtr: Currently use approximations that are increasingly
incorrect as we add more advanced rendering features
chrishtr: When content is skipped using content-visibility, protects
code so that don't accidentally force-???
chrishtr: We've seen this problem when adopting content-visibility
chrishtr: Proposed definition is that box has to be "rendered" per
HTML, i.e. has a box
chrishtr: 'visibility' is 'visible'
chrishtr: not in the skipped subtree of content-visibility
smfr: opacity:0 is visible, right?
chrishtr: Yes, and clipped out counts as visible
smfr: So not really visible to the user, but some more subtle
definition
chrishtr: Also scrolled off-screen considered visible
<lea> Seems like there's a lot of disagreement about the exact
definition, what if this accepted a dictionary so that authors
can define the type of "visibility" they need?
chrishtr: so seems like need name to be slightly different, e.g.
isVisibletoDocument
<lea> Also, not sure how `isVisibleToDocument()` adds clarity over
`isVisible()`, it mainly seems more verbose
Rossen: I wanted clarification on whether or not isVisible state here
means that the box of the element is rendered inside the
viewport or not
Rossen: Sounds like the answer is not necessarily?
Rossen: Seems like the definition is box of the element could
potentially be viewable
Rossen: So, like, *can* be visible
lea: It seems there's a lot of uncertainty about the exact definition
of this function
lea: Couldn't we have options so that authors can decide what type of
visibility they care about?
lea: Because clearly a single definition is not serving all use cases
lea: Also, isVisibleToDocument() doesn't seem to really add clarity,
just adds verbosity
<fantasai> +1
chrishtr: Not sure I understand use cases?
lea: Some use cases need to know whether visible in viewport, some
just need to know if there's a box, and some need to know if
contents are rendered
lea: so different use cases
chrishtr: We did consult with reps from Pupeteer and Clearwrite
chrishtr: and they thought the definition was good for their use case
chrishtr: and meets the needs of the content-visibility partners we
have
lea: As a web dev, testing whether a box is visible is something web
developers have needed and use frequently
lea: adding isVisible that is a specific type of rendering for a
specific use case
lea: if we're adding this new function, can't we add an ability that
a majority of the authors need?
<smfr> +1 to lea’s suggestion
<fantasai> +1 to lea
dholbert: I'm curious whether it makes sense to include
visibility:hidden in the definition
dholbert: Seems different category of visibility than
content-visibility and display:none
dholbert: visibility:hidden, you still have to compute layout with it
dholbert: and authors are fully in control of it
chrishtr: Maybe it makes sense to be more specific about what the
function does, and maybe introduce multiple function
chrishtr: e.g. has a box and not ??
chrishtr: visibility can be checked directly with existing methods
dholbert: opacity:0, as smfr mentioned; and then content covered up
by other content
chrishtr: so the only one is has a box and is not skipped
chrishtr: I think that would meet the needs
dholbert: only issue is that isVisible is a problematic name
<lea> Potentially useful, as this has historically been used *a lot*
by authors: https://api.jquery.com/visible-selector/#visible1
<lea> (jQuery implements as a selector, but it was used in the same
way, to test visibility of a given element, for a certain
definition of visibility)
<lea> also, would be nice if it addressed use cases like
https://stackoverflow.com/questions/123999/how-can-i-tell-if-a-dom-element-is-visible-in-the-current-viewport
<Rossen> a11y tools have been requesting such behavior for a very
long time... yet I don't see that as a strong use case
fantasai: I suggest "isDisplayed", cause that's got more to do with
what we are doing
fantasai: here, visibility variants isn't quite right
fantasai: displayed links to the idea of 'display' and the box
generation
smfr: I like lea's idea of a more fine-grained approach
smfr: could imagine 2 versions
smfr: A function isVisible() takes a dictionary, which properties
interested in
smfr: Another is returns a dictionary, which says which types of
visibility involved in
smfr: First one is more performant, don't have to calculate types
that aren't needed
smfr: If more fine-grained API, that removes ambiguity or confusion
around things that affect visibility
lea: Pasted a link to jQuery API for similar functionality
lea: They've done a lot of work to address use cases
lea: Would be good to take prior art into account
lea: Seems they define as whether any layout boxes
lea: but seems definition changed at one point
lea: Also linked to stack overflow, other places, people want to know
whether an element is visible in the viewport
lea: Would be useful if it could do that as well
lea: Right now the way to test this is to create an intersection
observer
lea: but it's awkward to write code like that, so would be nice if
there was a function that would just tell you
lea: Unsure if isDisplayed is more clear, would go with isVisible
because shorter
fantasai: Just to clarify, I think if we're doing something general
then isVisible is fine, but if limiting to whether the box
is generated isDisplayed makes sense to me
vmpstr: If going with dictionary approach, would dictionary be things
like test viewport visibility, test display none, test ???
vmpstr: How would that work?
lea: I think we should center around use cases rather than specific
properties, so that it is more future proof
<tantek> +1 leaverou, decide on the functionality first, and then the
name can follow
lea: I propose we resolve to work on it, and go back to the drawing
board and revisit later after redesigning
<bradk> 👍
chrishtr: sgtm
<tantek> +1 leaverou on all that. center around use-cases, revisit
after redesigning
Rossen: Seems like we went down this path of content-visibility and
trying to chunk how much content is processed and address
performance gains, which is a good effort
Rossen: now we're trying to contain the damage
Rossen: ... things that were otherwise easily discoverable
Rossen: This type of functionality has been requested by
accessibility tools for a long long time
Rossen: to recognize whether something is visible, can it be visible,
where is it visible
Rossen: They have frameworks working around these problems
Rossen: trying to reverse-engineer engine's decisions and results
Rossen: so I don't see a11y considered anywhere in this issue, and
would recommend we take these use cases as well
Rossen: in addition to ones described by Lea and Simon
Rossen: Any other feedback to this issue?
chrishtr: Resolving as Lea suggested that use cases make sense and go
back to issue makes sense
chrishtr: Just want to make sure that WG has consensus that these use
cases are worth solving
<lea> +1 on the use cases being worth solving
<lea> (that was the first part of the resolution I proposed :)
Proposed Resolution: Work on solving these use cases for an
isVisible API
RESOLVED: Work on solving these use cases for an isVisible API and
revisit in a future call
CSS Color 5
===========
color-extract() function to extract individual color components
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6937
lea: Had discussions in the past, especially after Web Almanac
lea: when we saw that authors are often generating color variations
by extracting color components and doing math on them
lea: We have relative color syntax for most of these use cases,
already implemented in Safari
lea: however, don't have a way to combine components from multiple
colors
lea: these are much more rare, but they do exist
lea: There was even a WG resolution for how to express a thing, which
required combining output of one color and components of other
color
lea: color-mix() used to be able to to do that in an awkward way,
which we removed
<TabAtkins> (We ended up doing something different, but yeah it was
part of Forced Colors Mode.)
lea: At first Chris and I were thinking to add e.g. lch-lightness()
etc on a use-case basis
lea: but now thinking why not have a generic extraction function
lea: Extra effort in terms of spec and implementation shouldn't be
too high
lea: Main argument is it's very verbose, but for common cases have
other methods
lea: so I think the extra verbosity is OK
lea: and Tab already said he agrees with the idea in the issue thread
<TabAtkins> yeah +1 to it, and I'm happy with how it slots into the
color() component naming stuff
chris: I think it's verbose, but it makes sense and is clear
chris: I like re-using existing things like color space and
components, etc.
chris: Lea, you have component there, in Color 5 have custom
components for custom spaces, could you re-use?
lea: Yes, could re-use
chris: Great, I like the generality
smfr: I'm trying to figure out is this an API for converting APIs
between color spaces?
lea: No, this is an API for doing custom math with color components,
that is more general than relative color syntax
chris: No if you want to convert color spaces, can already do that
and it's very simple. But it gives you a complete color
smfr: If conversion under the hood and picking out components
smfr: should this just be a typed OM thing?
lea: JS API?
smfr: Oh, this is a CSS API
smfr: I need to read the issue
chris: I agree the Color API should have the same functionality
<miriam> +1 I like this proposal, and would use it
dino: Would be great to see an example in the gh issue of actually
doing a design or palette with the color-extract() syntax
fantasai: Seems like people need more time to review, maybe revisit
next week. Seems likely to have support though.
<lea> +1
Rossen: Seems we might be able to record a resolution today actually
Proposed resolution: accept the work in color-5
Rossen: Any objectionsS?
<chris> syntax actually looks good to me, and tab already said he
liked it
RESOLVED: Add color-extract() to Color 5 and continue work
Make all color components in Relative Color Syntax optional
-----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6938
lea: Right now have a relative color syntax that allows you to do
arbitrary math over components of a single color
lea: also converts the color you're working with to the color space
you're using
lea: Could just want to convert to the color space
lea: e.g. from-color l c h
lea: Can also convert using color-mix() and 100% of the color you want
lea: Chris and I were thinking this is awkward
lea: Maybe just allow drop the components to convert spaces
lea: and if 3 or zero components, then maybe could even have some
components
lea: but Tab seems a bit against that
lea: Question of why convert among spaces if not doing anything
with it
lea: ...
lea: Right now adding to all features that use interpolation
lea: if no reason, then not worth having a shortcut
lea: Chris, any reason to convert color spaces but not do anything
with the resulting color?
chris: If we do make these optional, then I would want to make all
components optional
chris: or maybe trailing ones, is sort of annoying
chris: That's confusing. I'd prefer all or none
chris: but don't see point for using positional ordering
lea: What's use case for none of them?
chris: The use case was color space so I can mess around with it, but
now we have color-extract()
lea: Even with relative color syntax could do color conversion and do
math on the components
lea: so I'm not sure why you would need to do that, so inclined to
close this as no change
chris: I think that would be fine
Rossen: Can we do that?
lea: Yes, that's my proposal. Unless Chris can think of a use case
for it
Rossen: We can always re-open if a strong use case comes forward
RESOLVED: Close no change
Rossen: Reminder long-form meeting next week, will add to our calendar
Received on Thursday, 13 January 2022 00:15:54 UTC