- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 3 Mar 2022 06:51:15 -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.
=========================================
Future F2F Meetings
-------------------
- Group members are asked to fill out the anonymous survey on TPAC
attendance that was sent to the private list
CSS Cascade
-----------
- There was no strong preference on the call for how to handle issue
#7083 (Should 'revert' really treat animation origin as author
origin?). Discussion will continue on github to try and
understand the reasons behind the original decision for the
'revert' behavior.
CSS Contain
-----------
- RESOLVED: Keep the current syntax (Issue #7073: Move style() to the
feature level in the grammar)
CSS Images
----------
- RESOLVED: We add to Images 5 these 2 properties, object-viewbox and
object-overflow. 1 is boolean about hidden and visible
and the other is equivalent of SVG viewbox. We would try
and create a mapping between SVG and new property. New
property would take inset and xywh so there's 2 ways to
specify size (Issue #7058: Proposal to allow replaced
elements to paint outside of their bounds)
CSS Flexbox
-----------
- RESOLVED: Treat items as not monolithic (Issue #6855: Multi-line
column flexbox fragmentation)
- RESOLVED: Update fragmentation rules to flexbox to handle
multi-line independently (Issue #6855)
CSS Grid
--------
- RESOLVED: Add this functionality to grid L3 (Issue #6692:
Conditional subgrid fallback when no parent grid is
available)
CSSOM View
----------
- RESOLVED: Add isVisible to element as defined in the issue. Work
out the corner case in a separate issue (Issue #6850:
Proposal: add Element.isVisible[toDocument] to detect if
element is visible in the document)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2022Mar/0000.html
Present:
Rossen Atanassov
Tab Atkins Bittner
David Baron
Oriol Brufau
Elika Etemad
Robert Flack
Simon Fraser
Chris Harrelson
Daniel Holbert
Dael Jackson
Vladimir Levin
Daniel Libby
Ting-Yu Lin
Peter Linss
Alison Maher
Cameron McCormack
Alan Stearns
Miriam Suzanne
Regrets:
Adam Argyle
Jonathan Kew
Florian Rivoal
Jen Simmons
Scribe: dael
Future F2F Meetings
===================
Rossen: It's 2 minutes past so let's get going
Rossen: Before we get going, I want to call for any additional items
or changes
Rossen: Also want to use a minute and ask for you to go ahead and
provide the anonymous signal as to if you're interested in
joining TPAC in person, virtual, or not at all
Rossen: Reason is we want an idea about how many folks are willing to
do in person F2F in general. On the back we can start
figuring out if we can start doing hybrid F2F.
Rossen: We have one coming with TAG where it's split between 2
different geographies and we'll find a way to sync
Rossen: There are ways to think about how to meet in person. But want
a pulse about if most people want to do it or not
Rossen: Link is in the private email
Rossen: Any extra agenda items or changes?
CSS Cascade
===========
Should 'revert' really treat animation origin as author origin?
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7083
oriol: I can explain unless fantasai wants to explain
fantasai: Go ahead
oriol: The thing is that according to spec when you have revert in
keyframes rule, that's animation origin, and revert rolls
back. Spec says animation origin is author origin and we roll
back to user. Only happens for revert but not revert-layer
oriol: Having this special behavior for revert surprised me when impl
this in webkit where revert didn't work in keyframes
oriol: Seemed strange
oriol: Also has performance cost. By time resolving keyframe styles
you have base styles of the element. At least WK not tracking
which styles are from which declarations. If there's revert I
have to recollect all the declarations in order to have proper
behavior
oriol: revert-layer it's just a matter of using base style so no perf
hit
oriol: Not just WK, check in Blink. Mentioned impl this required
disabling and optimization.
oriol: Wondering if could change
oriol: Anders mentioned blink would still disable optimization due to
em units
oriol: No strong opinion. It surprised me and maybe more consistent
to align. But 2 behaviors can give more flexibility to authors
Rossen: Other opinions?
fantasai: The main thing to think about is if you use revert in
animation do you want it to revert to user style sheet? Or
revert the rules for the keyframe down to just the authors
regular rules
fantasai: From user point of view that's the question
fantasai: No strong opinion
fantasai: I think original thought is revert in author stylesheet
removes what author has done. Since animations more likely
to be used by author having revert roll back to no author
styling made sense at time. I think dbaron proposal for that
Rossen: Looking to see if dbaron is here
<dbaron> not here
oriol: About which one can be more useful, I guess what's spec for
revert may be a bit more useful since revert-layer...in most
cases you can just remove the declaration. Exception is a
fallback in a value
Rossen: What would you prefer here? Prefer to try and resolve now?
Rossen: Which way would you prefer to take the resolution, oriol? If
we need to wait for dbaron I'm sure he can get back to us if
her doesn't agree or we wait for dbaron
oriol: I don't have much of an opinion. Opened for discussion and to
know background. I don't have a hurry to resolve
oriol: Maybe we can wait for dbaron
Rossen: If there's no urgency let's continue in GH. I see dbaron so
I'm hoping he'll engage on GH
CSS Contain
===========
Move style() to the feature level in the grammar
------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7073
miriam: When we defined both size and style functions for the
@container rule we made them so they could wrap larger chunks
of syntax so can have multiple style/size queries in style
miriam: Seemed useful as syntax sugar. Since then removed size and
left only with style and possibility of future functions
miriam: What we're looking at is do we still want style and any
future functions to have that sugar of allowing multiple
queries or statements inside the function? Or restrict to
each function is a query?
miriam: Provided 2 examples, don't look terribly different. Lean
slightly toward keeping flexibility but very slight. Anders
argued to remove it
fantasai: My thought is that it's annoying to type something over and
over again. If you have a complex style query it would be
annoying to type style again and again. Selectors has built
in logic to handle multiple boolean logic. I think for
author friendliness it's better to allow
Rossen: If Anders is not here; anyone in favor of dropping?
miriam: I haven't heard from anyone else in that direction
Rossen: I'm fine with taking a resolution and revisiting in case
Anders has a strong position and reason. From listening to WG
seems we're leaning more to keep it
Rossen: Other opinions?
Rossen: Objections to keep the current behavior?
RESOLVED: Keep the current syntax
CSS Images
==========
Proposal to allow replaced elements to paint outside of their bounds
--------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7058
TabAtkins: While discussing the shared element transitions proposal a
couple weeks ago there was some obvious need to control
how the image snapshot sized better
TabAtkins: The image snapshot can be sized to elements but larger to
capture outlines or shadows. Awkward interaction with
normal image sizing. When looking at Jake's proposal I
realized this would be useful in general and addresses a
gap in Paint API
TabAtkins: General proposal is add 2 properties to object family;
object-viewbox and object-overflow. Apply a viewbox to
replaced content and allow it to overflow context box
TabAtkins: Viewbox is same grammar as SVG and has same effect. Let's
you say x/y boundary is the image boundary.
TabAtkins: [gives example]
TabAtkins: The natural size of image adjusts to spec width and
height. For sizing it assumes the element transition
snapshot is the size of element border box. If part
outside is displayed somehow due to something like
object-overflow you can see the rest like the shadows
TabAtkins: Generalizing the use case, one of the use cases we wanted
to handle in Houdini Paint API is doing custom shadows.
Groups like Google material design did optics based
shadowing. Because couldn't paint outside the bounds you
had to do weird tricks to do it
TabAtkins: This would allow you to do that exact thing as well when
paired with object-overflow. 2 properties, hidden and
visible. Hidden is like today
TabAtkins: With these 2 properties would help a lot with shared
element transitions but useful general property
TabAtkins: fantasai provided feedback might be good to have it just
be viewport and we upgrade the SVG to a property and do
that.
TabAtkins: I'm fine with that if people believe it's a good way to go
TabAtkins: Last I checked no other feedback. Any questions or
concerns I'd love to hear it.
TabAtkins: Else could add to images
smfr: Sounds reasonable. Not a huge fan of new ways to do ink
overflow, but I see the use case
smfr: If you do object overflow and then object-fit:cover you'll have
bits outside that don't respond to hit testing. Might encourage
people to make weird content for hit testing
TabAtkins: That is true. I don't know how to address it, though. It's
part of core functionality since shadows shouldn't hit,
but you could also do cover. Not sure if we can solve that
or put a note saying don't do
smfr: Note is probably fine
smfr: Other thought is how it interacts with aspect-ratio
TabAtkins: Should be straight-forward. Changes element natural size
to spec width and height and that implies aspect-ratio.
I'm not sure if we allow width and height without
aspect-ratio. Should have same effect. 2:1 and set square
viewbox it's 1:1 for all other purposes
smfr: Alright
plinss: I thought I heard there would be viewbox property that takes
same as SVG viewbox?
plinss: Little concerned because SVG will look a bit like standard
rect and it's not. Might be confusing. Maybe have it be a
shape function?
TabAtkins: Would that imply we want to allow other shape or is this
just special for the property?
plinss: Restrict to small set of shapes. rect and inset might make
sense.
plinss: Just confusing about a bare property that takes 4 values but
it's not the same
<fantasai> +1 to plinss's suggestion of both rect() and inset()
TabAtkins: I get you. And having rect and inset would be pretty
worthwhile. If you use viewbox you have to get width and
height but inset lets you set 20px. I think that sounds
pretty good
plinss: I'm not opposed to having another one to take SVG syntax for
people who know it but we should call out
TabAtkins: Doesn't rect take svg?
plinss: I think it's trbl
plinss: I don't want to rat hole, but calling out
TabAtkins: We don't have rect, we have inset. So add a rec or some
other name that takes xy stuff
<fantasai> xywh()
plinss: There is rect on clip unfortunately
TabAtkins: Okay
dholbert: One other concern with SVG viewbox is it's a list of 4
numbers and doesn't allow units or %. Might make it we'd
have to extend a fair bit. Might be worth abandoning it for
that purpose
TabAtkins: I would have presumed we upgrade to css units. But point
taken
vmpstr: I wanted to confirm how scaling works. If we scale images
such that we squish. Squish the viewbox and overflow squishes
TabAtkins: Right. If you scale image of SVG element using viewbox the
whole thing squishes including the outside
fantasai: For rect function media uses xywh. Makes it clear what each
argument would be.
fantasai: For SVG correspondence we've tried to create mappings. We
should look more because if we can make them map it solves
viewbox which has not had a mapping
TabAtkins: I don't think there is a big problem...speaking from
ignorance but suspect not a big problem with making this
property override viewbox of inline SVG. Probably okay.
TabAtkins: Should put in as an issue without effecting rest of design
fantasai: If you put it in from an embedded SVG it should have same
effect
TabAtkins: Not sure about that. That would mean that applying the
style to an image element could have distinct effects
based on source type
fantasai: True for width and height. If you apply sizing to root SVG
for embedded vs inline get different
TabAtkins: Talking embedded SVG vs png
fantasai: No, if you have it inside the SVG file
TabAtkins: Yes, yes. If it applies to svg-in-html it would apply to
raw SVG as well
fantasai: Sounds like proposal is we have these 2 properties,
object-viewbox and object-overflow. 1 is bool about hidden
and visible and the other is equivalent of SVG viewbox. We
would try and create a mapping between SVG and new
property. New property would take inset and xywh so there's
2 ways to spec size
fantasai: And that's in images 5
TabAtkins: Correct
Rossen: Other opinions?
Rossen: Objections?
RESOLVED: We add to Images 5 these 2 properties, object-viewbox and
object-overflow. 1 is boolean about hidden and visible and
the other is equivalent of SVG viewbox. We would try and
create a mapping between SVG and new property. New property
would take inset and xywh so there's 2 ways to specify size
CSS Flexbox
===========
Multi-line column flexbox fragmentation
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6855
alisonmaher: This issue is how to handle fragmentation for multi-line
column. A couple questions
alisonmaher: First is around the spec recommendation to treat items
as monolithic. Curious reason and if we should remove
because otherwise items in a single line could frag
differently than a 1 line multi-line
alisonmaher: Also, each element has it's own stack. Implies
multi-line column flex has it's own context except items
are monolithic. Doesn't make sense. If we fragment
independently the result would be closer to
unfragmented. Firefox doesn't match for either of these
alisonmaher: Proposal is update spec to match FF for frag multi-line
column
alisonmaher: May have to reconsider break-before and -after
alisonmaher: Curious about reasons to keep spec text as is
TabAtkins: First, alisonmaher, this entire chapter was a best guess
set up and we're happy to change to match impl or good
results.
TabAtkins: What you're saying makes sense. Pending more detailed
review as I write this seems plausible
fantasai: What TabAtkins said, chapter was a best guess. Multi-line
column flexbox was the weirdest. Written the way it was
because not sure what you're suggesting is possible. If it
is possible to shuffle across page break, it makes more
sense.
fantasai: As to if we should make any changes to this, we should try
and match both good behavior and implementations. I think
these changes make sense
Rossen: Other opinions? fwiw I remember some reasoning behind
monolithic items it was because simpler and we were waiting
for an implementation and here we are
Rossen: alisonmaher can you summarize the proposal?
alisonmaher: Update flexbox spec to fragment multi-line columns
independently and make items not monolithic
Rossen: Objections to not monolithic?
RESOLVED: Treat items as not monolithic
Rossen: Objections to update fragmentation rules to flexbox to handle
multi-line independent
RESOLVED: Update fragmentation rules to flexbox to handle multi-line
independently
CSS Grid 2
==========
Conditional subgrid fallback when no parent grid is available
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6692
Rossen: Opened by Morton. TabAtkins can you take?
TabAtkins: Morton is asking for...right now the rule is if you say a
grid is subgrid in 1 axis and it doesn't have a parent it
reverts to being an ordinary grid with no declaration on
that axis
TabAtkins: Can rely a bit on grid template areas but it's hacky. We
consider this to be an error case. If you say it's a
subgrid and not inside a grid you messed up
TabAtkins: However, if you're writing an independent component
reasonable to allow for that. If subgrid works in the
parent and if not has own tracks
TabAtkins: Upon review fantasai and I decided grammar handles this.
You can already spec the names without sizes. If we allow
a full track list seems reasonable for grammar and we
ignore sizes if you're subgrid
TabAtkins: Small wrinkle from oriol is make sure not to put
auto-repetition is. We have a grammar term that does that
and allows non-auto-repeat
TabAtkins: We wouldn't put in grid 2, but reasonable for grid 3 with
other new features. Thoughts? Objections? Okay to explore
in grid 3?
<miriam> +1 I would use this
<dlibby> +1 for grid 3
Rossen: Following your explanation it seems reasonable. Curios about
other opinions. See IRC support
Rossen: Sounds like something we can add to L3 of grid. Objections?
RESOLVED: Add this functionality to grid L3
Rossen: Means you need to make Grid 3 TabAtkins
fantasai: It's on the to do list
TabAtkins: Long list of features we've deferred
fantasai: Wrapping up L1 & 2 first
CSSOM View
==========
Proposal: add Element.isVisible[toDocument] to detect if element is
visible in the document
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6850
chrishtr: Brought this up a couple weeks ago. 2 use cases to add. 1)
know if an element is visible via testing framework. Some
links for that in the issue. 2) if content under
content-visibility:hidden is skipped. Checking without
forcing render
chrishtr: Previously talked a bit about name and about mapping this
back to use cases and prior art. Discussion about how to
make this extensible to different definitions of visible
chrishtr: I went back and looked at jquery visible function and
looked at a11y tech. a11y tech looks at internal UA APIs so
this seems not applicable.
chrishtr: Proposal: add isVisible function with 2 default behaviors.
Having a layer box and not being in
content-visibility:hidden subtree. Dictionary argument to
allow you to opt into other types that are both convenient
and not convenient to query now in order to allow devs to
query
Rossen: Looking at some of the discussions around a11y and how such a
feature could be used. I think you're right most AT go
through something like UI automation and not this. But what
they go after is they look at APIs available to authors and
then negotiate with platforms about if it makes sense for
them to have
Rossen: My motivation there was to see if having a property like
isVisible won't trigger additional interpretations. Having
had discussions with one of the ATs it doesn't look like
they'd be too interested. I can't speak to more then them
Rossen: Based on that I'm fine. if more requests come our way we can
consider if we should discuss this as part of css-aam to have
further mappings
chrishtr: Okay. I had a similar discussion with Chrome a11y team and
they reached same conclusion
Rossen: Okay. Back to functionality merit, any other opinions or
reason we want to change anything?
chrishtr: Proposal: Add isVisible function to the element object that
has behavior: has a box and is not skipped by
content-visibility:hidden ancestors. Dictionary of options
for additional types of visibility; tracksVisibilityName
which is a bool attribute
<heycam> "track" sounds like some checking that is ongoing
chrishtr: Return value is also a dictionary indicating if it's a box,
if it's skipped, and would tell you other information based
on what's defined
chrishtr: Most important is isVisible and we can work on dictionary
in ED
Rossen: Objections to accepting this?
heycam: I think the word tracks sounds like doing something ongoing.
Probably a better word to be found
fantasai: Check?
chrishtr: Check is a good word
chrishtr: Change proposal to check. That makes sense
flackr: Skimming proposal. If you requested a bunch of checks and
element was skipped do we clean the style to see if other
checks are true or false?
chrishtr: Hm. Hadn't considered. If it doesn't have box or box is
skipped...I guess if you spec those perhaps it should force.
flackr: Not sure right behavior
chrishtr: Either could ignore you or return false. Weird to say
you're visible but not
vmpstr: Will their return a bool of all params?
chrishtr: Returns a dictionary.
chrishtr: Another option would be return the first 2 and then it's
null
Rossen: Would it be better to, instead of think on our feet, let's
resolve on the bigger capability and then you can work out
this case in a separate issue. Unless you're looking for a
concrete resolution
<vmpstr> +1
<flackr> +1
chrishtr: Makes sense to resolve on the big thing
Rossen: Proposal Add isVisible to element as defined in the issue.
Work out the corner case in a separate issue
RESOLVED: Add isVisible to element as defined in the issue. Work out
the corner case in a separate issue
Rossen: That brings us to the top of the hour
Rossen: Thanks for calling. Please answer the quick survey about
showing up in person for a F2F
Received on Thursday, 3 March 2022 11:51:55 UTC