- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 26 May 2021 18:33:16 -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 Color
---------
- RESOLVED: Republish WD of Color 4 & 5
CSS Sizing
----------
- RESOLVED: Only apply contain-intrinsic-size: auto with
content-visibility: auto (Issue #6308: Only apply
contain-intrinsic-size: auto with content-visibility:
auto)
- The use case described in issue #6257 (Removing intrinsic
aspect-ratio from an image) is better achieved by contain:size.
The group is open to adding aspect-ratio:none but needs more use
cases to determine if it's necessary.
CSS Cascade
-----------
- RESOLVED: Accept the new reorder layering as detailed in the issue
(Issue #6284: Reconsider placement of unlayered styles,
for better progressive enhancement?)
- In addition to the default agreed upon above there is interest in
further exploration into allowing authors to define which layer
should be exposed to older browsers.
CSS Scoping
-----------
- RESOLVED: Tentative agreement on the spec text as in the draft.
Subject to further review of current interop behavior
(Issue #1995: Handling global name-defining constructs in
shadow trees)
- TabAtkins will put together the change log and then request a
republication of Scoping.
CSS Contain
-----------
- RESOLVED: Container queries are triggered by independent property
(name to be bikeshed) (Issue #6174: Should there be a new
syntax for establishing queryable containers?)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2021May/0014.html
Present:
Rachel Andrew
Adam Argyle
Rossen Atanassov
Tab Atkins-Bittner
David Baron
Christian Biesinger
Mike Bremford
Oriol Brufau
Emilio Cobos Álvarez
Elika Etemad
Simon Fraser
Chris Harrelson
Daniel Holbert
Dael Jackson
Brian Kardell
Una Kravets
Rune Lillesveen
Chris Lilley
Ting-Yu Lin
Peter Linss
François Remy
Morgan Reschenberg
Florian Rivoal
Miriam Suzanne
Greg Whitworth
Regrets:
Tantek Çelik
Jonathan Kew
Alison Maher
Lea Verou
Scribe: dael
Rossen: As I mentioned earlier, looking for any other extra agenda
items or topics we need to discuss. I did see chris's
addition.
Rossen: Anything else?
Rossen: MQ and color adjust are at the end because intended to
discuss next week. We might have to push if we get to them
CSS Color
=========
Republish Color 4 & 5
---------------------
Rossen: Color 5 is an updated WD based on the FPWD. Is that the case?
chris: Correct. both are WDs
Rossen: For 5 let's just republish.
Rossen: For color 4 it's being prepared for CR. Anything special we
should pay attention to as we're close to CR?
<fantasai> +1 to publish
<fantasai> Publish early, publish often
chris: It has had wide and horizontal review. Would like to push so
when we go to CR number of changes is small. Right now changes
list is huge
Rossen: I wanted to get an understanding of if republish needs to
push spec back into wide review
chris: I don't think so
RESOLVED: Republish WD of Color 4 & 5
CSS Sizing
==========
Only apply contain-intrinsic-size: auto with content-visibility: auto
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6308
cbiesinger: With contain-intrinsic-size: auto you can get into
situation where current size of element is based on css
property that's no longer set on element.
cbiesinger: Set explicit width, remove it, explicit width could still
be remembered and applied.
cbiesinger: Weird situation. Main use case for
contain-intrinsic-size: auto is when in combo with
contain-visibility: auto
cbiesinger: Suggestion is to make it only apply with
contain-visibility: auto which means this will not be
visible for user but address main use case
cbiesinger: What does WG think. Is this a problem we care about and,
if is, is this a good solution?
TabAtkins: Makes sense to me. Happy to do this.
emilio: Can you remind me of how we made content-visibility: auto
work? Does it change just the used value?
cbiesinger: Not sure offhand
emilio: Depending on how that works this doesn't solve the problem or
solves it.
emilio: If the computed value remains auto proposed solution...needs
to be more subtle
chrishtr: Saying script looks at bounding client rect of the
offscreen element it would notice old width?
emilio: Yes, but not complaining. When have content-visibility: auto
and becomes visible do we change content-visibility style?
chrishtr: No. Contain-size is removed
cbiesinger: Spec only changes used value of contain
emilio: Then this doesn't solve issue, does it? Need to be only for
content-visibility: auto that are offscreen
cbiesinger: If it's on screen contain size won't apply so
contain-intrinsic-size doesn't apply
<TabAtkins> To be clear: it has no effect on the used value of
'contain'. It simply applies containments, *independent*
of the 'contain' property.
emilio: Makes sense. Wanted that clarified
Rossen: That satisfies your concern emilio?
emilio: Yeah. Seems reasonable
Rossen: Other opinions or concerns?
emilio: Another question- if main use case...why do we want to make
this special case? I understand it can cause weird behavior.
If authors not expected to use contain-intrinsic-size:auto
with things that don't have content-visibility:auto...do we
need to special case?
chrishtr: Argument for is to avoid possibility of element on screen
that dev is confused about. Only use case we know of is
placeholder sizing when element is offscreen.
chrishtr: Hard to say if would be a big problem in practice
emilio: I guess somebody could come with creative use cases. I don't
know. I would prefer to not special case if we don't have
evidence this is really confusing. Not a hill I want to die on
cbiesinger: I don't really care so much myself. TAG and someone else
had concerns and preferred the change. I'm happy not
changing if WG thinks we don't need to
emilio: TAG is generally smarter then me. If they think would be
confusing I'm okay
Rossen: cbiesinger what was the context of the review?
cbiesinger: Review auto value of contain-intrinsic-size. I can find a
link to the review
Rossen: We can link in the issue later
<cbiesinger> https://github.com/w3ctag/design-reviews/issues/624
Rossen: There is some thumbs up and lots of not really caring about
how this goes one way or the other. I want to call for
objections to resolving on this
Rossen: We can always come back, but not hearing strong pushback.
Proposed behavior does make sense and will improve the
behavior
Rossen: Objections to only apply contain-intrinsic-size: auto with
content-visibility: auto
RESOLVED: Only apply contain-intrinsic-size: auto with
content-visibility: auto
<chrishtr> Thanks all!
CSS Sizing
==========
Removing intrinsic aspect-ratio from an image
---------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6257
miriam: I was playing with images in a grid. Wanted to be able to
remove aspect-ratio and use object-position and fit to have
it fit without contributing to grid sizing. I thought
aspect-ratio:none would be a way to do that
TabAtkins: Makes sense
iank: Made a comment on GH just now. contain:size does it today.
aspect-ratio:none might not be best because won't clear out
natural size of image. Could fallback to 300x150 which might
still contribute. Want to be cognizant of that
Rossen: Is that behavior of sizing today which is based on actual
size and that's how you infer the aspect-ratio?
iank: Yes, it's subtle. image has aspect-ratio and natural size.
aspect-ratio:none would 0 out the aspect-ratio. Wouldn't 0 out
natural size and that may still contribute to grid area.
contain:size does both, null the aspect-ratio and set the
natural size to 0.
iank: If the use case if we want both we've got contain:size to do
that
Rossen: Isn't proposal only to remove aspect-ratio and not the size
an image contributes to the grid area if being sized for its
contribution to the sizing algo? Question to miriam
miriam: I think my goal was to remove any size contribution so might
be more what contain:size does. aspect-ratio is what I assume
would allow me to remove it
Rossen: I think aspect-ratio will only remove 2:1 or whatever it
happens to be. Height might be different than expect. 2x1
grid where first cell is image and that image contributes a
width. Auto height and not natural intrinsic height.
Rossen: Let's say image has 100w x 50h. aspect-ratio by sizing
algorithm computes as 2:1. We can say this is ignored but
then your height can be changed by sizing algorithm based on
second cell.
Rossen: Subtle difference. Not discounting that aspect-ratio:none
will still be effective and useful. Certainly what you're
looking for is contain:size to not have any contribution
miriam: Okay
<TabAtkins> Actually now I'm confused as to what 'aspect-ratio: 1/1'
does to the natural sizes of an image with 300x150 size :/
Rossen: I guess issue boils down to do we have enough use cases to
justify aspect-ratio:none by itself
Rossen: I see TYLin linked another issue discussing this which was
closed
emilio: Another tricky thing. Object:fit doesn't interact well with
containment
miriam: Seeing that in my demo. Trying to add contain:size
[everyone silently experiments]
Rossen: Back to the proposal. aspect-ratio:none the way you described
the anticipated behavior is more than aspect-ratio:none. I
think we agree on that for this use case
Rossen: First question is what is the best way to achieve intended
behavior. Second question is does aspect-ratio:none make
sense in other use cases. If we need more time we can revisit
next week
miriam: Works for me
Rossen: Any other comments? I think we've captured enough feedback
and lines of thought
Rossen: If there's findings to have aspect-ratio:none we can bring it
back
CSS Cascade
===========
Reconsider placement of unlayered styles, for better progressive
enhancement?
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6284
miriam: This came up in a few conversations about cascade layers and
migration path onto it. Potential for polyfill. As people
move styles to layers they become invisible to older browsers.
miriam: Might work better if styles hidden from older browsers were
more targeted styles rather than lower target defaults.
Matches a bit better to how I think about progressive
enhancement. Better defaults and then enhance details
miriam: jensimmons had a comment about letting authors decide and say
where unlayered styles go which is also interesting idea
Rossen: Feedback from group?
TabAtkins: As I said on issue, no preference. Fine with what group
decides
Rossen: Silence suggests group is fine with either. What is proposal
miriam?
miriam: If we want to explore jensimmons's option I could put time
into that and see if good way to make it explicit. Happy to
do that before resolving
fantasai: Even if we allow author to define we need a default
fantasai: I think it does make sense the way miriam suggested.
<bkardell> +1 I was thinking what fantasai just said
fantasai: When you have layers pulling in from an imported doc they
are usually overwritten by outer style. If doing layers in
separate files it's natural for ones in doc to have higher
priority
<miriam> +1 that makes sense
fantasai: I think her proposal makes sense overall as a good default
Rossen: Anyone else?
fantasai: I think it's more confusing when consider !important
because they will not override. A little mixed feelings
miriam: !important in the unlayered styles we're putting at bottom of
the normal stack. It's backwards
fantasai: Can't put !important below
miriam: By default normal styles are below layered styles. !important
becomes above
fantasai: So my explanation is opposite. So proposal is layer pulls
it higher. !important overrides. Overall makes sense. Not a
strong opinion but logic makes sense
Rossen: Hearing still support for the proposal. Will ensure good
defaults and default !import override the first layer. Don't
know if this needs further discussion or if we're okay
fantasai: Lean toward accepting
Rossen: There's more consensus then I hear other or different
opinions.
Rossen: Let's call for objections and we can always revisit
Rossen: Objections to accept the new reorder layering as detailed in
the issue
RESOLVED: Accept the new reorder layering as detailed in the issue
CSS Scoping
===========
Handling global name-defining constructs in shadow trees
--------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1995
<Rossen> https://github.com/w3c/csswg-drafts/issues/1995#issuecomment-840895144
Rossen: This is being brought to the group a second time. Link to
more relevant discussions ^
TabAtkins: Since introduction of shadow dom and we isolate chunks of
html it became unclear how name defining constructs work.
Can fontface defined in outer be in shadow dom? Defined in
shadow dom in outer? If same name in both which wins?
TabAtkins: All undefined
TabAtkins: Had a proposal for a long time.. Put it in scoping.
Tweaked to match reality
TabAtkins: Summary of proposal for informative introduction- Whenever
you have a name defining construct the names are defined
in a css context, a tree scope. Inherit into nested tree
scopes. A component with shadow dom can see names in outer
scope and override
TabAtkins: Same logic as inheritance. Within the shadow dom the inner
defined one wins and doesn't interfere with rest of page
TabAtkins: References to that. font-family:foo on an element. It sees
the font-face rule from the context it's in. If you write
it in the shadow dom you see the shadow dom defined.
Carries that around as it inherits. Writing
font-family:foo in the outer page. Inherits into shadow
dom it still refers to outer page, even if there's a
font-face:foo in the shadow dom
TabAtkins: Required so you don't have to worry about collisions as
you inherit.
TabAtkins: [missed example about how this can be very bad]
<astearns> missed example is you can only avoid collisions by adding
a bunch of random noise to names
TabAtkins: That's the proposal. All reflected in scoping spec. To
best of my knowledge the spec text is completed and well
defined. Somewhat matches some browsers impl. none do
everything correctly. For font-faces specifically there's
a mix across browsers. I don't know what plan is to update
to correct.
TabAtkins: I think any behavior except what's in the spec is bad for
authors and users. There might be compat we have to worry
about and work around because so many years of the wild
west. Would appreciate feedback to that
TabAtkins: Need to get these on a level to where things work
consistently. Right now authors cannot use name defining
constructs in shadow dom.
TabAtkins: I tried to go through the specs I owned to make sure it's
all well defined. Want to make sure everyone invokes
properly. I'll ping authors of other specs
TabAtkins: If a browser impl has objections or concerns I'd love to
hear them
fantasai: Thanks for the overall explanation model you proposed makes
a lot of sense. I think we need a WG resolution on this
because not discussed before.
Rossen: Other opinions or concerns about impl or from impl with
respect to compat risks?
emilio: When I implemented keyframe lookups in gecko and how they
work in shadow dom I recalled weird behavior from other
browsers. I want to make sure we have a place where we can
see current state in all browsers.
emilio: I think font-face doesn't work at all in shadow trees. Maybe
in safari but probably show up in document.fonts which is
wrong
emilio: Usually we have something to say current state of compat
TabAtkins: Reasonable. I can put together a wiki page and we can
collect data
emilio: That would be great. I think only keyframes work in gecko
emilio: Other thing is do we need a shadow root prototype of fonts
and how does that work. For now getting @fontface working is
more important
futhark: I wanted to mention we started working on this in blink.
De-prioritized. Main concern is font caching. Had a plan to
do it, but how do you do font caching in tree scopes; it's a
complication but not impossible. Not straightforward to make
it performant
Rossen: Other opinions?
Rossen: Sounds like TabAtkins you will start collecting the current
state of interop between browsers which will be great
Rossen: futhark is expressing some concern about impl complexity
which is good but doesn't seem like a blocker?
futhark: Not blocking. Explanation that this isn't trivial to impl
bkardell: Apologies if this is just noise. Conceptually document
scoped things, we have a bunch of open questions and
ongoing things. Not necessarily CSS. Like id ref for aria.
Conceptually they're very similar.
bkardell: Feels like they shouldn't be considered completely in
isolation. Not sure if that's helpful
emilio: id ref is slightly different case. That's more about allowing
to reference stuff inside shadow tree in a global way. This
is equivalent to shadow root get element by ID not doing
anything
bkardell: Not saying they're the same. Conceptually there's a lot of
issues where there's this boundary and need cooperation
mechanism. Would be great if we didn't have to have 10 of
them.
bkardell: Probably just noise but in my head feels like having a lot
of convos that are spiritually related.
emilio: That is true
Rossen: Thank you bkardell
Rossen: On the issue here, other opinions?
Rossen: If not let's see if we can resolve
TabAtkins: Prop: Tentative agreement on the spec text as in the
draft. Subject to further review of current interop
behavior
fantasai: Can you summarize? Binding the name per context through
inheritance
TabAtkins: I don't want to try and nail down to that level of summary
because that admits some bad behaviors. There's variants
that can break. Details matter a lot and would rather
point to spec
Rossen: Objections to TabAtkins proposed text?
RESOLVED: Tentative agreement on the spec text as in the draft.
Subject to further review of current interop behavior
fantasai: Spec is super out of date. When republish?
TabAtkins: Fine with now if we want to resolve.
fantasai: Do you have a changes summary?
TabAtkins: Need to collect it. I'm sure a lot
fantasai: Last publication was 2014
florian: Let's republish
Rossen: TabAtkins would you gather summary of changes and we'll
resolve over email. It's just WD update, right?
florian: Why would we not republish?
fantasai: In case there's unreviewed new things
florian: Alright
Rossen: We have a path forward. Please get the set of changes and
we'll resolve over email
CSS Contain
===========
Should there be a new syntax for establishing queryable containers?
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6174
miriam: In the first proposal for container queries and in chrome
prototype we've been using establishment of containment.
miriam: Been concern about that from different angles. Interest in
more explicit syntax. Looking at new values for contain which
felt cluttered or adding a new property which is what I'm
proposing
<bkardell> miriam: could you summarize what the 'from a lot of
angles' concerns about current were?
miriam: For now calling it container property. Don't know if names
are too similar but it's the name of the feature.
miriam: Idea is this would trigger containment on the backend. I
think we have precedent for that. This would allow us to
flesh out syntax where author only says what they hope to be
able to query on a container and then containment happens on
the backend. They just say I want to query inline dimension
and containment is provided
miriam: New path for can we have named containers. Can give
containers a custom ident. That's a separate issue
miriam: Can resolve we like this general direction. Can resolve to
move forward with container for now. Also are we interested
in pursuing named containers more
fantasai: Question about should it be a keyword in contain or
separate. Cluttering the syntax might get complicated as
you outlined. We can do things like query is a keyword and
add other keywords
fantasai: Question is should they cascade independent or together and
that decides if you want separate or same property. Not
sure which way, but that's the question you need to ask.
Cascade to combine or cascade to override.
fantasai: It's less about what is the prettier syntax and more about
cascading question
fantasai: If keyword is query perhaps property should be query since
contain and container together might be confusing.
<fremy> Good point. Do we want it to be easy to have `contain:paint`
and `contain:container` override each other?
florian: From cascading argument I suspect nice to have separate.
contain is used for performance and container queries is not.
florian: I was wondering, do you expect you will need to set very
different types of containment depending on what you need to
query about? If yes, argument to separate the two. If
regardless of what they want to query it's pretty much set
all containments it's less to separate
miriam: There is talk about types of query that wouldn't require as
much or any containment. None in sense of it's outside of
element doing the query. That is another reason to add as
separateue
bkardell: I think florian and miriam covered my point. I support that
containers is a separate concept. Currently we don't know
everything will require containment as defined in
containment.
bkardell: Other point is first from florian that containment is used
for performance which is a separate concern and don't want
to step on one or another
fremy: I was going to say the same thing
Rossen: Any other feedback?
Rossen: Proposed path...can miriam or fantasai summarize?
Rossen: What do we want WG to resolve on?
fantasai: Prop: Container queries are triggered by independent
property
bkardell: Still in contain?
florian: In spec, yes. Mechanics will probably effect used but not
computed value of contain property
bkardell: Just meant where does text go
florian: Need to bikeshed spec text.
<bkardell> interesting!
<bkardell> I think miriam also was doing some polling on bikeshedding
another name somewhere?
fantasai: Prop: Name of property is 'query' rather than 'container'
so we don't have 'contain' and 'container'. Either way we
go independent property
Rossen: Prop: Container queries are triggered by independent property
(name to be bikeshed)
RESOLVED: Container queries are triggered by independent property
(name to be bikeshed)
Rossen: Thank you for staying a little over
Rossen: Thanks to Dael on behalf of the whole WG for her work.
Received on Wednesday, 26 May 2021 22:33:59 UTC