- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 8 Jun 2022 19:24:33 -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
----------
- The polls run on twitter for the name change in issue #7317 (Rename
Element.isVisible to Element.isHidden?) produced reasons against
both names. checkVisibility was also suggested and had mixed
support. Bikeshedding will continue on github to collect ideas.
CSS Contain
-----------
- The concerns about a previous resolution explained in issue #7066
(Revisit decision to make 'style' the default 'container-type')
were around both author clarity and performance issues in some
cases.
- Most of the group's focus was on ensuring that the property
works well for the authors.
- There was a new proposal to use longhands that needs to be
discussed more as a potential solution before the group tries
to reach a resolution.
CSS Text
--------
- RESOLVED: Keep 'distribute' keyword alias (Issue #7322: Consider
removing distribute value for text-justify from the spec)
- RESOLVED: text-align: match-parent computes to 'start' on the root
element (Issue #6542: text-align: match-parent on the
root element with direction: rtl doesn't match browsers)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2022Jun/0007.html
Present:
Rachel Andrew
Rossen Atanassov
David Baron
Tantek Çelik
Emilio Cobos Álvarez
Elika Etemad
Simon Fraser
Megan Gardner
Chris Harrelson
Daniel Holbert
Brian Kardell
Jonathan Kew
Vladimir Levin
Rune Lillesveen
Alison Maher
Jen Simmons
Miriam Suzanne
Regrets:
Tab Atkins Bittner
Robert Flack
Chris Lilley
Lea Verou
Scribe: fantasai
Scribe's scribe: emilio
CSSOM View
==========
Rename Element.isVisible to Element.isHidden?
---------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7317
chrishtr: Bringing up naming of isVisible/isHidden
chrishtr: Last week we resolved to change to isHidden
chrishtr: but also spun up some Twitter polls
chrishtr: Tab's poll indicated isVisible got more votes
chrishtr: Jen's poll seemed inconclusive?
<jarhar> https://twitter.com/jensimmons/status/1532137408418004994
<vmpstr> https://twitter.com/tabatkins/status/1532138513704943617
chrishtr: Also original reasons for isVisible
chrishtr: basically, doesn't guarantee it's visible
chrishtr: There's some conflicts with isVisible idea from
IntersectionObserver
chrishtr: And conflicts with element.hidden
chrishtr: So that's the rundown
chrishtr: There's data both ways, so maybe leave the way it is?
fantasai: There's also a comment suggesting checkVisibility
fantasai: Maybe that would be possible?
fantasai: I think the mixups between isVisible/isHidden in the
twitter poll make me think we need to do a bit better
fantasai: and in the issue
emilio: Was going to say something along the same lines
emilio: make it less confusing
emilio: I'm not sure I'm satisfied with either isVisible or isHidden
emilio: checkVisibility sounds reasonable
<chrishtr> checkVisibility is fine with me too
<smfr> not a fan of “check”
fantasai: checkVisibility with args and defaulting to a set of argus
would maybe be less confusing
fantasai: you're checking for these specific things, not for total
visibility
<emilio> computeVisibility?
Rossen: Maybe investigate longer? Is there any pressure for this?
chrishtr: We'd like to implement in Chromium, so hoping we can come
to an agreement
Rossen: We have a name for now
Rossen: I would say let's continue working in the thread,
bikeshedding on the call not so helpful unless something
comes up that's obvious
Rossen: and don't have anything better at the moment
Rossen: Sounds like you're going to start writing code, changing name
should be fairly straightforward
chrishtr: Have code written, want to ship it
chrishtr: Don't want to ship something the group disagrees with
fantasai: It's not so much about group disagreeing, it's about
getting something we're confident that authors will find
usable
fantasai: and the current information we have indicates that we maybe
don't have that yet
fantasai: so I think we should work on it a bit more, so that when we
ship, it's something authors find natural and easy to use
Rossen: Should we continue to discuss here or take it back to the
issue?
Rossen: Suggest engaging on the issue
Rossen: Let's collect ideas and organize them and take the winner
CSS Contain
===========
Revisit decision to make 'style' the default 'container-type'
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7066
miriam: We've discussed this a few times, but the resolution we took
last time need some clarification either way
miriam: We resolved last time we talk to make every element a style
container by default
miriam: On the one hand, in this thread, it seems we feel confident
that's a good choice in terms of author expectations in terms
of style queries
miriam: really helps for inherited properties, if you can assume that
you always get the value from the parent
miriam: If we stick with that direction, need to clarify what it
means for being default
miriam: Does that mean style is the default, but if set other type,
would drop style type?
miriam: More likely, would mean every container is a style container,
always true of all elements don't have a value for it
miriam: So if we want to stick with that resolution, need to clarify
that this is how it works
miriam: On the other hand, all three browser engines have commented
that this would be a performance hit
miriam: I'm not sure how we want to weigh those two things
miriam: Allowing people to set them individually let's people control
performance
miriam: but if set style globally to get the behavior we want, then
would have to juggle carefully your values because then it
would get overridden when you try to set up other types of
containers
miriam: so we have a potential performance issue vs author usability
Rossen: Want to know if implementers would clarify the exact
performance implications
futhark: I'm not sure we can say it's a performance issue in general,
but in certain cases can get into one
futhark: If you look at example I gave, where you have a universal
first-child rule that queries a custom property... if you
don't use container names
futhark: you could query a custom property that only makes sense for
certain parents in the document
futhark: but in order to figure out that this custom property can
cause invalidation of children, would have a lot of overhead
emilio: Would make style queries evaluate against all elements by
default, which is not amazing
fantasai: I think the authoring usability problems are actually
pretty severe
fantasai: It's not too bad to require somebody who wants to use style
queries to set this extra rule on all elements
fantasai: but the fact that it becomes nearly impossible for the
author to then juggle to different values
fantasai: so that when they want to set a size container they also
need to set style size instead of just style
fantasai: that's very tricky and easy to get wrong
fantasai: If you have multiple sets of libraries it's very easy to
get conflicts
fantasai: Only way to resolve that problem would be to split the
container property into multiple boolean properties
fantasai: in order to allow authors to turn them on and off
independently
fantasai: If we want to avoid making this the default we need to turn
them into longhands
fantasai: and I suspect most libraries would set style containment as
a convenience to the author
fantasai: and we're going to have to make these optimizations anyways
fantasai: so if we end up having to make these optimizations I'd say
we'd rather make it the default
emilio: The problem with making style containment the default, that
wouldn't solve the problem with conflicts right?
fantasai: If we make it the default, it would always be a style
container regardless of other containment set on it
fantasai: same way list-item is always incremented, unless you
explicitly say not to
miriam: That's the clarification we needed if we went in that
direction
emilio: I don't quite get why style queries are useful
emilio: It seems that regardless of what path we take, the initial
value for container type should be 'none' and when we get to
style queries, just make every element magically a style
query container
emilio: Does that sound like a reasonable description of what we're
proposing?
fantasai: I think so yes
jensimmons: I'm still confused about the author experience here
jensimmons: I think we'll teach everyone to use size queries for the
next 2 years, and in that teaching they will be taught
that you have to define your container
jensimmons: your query will be against that container
jensimmons: When style queries come along, I think authors will
expect it to work the same way
jensimmons: I think they will define a container on the root, or on
the main div, or a side element, or whatever
jensimmons: rather than * { everything }
jensimmons: I agree that there's a problem with size queries and
style queries both being set on the same element and
accidentally overriding each other, and we can address
that problem
jensimmons: That's a flaw, maybe we can address it
jensimmons: They're going to be designing components and dropping
randomly in the page
jensimmons: There's 2 components, sans-serif and then serif
typography stuff, and want to query which one is set and
query on that
jensimmons: but this particular component is going in different
places, so font-family is inherited through the tree
jensimmons: so idk maybe answering question as I talk
jensimmons: but maybe Miriam you can explain why we want to get away
from the idea of defining container
miriam: For non-inherited properties it would work fine to set the
container and query it, but for inherited properties you
always need to check the parent
miriam: otherwise not getting an accurate idea
miriam: You're generally always going to want to know the closest
answer
miriam: and it becomes very fragile if you have to set that explicitly
miriam: Every time I want to check whether font is italic, I have to
make sure the parent has the right style container type
before I can find out whether I'm inheriting italics
miriam: and I think that's one of the key use cases
miriam: if the parent's italic, make me normal, if the parent is
normal make me italic
miriam: This use case is only possible if we can assume querying
parent
miriam: for non-inherited properties, we can always set a name
miriam: and we've gone out of our way to encourage naming containers,
both with size queries and style queries
miriam: so that will transfer, there will be differences in these two
in how they're used, but if querying something specific
you'll give a name
fantasai: The case where you want to have 2 different styles, you
don't actually want to be querying the font-family property
fantasai: You likely want to query a custom property
fantasai: and you just want to make a custom property that represents
your style
fantasai: You'll want to track those through custom properties and
the style query would let you query what kind of thing
you're inside
fantasai: and querying always the parent makes sense even if you want
to switch (e.g., if you want to switch your color-scheme)
fantasai: So I think you want to track that info through a custom
property rather than attaching everything to a container
dbaron: Wanted to comment on a use case Miriam raised wrt font-style
italic toggling
dbaron: I think using style queries for that feels like a very
heavyweight mechanism for solving that problem
dbaron: We had the cycle()/toggle() proposal for that
dbaron: I think a mechanism like that would be more efficient way to
address that sort of use case, whereas doing that with style
queries, you're using something that's got much bigger perf
implications
dbaron: because it's a mechanism that can query any property and
apply the result to any other property
<bkardell> I was going to queue to say similar to dbaron - for that
specific case at least
emilio: Wanted to make a comment similar to dbaron's, other proposals
that may address many of these use cases
<emilio> like `if(<foo>, <bar>, <baz>)
jensimmons: From what fantasai described, using custom properties and
querying them
jensimmons: put the word style aside, it becomes a way to define
variables and query which one is being used right now
jensimmons: which CSS doesn't have right now
jensimmons: When people get their heads around that, they might not
care about styles, they might just need variable queries
jensimmons: and that's what they'll start using it for
miriam: Large overlap with leaverou's higher-level custom properties
proposal, in terms of use cases
miriam: Setting properties that you can query and use them in
selectors, and make larger changes based on the value of a
property
fantasai: There was some issue Oriol raised against toggle(), we
decided didn't matter because moving to style queries, but
if not need to dig up that issue and see if solvable
<SebastianZartner> If it's mainly about querying custom properties,
why not restrict to them for now to do style
queries?
fantasai: Regardless of this, do we need to split contain property
into longhands per containment type?
fantasai: to avoid conflicts
jensimmons: If we land somewhere that every element is style
container always, then no problem, but otherwise we need
to solve the problem
jensimmons: If someone wants to set up a size query ends up
accidentally turning off a style query, that's accidental
result
jensimmons: consider working across teams, across time
fantasai: Lots of room for error if we don't split
jensimmons: Especially since the whole point is to allow ppl to
create [missed]
jensimmons: Don't know what kind of collisions you'll create
Rossen: Doesn't sound like we're approaching consensus, if anything
sounds like we're expanding the problem space of the issue
and underlying features
Rossen: If this was in times when we have more regular F2Fs, I'd say
let's do a breakout and come back with proposed changes and
move on from there
Rossen: so perhaps that's what we need to do, do a breakout similar
to scroll animations and hash it out
Rossen: Sounds like topic is expanding rather than converging
miriam: I think it's possible that emilio's suggestion would allow
browsers to release without a problem
miriam: Initial value is 'none', and if make style containers the
default, not doing with an initial value of style would do it
more globally
miriam: so that might be a resolution that gets us able to release
size queries without solving this
fantasai: I have a different idea
fantasai: that'd solve style queries, but not other types of
containment in the future
fantasai: cause we want to also allow for other containment types in
the future
fantasai: we'd need to release a longhand
fantasai: My concern is that grouping these into this one property
causes issues in the future
fantasai: I think that's something we are going to need to explore
before we ship
fantasai: because if we ever add another type of containment that
isn't size containment...
jensimmons: Maybe we don't even need to make them a shorthand
jensimmons: whatever gets decided I'd argue for folks to decide soon
jensimmons: because Safari 16 is going to ship container queries
Rossen: I don't think we'd like to suggest to punt on this for weeks
or months
Rossen: still not hearing good consensus
Rossen: Do we want to try to resolve on anything today?
Rossen: or do a breakout session next week or so?
fantasai: I'd say we discuss and explore the longhands approach and
come back next week
Rossen: I think there are a couple of other issues in the same space
that deserve focus time
Rossen: Happy to help organize something
Rossen: if that moves the ball forward quicker
emilio: It seems there's agreement on `style` not being a value on
`container-type`
emilio: regardless of whether we split `container-type` into
longhands or not
fantasai: I wouldn't be happy to resolve without an alternative
Rossen: Let's take it back to the issue
Rossen: and bring it back next week. Happy to prioritize if there's
progress / something we can resolve on
CSS Text
========
Consider removing distribute value for text-justify from the spec
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7322
fantasai: I don't know if we can resolve on this because discussion
has expanded a little bit
fantasai: Issue was a suggestion to remove this value, because Chrome
/ Safari don't support it, but Firefox does and IE did, and
it was in CR in 2003
fantasai: so my preference is to not remove it unless it's harmful /
complicated
fantasai: We got some data showing that it is used on some pages
fantasai: not a lot of them
fantasai: There's an assertion that there's no compat bugs reported,
but pages using this in CJK, which are less likely to
complain about it
fantasai: This doesn't cause a fundamental degradation of the page,
justification isn't just what's exactly desired
fantasai: The main difference is whether you distribute in between
letters in English / Greek, but not in CJK (??)
fantasai: It's something that was standard and implemented by the
most widely used engine at the time
fantasai: so I'd lean against removing it
fantasai: because people should expect it to continue to work
<astearns> +1 to not removing for now
emilio: The only thing I'd say is that we changed how this alias
worked in the past
emilio: now it's a parse-time alias of inter-character
emilio: I don't think it matters substantially
emilio: given it's a compat alias
emilio: I'd rather not remove it, it's cheap to support
emilio: as long as you support inter-character
emilio: so don't see a strong reason to remove, since aliases are
extremely cheap to support
fantasai: The only complaint here was that parse-time aliases are
inconvenient in some engines
fantasai: We could allow either type of alias (parse-time or
compute-time), I don't think it matters
Rossen: Any objections to keeping 'distribute' keyword?
RESOLVED: Keep 'distribute' keyword alias
text-align: match-parent on the root element with direction: rtl
doesn't match browsers
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6542
fantasai: Seems we currently have all browsers matching
fantasai: I don't think this is the ideal behavior but it's not
terrible
fantasai: and it's a situation that is almost never going to happen
in a real page
fantasai: unless somebody did something super weird by accident
fantasai: Given we currently seem all engines compute to start
fantasai: which is Firefox's behavior
fantasai: I'm happy to resolve to that
fantasai: I think the right answer is to compute to right
fantasai: because it otherwise resolves to an absolute side
florian: So proposal is computing to start
florian: behavior is the same as the spec asked for on
single-direction pages
emilio: I would rather to this, mostly because of how it interacts
with writing-mode propagation
emilio: just compute to start value
Rossen: Any objections?
RESOLVED: text-align: match-parent computes to 'start' on the root
element
Having a summer face-to-face
============================
<fantasai> Survey:
https://lists.w3.org/Archives/Member/w3c-css-wg/2022AprJun/0080.html
<dbaron> It might also be good to get more responses to the survey
(on the mailing list).
Rossen: If you don't feel comfortable replying publicly, send an
email to me and Alan
Rossen: We'll count these people also
Received on Wednesday, 8 June 2022 23:25:12 UTC