- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 18 May 2022 18:30:39 -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
----------
- RESOLVED: Remove checkInert from IsVisibleOptions (Issue #7274:
isVisible inert option)
CSS Fonts
---------
- There were some concerns about the proposed new keyword for
font-display (Issue #7271: Add a font-display keyword to
eliminate @font-face FOIT & layout shifts) encouraging authors
toward behavior that is bad for users. Discussion will go back to
github to discuss further the intent to assist authors in making
a decision they're already trying to make and how to balance that
against the concerns.
CSS Pseudo
----------
- RESOLVED: forced-color-adjust doesn't do anything on highlight
pseudos, and highlight pseudos take their forced color
state from the originating element (Issue #7264:
Highlight pseudos and forced-color-adjust)
Selectors
---------
- RESOLVED: Issue of topmost modal dialog to be addressed with a
pseudo-class (name TBD) (Issue #7258: Should :active
apply to dialogs?)
- RESOLVED: Add :-webkit-autofill in an appendix of selectors 4
(Issue #7257: List of -webkit- legacy aliases)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2022May/0006.html
Present:
Rachel Andrew
Rossen Atanassov
David Baron
Tantek Çelik
Daniel Clark
Emilio Cobos Álvarez
Elika Etemad
Simon Fraser
Xiaocheng Hu
Jonathan Kew
Vladimir Levin
Peter Linss
Ben Mathwig
Tim Nguyen
Alan Stearns
Miriam Suzanne
Regrets:
Delan Azabani
Chris Lilley
Lea Verou
Scribe: dbaron
CSSOM View
==========
isVisible inert option
----------------------
github: https://github.com/w3c/csswg-drafts/issues/7274
vmpstr: We have recently added an isVisible function to Element. It
takes a dictionary of additional options. One of those
options was about inert-ness.
vmpstr: Mozilla indicated that checking for inertness was a strange
thing to correlate with visibility. So we'd like to remove
this dictionary option, at least for now.
vmpstr: It's easier to add it later if people actually want this than
to remove.
Rossen: I'm assuming this is relatively safe at this point?
vmpstr: I'm not aware of implementations.
Rossen: Did you consider oriol's question?
vmpstr: ... with aria-hidden? Rereading it now.
vmpstr: It's a good question, but we'd like to begin by shipping
isVisible as a somewhat non-controversial set of options...
questions such as these can be raised to add additional
dictionary options if there are developers who want to check
these things.
Rossen: Any objections to dropping dictionary for now?
<chrishtr> +1 to removing
vmpstr: Just dropping the inert-ness member from the dictionary.
RESOLVED: Remove checkInert from IsVisibleOptions
Rossen: And hopefully oriol will get back to us if he has something
to raise.
CSS Fonts
=========
Add a font-display keyword to eliminate @font-face FOIT & layout shifts
-----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7271
xiaochengh: I propose adding a new keyword to font-display descriptor
so it's critical and blocks load event of stylesheet.
xiaochengh: The purpose is to eliminate flash of invisible/unstyled
text or layout shift caused by web fonts.
xiaochengh: There are many ways to mitigate flash or layout shift,
but either complicated to use or have other issues.
xiaochengh: This one keyword proposal can hopefully solve this.
Rossen: I see a conversation back and forth between Jonathan and
Laurence on the issue. Jonathan is raising some points -- not
sure they've been answered, especially his first point about
what is truly critical.
chrishtr: Regarding critical -- there are examples in issue of font
use cases that would be considered critical. This isn't a
question about why they'd be served from a 3d party domain
if they were critical. If you want your site to be fast
you'd ideally serve from same domain, but many sites use 3d
party font service to serve fonts, which allows 3d party
font service to update fonts over time.
chrishtr: xiaochengh is proposing that critical fonts should be
loaded only if they're truly critical. Hope that font
providers could have query parameter so that their
stylesheet could say it's render blocking.
Rossen: Jonathan...?
jfkthame: Don't have anything specific to add... was trying to
understand goals and how it would work. I have a little
reluctance to complicate font-display ... already fairly
complex that few people understand. But I haven't tried to
think through implementation issues.
jfkthame: ... of the new critical value.
jfkthame: Other question is how this relates to font loading api. Are
these use cases where authors should be using font loading
api to more closely control what is happening? Not sure...
fantasai: My concern is that it prevents the page from showing text.
I understand that intent is that authors not use it for
most of the text, but I think authors might use it for
that. We normally don't make it easier to prevent the page
from loading for long periods of time, perhaps forever.
xiaochengh: Problem is developers are already trying to block render
of page with various hacks. One example is to add empty
external stylesheet that blocks rendering so font can
load. Other is add display:none or visibility:hidden and
remove when font is loaded. Since developers are already
trying to do it, we can provide a better way.
<chrishtr> also, style sheets and scripts already block rendering,
potentially indefinitely.
<chrishtr> this attribute also indicates intent directly, and allows
the UA to ignore it after a timeout
fantasai: I think technique of using visibility:Hidden and then
visible is the developer very clearly saying that it's not
to be rendered until font loads. Very clear they want
invisible.
xiaochengh: not just making element invisible... making entire page
invisible.
Rossen: This is use-case specific. People can do it in a more
targeted way.
fantasai: My concern is that someone will be like "Oh, my wedding
invitation *has* to be loaded in this font because it looks
ugly otherwise, so I definitely consider this a critical
font" and then the reader of the invitation, on a different
connection, ends up never able to read the page
astearns: I think I agree with fantasai that the current hacks might
be sufficient for this. But I got on queue because of
concern with how this works only with render-blocking style
sheets. I worry about adding something that will work in
some cases but not in others. We'd have to specify what
this does, if anything, if the style sheet is not render
blocking. And I'm worried about adding something that has
that works and doesn't work
astearns: characteristic.
xiaochengh: The intention is to make it render-blocking but after the
document has already started there's no way to block
render, so to keep things simple I'm just making it block
load of style sheet.
emilio: Similar to that... this would imply the font should load
unconditionally and fully -- don't have unicode-range (
presumably ignored) -- my other question isn't this more
similar to how background images block the load event of the
page but not of the style sheet. Doesn't achieve the
rendering blocking that you want... but maybe it does?
Background image loads get started before layout rather than
during layout like fonts.
plinss: I agree with fantasai. I hear the argument that authors do
this so we should make it easy. That argument falls down when
authors are doing something bad -- we have no obligation to
do that. We should teach authors how to do fallbacks,
progressive rendering ,etc.
<fantasai> +1 to "don't optimize for making the bad things easy"
chrishtr: plinss, I don't think there is a good way to do it right
now. Only way to do it causes flashing on load. size-adjust
was added but ??. This is a clean solution to this natural
problem.
plinss: We have to weight harms between flashing and blank content.
Look for other alternative rather than blocking?
Rossen: Not sure how this isn't creating flashing as well while
you're waiting.
chrishtr: Shows white.. shouldn't consider that a flash of unstyled
content.
fantasai: We already have the block keyword that shows white.
chrishtr: The existing keyword shows white only for the text, not the
page
?: ... and there's layout shift.
plinss: I'd say both preferable to blank page.
chrishtr: I think use cases for either.
plinss: Authors don't always consider all the factors
plinss: Doesn't mean we should make it easier... think it will lead
to more abuse.
<fantasai> If we're adding a keyword for this, it needs to be
something really obnoxious and obvious, like
"block-entire-page-load-forever"
Rossen: I'm hearing a good bit of feedback. So I think we should take
this back to the issue and accumulate a little more consensus
there before we bring it back for a resolution. Also given
how many people missing today.
Rossen: Anything else you wanted to highlight today, xiaochengh?
xiaochengh: The intention is not to help authors do bad things... let
me outline this another way. We're trying to help authors
make a tradeoff more easily... tradeoff between page
stability and responsiveness. No easy way to go to one
end of the tradeoff.
Rossen: We'd like to move it back to the issues.
<astearns> I don't think this is necessarily a bad thing, but I am
not convinced there is no current way to achieve an
appropriate result
fantasai: My understanding is that the proposal is to add a keyword
that blocks the page rendering *literally forever* if the
font doesn't load. If it's still not loading 30 seconds
later because the font isn't loading, that's a problem for
the user.
plinss: I think the concern is that authors will unknowingly use this
badly and wind up doing bad things by accident.
<tantek> +1 fantasai, plinss this makes it too easy for authors to do
*harmful* things to users
<florian> +1 to not liking this, for the reasons said by fantasai and
plinss
<emilio> one could make a case that the same can effectively already
happen for any stylesheet tho
<chrishtr> Fantasai: this is not new, style sheets can and do already
block rendering. I do think the spec for this should say
the UA should provide a timeout.
<emilio> (I guess that's what chrishtr just said)
<fantasai> emilio, yeah, and it's obnoxious when I try to load a page
and it gives me a blank forever even though I know the
text is loaded
CSS Pseudo
==========
Highlight pseudos and forced-color-adjust
-----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7264
dandclark: Question about how forced-color-adjust:
preserve-parent-color should work with highlight
inheritance
dandclark: This interaction is potentially problematic.
dandclark: Prerequisite: consider whether forced-color-adjust should
be allowed in highlight pseudos.
dandclark: The spec gives a list of properties. Currently not allowed
there.
fantasai: I think the idea of having it not apply and just applying
the forced-color-adjust effect of the originating element
makes sense to me.
fantasai: I think that was mentioned in the post as a way to deal
with this.
dandclark: I think that's a good outcome... seems simplest.
dandclark: For all other color based properties the highlights are
sort of an independent cascade. But I think it makes sense
here. Seems odd that the originating element would take
forced colors and the highlights not.
dandclark: If the originating element has
forced-color-adjust:preserve-parent-color, what does that
mean for highlight pseudos that are active over that
originating element?
fantasai: Effect is that the color property is able to inherit from
the parent the actual color of the parent... and that
doesn't really impact the highlight pseudos ... which
doesn't matter for highlight pseudos where the currentColor
keyword comes from the previous layer. So the keyword
wouldn't have an effect.
dandclark: So then try to resolve that forced-color-adjust doesn't do
anything on highlight pseudos, and that highlight pseudos
take forced color state of originating element
Rossen: Proposed resolution: forced-color-adjust doesn't do anything
on highlight pseudos, and highlight pseudos take their forced
color state from the originating element
<dandclark> +1 to the whole thing. I think it's good to have that
clarification.
RESOLVED: forced-color-adjust doesn't do anything on highlight
pseudos, and highlight pseudos take their forced color
state from the originating element
Selectors
=========
Should :active apply to dialogs?
--------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7258
plinss: The sense is that there can be multiple modal dialogs and
only one is active. Should have a pseudo class for it. I
propose we re-use the :active pseudo class, though what
pseudo used is not that important.
plinss: There was a lot of pushback against using :active. I accept
it could be problematic... many people seem to think :active
means the mouse is down, but I think it means the thing is
active.
emilio: I was going to echo that... :active applies to all elements
when you press the mouse, regardless of whether they're
activatible. So I think it would be very confusing to use it
for this. Especially because it would trigger when you click
something in a dialog, because :active applies to the whole
chain of things.
emilio: I don't know that the pseudo is that useful -- can't think of
cases where you want different styling for the topmost modal
dialog from other modal dialogs.
Rossen: Is the point you're making that an active modal dialog must
always be the topmost one, and ... ?
emilio: I think reusing :active would be a mistake because it already
applies to <dialog>, and that I don't think there's a lot of
use cases for styling the active (i.e., topmost) dialog
versus styling a modal dialog that is not the topmost one.
emilio: We need to do that internally for inertness, but that's just
to control inertness of the topmost thing.
plinss: If you have nested dialogs, I can see wanting to
differentiate them visually. They may not necessarily be on
top of each other or obviously obscuring each other. I think
there's a valid use case for it.
emilio: Fair. I guess I think it's something the backdrop usually
takes care of.
plinss: Depends on what effect backdrop has and whether it's obvious.
ntim: I'm also against using :active for this. If you're really
targeting the dialog ??? ... that would make it incompatible.
ntim: :active has a historical meaning, so I'm against doing that.
ntim: I also don't see a lot of use cases. But my main pushback was
using :active.
ntim: Personally regarding use cases, since modal dialogs are
triggered using javascript, you can control which class you put
on the topmost one. I don't see a real gain from adding
pseudo-class.
plinss: You could make that argument about almost every pseudo-class.
Let me push back on :active meaning the mouse is down -- I
don't think that was original intent. I think it was a
mistake -- not sure if it's one we can fix.
ntim: Let's say you have a button inside a dialog, and you're
pressing that button. Unexpected that :active would apply,
given that :active propagates to parent elements.
plinss: It would already be active if the button is clickable
emilio: not if the dialog isn't modal
emilio: If I understand correctly, this would make a pseudo for the
topmost modal dialog. Would be confusing for that pseudo to
apply to non-modal dialogs.
<Rossen> +1 to emilio and :active interop being bad
emilio: Put on queue to say that :active interop is pretty bad. This
would make it a lot more confusing.
fantasai: I agree we can't use :active given how it's been
reinterpreted by implemented. Was never intended to be
"while I'm clicking on this element".
fantasai: I can see there might be use cases for having a
pseudo-element for the topmost modal. Wish we could use the
word active for it, maybe :active-modal or similar.
Rossen: I'd like to break the solution into validating the use case
and coming up with a solution, and then the bikeshedding.
Rossen: Would like to validate the use case first.
chrishtr: To the point about developers don't need it because they
control the dialogs... it's still convenient because it's
very simple to just have to style the front-most dialog and
not have to use script to polyfill the same thing.
Rossen: Sounds like there's more validation to the use case... name
of the pseudo TBD.
Rossen: Would prefer to take bikeshedding back to the github issue.
<tantek> I would like to get input from the OpenUI folks on this
<tantek> I didn't see any in https://github.com/w3c/csswg-drafts/issues/7258
ntim: If you have a UI that does stacking multiple dialogs... it's
not a great UI. This sort of encourages it in some way. I guess
the role of CSS isn't how to say how to build UIs.
plinss: I agree stacking modal dialogs is a bad pattern... though
maybe modal dialogs are a bad pattern to begin with. If we're
going to do them we should do them well.
plinss: ... goes against my earlier advice about allowing authors to
do bad things, but arguably modal dialogs in general are a
bad idea. If we're going to do them, though, let's do them
well.
tantek: I'm looking at issue and leaning towards plinss opinion as
well. But haven't considered motivating use cases.
tantek: I think OpenUI folks should comment... may have more context
of uses cases that would need this pseudo class... or they've
considered it and decided they don't need it.
Rossen: I think the decision of styling the active modal dialog
through a pseudo-class is seemingly obvious decision even if
we invalidate the use case later.
Rossen: I'd like to record a decision here....
ntim: Looking at top layer generally, maybe use case is targeting
topmost thing in top layer rather than active modal dialog.
Look at it from different perspectives as well.
ntim: How does this fit with other things that use the top layer --
full screen api, popup api.
ntim: How does this pseudo fit with this stuff... and should it be
more generic to these things?
ntim: so maybe openUI input would be good.
plinss: Happy to get openUIs input, but would like to take a
resolution to have a pseudo-class.
<chrishtr> +1 to resolving to add a pseudoclass now. :modal-active ?
<astearns> hears :tdb
Rossen: Proposed resolution that issue of topmost modal dialog to be
addressed with a pseudo-class (name TBD).
RESOLVED: Issue of topmost modal dialog to be addressed with a
pseudo-class (name TBD)
List of -webkit- legacy aliases
-------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7257
fantasai: We have a bunch of :-webkit- pseudo classes and things that
we may need to add to selectors spec. ??? has come up.
Questions are (1) do we define this in selectors 4 spec
(2) other aliases to add or (3) do we incorporate these
into definitions of each pseudo, or do we put them in an
appendix at the end.
ntim: Isn't there a web compatibility spec that defines a lot of CSS
prefixes?
fantasai: Yes, and the editors prefer that we'd define them in the
relevant specs.
<ntim> https://compat.spec.whatwg.org/
florian: That spec is meant as a stopgap for things not spec'd in
their native space.
florian: In general: preferably get rid of them. If we can't, spec
them. Appendix is a good way to spec without encouraging
adoption.
Rossen: Main question was should webkit prefixed things go in
selector 4 spec.
fantasai: Sounds like add as appendix to selectors 4. Do we add
:-webkit-autofill specifically? Are there others?
RESOLVED: Add :-webkit-autofill in an appendix of selectors 4
<tantek> I know we're over time, but I'm not seeing a reason to
duplicate the list from the compat spec
<fantasai> tantek, compat doesn't have a list of selectors
<fantasai> and also, they'd prefer we move things here
<fantasai> iirc
<tantek> thanks fantasai
Received on Wednesday, 18 May 2022 22:31:20 UTC