- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 18 Jan 2023 19:55:45 -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 Contain
-----------
- On the call there were two new options raised to address issue
#7551 (Inconsistent handling of known and unknown features
jeopardizes backward compatibility):
- Each queried feature could evaluate to different container.
- Attempt to match the queries against each possible container.
If the container *can* match a given query, good; if not, it
evaluates to unknown.
- The group wanted to add examples to evaluate the two options so
discussion will return to GitHub.
View Transitions
----------------
- RESOLVED: Adopt suggested change to rename to `updateCallbackDone`
(Issue #8144: domUpdated isn't the right term)
CSS Text
--------
- Discussion will return to github for issue #616 (Hyphenate only
overflowing words?) to discuss if hyphenate-limit-zone could
cover the use case.
- The initial thought was it would be possible to use
justify-content instead of text-group but there was a need to
confirm the compatibility before going that route (Issue #5703:
Re-use justify-content instead of text-group align?).
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2023Jan/0006.html
Present:
Jake Archibald
Adam Argyle
Tab Atkins
David Baron
Oriol Brufau
Tantek Çelik
Emilio Cobos Álvarez
Yehonatan Daniv
Luke Dary
Elika Etemad
Robert Flack
Mason Freed
Megan Gardner
Paul Grenier
Chris Harrelson
Daniel Holbert
Brad Kemper
Jonathan Kew
Rune Lillesveen
Peter Linss
Jonathan Neal
Cassondra Roberts
Jen Simmons
Alan Stearns
Miriam Suzanne
Bramus Van Damme
Regrets:
Chris Lilley
Lea Verou
Chair: astearns
Scribe: bramus
CSS Contain
===========
Inconsistent handling of known and unknown features jeopardizes
backward compatibility
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7551
miriam: Discussed before but implementers have been pushing back
miriam: Issue that in CQ we are just looking to see if it resolve to
true or false but that something to resolve against
miriam: In that finding container step we look at question ask: if
looking for width we are looking for container with inline
size set
miriam: height block size, both
miriam: Problem if when asking for width or height, it can resolve
true even though half of it is recognized
miriam: Feels fine for now, as it could become recognized later
miriam: as we add queries it not only changes if it resolve to true
or false but also which container to look at
miriam: causing possible backwards compat issue
miriam: where something resolves differently whether its recognized
as a query feature or not
miriam: Some vendors have shipped, so changing now is a breaking
change
miriam: would love to resolve sooner than later
miriam: Resolved previously was to split on the or [missed]
miriam: Browsers said that would be difficult and not logic to split
on or
miriam: other directions with unknown query feature can match
container
astearns: There is no container that can anSwer all sides of the
query
miriam: Yes
miriam: Width or unknown would then not resolve
miriam: Width or height would also not match
oriol: Agree that there are problems with or. what if you have
negated and seems strange
oriol: Also want to consider third option to consider: could be
possible that each queried feature could evaluate to
different container
oriol: that is what we do with container units
astearns: Not sure I understand
oriol: For example at container rule "width > 100px and height
> 100px"
oriol: Parent that only has inline size will be able to match
height. Other parent would match the width query
oriol: Might be confusing though.
oriol: just wanted to list for completeness
oriol: Fine with 2nd option: if feature not recognize, just resolve
as unknown
miriam: In the or case it could resolve on one side of the query
still
oriol: We would resolve each feature against the nearest container
that supports it and if there is an unknown feature that we
do not support by any ancestor then it would resolve entirely
to unknown
bramus: A unknown is then false?
oriol: It does not apply the rule
oriol: it only becomes false at the top level
<TabAtkins> (I'm strong against resolving a single query against
multiple elements.)
astearns: Option 3 would allow to keep previous resolution
astearns: Would get past implementer objection?
oriol: What are the objections? probably third option more complex
than option 2. haven't considered if easy to implement or not
<dbaron> I do feel that it's strange that @container (width > 100px)
{ @container (height > 100px) { ... } } is different from
@container ((width > 100px) and (height > 100px)) { ...},
and I think oriol's option 3 fixes that... but it's also
strange on itself, and maybe we should be thinking about
use of container names as the "good practice" and these
being sorts of error cases.
florian: I understand option 3 and find it interesting in the
abstract. Fairly hard time deciding whether that is
confusing to authors or opens up a new and maybe convenient
option
florian: Opens up extra possibility
florian: would need examples to back up any reasoning
TabAtkins: In the discussion with Antti he was having a different
view of option 1?
TabAtkins: Rather than looking at query and using that as a
prefilter for containers to look at, we instead will look
at each possible container and if the query can be
resolved against that we will do that, otherwise unknown
TabAtkins: In the case "width or height" will work on inline-size
container because container can handle a part of that
TabAtkins: but if you do "width and height" this would fail because
of the 1 unknown
TabAtkins: that was option 1, right?
miriam: No, don't think so but that could work
TabAtkins: Don't really understand what Antti's understanding is so
I can't comment on what it might mean
TabAtkins: but what I said is what I voted for
miriam: That would work, as does oriol's proposal
miriam: I don't see problems with oriol's proposal and potentially
does match author intent
TabAtkins: Disagree with that. You almost certainly want both
conditions to match against same element, not a parent
higher up
* astearns agrees single container evaluation makes more sense
TabAtkins: (mentions dbaron‘s note)
TabAtkins: While you may want to target 1 element, you almost never
want to target 2
<bradk> +1 to what Tab said
TabAtkins: While you might sometimes want to write nested queries
and target the same element both times, you probably
never want to write a single query and have it target two
separate elements
dbaron: Trying to understand option 1. it seems very strange to me
that you would take a query "height or width" and then
evaluate against 1 part of that against 1 element and ignore
the 2nd part of the query
dbaron: Seems strange. would expect to evaluate against a single
element that answers to all parts
TabAtkins: That's the compat issue: unknown query
florian: no element
miriam: option 1 may have been poorly written
miriam: I think tab's and oriol's could work
miriam: 1 container or loosen that?
dbaron: Could tab clarify?
<TabAtkins> So then my proposal: attempt to match the queries
against each possible container. If the container *can*
match a given query, good; if not, it evaluates to
unknown. (Unknown queries are always unknown.) Then if
the top-level result is unknown, move to the next
possible container.
<TabAtkins> So (true or unknown) will match, (true and unknown) will
fail to match (and stop), (false or unknown) will
continue looking.
fantasai: RE 1 container or 2: it does seem weird that combining
[…]. if you wanted to match against single container we
have explicitly type argument right?
miriam: No, we don't
fantasai: Ok, all implicit
fantasai: If we had explicit type then author could define
dbaron: auto-finding parent based on query might be bad idea. It
should search using name or nearest
miriam: That creates other problems such as style queries where we
determined that you usually want direct parent so elements
are style container by default so that you can query nearest
but we don't want them getting in the way of size queries.
Going with nearest is going to be fragile.
TabAtkins: My proposal is going to match nearest that can possibly
match. in worst case its going to be […] right away.
astearns: I see couple of ways forward
astearns: Resolve on tab's reworking of option 1 or take back to
issue
<dbaron> I'm OK with Tab's proposal.
astearns: Anyone need more time to review?
oriol: Not sure if I understand proposal; what does it mean that
container matches query?
TabAtkins: It means that you satisfy the conditions to potentially
match. Mainly that you have right container type.
oriol: How do the binary operators work?
TabAtkins: If you aren't capable of matching, then evaluates to
unknown. e.g. inline size vs width and height, one will
be true/false and other unknown. if finale result at top
level is unknown: skip and move up tree. if true/false:
use that.
TabAtkins: true + unknown = skip
TabAtkins: true and false = false
florian: I would like to go back to issue and throw some examples in
issue to compare Tab's option and Oriol's
dbaron: Weird consequence of tabs proposal: nested containers: inner
one has inline and outer one haas both containmenbts. there
is going to be a point where you switch from using inner one
to outer one. that jump seems pretty weird
dbaron: I guess we need to work through examples
dbaron: ... to see if it does backwards jumping or not
astearns: OK. let's take back to issue
<fantasai> I believe with Tab's logic you might choose different
containers depending on whether you support 'unknown'
miriam: Other part of this: do we need use counters as this is
breaking?
astearns: Good idea. put it in issue.
View Transitions
================
domUpdated isn't the right term
-------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8144#issuecomment-1377651538
<JakeA> Summary
<JakeA> View transitions wraps a state change - we attempt generate
a transition from that state change
<JakeA> The developer provides a callback where they do that change,
usually by modifying the DOM in some way. It can be async.
<JakeA> Sometimes you just want to know when the state change is
complete
<JakeA> We provided a promise for that,`domUpdated`, which fulfills
when the promise returned by the callback fulfills
<JakeA> Anne said "we don't really expose DOM as a term to web
content", so the name is bad
<JakeA> So, we need a new name
<JakeA> Couple of options: `stateUpdated` - avoids using DOM, but a
bit vague, might be confusing due to frameworks use of
'state'.
<JakeA> Vlad suggested that, since the promise resolves along with
the callback, we name it `updateCallbackDone`.
<JakeA> I like that, since if the developer does stuff other than
DOM updating in the callback, the promise name still makes
sense.
<JakeA> Anne is happy with that.
JakeA: I can take up this one. Posted a bunch of messages above
<TabAtkins> +1 to suggested name change, it's clear and tied
directly to what's actually happening, and I think will
make sense for an author.
<masonf> `DOMContentLoaded` ?
JakeA: I guess we are saying: any objections?
astearns: Not knowing what the callback is named that seems vague.
What is it?
JakeA: It does not have an developer visible name. authors pass it
in as argument
JakeA: `updateCallback` and then `updateCallbackDone`
<florian> have not followed deeply, but seems reasonable
TabAtkins: I like it. Makes sense and matches spec language
bramus: +1
astearns: Proposed resolution: adopt suggested change to rename to
`updateCallbackDone `
RESOLVED: Adopt suggested change to rename to `updateCallbackDone`
CSS Text
========
Hyphenate only overflowing words?
---------------------------------
github: https://github.com/w3c/csswg-drafts/issues/616
<fantasai> https://github.com/w3c/csswg-drafts/issues/616#issuecomment-1368091416
fantasai: Link to comment
fantasai: Can you turn on hyphenation but only if it overflows?
fantasai: We could do this by adding keyword to overflow-wrap or
hyphens property
fantasai: hyphens controls hyphenation. values none/manual/auto
fantasai: overflow-wrap controls what you are going to do with
overflow
fantasai: Want to know if we want this addition and which one we
prefer
astearns: Fine with adding. Slight preference for value in hyphens
florian: Opposite slight preference for adding to overflow-wrap. But
on the other hand hyphens prop also related of course
florian: between line-break/word-break/overflow-wrap, lots of
properties. [missed] adding extra keyword to that property
keeps it that way.
jfkthame: Not sure if this is a good idea. Its a very specific
property. We already have other properties for authors,
e.g. hyphenate-limit-zone
astearns: You propose to setting that property to something close of
width to only allow hyphenation in overflow cases?
jfkthame: I think it would have that effect
jensimmons: Seems like a valid use case.
jensimmons: I can see people putting this in their default
stylesheets and turning it on for everything. Not sure
on how exactly to do it
fantasai: We should take back and check with hyphenate-limit-zone
florian: Same
astearns: Let's take back to issue with jfkthame's proposal
Propose 'text-spacing: space-first' (trim-start-except-first-line) as
a normal behavior
-----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2462
fantasai: there are new comments on the issue. maybe skip for today?
florian: I think the comments support it, no?
florian: Can wait
fantasai: There are comments that it might not work as well for
Chinese
florian: Yeah, but it says 'it is not ideal' but what is ideal?
florian: Can take a few days to reconsider
astearns: Let's go on to next issue
<florian> https://github.com/w3c/csswg-drafts/issues/2462#issuecomment-1367692407
florian: People who care about this should read from [link] down
astearns: Please all take a look
Re-use justify-content instead of text-group align?
---------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5703
<fantasai> -> https://www.w3.org/TR/css-text-4/#text-group-align-property
<fantasai> -> https://www.w3.org/TR/css-align-3/#align-justify-content
jensimmons: I can describe
jensimmons: text-wrap is a property and balance is value for it
jensimmons: It enables to do balanced text for text that spans
multiple lines
jensimmons: text-group in text level 4 is the new property to
accomplish that use case
jensimmons: Do we need this new property or should we use
justify-content?
ntim: Makes sense to reuse justify-content
ntim: [missed]
iank: justify-content will start new formatting context, right?
fantasai: Yes
iank: So that is one relative difference between the two
fantasai: We could define it to not do that
iank: Would align-content be harmonized?
fantasai: That one needs it
fantasai: In terms of inline-axis one thing that gets weird when we
don't create formatting context: what happens when we have
floats?
fantasai: for floats inside the box it's straightforward, but if
floats are intruding from the parent... it gets weird
florian: I think it's good to create the formatting context
florian: Then floats don't do strange things
astearns: Questions about formatting contexts and floats are
questions for either new property or the existing property
iank: Float question falls into two sub questions
iank: Would make easier if floats don't intrude from outside
iank: How floats withing that if interacts is another question.
florian: I think Alan is right that that concern applies to both
properties
iank: I want to point out formatting context difference.
fantasai: I think what florian is trying to say: either way since
neither property is implemented right now, we can decide
what to do. question applies to both properties
iank: Slight forward compat risk with reusing justify-content
fantasai: Less concerned about that
fantasai: Currently when you have a bunch of line boxes they fill in
container. We have to tell those boxes to be shortened
fantasai: and then there is this fun interaction with line boxes.
Say I have a div and center it. In order for it to be
centered we have to shorten line boxes. that is
straightforward if boxes are directly contained by div.
what if that div contains other divs?
fantasai: Do we some kind of propagation? do we inherit? do we not
affect any of the child divs? etc.
fantasai: With justify-content there is more of a consensus that you
lay out all children as a unit
<iank> justify-content creating a new formatting-context is a
relatively large compat risk IMO
fantasai: [missed]
fantasai: so it will not have any effect of centering the text.
iank: If that list is shortening all the line boxes that [missed]
astearns: Seems like issue that is going to come up for either
version of the property
astearns: Can we resolve on using justify-content or not?
iank: Compat risk is making justify-content establish a new
formatting context
iank: Things suddenly become fc when they were not previously
florian: Assuming people already use this property
iank: Exactly
<fantasai> specifically to blocks that are not already BFCs
florian: Can we have a use counter to check?
iank: I think apple folks are more interested in shipping
astearns: Should prioritize whether we should create new fc or not
and use that info to decide if we reuse property or go
with proposed thing
florian: yes, though we might still be able to go with
justify-content even if we want a fc depending on the
compat situation
astearns: We are at time
astearns: Let's take back to github
astearns: Most likely need more discussion on compat issue
Received on Thursday, 19 January 2023 00:56:27 UTC