- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 20 Jan 2022 05:43:38 -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.
=========================================
Media Queries 3
---------------
- RESOLVED: Publish a Proposed Correction for MQ3, along with any
necessary antecedents as determined by florian/chris/
fantasai (Issue #6962: REC update)
CSS UI
------
- RESOLVED: Put an issue in the draft saying we'd like to remove
(Issue #6788: 'input-security' considered harmful)
Fullscreen
----------
- RESOLVED: Set visibility:hidden [typo: this should be
visibility:visible] on modal dialogs (Issue #6939: How
does top-layer interact with ancestors)
- New issues will be opened to resolve the modal pseudo-class and
reparenting issues raised as a part of issue #6939
Conditional & Selectors
-----------------------
- RESOLVED: Close no-change (Issue #3936: How should selector
supports test react to partially-implemented selectors?)
CSS Text
--------
- RESOLVED: hyphenate-character is shippable; we'll add it to the
Snapshot 2022 list of exceptions (Issue #6887: Is
hyphenate-character stable enough to ship?)
===== FULL MINUTES BELOW ======
Agenda: https://github.com/w3c/csswg-drafts/projects/29
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins Bittner
Delan Azabani
David Baron
Mike Bremford
Oriol Brufau
Tantek Çelik
Emilio Cobos Álvarez
Elika Etemad
Simon Fraser
Daniel Holbert
Brad Kemper
Jonathan Kew
Vladimir Levin
Rune Lillesveen
Chris Lilley
Ting-Yu Lin
Peter Linss
Alison Maher
Morgan Reschenberg
Jen Simmons
Alan Stearns
Miriam Suzanne
Lea Verou
Scribe: TabAtkins
Media Queries 3
===============
REC update
----------
github: https://github.com/w3c/csswg-drafts/issues/6962
florian: Elika suggests we might want an update since it's been a
while
florian: We haven't touched it since 2012
florian: Presumably we thought 4 and 5 would be done
florian: Also haven't rebuilt it since then, since it's on the old
preprocessor
florian: Some edits went into source, some went into output
florian: I synced them, and deleted the source since nobody uses it
anymore
florian: And made a few markup fixes
florian: Also errata. Most are editorial
florian: One was later overturned, but we didn't remove it from errata
florian: One was normative, so I've included it as a candidate
correction
florian: I think we're ready to publish.
florian: But if the group agrees I'd rather have it as a proposed
correction rather than candidate correction
chris: Don't think you can do that
chris: A proposed correction must have the same text as a candidate
correction
florian: hm, you might be right, but I think we could do two pubs in
a five minute span
chris: True there's no minimum review period
chris: Think it's an abuse of process, but it's not disallowed
astearns: So we could do candidate corr, let the AC know...
florian: Letting the AC know is the *proposed* correction thing
astearns: So you're suggesting do a candidate correction now, and do
a proposed correction sometime later?
florian: I propose doing it immediately after since we gain nothing
from a delay, but we can wait a bit if necessary
chris: You can do a proposed correction and ask the director and see
what happens, but it might take more time
florian: We don't need to ask the director, these are non-normative
until they're folded in
[missing some process discussion]
TabAtkins: Propose we resolve to publish a Proposed Correction, along
with any necessary antecedents?
<chris> https://www.w3.org/Guide/transitions?profile=REC&rec=substantive
RESOLVED: Publish a Proposed Correction for MQ3, along with any
necessary antecedents as determined by florian/chris/
fantasai
florian: Maybe a followup, maybe implied
florian: Once this is done we should clear the errata
chris: You automatically start with a new blank errata whenever you
publish a doc
CSS UI
======
'input-security' considered harmful
-----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6788
florian: I disagreed with just one of his statements, not all
florian: In UI4 we introduced 'input-security: auto | none'
florian: 'auto' does nothing by default, but on password fields (and
other host-defined "sensitive" things) it obscures the text
via *** or whatever
florian: 'none' turns that off
florian: Mats says this is a useful feature, but shouldn't be under
the author's control, needing them to use JS on things.
florian: UAs are also much more likely to get a11y right on things
like this.
dholbert: Also Edge already does this by default with a little button
on password fields
scribe: fantasai
astearns: Anyone implemented the CSS value?
TabAtkins: WebKit did, Chrome inherited it pre-fork
TabAtkins: Not ok to drop without a replacement
TabAtkins: Maybe mark as deprecated and that we will remove, once
HTML spec is updated to require
TabAtkins: No mandatory UI, but required functionality
smfr: I don't have much of an opinion.
smfr: If we need it internally we can keep it internally, don't have
a strong opinion
florian: Can we not have the dependency on HTML?
TabAtkins: The functionality is useful
TabAtkins: Optimal place is not in CSS, but if we don't have the
functionality otherwise should leave it in
florian: I'm saying we drop it from CSS now, and encourage browsers
to do the right thing
florian: rather than not removing it now
TabAtkins: That falls into the failure mode that's likely, which is
that we remove it and nothing happens to HTML
TabAtkins: and I think this is useful enough for users that we
shouldn't encourage nothing
<oriol> Firefox also has a UA button to show text (like Edge) behind
pref: layout.forms.input-type-show-password-button.enabled
florian: Chrome has it?
TabAtkins: yeah
florian: Edge has it?
dholbert: Firefox also has it on Nightly
florian: So seems like the scenario of not having it is unlikely
Rossen: Talking about the property?
florian: The behavior of being able to reveal the password
TabAtkins: We don't have it in Chrome
??: We disabled in Chrome because of compat issues
astearns: Issue in HTML spec?
<jensimmons> Issue at HTML: https://github.com/whatwg/html/issues/7293
astearns: That issue mentions something I'm concerned about, which is
the HTML spec might need a CSS definition in order to say
"here's what happens"
astearns: with this attribute or UI
florian: OK, maybe let's go back to what Tab suggests
florian: Resolve, we would like to remove this, would like it to be
in HTML
astearns: So adding an issue to draft, we'd like to remove please
don't implement?
dholbert: My concern is that if we leave it, HTML spec might point at
CSS for how to do it, and then JS can set in buggy ways
astearns: Note would say we'd like to remove, please don't implement
property, and HTML should define in a way that doesn't
depend on CSS
florian: Tess is arguing for what we are saying to not do
astearns: Which is we should make it an issue and get Tess's input
Tim_Nguyen: Issue on our side was that inputs tend to have buttons
for e.g. password autocomplete, and would need UI that
wouldn't interfere
astearns: Sounds like we're not going to resolve any spec edits
today, but let's add an issue to the draft saying we'd like
to remove this
astearns: Proposed resolution is to put our recommendation into an
issue in the draft, and come back to it later when we can
get more discussion on it
astearns: Objections?
RESOLVED: Put an issue in the draft saying we'd like to remove
Fullscreen
==========
scribes: TabAtkins & fantasai
How does top-layer interact with ancestors
------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6939
smfr: top-layer is used by <dialog>, ::backdrop, etc
smfr: They generate new stacking contexts, escape ancestor opacity,
other graphical effects
smfr: 'visibility' is a bit different
smfr: It's inherited; as specced, a visibility:hidden ancestor will
hide a dialog
[simon was dropped]
smfr: Tab responded with a confusing comment
TabAtkins: ...
smfr: He said top-layer things are reparented in the box tree
smfr: so that doesn't affect inheritance
smfr: I think people might be confused about that effect with
visibility
smfr: Maybe UA stylesheet should put visibility:visible on the dialog?
ntim: Worth noting - display:none on the ancestor propagates to the
top-layer element
emilio: Unsure to what extent display and visibility work together
emilio: was going to suggest Simon's UA stylesheet tweak to make it
work
TabAtkins: That seems fine to me. I don't see a particular issue to
set 'visibility' in the UA stylesheet
TabAtkins: I think it is surprising that a dialog would stay hidden
if the ancestor is hidden
emilio: Seems like a special case, yeah. But other than that, no
strong feeling.
TabAtkins: I guess 2 resolutions
TabAtkins: a) Top-layer elements are essentially reparented in the
box tree, so visual effects from containers don't apply,
but inheritance applies as normal
TabAtkins: b) We add rule to UA stylesheet that dialog is visibility:
visible
emilio: I'm not super convinced we should add it
emilio: could argue the same for a ton of other properties
emilio: but not strong, so won't object
astearns: What other properties?
emilio: Everything that inherits, like pointer-events
emilio: Anything that inherits thru could potentially be weird
astearns: And we're only talking about setting visibility and not
display
TabAtkins: display is consistent with what I said because it can't be
reparented in the box tree, because it's not in the box
tree
astearns: So first proposal from tab is top-layer elements are
reparented in the box tree, and point out that inheritance
isn't affected by that
smfr: The "etc" in the spec text needs clarification
TabAtkins: Agree, can do that
emilio: Related to 'display' issue, something came up recently while
triaging
emilio: Blink will create a box if the dialog is a child of the
replaced element
TabAtkins: I probably agree with you, decided on that in my comment
too quickly. Because affects box generation, dialog
shouldn't display at all
astearns: So any more discussion on the "reparenting in box tree"
portion?
smfr: do we need to be that specific?
TabAtkins: You asked a bunch of questions, need to have consistent
answers
TabAtkins: and having this conceptual model gives us consistent
answers
ntim: I think stacking context/containing block dfns are enough to
cover those cases
TabAtkins: Possibly
TabAtkins: I can review and see if that's enough
astearns: So why don't we not take that resolution for now, and you
can review
astearns: Okay so the etc
ntim: pointer-events
TabAtkins: It's an inherited property, so will just inherit. Unless
we want to do a reset in the UA stylesheet
astearns: Do we need to resolve on resetting visibility?
TabAtkins: OK, let's do that
astearns: Proposed to have UA stylesheet reset visibility for
dialog ... what about other top-level elements?
TabAtkins: Can't for other elements, can be arbitrary elements
TabAtkins: so can only do for dialog
astearns: OK, so proposed is that UA stylesheet sets 'visibility' on
dialog
smfr: When they are in the modal state
fantasai: I believe there's a :modal pseudo-class in HTML
ntim: We have a pseudo-class, but internal, not exposed in CSS
iank: I wrote that internal class
iank: Wording is there, but not actually in the HTML spec
astearns: Anything else we can use to select?
TabAtkins: Reasons we don't want to go into, are they blockers to
putting in HTML spec or historical?
iank: There was pushback to adding as an actual pseudo-class
iank: HTML spec didn't want to define pseudo-classes itself
TabAtkins: put it in Selectors
ntim: UA stylesheet, should have a statement about it
smfr: Comment about ::backdrop
smfr: Current behavior, if have visibility:hidden ancestor on dialog
smfr: Is that dialog is hidden but backdrop shows up
smfr: because backdrop not affected by inherted visibility, that's
not great
TabAtkins: Right, because ::backdrop inherits from the root
emilio: I thought it didn't inherit, which causes problems with
system properties
rune: ...
<iank> https://html.spec.whatwg.org/#phrasing-content-3 and scroll up
<iank> "The dialog element, when its is modal flag is true, is
expected to act as if it had a user-agent-level style sheet
rule setting the following properties:"
emilio: Which is something we may want to consider fixing
TabAtkins: That can be done in today's CSS by setting 'all: initial'
in the ::backdrop stylesheet
TabAtkins: so explainable in current CSS
emilio: Is it though?
emilio: All doesn't reset custom properties
emilio: We have an agenda item about selection, e.g. new ::selection
model not inheriting from original element which causes other
issues
iank: Quoted the prose from HTML
TabAtkins: HTML spec says "pretend there's a pseudo-class, and apply
these properties"
TabAtkins: let's just define the pseudo-class
iank: Pushback was exposing the internal pseudo-class to web
developers
astearns: Is there a concern about exposing to web devs?
emilio: I think Gecko was the first to implement via internal
pseudo-class
emilio: Everyone converged on that model
emilio: I think at first there was some resistance to expose a
pseudo-class because not how some browsers work
emilio: but at this point, given we have interop in that sense, all
browsers have internal pseudo-class
emilio: maybe makes sense to expose it
iank: Agree it makes sense, but think we'll still get pushback from
WHATWG
iank: Another thing that could be internal class but isn't
TabAtkins: We don't have to invoke WHATWG, we just put it in Selectors
TabAtkins: As long as browsers want that, not a jurisdictional problem
emilio: ...
TabAtkins: To change the styling of a dialog based on whether it's
open in a modal style or not, if UA wants to do it don't
see why authors wouldn't want to do it
ntim: I don't see much use case for it
ntim: Unlikely that someone will call showModal() and show() on the
same dialog
astearns: I suggest we separate out whether properly-defined pseudo
into own issue
astearns: but whether or not we do that, we should define certain
things for dialog using existing internal pseudo-class
astearns: So have some changes mentioning that you set visibility and
perhaps pointer-events
astearns: using same handwavy definition that HTML currently has
astearns: and separately figure out whether we need an exposed real
pseudo-class to put into Selectors
astearns: Does that sound reasonable?
TabAtkins: OK, opening issue
astearns: So can we resolve to set visibility using internal
pseudo-class?
astearns: Anyone want to continue discussing? Anyone have an
objection?
[continued silence]
RESOLVED: Set visibility:hidden on modal dialogs
astearns: Any other property to resolve now, or continue discussing
in the issue?
ntim: Pointer-events maybe?
ntim: Idk if it should be auto or all ...
astearns: In interest of time, let's punt to issue
astearns: and find out what the value should be and figure out any
other properties that should be set in this way
astearns: Done with this issue for today
astearns: bit about box-tree reparenting, should that be a separate
issue so don't lose track of it?
(new issue for :modal-dialog https://github.com/w3c/csswg-drafts/issues/6965)
astearns: OK, we'll keep this issue just about properties to set in
UA stylesheet
astearns: separate issue on modal pseudo-class
astearns: and separate issue on reparenting
Conditional & Selectors
=======================
How should selector supports test react to partially-implemented
selectors?
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3936
fantasai: So it's about how supports() should work for
"partially-implemented" selectors (only implemented in some
contexts)
fantasai: And if we need a separate supports*() function to
differentiate them.
TabAtkins: :has() pseudo-class, was suggested could be implemented
just in .querySelector and not in CSS
TabAtkins: Question about whether @supports/.supports() return true
for support in that case
TabAtkins: Conclusion was that only true if supported in CSS
TabAtkins: and can tell if .querySelector supports by whether or not
it throws
TabAtkins: So shouldn't need additional work
astearns: So anyone interested in keeping the issue open, or okay
with closing?
astearns: Objections to closing?
astearns: I trust if Amelia disagrees we'll hear about it
proposed: .supports/@supports checks for support in CSS, use
.querySelector throwing to check for support there, close
no change
RESOLVED: Close no-change
CSS Text
========
Is hyphenate-character stable enough to ship?
---------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6887
jfkthame: Question in the title
jfkthame: webkit and blink have this, but -webkit- prefixed
astearns: And Firefox has this unprefixed?
jfkthame: Yes, behind a nightly flag
jfkthame: So question is whether we can ship it unflagged
fantasai: I think so. I don't remember there being any issues against
this particular property for the many years it's been around
florian: Agree. You noted there might need to be extensions later to
be smart about some details, but they can be put on top of
the current value set
astearns: What's state of the spec?
florian: WD, this is level 4
astearns: So we resolve this is okay to publish, and add this to the
snapshot list of things that are shippable ahead of process
astearns: objections?
RESOLVED: hyphenate-character is shippable; we'll add it to the
Snapshot 2022 list of exceptions
fantasai: Do we want to resolve to publish a Draft Note 2022 with
this change?
astearns: I think we should publish as needed, yes.
chris: Seems much better to publish as we have updates, yes
astearns: So proposed resolution is we publish a Draft Note for 2022
<fantasai> (Now that we have a Draft Note)
chris: Since /TR/CSS goes to the snapshot, why don't we publish a
Note series with "css" as the shortname, so every time it's
not the first draft, but just an update?
fantasai: I didn't like this; I think it's useful to have snapshots
on a yearly basis
fantasai: Just walking back thru publish history isn't the same
chris: If you follow history right now, it'll say "css 2022 has been
published once", and you can't go back to 2021 from there
fantasai: I think your point is valid but it is true for all leveled/
versioned things
fantasai: That's an issue for the templates
astearns: So no resolution, we'll break
<break>
Received on Thursday, 20 January 2022 10:44:20 UTC