- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 5 Aug 2021 06:10: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.
=========================================
CSS Overflow
------------
- RESOLVED: Promote scrollbar-gutter to L3
- RESOLVED: Undo previous resolution. Explicitly mark inline-end
padding of block container scrollers as undefined in the
draft for now (Issue #129: Clarify padding-bottom in
overflow content)
CSS Masking
-----------
- RESOLVED: Republish masking-1 as CR Draft (FXTF Issue #431:
Republish masking-1 as CR Draft)
CSS Color 3
-----------
- RESOLVED: Publish Colors 3 as updated Recommendation with Candidate
Corrections (Issue #6486: Publish updated Recommendation
with Candidate Corrections)
Highlight API
-------------
- RESOLVED: Revert previous resolution and allow any ranges to be
added to a registry. At paint time we only use ranges
that are with the originating document (Issue #6417:
Specifying behavior for Highlights involving multiple
documents)
CSS Nesting
-----------
- RESOLVED: Conditionals nested into style rules have their contents
parsed the same as style rules (so raw properties are
allowed) (PR #6483: Allow conditional nested rules to
adopt context)
CSS Sizing
----------
- RESOLVED: When we have a compressible elements also transfer a
fixed min block size through the aspect-ratio to become a
min inline size (Issue #6341: Compressible elements with
aspect ratio)
- Next week the group will come back to issue #6341 to try and reach
a resolution on how to deal with percentage block sizes.
CSS Transforms
--------------
- There were several questions on issue #6488 (After #6320 there's no
way to get an identity transform for interpolation of
perspective) and the group ran out of time before consensus could
be reached. It will be added to next week's agenda in order to
reach resolution.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2021Aug/0000.html
Present:
Adam Argyle
Rossen Atanassov
Tab Atkins-Bittner
Amy Carney
Daniel Clark
Elika Etemad
Simon Fraser
Daniel Holbert
Dael Jackson
Sanket Joshi
Daniel Libby
Chris Lilley
Ting-Yu Lin
Peter Linss
Alison Maher
Cameron McCormack
Alan Stearns
Matt Woodrow
Regrets:
David Baron
Chris Harrelson
Jonathan Kew
Morgan Reschenberg
Greg Whitworth
Miriam Suzanne
Scribe: dael
astearns: This looks like enough people to start
astearns: I did notice fantasai the issue you added the agenda+ to.
If we have time we'll get that
astearns: Any other changes for the agenda?
fantasai: Wanted to ask about moving the scrollbar to overflow 3
from 4
<fantasai> https://drafts.csswg.org/css-overflow-4/ overflow-4 is
mostly about exploratory fragmentation ideas
astearns: We can start with that. Other changes?
TPAC
====
AmyCarney: We discussed maybe meeting with APA at TPAC?
astearns: We'll start with that
AmyCarney: I don't have a designated time yet. You said it might be
flexible on your part. Mostly APA wanted to bring up MQ
again. Discuss things ?? gave a presentation on that could
be in MQ5
astearns: I think APA should propose a time and we will show up. We
have no other obligations for TPAC week yet
AmyCarney: I will discuss that with the group next week
astearns: It will be good to have those items on the agenda. Anything
else you want to discuss we should probably bring it up
before. If anyone else has topics for APA please add it to
the email thread
astearns: Anything more on that?
AmyCarney: That's all
CSS Overflow
============
Moving scrollbar-gutter to overflow 3
-------------------------------------
fantasai: Currently in overflow-4 but it's contents are mostly super
exploratory stuff that we want to work on one day but not a
focus.
fantasai: scrollbar-gutter is looking at being implemented at some
point. Make sense to shift to overflow 3
fantasai: Had discussed moving it to scrollbar, but doesn't style
scrollbar itself and concept of scrollbar-gutter is a
useful layout concept we'll need to reference.
fantasai: I figured make sense to leave in overflow
<florian> +1, WFM
astearns: Do you know where in the process overflow 3 is?
fantasai: Not in CR yet but getting close. Most things are actively
under implementation or are implemented
florian: Low 10s of open issues
astearns: Any concerns with promoting scrollbar-gutter to L3?
astearns: Objections?
RESOLVED: Promote scrollbar-gutter to L3
CSS Masking
===========
Republish masking-1 as CR Draft
-------------------------------
github: https://github.com/w3c/fxtf-drafts/issues/431#issuecomment-891182920
chris: I'd like to publish a new CR draft
chris: It was published in 2014. Bunch of technical changes since.
Then we can start wide review and publish CR snapshot later
astearns: Sounds good to me. Other comments?
astearns: Objections?
RESOLVED: Republish masking-1 as CR Draft
CSS Color 3
===========
Publish updated Recommendation with Candidate Corrections
---------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6486
chris: Long bug with hsl colors. Color 3 has ABC program for that. We
received a report that almost 50% of values are wrong.
chris: Fixed in color 4 by running the JS. Having done that made
sense to put in L3.
chris: Also a couple of little changes in ED that I also did as
candidate corrections. We can publish and get that process
moving. Doesn't require directors decision, just decision to
publish
astearns: Concerns?
florian: Question- we're positive JS is right?
chris: Yes
florian: Rest is editorial?
chris: Yes
chris: Removed media from propdef is in as candidate
florian: Sure. Process def of editorial is narrow
chris: They're property corrections that allow you to see in place
the change. Proposed corrections have normative force
florian: If parts of spec are editorial you can do them immediately.
If they are grey...
chris: I think it's grey zone
astearns: Other comments?
astearns: Objections to Publish Colors 3 as updated Recommendation
with Candidate Corrections
RESOLVED: Publish Colors 3 as updated Recommendation with Candidate
Corrections
astearns: Other publishing things?
Highlight API
=============
Specifying behavior for Highlights involving multiple documents
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6417#issuecomment-884332586
dandclark: This is a rerun of an issue I raised a couple weeks ago.
Reached resolution but thought of an issue with that
resolution.
dandclark: Summary is that if we have a couple of same domain iframes
have a couple of registries and can add range from wrong
window. Resolved to make impossible by throwing when you
attempt to add highlight registry from another window
dandclark: This is trying to establish invariant where they only have
ranges from same window. Issue might be is if I add range
from same window and I moved to another window I have
violated the invariant and it's not clear what to do
dandclark: No straightforward way to block unless we check when we
move
dandclark: I'd like to revisit if throwing is right. If we can't
maintain this invariant re-open allowing and during
painting step they're skipped.
TabAtkins: If we can check what window they're from at painting time
I'm not sure why it's problematic to check upon assignment
to registry
dandclark: We can, but if at time assigned to registry it's correct
but then I can take and position in a different window and
it's too late to stop
TabAtkins: Oh, didn't realize range could move like that
dandclark: Codesnip in the issue
<dandclark> https://github.com/w3c/csswg-drafts/issues/6417#issuecomment-884332586
<iank> ranges are amazing like that.
florian: I haven't followed this closely, but it reminds me of
interaction between ranges and CSS contain where range had
one end outside and one within and the possibility that
changing violates containment
florian: Had considered having in dictionary and ignoring it. I don't
think we resolved there and it's still open
<florian> the css-contain issue is:
https://github.com/w3c/csswg-drafts/issues/4598
smfr: Do we need to invent a new kind of range that's live but
contained in a single document? Cannot move between docs?
TabAtkins: And restrict to only accept that type?
smfr: Range would associate to that document and throw if you call
with a node from different doc?
TabAtkins: But we only allow that new type of range with this API?
smfr: Possibly
TabAtkins: If we didn't restrict not sure what we gain with the new
range type
smfr: Yeah, only get benefits if you enforce using the new kind of
range
sanketj: I wanted to echo what florian was saying. Similarities with
the contain boundary case where it doesn't make sense for
range boundary to check and it's allowed at paint and we
decide then to allow
sanketj: This should work same where we allow authors to place ranges
where they want but when we paint we only paint those on
same originating doc as the highlight registry. That's my
preferred solution here
<dandclark> +1 to what sanketj said :)
<GameMaker> +1 for sanketj/florian's solution as well
astearns: I think I prefer that solution as well. I can imagine this
being whack a mole where we restrict things being added and
someone comes up with a method of getting a range into a
registry we hadn't thought of
astearns: Seems like it's fitting the problem better
Rossen: I agree with the path forward.
Rossen: Before we resolve, sanketj or florian, can you remind us what
the OM or a11y model behind the ranges? How would they be
exposed to assistive tech. Expose collection, only active,
etc.?
florian: I think unresolved in spec. Maybe sanketj knows what was
explored implementation-wise
sanketj: I don't think we've reached exploring how to expose. OM-wise
the highlight, range objects are OM types we're working with
Rossen: I think it would be unfortunate if we reach too far into
implementing without considering those scenarios. I would
suggest to start thinking through these
florian: You're right. It's been known for a while but it's about
time we look into it
heycam: Just realized I think we have another instance of this which
is selection object from getSelection. I don't remember what
happens but maybe we can see what that does and perhaps do
the same
astearns: Anyone know what happens for selection?
sanketj: I don't know how selection values update, but nothing blocks
from being selected in another document. I'm not sure what
happens when it does, though. Nothing stops it from being
placed in arbitrary locations
astearns: Previous resolution was throw on mismatches
astearns: I'm hearing proposal is revert previous and allow any
ranges to be added to a registry. At paint time we only use
ranges that are with the originating document
astearns: Any discussion on that proposed resolution?
dlibby: We kept mentioning paint time. Is it more about how
properties cascade? Or is it really checking when you paint?
TabAtkins: I suspect it will be some ranges are valid when in right
document and painting will only paint valid ranges. And
that would let you hook to a11y tools where they only get
valid ranges
florian: And the cascade is for set of ranges for whole highlight so
some invalid range doesn't change cascade
dlibby: That's right, thanks
astearns: Any more comments?
astearns: Objections?
RESOLVED: Revert previous resolution and allow any ranges to be added
to a registry. At paint time we only use ranges that are
with the originating document
astearns: Thanks for bringing this up again dandclark
CSS Nesting
===========
Allow conditional nested rules to adopt context
-----------------------------------------------
github: https://github.com/w3c/csswg-drafts/pull/6483#issuecomment-891359090
TabAtkins: Currently in nesting we have text to let you nest
conditional into style. But we don't change the interior
of nested media rule. Only accepts more rules.
TabAtkins: If all you wanted to do is set a particular property when
a media matches you have to write a rule with a & as a
selector to let you put property
TabAtkins: Proposal is extend mixture of properties to also apply to
nested conditional rules so if it's directly nested inside
a conditional you can put it in
TabAtkins: Example in issue
<TabAtkins> .foo {
<TabAtkins> display: grid;
<TabAtkins>
<TabAtkins> @media (orientation: landscape) {
<TabAtkins> grid-auto-flow: column;
<TabAtkins> }
<TabAtkins> }
astearns: Adam put current and proposed. Would both work or only
proposed?
TabAtkins: Both would work. Putting full rules is allowed, but not
required when you're only styling element from outside
<jensimmons> The proposed syntax is *far* better for Authors. Having
both work is a good idea, for those who think that's the
only way it will work.
heycam: That proposed one you have @media as direct child. What would
happen if you used & in some other rule?
TabAtkins: That's specified already. Contents of nest conditional
rules do inherit nesting selector context. Their &
resolves to the nearest parent style rule
TabAtkins: The other example shows how you would write it today with
an &
<TabAtkins> .foo {
<TabAtkins> display: grid;
<TabAtkins>
<TabAtkins> @media (orientation: landscape) {
<TabAtkins> & {
<TabAtkins> grid-auto-flow: column;
<TabAtkins> }
<TabAtkins> }
<TabAtkins> }
TabAtkins: That will continue to work and & inherits content from the
outside
astearns: See support from jensimmons
astearns: Other comments?
astearns: Anyone against allowing or concerns about allowing this?
astearns: Proposal: Not require the & syntax inside?
TabAtkins: I'll write in IRC
<TabAtkins> proposed: conditionals nested into style rules have their
contents parsed the same as style rules (so raw
properties are allowed)
astearns: Any objections?
RESOLVED: Conditionals nested into style rules have their contents
parsed the same as style rules (so raw properties are
allowed)
TabAtkins: That was last major issue before FPWD so we will be
publishing very soon (we have the resolution to publish)
CSS Sizing
==========
Compressible elements with aspect ratio
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6341
iank: The context for this is that when we've got compressible
element. Example min size we look at min width. If you've got
min width 50px that's the min size. What nobody does with
aspect-ratio is transfer min-height
iank: Can get weird min width 50x and min height 100 px and
aspect-ratio of 1:1 you end up with a rectangle. Proposal is
allow the transfer
iank: Interesting is what to do when can resolve min-height of 100%.
That's what fantasai and I have been talking about
iank: I'm on side of resolving % since that matches what we do with
height and I think leads to better behavior. I think fantasai
has concerns with that
fantasai: I read your reply, but haven't thought through it
fantasai: My concern is we have weird stuff with grid and flex with
cyclic aspect of grid in particular. Don't want to resolve
% in a way that causes issues for current content
fantasai: Pretty sure we should transfer fixed sizes. Less sure on %
fantasai: I did notice you responding to is your table is asymmetric
between 2 axis and block size resolves and definite. Why
not both definite or both 0?
iank: That's what happens in the min/max size contributions. Resolve
if it's definite and that transfers but inline axis is cyclic.
fantasai: I think symmetric is better
iank: I don't think so. By definition it's not symmetric
fantasai: If height is resolved but not width it's weird
iank: That's what happens, though
fantasai: % usually resolves in width
iank: Explicitly for min/max. For inline axis they're cyclic. For
block we do resolve when possible. That's how min/max works in
all browsers today
astearns: Sounds like on that concern we should have test cases
iank: Most of the test cases I've written. I can give example of how
asymmetric today
fantasai: I think we can agree if it's fixed size it should transfer.
Resolve on that and keep discussing %?
jensimmons: Question is about use cases and not %. I have a system
where an image is placed and I don't know aspect-ratio. I
put on it max-width 100%. So that would be usually 100%
but blow up if it's big.
jensimmons: I also do max height of 100dvh
jensimmons: So then I want it to be no bigger than 100vh if it's
quite tall and it could shrink down a bunch because of
it's aspect-ratio.
jensimmons: Is that the intention of this?
fantasai: Or that case nothing changes. Case is what happens if you
have that code and a min-height or a min-width. How does
that interact with your max if you put it in a shrink to
fix box. What size will it end up being. In a min-content
grid column current code allows the image to shrink to 0
even though has an intrinsic size
fantasai: If you set a min-width we won't shrink to 0. If we have a
min-height instead do we transfer the min-height across the
aspect-ratio to prevent collapsing to 0. That's the
question here
fantasai: If you give it a min-height of 50px in a shrink to fix does
it transfer across and have a min-width. The question iank
has is if i set min-height 10% what do we do there
<iank> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=9537
iank: jensimmons I just put in a link to a case
<iank> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=9536
iank: fantasai I put in case 9536 to show the asymmetry we have today
astearns: We could resolve for the definite case. Or resolve for both
definite and % and leave to fantasai to determine if % is
incorrect?
fantasai: I'm not sure I understand the asymmetric issue. Happy to
resolve on fixed
astearns: Resolve on just the fixed today, then I'd want to come back
next week for %
fantasai: Sure
iank: Proposal: When we have a compressible elements also transfer a
fixed min block size through the aspect-ratio to become a min
inline size
astearns: Any further discussion?
astearns: Objections?
RESOLVED: When we have a compressible elements also transfer a fixed
min block size through the aspect-ratio to become a min
inline size
astearns: We'll come back next week for % case
CSS Overflow
============
Clarify padding-bottom in overflow content
------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/129#issuecomment-891194919
iank: I wasn't around last week. We have data that weren't not as
compat constrained as we thought. So I'd like to undo resolution
iank: We've been slowly changing our behavior. Most recently for flex
to consider inline and block end padding. Did this in Chrome 91
which has been out for 2 months. Haven't received any bug
reports
fantasai: That's in the spec already
florian: Resolution is only block layout
iank: Getting to that. As part of this we had use counters
iank: 1 for if we change behavior for if flexbox already scrolled
iank: [missed] If block it's already scrollable that's less than the
change we did for flexbox. So if the block scrollable element
is scrollable in that axis we can add the end padding
iank: Second is that we're making something not previously scrollable
in inline direction. Looking at data might be web compat as
well but need to investigate more. One library is causing use
counter to be relatively high and I need to research more. May
be one trick we need to do
florian: If I got that right you say that even without adding padding
we were scrollable that case is safe? And looking at
remaining?
iank: Correct
florian: How long to get data? I think you're right that if we can do
it it's preferable
iank: That's why I want to undo previous
florian: Or at least hold
iank: If something is scrollable and we add inline-end padding that's
fine. Should revert that. We're prepared to try and we can
report back. We're doing this slowly and watching metrics
iank: I think still might be possible to do it universally. One trick
we might need to do
dholbert: The bit about if things are already scrollable makes me
slightly uneasy. Are you saying whether or not we include
inline padding depends on if we're overflowing and what
happens to content changes where we wouldn't be
<astearns> +1 to concern if we can only do this for
already-scrollable things
iank: Today Chrome calculates both overflow areas and return one or
the other. With these 2 overflow areas can compare to padding
rectangle and see this is already scrollable so we could return
slightly larger one.
iank: If it became dynamic and it didn't have overflow we would stop
including inline end padding
dholbert: And if it would if you include inline end and wouldn't if
you didn't? Or if you weren't in that scenario and content
is deleted do we suddenly not include the inline padding?
iank: Correct
florian: Proposing we resolve on this, leave rest, and you tell us
when you know? Or leave whole undefined?
iank: Probably easiest to leave undefined at the moment with an
explanation. I think might be able to do universal but I need
more use counters
florian: I suspect it's worth waiting for if it's a reasonable
timeframe. It's a better behavior
iank: Yeah. I need to add use counters to detect for this library to
see if we break
<fantasai> I'm ok with leaving this specific case -- inline-end
padding within block container scroller -- to be undefined
for now
florian: Do we need to be concerned about different compat concerns
for other browsers?
iank: Not for inline. I would have been more concerned about block
iank: Example timeframe for the data is 3-6 months
astearns: Is that reasonable timeframe?
florian: I guess. Was hoping for CR shorter
iank: Issue has been open for 5 years
astearns: And we have reverted resolutions in the past too
astearns: My understanding is that we are gaining consensus on undo
previous resolution and leave the issue open until more data
fantasai: Happy to leave undefined but I don't think needs to block CR
astearns: Undefined in draft?
florian: It's an issue. We'll mark as issue and undefined
astearns: Proposal: Undo previous resolution. Explicitly mark as
undefined in the draft for now
astearns: Objections?
RESOLVED: Undo previous resolution. Explicitly mark inline-end
padding of block container scrollers as undefined in the
draft for now
iank: What I'm going to do next is change behavior to include inline
end padding if it was scrollable and I'll add another use
counter for the case I was more worried about. I'll report back
in a couple months
CSS Tranforms
=============
After #6320 there's no way to get an identity transform for
interpolation of perspective
-----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6488
TabAtkins: Previously we had odd behavior where perspective function
with 0 treated as no perspective. That was null transform.
TabAtkins: A little while back resolved that's weird and silly.
Perspective of 0 px is your eyes are on the screen and
that's different. We clamped to a floor. You can't say 0
anymore
TabAtkins: Now we have no way to say no perspective applied. That
means infinite. Possibly this can be done with infinity
keyword in calc. A bit awkward and implies infinite link
is stored internally or the max value triggers this
TabAtkins: We probably want an actual preserved value. Proposal is
allow perspective to take keyword infinity directly
TabAtkins: That's the no transform, does 0 stuff
astearns: Reasonable to me. Any concerns?
smfr: Do we have that keyword?
florian: How is it different from none?
TabAtkins: None is a null transform list. If you need to match 2
lists and want 2nd list to not do anything you cannot
write that. You can't put none in the middle of a
transform list
TabAtkins: I'm not sure what you mean smfr
smfr: Animation iteration takes keyword infinite. Are there other
places in CSS where this would be reasonable or is this special
TabAtkins: I think special case because any other place
where....well...any place where infinity might be
meaningful we should have a keyword indicating that
behavior rather than fallback to calc constant because
that is clamped to a numeric value
smfr: What happens when interpolate between infinity and 100
TabAtkins: Well defined. Infinite is identity matrix. It has to
because before this perspective 0 was the infinite, it was
just the wrong way to write it
astearns: We're over time. I'm guessing we should punt to next week
and resolve
smfr: Sounds fine
TabAtkins: Fine
Received on Thursday, 5 August 2021 10:11:34 UTC