- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 2 Nov 2023 19:08:50 -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.
=========================================
CSSOM View
----------
- RESOLVED: Adopt the naming scheme for future values and as aliases
for existing values (Issue #9487: checkVisibility options
have inconsistent naming schemes)
CSS Values
----------
- RESOLVED: Revert the previous resolution and the serialization for
spec value is a 3-value serialization (Issue #2274:
Inconsistent position serialization)
- RESOLVED: Define how new and old viewport units interact and that
old units are equivalent to large viewport units (Issue
#6454: Restrictions on UA-default viewport units
(unprefixed v*))
- RESOLVED: We define relationship between ICB, abspos, and fixedpos
and viewport size as detailed in the comment [comment:
https://github.com/w3c/csswg-drafts/issues/6453#issuecomment-1783581699
]
(Issue #6453: viewport units vs initial containing block)
CSS Grid
--------
- Added Brandon Stewart as an editor to CSS Masonry spec.
- RESOLVED: Add row-reverse, column-reverse, and wrap-reverse (Issue
#3622: Add more directional values to grid-auto-flow)
- RESOLVED: Add two numbers to the repeat function that when used
with one of the keywords define a range (Issue #9325:
Repeat range)
CSS Pseudo
----------
- RESOLVED: ::backdrop is a tree abiding element. It's tree is a
sibling of the root tree. It inherits from its
originating element (Issue #7845: Define ::backdrop)
- RESOLVED: ::backdrop does not have a ::before and ::after (Issue
#7845)
CSS UI
------
- RESOLVED: Remove the claim that outline-width influences the
rendering of auto style outlines (Issue #9201: Influence
of outline-width on auto style outlines)
CSS Contain
-----------
- RESOLVED: @container rule can have just a container name and match
the closest container with that name (Issue #9192: Make
`<container-query>` optional in `@container`)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2023Oct/0013.html
Present:
Tab Atkins-Bittner
Oriol Brufau
Elika Etemad
Robert Flack
Simon Fraser
Paul Grenier
Daniel Holbert
Dael Jackson
Vladimir Levin
Tim Nguyen
ChangSeok Oh
Alan Stearns
Brandon Stewart
Regrets:
Rachel Andrew
David Baron
Jonathan Kew
Chris Lilley
Florian Rivoal
Miriam Suzanne
Lea Verou
Sebastian Zartner
Chair: astearns
Scribe: dael
Agenda Setting
==============
[decided to add Brandon Stewart as editor to the CSS Masonry
spec (CSS-Grid-3)]
astearns: Anyone want to propose any changes to the agenda aside from
skipping item 9?
[no other changes]
CSSOM View
==========
checkVisibility options have inconsistent naming schemes
--------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9487#issuecomment-1782109845
fantasai: We're pretty inconsistent where we have checkOpacity and
css has checkVisibility. Proposal is to set up naming
scheme where for CSS
fantasai: fooProperty for CSS foo property checks. fooBar for CSS foo
property checking value Bar. For the current values that
translates to opacityProperty, visibilityProperty, and
contentVisibilityAuto
fantasai: Comments on issue that check makes it easier to understand,
but could lead to checkcheck for things like checkVisibility
fantasai: Need some consistency so this is proposal
vmpstr: This is in addition to existing properties as aliases?
fantasai: Yeah. Others are shipping so we need to keep them
astearns: Anything new we add will follow this scheme
astearns: Seeing agreement in issue. Hearing no concerns
<TabAtkins> +1 to the proposal
astearns: Proposal: Adopt the naming scheme for future values and as
aliases for existing values
astearns: Objections?
RESOLVED: Adopt the naming scheme for future values and as aliases
for existing values
<TabAtkins> vmpstr, yeah, we'll spec it to just be an OR between the
two aliases for each option
CSS Values
==========
Inconsistent position serialization
-----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2274#issuecomment-1783497212
fantasai: We dug through a lot of serialization issues in the past.
Most edited in. There was some edits for backgrounds to
handle 3-value syntax that's not allowed outside of
background-position
fantasai: Decided we would foresee 3 value to 4 value. Looking at
impl we noticed we have interop with 3-value serialized as
3-value. Note this is for computed values. For specified
when serialized out all browsers are serializing out as 3
values
fantasai: Proposal is reverting previous resolution and keep what
browsers are doing now
astearns: Mainly because this is not a big enough deal to force a
change?
fantasai: Yeah, we don't have actual problems with serialization. If
you try and take it and put it into a different property
there might be problems, but don't do that you're fine. Or
grab the computed value and it works.
astearns: Comments?
astearns: Proposal: Revert the previous resolution and the
serialization for spec value is a 3-value serialization
astearns: Objections?
RESOLVED: Revert the previous resolution and the serialization for
spec value is a 3-value serialization
Restrictions on UA-default viewport units (unprefixed v*)
---------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6454#issuecomment-1251015591
TabAtkins: A while back when defining the set of viewport units there
was a question what old version should be. The plain ones
TabAtkins: Defined as undefined but have to between small and large.
I believe at the time UAs were inconsistent
TabAtkins: Now the test we performed seem to show unprefixed is large
viewport is where people converged. Would like to spec that
astearns: Comments? Concerns?
astearns: I see some research. Do we have WPT?
TabAtkins: I believe research was based on WPT but we can make sure
to cover
TabAtkins: Issue is difference between units only shows on mobile,
but WPT coverage of mobile is underdeveloped. There is
work on that
astearns: Proposal: Define how new and old viewport units interact
and that old units are eq. to large viewport units
astearns: Objections?
RESOLVED: Define how new and old viewport units interact and that old
units are eq. to large viewport units
viewport units vs initial containing block
------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6453#issuecomment-1783581699
TabAtkins: There was some certain screen sized things related to each
other. ICB, viewport units, and fixedpos containing block.
TabAtkins: Appears there is almost perfect consistency. There wasn't
a few years back, but have converged with one exception.
TabAtkins: Suggest we spec. ICB is small viewport size. Abspos
containing block that you get if you have abspos relative
to no element is also small viewport size. fixedpos if the
layout viewport which is the dynamic viewport size
TabAtkins: That's the proposal. ICB is small viewport. fixedpos
matches dynamic viewport
astearns: How is Firefox on iOS differing from Safari when they use
same engine?
TabAtkins: That's a great question and we don't know, but it was
definitely doing that. We have no idea. But browsers
showed different behavior for this test case.
<smfr> There is some WKWebView and UIScrollView inset stuff that can
affect this behavior, and they are controllable by the app
astearns: Okay defining all these relationships. I assume we should
have WPTs as well
TabAtkins: Yep. We'll verify that there is
astearns: And smfr in chat gave us a possibility for why the
difference
TabAtkins: Yes, I thought stuff outside the web rect might be
effecting it.
astearns: Proposal: We define relationship between ICB, abspos, and
fixedpos and viewport size as detailed in the comment
<smfr> no concerns
astearns: Objections?
RESOLVED: We define relationship between ICB, abspos, and fixedpos
and viewport size as detailed in the comment
CSS Grid
========
Add more directional values to grid-auto-flow
---------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3622#issuecomment-1777848435
fantasai: We have a longstanding issue where someone requested
reverse keywords. iank had raised not having reversing as a
reason to split masonry and grid. Regardless, seems it
would be worth adding reverse keywords to auto-flow
bts: From reading issue a lot of this came from wanting to support
flex prop in grid. Makes sense to have in masonry too.
TabAtkins: row and column reverse makes sense. Not sure how
wrap-reverse would work. Implies we'd create implicit rows
in negative
fantasai: Yep, start at bottom of explicit grid
TabAtkins: That seems fine. Okay. Yeah.
astearns: Alright. Last time this came through I asked for use cases.
More detail in the issue so I'm good now
astearns: Proposal: Add row-reverse, column-reverse, and wrap-reverse
astearns: Objections?
RESOLVED: Add row-reverse, column-reverse, and wrap-reverse
Repeat range
------------
github: https://github.com/w3c/csswg-drafts/issues/9325#issuecomment-1777861139
<TabAtkins> +1 to the proposal, and to making the keyword optional if
numbers are given (defaulting to auto-fill)
fantasai: Another issue iank brought up is desire to have repetition,
example 3 to 5 instead of exactly 5. Seemed useful for grid
regardless of masonry. Opened issue to propose repeat
syntax that covers a range. It would be autofill or autofit
with one or two numbers. If two, first is min and second is
max. If you only give one it's a max.
fantasai: One is a max is consistent with how we do multicol. And
consistent that main problem is too narrow, not too wide
fantasai: Syntax is re-orderable because generally want to allow
reordering unless parsing reason not to
oriol: It seems reasonable to me to be able to spec a min with no
max. I guess you could do it was calc 1/0 to get infinity.
Should we add a way to spec min?
fantasai: You can spec infinity as a keyword. You can spec a keyword
for no max
TabAtkins: I agree makes sense to allow unspecified as max so keyword
makes sense
fantasai: keyword like 'no-max'?
TabAtkins: Should go with infinity. Or infinite.
fantasai: Okay, that's in animation. Good to be consistent
astearns: If you have a repeat that's repeat(autofill 3) it's a max
but if you add infinite keyword the 3 is the minimum
fantasai: If you add a 5 the minimum is 3.
TabAtkins: Having consistently the first number be the min isn't
problematic and you can always add a max
fantasai: I don't think we want to do that because columns we do that
as a maximum
astearns: Question do we require 2 numbers
TabAtkins: In column-count can we do min and max?
fantasai: Just a max
TabAtkins: Then I think more comfortable requiring 2
fantasai: I could live with that.
fantasai: I think it would be nice to have the one, but if we want to
require we can do that
astearns: We can start with both and when there's author experience
decide if we want to allow a single
astearns: One question...you talk about this is important for
masonry, but also important for non-masonry 3?
fantasai: Yes. Prop is add to grid properties to affect both
astearns: And we don't have a repeat function?
fantasai: Repeat can take number or a keyword. This allows you to
combine both to get a range
<TabAtkins> I forgot that we could take a number by itself. in that
case I definitely think the range should require both
astearns: Proposal: Add two numbers to the repeat function that when
used with one of the keywords define a range
astearns: Objections?
RESOLVED: Add two numbers to the repeat function that when used with
one of the keywords define a range
CSS Pseudo
==========
Define ::backdrop
-----------------
github: https://github.com/w3c/csswg-drafts/issues/7845
TabAtkins: We discussed question 1 at the F2F. 2 and 3 were not
decided at the time.
TabAtkins: I don't recall why we stopped at that point
oriol: I think it was a regular call and we ran out of time
TabAtkins: Question 2- is backdrop a tree abiding pseudo element? Or
does it need restrictions
TabAtkins: Consensus from comments is call it tree-abiding. People
don't care if it has a before/after. So it's a matter of
if it's easier to restrict or leave it in
<ntim> +1 to no before/after
TabAtkins: Proposal is backdrop is tree abiding and does not have a
before/after element
oriol: Concern with tree abiding is we need to define where it's
originated and there's no clear definition for that. We can
pick one which is fine but since it's not clear I have a mild
concern
TabAtkins: That question is question 3. My possible answers are it's
considered to be from the root or say it's after ::after.
If you're using counters in the backdrop that's weird. Any
place is fine. If there is a use case for something like
counters in backdrop having it treated as child of
originating element is most sensible
fantasai: How does it get below the element in order?
TabAtkins: By virtue of being in the top layer.
fantasai: So there's magic that puts it below toplayer
TabAtkins: Yes. Anything that does backdrop also has associated
toplayer magic
fantasai: I guess I would have thought of putting it first because it
paints first. But there's magic either way, because it has
to also paint below the box
TabAtkins: We can put it first. Only deal is, I think this only shows
for counters, but if you want counter on element they're
incremented by marker or before and being able to see that
effect would be good
TabAtkins: That argues for end because not expecting to effect
anything in element
astearns: But we don't know why anyone would put counter display in
backdrop
TabAtkins: Yeah. But needs a definition
fantasai: Only time it would matter is if you're increment stuff
referencing from the element.
TabAtkins: Not unusual to things incrementing from the before
astearns: So we can resolve that backdrop is tree abiding?
TabAtkins: It's tree abiding and it occurs after the ::after of it's
originating element
astearns: fantasai you're okay with this?
fantasai: I think it's okay. Good to check if anyone comes up with
reasons
ntim: Rational to put it after ::after?
TabAtkins: Needs to live somewhere. For few cases where it matters
being able to see effects of something that happened in
element, specifically counter or marker, makes sense to
have later. But if you've got a reason for earlier it's
fine
ntim: Okay. No strong opinions. Where is it placed relative to marker?
fantasai: Should be after. It should be first or last.
TabAtkins: before and marker are siblings
fantasai: I don't know if it should be first or last but it has to be
first or last.
astearns: If anybody has a strong opinion, please speak up. I think
I'm ready to resolve it's tree abiding and it's after
::after. If that's wrong can open new issue
ntim: I think WK puts backdrop box as a child of the root element box
ntim: I don't know how easy it is to make it tree abiding
<flackr> slight preference for before since after is usually above
fantasai: I'm a little concerned. Might be better to have in box
order immediately before
TabAtkins: For rendering it doesn't matter given we have top layer.
Making the box generate as a child of the root was
important before toplayer so it could avoid overflows and
clips. That's no longer necessary
ntim: Simpler for WK to put as child of root element because you
don't have render being in weird places and having to update
when you append a child inside top layer element. Initial WK
impl had backdrop as a child of top layer and we moved away
from that
ntim: because first of all we have replaced elements that can't have
children and the code was more complicated to maintain position
TabAtkins: That was my other suggestion is all backdrops are
independent trees so they won't see anything from
documents counters. I'm fine with that too
ntim: I think that's better for impl purposes
fantasai: Will they inherit from originating element?
TabAtkins: Yes.
fantasai: Okay, otherwise a fragment that inherits from originating
element.
fantasai: Seems weird to spec out, but I trust you can do it.
TabAtkins: ntim- to check: if you established a counter on the
backdrop you wouldn't expect to see it anywhere else?
ntim: Not really, not
TabAtkins: Okay, that makes it easier. Separate tree
astearns: So they are tree abiding elements?
TabAtkins: They're siblings of the root tree
oriol: Is it tree abiding if it's a different tree?
TabAtkins: Tree abiding implies it's a single box you can do stuff
to. If it is tree abiding you can do CSS stuff like it's
an element. But if you want to other stuff like width or
height it's defined how it works. Tree abiding is the term
we use for those types of things
TabAtkins: It lives in a tree. Doesn't need to live in document tree.
astearns: Do we have other tree abiding things not in document tree
TabAtkins: No. Always time for a first
TabAtkins: Important part if is it's a rectangle conceptually and can
be styled like one and unlike a selection that we only let
a few things apply to
astearns: Concerns about defining this as a tree abiding element that
lives in a sibling tree to the root tree
fantasai: As long as we clarify inheritance
TabAtkins: Well defined, inherit from their parent.
fantasai: But they live in the tree exactly where they would inherit
from. This needs to be clear
TabAtkins: We had hypotheticals where we discussed this
fantasai: Those were hypotheticals
astearns: We'll need to be careful in defining it.
TabAtkins: I agree that's a good note
astearns: Proposal: backdrop is a tree abiding element. It's tree is
a sibling of the root tree. It inherits from its
originating element
astearns: Objections?
RESOLVED: backdrop is a tree abiding element. It's tree is a sibling
of the root tree. It inherits from its originating element
astearns: before/after?
<fantasai> +1 to not having ::before/::after
TabAtkins: ntim said not allowing is better. Thread was neutral. I'm
happy to have it say backdrop has no child pseudo elements
unless otherwise spec
astearns: Proposal: backdrop does not have a before and after
astearns: Objections?
RESOLVED: backdrop does not have a ::before and ::after
CSS UI
======
Influence of outline-width on auto style outlines
-------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9201
astearns: This was florian
TabAtkins: Look straightforward
astearns: Proposal: Remove the claim that outline-width influences
the rendering
astearns: Objections?
astearns: Proposal: Remove the claim that outline-width influences
the rendering of auto-style outlines
RESOLVED: Remove the claim that outline-width influences the
rendering of auto style outlines
CSSOM
=====
How safe is it really to shorthandify properties?
-------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8398
[hunting for the agenda + reason]
astearns: This isn't the first time we got to it and didn't know what
to discuss. I suggest we take agenda+ off until we have an
idea what to discuss.
fantasai: That's fine. I think it's a non-APAC item. I'd like the
issue resolved
CSS Contain
===========
Make `<container-query>` optional in `@container`
-------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9192
oriol: I can try to explain, though maybe leaverou would prefer to be
in discussion
astearns: Why don't you introduce?
oriol: In this issue when you have a container @rule there's
container-query. Idea is make it optional. leaverou proposed
as a way to have more reasonable defaults for container-query
units.
oriol: That wouldn't be possible, but still proposing to make it
optional. Functionality it would have is to apply styles with
the assumption that a container has a given ancestors name,
but not giving a condition. I think it's reasonable. not sure
super useful, but reasonable and not hard to impl
oriol: Idea is allow to provide a name but with no condition in the
element
TabAtkins: How do you conditionalize styles to only apply if ancestor
has container?
fantasai: Using @container container name {}
oriol: The idea is provide the name with no condition. The condition
would be there is an ancestor with the name
TabAtkins: Got it. That seems reasonable
astearns: Is this possible by setting condition to something that
always evaluates to true
TabAtkins: Yep. And that seems silly to require
astearns: Yep, if this exists already and we're making it easier it's
good
astearns: Proposal: @container rule can have just a container name
and match the closest container with that name
astearns: Objections?
RESOLVED: @container rule can have just a container name and match
the closest container with that name
astearns: I think we're done for the day. Thanks everyone for
calling in.
astearns: Next week we will have time to talk about css 4. Una has
wanted time to present
fantasai: We're also looking at dates for F2F. Anyone that hasn't
responded it would be good to get answers
<fantasai> https://lists.w3.org/Archives/Member/w3c-css-wg/2023OctDec/0041.html
<fantasai> RESPOND TO POLL^^^^^^^^
TabAtkins: I want to tell the admins to get a conference room next
week
fantasai: And there's an async resolution out
<fantasai> https://lists.w3.org/Archives/Public/www-style/2023Oct/0012.html
<fantasai> async resolution proposal ^
astearns: Thanks again and we'll talk next week
Received on Thursday, 2 November 2023 23:09:26 UTC