- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 5 Jan 2023 19:48:24 -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 Display
-----------
- RESOLVED: Publish CR snapshot for display-3 (Issue #6516:
Horizontal Review)
CSS Values
----------
- Prior to the edits to address issue #3320 (Clarify fragment URLs
resolve against the current tree, not document tree) being
resolved upon by the group, text needs to be added to ensure
that media fragments will still work.
CSS Scoping & Selectors
-----------------------
- RESOLVED: Accept the edit (Issue #5093: <compound-selector-list>
should somehow affect :is() / :where() parsing)
- Edit: The logical combination pseudo-classes are allowed
anywhere that any other pseudo-classes are allowed, but
pass any restrictions to their arguments. (For example,
if only compound selectors are allowed, then only
compound selectors are valid within an '':is()''.)
CSS Contain
-----------
- RESOLVED: Go with option 1 and get implementer feedback (Issue
#7551: Inconsistent handling of known and unknown
features jeopardizes backward compatibility)
- RESOLVED: For elements in this situation we treat any overflow as
ink overflow (Issue #5868: Clarify what happens with
scrollbars on elements that 'skip their contents')
- RESOLVED: Allow var references in container queries without
particular type safety. Will check the type when a query
is evaluated against a container (Issue #8088: Can we
allow custom properties in dimensional container
queries?)
- There was interest in using a syntax like
container-reference(10cqi, card) for issue #7858 (Reference
named containers for cq units) instead of creating a whole new
syntax, however time ran out on the call before the group could
work through the idea thoroughly.
Highlight API
-------------
- RESOLVED: Change highlights from point to work on document or
shadow root with the intention of synchronizing how
highlights and elements from point work. Open a new
issue to harmonize the specs and doing the research
(Issue #7766: Exposing shadow DOM highlights in
highlightsFromPoint())
CSS Position
------------
- RESOLVED: Revert the change to how scroll position of sticky
positioned boxes are calculated (Issue #7930: Revisit
the scroll position of sticky-positioned boxes)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2023Jan/0000.html
Present:
Tab Atkins
Daniel Clark
Elika Etemad
Robert Flack
Simon Fraser
Megan Gardner
Daniel Holbert
Dael Jackson
Cameron McCormick
Tim Nguyen
Alan Stearns
Miriam Suzanne
Regrets:
Adam Argyle
Oriol Brufau
Yehonatan Daniv
Jonathan Kew
Chris Lilley
Florian Rivoal
Khushal Sagar
Jen Simmons
Bramus Van Damme
Lea Verou
Chair: astearns
Scribe: dael
Future Meetings
===============
astearns: While we wait for more people, we have something like 60
agenda+ items
astearns: Will likely need extra meeting times. I don't know what
people would prefer. Try and do a virtual F2F and take
most of a week? Smaller 3 hour meeting? Sprinkle an extra
one hour here and there?
<TabAtkins> I'm pretty free the next few months fwiw
fantasai: Another question is have an actual F2F
astearns: True
astearns: Actual F2F requires a host that commits to the kind of
hybrid we had in NY with good sound and video to let
people attend remotely
astearns: Any strong opinion speak up now. Or we can discuss on the
group list
fantasai: Does anyone have the ability to host F2F? Like, the budget
for it. If the answer is no that answers that question
astearns: I'll start a thread, a couple, one for another F2F and
another about extra telecons
astearns: Regular agenda- any changes before we get started?
CSS Display
===========
Horizontal Review
-----------------
github: https://github.com/w3c/csswg-drafts/issues/6516
fantasai: We had requested horizontal review a while back. Got most
back. We only made one set of changes since sending and
that was defining term root element which unlikely
horizontal review cares.
fantasai: [missed] suggest CR
fantasai: We could publish a CR snapshot to lock in patent stuff
fantasai: Need WG resolution for that
astearns: This is a snapshot based on draft a few months ago?
fantasai: Plus the changes we made for root element as a term
astearns: Concerns about publish CR snapshot for display-3?
astearns: Objections?
RESOLVED: Publish CR snapshot for display-3
CSS Values
----------
Clarify fragment URLs resolve against the current tree, not
document tree
-----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3320
TabAtkins: Last month I committed the initial spec text. Fragment
urls are now tree scoped references. Look up in tree
style is in to find url. Lets you refer to global if
nothing intervening
TabAtkins: A bit of changes to make. I don't strip fragment
directives because waiting on that spec to extract that
algorithm. They do that now so I'll make the change;
that's minor
TabAtkins: Only other issue is fantasai's comment on there that I'm
not handling other types of fragments like media
fragments in an intelligent way. Right now see if there's
an element with the fragment as the idea great. If not
fail. Means media fragments almost always fail. Would
like to specifically exclude them
TabAtkins: Don't think there's a conceptual definition of media
fragments so right now I'm not. If someone knows a way to
refer to these that is testable, great. For now no
practical effects so I think spec is workable but not
idea.
TabAtkins: If that's okay, we can accept and then tweak
fantasai: Disagree it's good now. Things like media fragments should
just work. URL fragments are not about pointing at an
element. They're sometimes pointing at an image. Often
that.
fantasai: Media fragment is reasonable way to clip out section of
image. I think spec text should work for these things
TabAtkins: If you can find a well defined way to talk about it, great
fantasai: Vaguely defined and correct is better than precise and
wrong. And you can file issue against url spec
TabAtkins: File and issue against me and I'll figure out some way to
talk about that
astearns: Split into a separate issue or have that accurate but not
precise issue before we close
fantasai: These changes are a regression so would like to address.
It did not spec how you do it, but it wasn't wrong
TabAtkins: Didn't say anything about that in previous
fantasai: Which is better than saying something wrong
TabAtkins: Don't think that is a follow-up, but alright.
TabAtkins: Happy to figure out how to address. Would like it
separate so SVG working is in there
fantasai: If there's spec text that excludes ID is fine
TabAtkins: Can we do that as separate so we close this issue that's
been open for years
fantasai: You don't have text that addresses this which is my problem
TabAtkins: Which we will fix in another issue.
<fantasai> Your text for this issue breaks other things.
<fantasai> Write text that doesn't break the other things, and then
you can close this issue.
astearns: I don't think we are going to come to an agreement between
the two of you on how we should track the remaining
problems. I suggest we leave issue as is until we get
something in the spec to address fantasai issue
astearns: And then we can close the issue. Acceptable TabAtkins?
TabAtkins: I can't do otherwise, so sure?
astearns: One remaining thing on this and we'll come back once
there's a little more in the spec and then create a new
issue for a better definition
CSS Scoping & Selectors
=======================
<compound-selector-list> should somehow affect :is() / :where() parsing
-----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5093
TabAtkins: Summary is after some discussion across a few related
issues, basic idea is logical combo pseudos that combine
things together passes down any restrictions the outer
pseudo is in
<fantasai> :is(), :where(), and :not() are the set in question
<TabAtkins> also :nth-child() i think
TabAtkins: You can use is in a compound context, but it has to be
compound too. That way you can't smuggle in a more
complicated selector
TabAtkins: Have spec text. Need approval
astearns: Text is in last comment. seems good to me
astearns: Other opinions?
astearns: Proposal: Accept this restriction and the edit that
defines it
fantasai: Kind of more of an expansion. Previously only allowed some
things and adds :is and :where
TabAtkins: Lot of places where they were allowed but could contain
whatever. But doesn't matter
astearns: Proposal: Accept the edit
astearns: Objections?
RESOLVED: Accept the edit
CSS Contain
===========
Inconsistent handling of known and unknown features jeopardizes
backward compatibility
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7551
miriam: The issue is that currently when we're looking for a
container to resolve queries against we look for nearest
ancestor of appropriate type
miriam: if containers we find don't have type, don't find anything,
we return false
miriam: however if you use a general enclosed unrecognized type
resolve as unknown
miriam: At some point unrecognized becomes recognized and instead of
resolving unknown we keep looking for more containers or
resolve false
miriam: Discrepancy between feature we don't understand and features
that are not supported on that type is different. Could be a
problem down the road
miriam: Two approaches we could take. One is complex about OR logic
where when there is an or we resolve 2 sides separately or
only need one match. That's getting a bit clever
miriam: Other is account for general enclosed in the selection
processes by accounting for it in container selection
TabAtkins: Not super clear on precise behavior. If you have query
height or width today and evaluate on inline-size it
doesn't evaluate to true?
TabAtkins: because width would be correct?
miriam: Doesn't evaluate at all. Looks at two types and says this
container can't answer question and it looks for a different
container
TabAtkins: Yeaaah. I suspect that's what we want to fix because
makes ORs not an OR
miriam: That would be option 1 to account for it in OR logic
TabAtkins: Only implication is right now can scan container query
and know what will be required for it to be valid so you
can filter more aggressively. Is that intention?
miriam: Intention is selection process is automated. Before it was
manual
miriam: I don't know if there's problems from impl side on splitting
the container selection logic on OR
fantasai: I don't think there would be
TabAtkins: Not being an impl expert, I'm going to say probably not
TabAtkins: Go with that pending obj from implementations?
<fantasai> +1
astearns: Yep unless there are other opinions?
astearns: Proposal: Go with option 1 and get implementer feedback
astearns: Objections?
RESOLVED: Go with option 1 and get implementer feedback
Clarify what happens with scrollbars on elements that 'skip
their contents'
-----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5868
TabAtkins: I believe the right answer is fairly clear.
TabAtkins: The core issue is current spec text says if element skips
contents they are not painted (as if visibility:hidden).
But if it's a scroller you still have to perform layout
because need to know if triggers overflow. Seems like
oversight because don't want to require layout
TabAtkins: Obvious case is make it assume no scrollbars are
required. Some talk about saying "as if display:none" but
that's not accurate either because would trigger lazy
layout
TabAtkins: I think best is say skipped contents are treated as ink
overflow so do not ever trigger scrollbars
astearns: Other side effects of ink overflow beyond creating
scrollbars?
TabAtkins: No, only around how large the overflow rectangle is which
is only to calc scrollbars
astearns: Proposal: Any overflow is treated as ink overflow
smfr: Normally when think about ink overflow think about triggering
paint invalidation. Never anything painted. So treating as ink
overflow maybe not best?
TabAtkins: Since there's a scroller ink overflow will get trapped by
the scroller
TabAtkins: Big thing is actual overflow area will be 0 essentially.
Things are clipped but also invisible
smfr: Describe in terms of overflow:clip?
TabAtkins: I little reluctant to define in overflow because make
sure do not stomp on existing overflow. Talking about in
terms of ink allows us to avoid. If you think there's
problems with ink we can look into it. At first blush
want to stick with ink
astearns: Other concerns?
astearns: Proposal: For elements in this situation we treat any
overflow as ink overflow
astearns: Objections?
RESOLVED: For elements in this situation we treat any overflow as
ink overflow
Can we allow custom properties in dimensional container queries?
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8088
miriam: With container queries we are resolving against a specific
container which is an element on the page. Which mean we
resolve relative units. If we query >30em we know what an em
is.
miriam: Similar with style queries we can resolve custom values in
the query against the container
miriam: Have practice to resolve things that need an element. Can we
take that and allow custom properties to be used in a
dimensional query?
miriam: There would be 2 ways we could define it. Main problem is we
need to resolve a type and make sure it's a number or length
or whatever we need. Could either rely on @property which is
a little manual or could say define types expected for each
dimensional feature
miriam: Anders lays that out in a comment. inline-size is a length
etc.
miriam: I think this would be a great thing. Moving toward custom
MQ. Slightly different, but a lot of same impact
TabAtkins: Definitely should do this and extremely good. I don't
think need to be fancy what we get out the end. Don't
need @property or do anything for types beyond what is
there defining syntax. All need to do is define what it
means after substitution if it violates the query. Get an
unknown or a false
<fantasai> +1
TabAtkins: Don't need to worry about types and more than we already
do. inline-size disallows 'red'
miriam: I like that answer
astearns: Other opinions?
heycam: What happens if...you might have said it but what if
variable isn't defined at computed value time
TabAtkins: It's guaranteed invalid
astearns: Proposal: Allow var references in container queries
without particular type safety. Will check the type when a
query is evaluated against a container
astearns: Concerns?
astearns: Objections?
RESOLVED: Allow var references in container queries without
particular type safety. Will check the type when a query
is evaluated against a container
astearns: This does seem cool
Highlight API
=============
Exposing shadow DOM highlights in highlightsFromPoint()
-------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7766
dandclark: This is about a highlight api v2 that we raised during
TPAC about making highlights interactive on scenarios
like spellcheck and can click the word and handle an
event knowing it was highlighted
dandclark: One issue during TPAC was exposing highlights in shadow
dom. Initial formulation was on css.highlights global.
Don't want the api to return highlights in shadow.
Alternative is follow example of point which can be
called on document or shadow root and it gives elements
under the coords on the shadow
dandclark: That seems like a close analog so should follow. Move
highlights to be on document or shadow root.
dandclark: One wrinkle is point doesn't seem to say it's callable on
doc or shadow roots. Seems to also be slight
inconsistency between blink and gecko about what can be
returned if it's on shadow so some details to work out
dandclark: Still seems to be best to pursue
TabAtkins: Reasonable to me
astearns: Do you have an opinion about when this is called on shadow
root do we return light dom?
dandclark: Loose opinion is I would expect only return in the shadow
dom. That seems most natural, but loosely help opinion
astearns: Other opinions?
astearns: Concerns?
TabAtkins: For question about light dom, are you thinking about
slotted light dom into the shadow or arbitrary overflow.
astearns: Thinking arbitrary but slotted is right. I would expect
slotted.
astearns: Definitely something to look into. I think I prefer the
route of changing highlights to work on either doc or
shadow root
dandclark: Maybe resolve today to move to document and shadow root.
Reality of browsers for point should be further
investigated and we should match to that and agree what
makes sense for both APIs. We can develop an opinion for
both
astearns: I think point is our document; cssom view
astearns: Proposal: Change highlights from point to work on document
or shadow root with the intention of synchronizing how
highlights and elements from point work. Open a new issue
to harmonize the specs and doing the research
dandclark: Sounds right
astearns: Concerns?
astearns: Objections?
GameMaker: Since I've been doing highlights, want to say this seems
to line up with things that will be okay
RESOLVED: Change highlights from point to work on document or shadow
root with the intention of synchronizing how highlights
and elements from point work. Open a new issue to
harmonize the specs and doing the research
astearns: dandclark I may ask you to make point element edits as well
CSS Position
============
Revisit the scroll position of sticky-positioned boxes
------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7930
flackr: There's a lot in the issue. Basically many years ago we
tried to come up with a scrolling position behavior for
sticky position elements when they overlap. Solved one use
case but breaks another common on. Never launched in any
browser
flackr: Prop is revert that change and explore other ways to handle
this use case. For this issue it's just to revert
smfr: What's the behavior after the revert?
flackr: Current impl behavior that scroll position of sticky
position element is it's calculated position
smfr: Doesn't use it's inflow position; that static position I think
it's called
flackr: Sticky position, I think, yes. No one impl it those and many
bugs against experiment
smfr: What about in fixed, assume it's in view?
flackr: Correct
TabAtkins: Sorry I missed ping flackr. This seems reasonable. No
option is ideal but current impl behavior seems fine and
compact impact is scary. Fine with prop
flackr: I have follow-up on improving edge cases but that's separate
astearns: Concerns on reverting?
astearns: Proposal: Revert the change to how scroll position of
sticky positioned boxes are calculated
RESOLVED: Revert the change to how scroll position of sticky
positioned boxes are calculated
astearns: I'm assuming discussion about other solutions are separate
issues?
flackr: Yes
CSS Contain Con't
=================
Reference named containers for cq units
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7858
miriam: The request is with container queries want to query a
specific container. Can do with full syntax but not with
units. Units give nearest container with right dimensions.
It's a good default
miriam: Nice if you can get the width, height, etc from a specific
container
miriam: Proposal is starting with cq functions that match unit is
cqw, cqh, etc. Function takes 1 arg which is name of
container. Returns the value of @unit. You can use that in
calc, multiply by something, and query a specific container.
miriam: Bonus request is do we allow function appended to a value is
same way as with custom units. Nice to do with functions.
Functions are powerful even without
TabAtkins: New functional unit is brand new syntax. Not a problem,
but just for conservativeness I think we want to lean
existing pattern. I would think takes cq-length and
contextually interprets based on container name as other
argument
miriam: Suggestion a function that's both multiplier and name?
TabAtkins: Same as nmn suggested
<TabAtkins> container-reference(10cqi, card)
TabAtkins: This function ^ Relative to name from second argument
miriam: Could work. As soon as looking at container-reference with 2
arguments does it have broader uses? container-reference(
2em, card) I would use
TabAtkins: We could define tightly and extend. If we go for more
than 1 dimension, aka a calc of stuff, I suppose works.
It's more work impl-wise
fantasai: All of this is longer to type than calc, right? calc with
a bunch of functions would be easier
<@miriam> calc(10 * cqw(card))
TabAtkins: What I described is shorter than doing same thing with
calc. If it's container reference that takes name and
returns the unit length that's longer
<@miriam> container-reference(10cqi, card)
<fantasai> how is that strictly longer
ntim: Would it allow querying the units for containers outside of
the container chain?
ntim: And any concerns if it is allowed?
miriam: The way I was thinking of it is resolves same as container
queries so has to be ancestor
astearns: Nearest ancestor whose name matches
astearns: One minute left. Hearing this is good to have but a bit of
quibbling over syntax.
miriam: Can take it back to the issue
astearns: Yep. Let's take it back to the issue and go over syntax,
but let's try and take this up. Seems like it will be very
useful
<TabAtkins> hm, I guess functions with the name of the cq* unit lets
you collapse things down to a pretty short thing.
<TabAtkins> but like `cq(10cqi, card)` vs `calc(10 * cqi(card))`,
the former is shorter
<fantasai> TabAtkins: ok, yeah, that version is shorter. Though only
if you're outside calc() already
<TabAtkins> yeah, which you usually are
<TabAtkins> functional units are def the shortest way thru this, tho.
astearns: I'll add issues on the list about extra meetings. We'll
talk next week!
Received on Friday, 6 January 2023 00:49:05 UTC