- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 17 Feb 2021 19:02:11 -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.
=========================================
Selectors
---------
- The group didn't agree on if the heuristic description for
:focus-visible should be updated to detail interactions with the
Shadow DOM (Issue #4893: :focus-visible and Shadow DOM). If it
is updated, it wasn't clear if the guidance should be to bubble
:focus-visible to the host or not.
- Part of the conversation around issue #5885 (:focus-visible
matches on initial programmatic focus) was about where the
browser should be drawing a focus ring which is a discussion
that should be held with the WHATWG. The discussion in the issue
will be focused back to the pseudo class itself and if it's
specified correctly.
CSS Page
--------
- RESOLVED: The stuff inside @page or @margin rule are descriptors
but act like properties for behavior and cascade (Issue
#5970: Should page descriptors support `!important`?)
- Issue #5970 still needs a resolution on how variables will be
handled. The proposal on the call was for them to be accepted
and to inherit from the root. There were concerns about
inheriting from the root causing issues when interacting with
media queries so discussion will continue on the github.
CSS Contain
-----------
- The group was unsure if they should allow container queries to
propagate (Issue #5913: :root/body viewport propagation and
containment). There will be an effort to check current usage to
verify that there's no risk of breakage if it's disallowed.
Discussion will continue on github to see if there's a way to
allow propagation without running into a circularity problem.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2021Feb/0010.html
Present:
Adam Argyle
Rossen Atanassov
Tab Atkins-Bittner
Christian Biesinger
Oriol Brufau
Emilio Cobos
Elika Etemad
Simon Fraser
Megan Gardner
Daniel Holbert
Dael Jackson
Sankit Joshi
Jonathon Kew
Vladimir Levin
Daniel Libby
Rune Lillesveen
Chris Lilley
Peter Linss
Alison Maher
Myles Maxfield
Tess O'Connor
Manuel Rego Casasnovas
François Remy
Cassondra Roberts
Devin Rousso
Florian Rivoal
Jen Simmons
Alan Stearns
Miriam Suzanne
Lea Verou
Regrets:
Rachel Andrew
Tantek Çelik
Brian Kardell
Morgan Reschenberg
Greg Whitworth
Scribe: dael
Selectors
=========
:focus-visible and Shadow DOM
------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5893
rego: Both our selectors topics are about :focus-visible. This is
about what happens when you have shadow DOM
rego: focus pseudo element matches when you have focus in a shadow
tree so matches in shadow-host. Wondering if :focus-visible
should match.
rego: Special thing is WK has wk-direct-focus pseudo class
rego: People use it in UA stylesheet to avoid outline when you focus
in the shadow tree.
rego: In chromium in this case if you focus the input in the shadow
tree you get the focus indicator. I believe :focus-visible is
about avoiding people removing the outline with focus
outline:none
rego: Tricky part is in theory you shouldn't be able to know if an
element is shadow host. Thanks to that you could check if it
is a shadow host. There are other cases where you can do that.
shadow host only matches in some cases. Need to think about it
rego: With WK solution you can inspect if it's in shadow host
because you can focus it and check if there's an outline shown.
rego: It's a trick.
florian: Question on indirect level. Asking if we should show
:focus-visible in this case, but :focus-visible isn't
defined when it shows. There's heuristics, but it says it
should match when focus indicator is shown. Are you trying
to spec more detail on when browser shows?
rego: It would be adding one more item on the heuristic list to
allow this case. One could be browsers don't show focus
indicator in shadow host when there's an element in shadow
tree with focus. It would be add a heuristic since current
impl follow the heuristic. It's non-normative, but adding one
more heuristic
Rossen: Back to shadow root topic. I was re-reading thread in issue.
Appears topic is discussed but not solved.
Rossen: If I hear you, you're saying there are other precedents
which would allow shadow root detection. If this is a fact
we shouldn't necessarily add things to make it easier and
more obvious to detect
Rossen: Where is the current thinking on that?
rego: When you focus an element you're not sure if it will match
:focus-visible. When you focus inside shadow tree if shadow
host doesn't match maybe you have it for a reason because user
did a different way to focus.
rego: There's another open issue on how that makes shadow host
observable
Rossen: Right. I think Alice's last comment summarizes it well. "By
design :focus-visible is not guaranteed to match when an
element is focused, so at best it would be a way to
heuristically detect that something maybe-probably has a
shadow root. Compared with the user harm from authors
disabling focus styling, which is the problem :focus-visible
is intended to solve, detecting that something might have a
shadow root seems like it's at the opposite extreme of the
priority of constituencies."
Rossen: This doesn't seem to have the answer. I see your comment
pointed to another issue. Seems up in the air
rego: I agree with Alice. I think Alice would be fine not matching
:focus-visible in shadow root. emilio might have something to
say
emilio: I agree with Alice but for a different reason. Don't agree
we're only probabilistically exposing. Given spec heuristics
you can force :focus-visible to show. If we want
:focus-visible to be used it needs to not match shadow host
or not match from UA rules. Don't know if we have precedence
for UA rules
emilio: WK is only one that implements and they have special pseudo
class for UA stylesheet. I think either column-focus or
:focus-visible should do the right thing or they shouldn't
match. Right is if you use from UA stylesheet it shouldn't
show on shadow host ancestors
<rego> Chromium also implements the :focus propagation on
delegateFocus:true, that's why you get 2 outlines in Chromium
Rossen: Catching up on IRC chat.
Rossen: emilio, the overall take away is you agree with problem of
exposing awareness of shadow host, though for a slightly
different reason?
emilio: Yeah. think it's solvable if we have special case to not
propagate. I don't know if we want to go that route
emilio: And we would still expose via getComputedStyle so I don't
feel too strong. Either do what rego and Alice propose or
making :focus-visible do right thing from UA stylesheet are
workable
Rossen: What is the ask here, rego?
Rossen: Asking for resolution with the proposed behavior you
summarized in opening comment?
rego: One option could be resolve we don't want :focus-visible to
match shadow host. Maybe we should explore alternative from
emilio in the issue
Rossen: For me that would be preferred path. I don't feel like
conversation with Alice is resolved. emilio you can expand
your proposal further
emilio: Can do
<Rossen> thanks emilio
fantasai: My understanding is definition of this pseudo class is it
will match when UA is doing something to style a focusable
element as focused and will not match otherwise. If UI
default focus was a dotted outline around everything if
the author replicated that they should get same behavior
as UA would give. All heuristics after example are
suggestions of things UA should think about when they
match :focus-visible in general
fantasai: Meaning any UA in any case...we can improve the heuristics
but they're not normative. Normative is if you style as
:focus you match as :focus-visible. We can do whatever we
want with heuristics but they're informative. We can't put
heuristics that won't match actual definition of most
browsers.
fantasai: I'm not sure what we're trying to do here. What's required
is clear and this is just helpful hints when designing a
UA.
emilio: When you focus an element inside a shadow tree a lot of
state in the page reflects that. focus pseudo class and
others. Issue is, for regular elements like DOM APIs, app
dev returns shadow host. That doesn't change if real active
element is there. Doesn't change what it is. Issue here is
should we do same with css pseudo classes
emilio: I agree it could go either way. But it doesn't change if
inner element should match :focus-visible. If we spec it
should bubble up and target dom apis all browsers should do
florian: Then are we saying it should style around the shadow host?
emilio: In order for bubble up to work you need to match is a
special in your sheets. UA sheets match in all shadow scopes.
fantasai: Point of :focus-visible was for UA to not have magic
pseudo class that does something different
emilio: Right, this should apply to all re-targeting like
column-focus. Not magic like how it's not magic if you
target inside the tree
florian: Does UA draw focus line around shadow root
emilio: Should not
florian: Then :focus-visible should not. It's what :focus-visible is
for
<rego> about the heuristics, despite they're not normative, all
implementations are following them, so they help to ensure
interop on :focus-visible implementations
emilio: Right, but if you think in terms of built in control like
date. You have inner element you focus. Date is little
editable fields for day, month, year. Inner focused is
editable inside shadow root. In that case you want
:focus-visible to bubble so you get outline around text
emilio: Maybe add a way for shadow host to opt in. By default we
shouldn't match
Rossen: Don't feel we're ready to resolve. I suggest back to the
issue and bring it back when we're ready
rego: Agree
rego: We should keep discussion on issue
:focus-visible matches on initial programmatic focus
----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5885
rego: This is about if :focus-visible should match after
programmatic focus. Current heuristics, though not normative,
talk about if active element matches then next element will
match. Spec didn't mention anything about if there's no active
element
rego: Proposal is to change a bit so instead of saying it's the
active element, you have to check last user interaction. ANd
if none you match :focus-visible. But if someone clicked a
button and there was blur you wouldn't match because first was
not a mouse
emilio: What interactions count and which don't? That's an issue. I
think current heuristic is fine. It's a problem on mac
because mac doesn't focus a bunch when you click on it. A
lot of programs when you click and then move focus the
heuristics say button wasn't focused so new thing shouldn't
match
emilio: On mac since element isn't focusable by mouse you hit this
issue. Good thing to come up with something that works.
Generally agree with proposal, but which interactions count
and which don't? I want the definition to be clear
emilio: Does an interaction a second ago prevent programmatic focus
from matching?
florian: Confused. Are we trying to define when a UA shows a focus
ring? If not, why defining when :focus-visible shows?
rego: Everyone is following heuristics. If we have clear heuristics
then it's better
florian: They're supposed to be heuristics about when they show
focus ring and :focus-visible matches.
emilio: True
florian: So we're talking about the combo, not getting out of sync
emilio: Right
emilio: I'm okay with the proposal. I just want whatever this
interaction means to be clarified
florian: Wondering if right spec and place. I think CSS spec has
what it needs. We match browser focus ring and the pseudo
class. When the browser shows focus feels more like HTML.
Should we move them and call them normative?
emilio: It's an option. Fine with that
florian: If discussing state of doc and state of UI it's not a very
css-y topic
fantasai: This text is just an example. It's not normative
florian: If you want normative it belongs in HTML, right?
Rossen: What are we doing with this?
rego: Keep going on the issue and see if we should move this
florian: Just before we wrap up, my impression is even though called
heuristics we're trying to harmonize browsers about when
they show/don't show focus ring
Rossen: And make it more detectable
florian: We have detectable. We have the pseudo class that matches
browser behavior. If we want to define browser we should
have that in html
Rossen: I think right next step are add any pseudo class discussions
in the topic and rego will continue working with html group
to see if there's additional behavior to define there
CSS Page
========
Should page descriptors support `!important`?
---------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5970
emilio: I noticed when reviewing patches for page descriptors the
whole thing is a mess in all browsers.
emilio: @page maybe is only one with keyframes. It's messy. Spec is
confused about what's a descriptor. Can we define what
cascade features work on @page and which do not?
fantasai: I don't think keyframes cascade in same way. They have
properties but I don't think they participate
fantasai: For @page rules they are supposed to cascade. Spec was
written before variables so doesn't take that into
account. Seems useful for those to work.
fantasai: They're all descriptors. They should behavior like regular
properties including supporting !important. They cascade
as properties with their own selectors and obey origin so
no reason not to support
fantasai: Useful to support variables, should inherit from root and
that's new
TabAtkins: Agree
fantasai: Main thing I'm concerned about is there are descriptors
that apply which are not regular properties. Not like you
can just say just like an element, there's special stuff.
But they should behave like properties, just not allowed
in normal elements
emilio: Way all browsers implement as far as I can tell is making
page descriptors css properties. Means blink and webkit
accept size in regular style blocks which is bad. So we
should probably define these descriptors to be like css
properties but that they can't be parsed in style blocks. I
agree
Rossen: Sounds like we are in agreement. What's the proposed
resolution?
fantasai: 2 resolutions. 1) The stuff inside @page or @margin rule
are descriptors but behave like properties for behavior
and cascade
fantasai: 2) Variables are also accepted and they inherit from root
element
fantasai: root to @page
emilio: Precedent for that? backdrop doesn't
TabAtkins: backdrop is just a pseudo element
emilio: Similarities. Custom properties work in ::backdrop. Page
being over root...I guess same for tables
fantasai: Useful because then you get the fonts and such
TabAtkins: Colors especially
TabAtkins: backdrops quickly, they're on particular elements
emilio: Don't inherit from them
TabAtkins: Okay. That's an exception
emilio: Inherit from root has another issue
emilio: Relative to font size and relativeness. Fine with this, but
not how browsers behave. Browsers and some print UAs take
@page into account for MQ. This introduces a cycle
emilio: Totally fine because I think we shouldn't take them into
account. Maybe we can resolve they support properties for
now and maybe move inherit from root to another issue
faceless2: I wanted to say pages inherit from root works well for
counter. No other way to do it. To my mind it's right way
to do it
emilio: Fine with that, but people want @page size to influence MQ
which sounds gnarly
TabAtkins: True
TabAtkins: Leave variable open and resolve on rest?
Rossen: Yeah
Rossen: The stuff inside @page or @margin rule are descriptors but
act like properties for behavior and cascade
RESOLVED: The stuff inside @page or @margin rule are descriptors but
act like properties for behavior and cascade
Rossen: And we'll discuss more intention for variables and bring it
back
CSS Contain
===========
:root/body viewport propagation and containment
-----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5913
rune: Encountered this looking at container queries
rune: We propagate the writing mode from body to root including
affecting used value for root element. Causes circularity if
we don't say if we have containment on html don't prop to
viewport. Wondering if it makes sense
rune: Mostly thought about writing mode, but other properties too
florian: Interesting problem. What's the solution other than making
contain not apply?
rune: Make contain not propagate to viewport
Rossen: Wasn't that way more impactful on compat?
florian: Not necessarily since existing content doesn't contain on
body or root
<fantasai> why would someone want to put containment on body anyway
hober: There is because sites exist over time and worked on by
different dev. Current maintainer might want the new shiny
thing and not realize site depends on viewport propagation.
They add this and cause a freaky action at a distance bug
where other things stop working. How do you figure that out?
florian: I don't want to break propagate. Doesn't seem as action at
a distance. Containment at root isn't meant as neutral. So
not worried about action at a distance. But some of the
propagation is probably there because they're useful. I
don't think containment on root or body is useful so not
apply seems fine
rune: Fine with that. Want to get rid of circularity.
<fantasai> for the record, propagation from root to viewport is
necessary and useful; and propagation from body is just a
hack we had to introduce for compat
<fantasai> I also agree with Florian that making containment just
not apply is fine, I can't think any reason why it would
be useful
jensimmons: Agree with hober. I've already seen people teaching that
best way to use container queries is to apply on root.
May theoretically make no sense to use, but people will
be confused by where to put containment. It's attractive
to put on root
florian: Confused as to why, but I believe they do
<leaverou> That's so bizarre. Isn't that basically like a MQ?
jensimmons: If it's impossible to do something with a sensible
default it becomes an exercise to teach webdev to not do
something stupid. I would lean toward can we make it not
terrible by default? The webdev are already saying just
put it on the root and it'll work
miriam: I haven't seen people talking about just apply to root, but
reason you might want to is for face that container queries
resolve against actual font size and MQ resolve against
external font size. That's one place where might be useful
on the root even though MQ do most of it.
iank: My personal opinion is not too worried about stopping
propagation. From my memory we added propagating as a
convenience or a compat issue that people put writing mode on
body and we didn't want to switching to orthogonal and back.
This cleans it up
iank: From what I've seen webdev will but it on the root and the
body. Seems like an edge case.
iank: I think what rune and florian propose sounds well reasoned
<miriam> +1 resolve container against root
florian: Two things. Containment and container query. I think if we
set container query so if there's no container it resolves
against root then no need to contain root. If you container
query without container you resolve against top level and
no need to apply containment to body. Would that be weird?
Rossen: I was on queue to highlight there's a ton of compat in the
history. Especially the tail end of body or html which are
used for setting up viewport. I don't think we should
minimize potential compat impact. As hober pointed out
someone could adjust styles and not realize they're
affecting lots of stuff
Rossen: At the same time I'm hearing there are potentially use cases
to have containment on body or html. Whatever the use cases
are we have to understand and figure out if we need to
support them and figure out what's the appropriate behavior
for backwards propagation. Maybe a middle ground to support
backwards compat while allowing containment
florian: jensimmons I want to check if I understand. What I thought
you said is there are people who want to do container
queries in general and some of the time it'll be in a grid
and sometimes it's not in anything and in those cases they
don't want a MQ for non-contained cases and they set the
query on the root
florian: If that's what you're saying I think we can work off the
root to answer query. But did I miss?
jensimmons: Both. People will set on the root because used to have
to set it somewhere. They're going to be lazy and stick
it where they want
florian: Queries or just containment?
jensimmons: While using container queries. Will they combine it with
a switch in writing modes, maybe. If it's really hard it
might we worth the extra effort, but don't assume it's
an edge case
florian: Making container queries on anything makes sense. If you
need containment to get container queries makes sense to
have containment. If you container query for anything it
could work
jensimmons: They're going to stick a design system container where
they want. Sometimes in flow, sometimes deep in dom.
They won't re-write the code depending on the context
florian: Under that pattern makes sense to allow and the containment
part applied to root does nothing. Query when not contained
asks the root. Don't have to break cycles, just go all the
way up
jensimmons: Maybe. not sure
<fantasai> +1 florian
<miriam> +1 florian
florian: Need to see if it works, but general approach makes sense
iank: Not sure it works, florian. Need to think. You can
set...specially setting html element and you can set
properties which means will mismatch from viewport size I
believe
iank: So you'll have logical mismatch
florian: max-width on html element?
iank: Yeah, or set a direct width. I forget exactly what applies,
but you'll have a mismatch between html element and viewport
rune: If you spec containment on root html element such that
container queries should work on html element we'll instead
use viewport?
florian: Yes, but iank has a point too
iank: Yeah, I think if the choice is matching...you can set width on
html element. If decision is making that resolve against
viewport vs fixing containment I'm not wild about containing
queries being special to one html element and having it match
against viewport in one case
florian: I need to think. I feel like there's a shortcut but the one
I mentioned earlier is wrong
florian: I'd like to try and find a way out of this that doesn't
require breaking backwards propagation of things
fantasai: I don't have problem breaking propagation from body. It
shouldn't have existed.
fantasai: If we want to break propagation from body, just do it
myles: Not unreasonable, but this is wrong time to make that kind of
big change
iank: This is only breaking if we have containment applied on body.
This isn't a big change. If people are worried about compat,
I'm not, but we can add a use counter
myles: I think jensimmons made a compelling argument that it will
not be uncommon
iank: I think it's uncommon at the moment. I agree it could become
common and you're opting in
florian: If you add a component with container queries and not
paying attention to where and you don't check Arabic, only
English, you broke Arabic
Rossen: iank are you offering to collect some data?
iank: I think I might offer rune to collect data. I also think this
will only break vertical writing mode pages
Rossen: We're at top of the hour. How about the following? If we can
get data, great. jensimmons I'd ask you to dig out some of
these examples of devs or designers talking about htis on
root that would be helpful
jensimmons: It's in random convos and slack channels. It's not blog
posts. It's the first hot take. Just set it on the root.
We can teach them not to do it, but if that's the first
take there's something attractive. It's a sign it's not
edge case
florian: I think we should make it work, just aim for least breaky
Rossen: It will come to a compromise so let's make sure it's the
right one
Rossen: We're a bit over, thanks for staying. That was great
discussion
Received on Thursday, 18 February 2021 00:02:52 UTC