16:00:43 <RRSAgent> RRSAgent has joined #css
16:00:43 <RRSAgent> logging to https://www.w3.org/2022/01/19-css-irc
16:00:43 <smfr> smfr has joined #css
16:00:45 <Zakim> RRSAgent, make logs Public
16:00:46 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
16:02:01 <oriol> oriol has joined #css
16:02:15 <alisonmaher> alisonmaher has joined #css
16:02:39 <vmpstr> present+
16:02:40 <alisonmaher> present+
16:02:51 <miriam> present+
16:03:04 <delan> present+
16:03:06 <jfkthame> present+
16:03:08 <dbaron> dbaron has joined #css
16:03:11 <TabAtkins> ScribeNick: TabAtkins
16:03:17 <TabAtkins> present+
16:03:39 <oriol> present+
16:04:23 <dbaron> Present+
16:04:30 <Morgan> present+
16:05:10 <dholbert> dholbert has joined #css
16:05:32 <TabAtkins> Topic: MQ3 Rec update
16:05:37 <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/6962
16:05:51 <TabAtkins> florian: Elika suggests we might want an update since it's been a while
16:05:55 <TabAtkins> florian: We haven't touched it since 2012
16:06:01 <TabAtkins> florian: Presumably we thought 4 and 5 would be done
16:06:09 <TabAtkins> florian: Also haven't rebuilt it since then, since it's on the old preprocessor
16:06:16 <TabAtkins> florian: Some edits went into source, some went into output
16:06:24 <TabAtkins> florian: I synced them, and deleted the source since nobody uses it anymore
16:06:31 <TabAtkins> florian: And made a few markup fixes
16:06:35 <TabAtkins> florian: Also errata. Most are editorial
16:06:42 <TabAtkins> florian: One was later overturned, but we didn't remove it from errata
16:06:52 <TabAtkins> florian: One was normative, so I've included it as a candidate correction
16:06:58 <TabAtkins> florian: I think we're ready to publish.
16:07:13 <TabAtkins> florian: But if the group agrees I'd rather have it as a proposed correction rather than candidate correction
16:07:19 <TabAtkins> chris: don't think you can do that
16:07:37 <TabAtkins> chris: a proposed correction must have the same text as a candidate correction
16:07:43 <argyle> argyle has joined #css
16:08:06 <TabAtkins> florian: hm, you might be right, but i think we could do two pubs in a five minute span
16:08:13 <TabAtkins> chris: true there's no minimum review period
16:08:23 <TabAtkins> chris: Think it's an abuse of process, but it's not disallowed
16:08:42 <TabAtkins> astearns: So we could od candidate corr, let the AC know...
16:08:49 <TabAtkins> florian: Letting the AC know is the *proposed* correction thing
16:09:09 <TabAtkins> astearns: So you're suggesting do a candidate correction now, and do a proposed correction sometime later?
16:09:22 <TabAtkins> florian: I propose doing it immediately after since we gain nothing from a delay, but we can wait a bit if necessary
16:09:37 <TabAtkins> chris: you can do a proposed correction and ask the director and see what happens, but it might take more time
16:09:55 <TabAtkins> florian: We don't need toa sk the director, these are nonnormative until they're folded in
16:10:02 <TabAtkins> [missing some process discussion]
16:10:49 <TabAtkins> TabAtkins: Propose we resolve to publish a Proposed Correction, along with any necessary antecedents?
16:11:09 <TabAtkins> RESOLVED: Publish a Proposed Correction for MQ3, along with any necessary antecedents as determined by florian/chris/fantasai
16:11:17 <chris> https://www.w3.org/Guide/transitions?profile=REC&rec=substantive
16:11:38 <TabAtkins> florian: Maybe a followup, maybe implied
16:11:44 <TabAtkins> florian: Once this is done we should clear the errata
16:12:01 <dholbert> dholbert has joined #css
16:12:09 <TabAtkins> chris: You automatically start with a new blank errata when3eve ryou publish a doc
16:12:15 <TabAtkins> Topic: input-security considered harmful
16:12:17 <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/6788
16:12:41 <TabAtkins> florian: I disagreed with just one of his statements, not all
16:12:47 <jensimmons> jensimmons has joined #css
16:12:50 <TabAtkins> florian: In UI4 we introduced 'input-security: auto | none'
16:13:12 <TabAtkins> florian: 'auto' does nothing by default, but on password fields (and other host-defined "sensitive" things) it obscures the text via *** or whatever
16:13:23 <TabAtkins> florian: 'none' turns that off
16:13:37 <TabAtkins> florian: Mats says this is a useful feature, but shouldn't be under the author's control, needing them to use JS on things.
16:13:49 <TabAtkins> florian: UAs are also much more likely to get a11y right on things like this.
16:14:07 <TabAtkins> dholbert: Also Edge already does this by default with a little button on password fields
16:14:15 <TabAtkins> astearns: Anyone implemented the CSS value?
16:14:38 <TabAtkins> TabAtkins: WebKit did, Chrome inherited it pre-fork
16:15:13 <fantasai> TabAtkins: Not ok to drop without a replacement
16:15:27 <fantasai> TabAtkins: maybe mark as deprecated and that we will remove, once HTML spec is updated to require
16:15:42 <jensimmons> present+
16:15:44 <fantasai> TabAtkins: No mandatory UI, but required functionality
16:16:04 <TabAtkins> smfr: I don't have much of an opinion.
16:16:07 <futhark> futhark has joined #css
16:16:11 <futhark> present+
16:16:15 <TabAtkins> smfr: If we need it internally we can keep it internally, don't have a strong opinion
16:16:41 <fantasai> florian: Can we not have the dependency on HTML?
16:16:47 <fantasai> TabAtkins: The functionality is useful
16:17:04 <fantasai> TabAtkins: optimal place is not in CSS, but if we don't have the functionality otherwise should leave it in
16:17:19 <fantasai> florian: I'm saying we drop it from CSS now, and encourage browsers to do the right thing
16:17:24 <fantasai> florian: rather than not removing it now
16:17:36 <fantasai> TabAtkins: That falls into the failure mode that's likely, which is that we remove it and nothing happens to HTML
16:17:44 <fantasai> TabAtkins: and I think this is useful enough for users that we shouldn't encourage nothing
16:17:45 <oriol> Firefox also has a UA button to show text (like Edge) behind pref:  layout.forms.input-type-show-password-button.enabled
16:17:51 <fantasai> florian: Chrome has it?
16:17:53 <fantasai> TabAtkins: yeah
16:17:56 <fantasai> florian: Edge has it?
16:18:08 <fantasai> dholbert: Firefox also has it on Nightly
16:18:17 <fantasai> florian: So seems like the scenario of not having it is unlikely
16:18:25 <fantasai> Rossen: talking about the property?
16:18:32 <fantasai> florian: The behavior of being able to reveal the passwrod
16:18:34 <jensimmons> Issue at HTML: https://github.com/whatwg/html/issues/7293
16:18:37 <fantasai> TabAtkins: We don't have it in Chrome
16:18:44 <fantasai> ??: We disabled in Chrome because of compat issues
16:18:52 <fantasai> astearns: Issue in HTML spec?
16:18:55 <fantasai> scribe+
16:19:23 <fantasai> 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"
16:19:27 <fantasai> astearns: with this attribute or UI
16:19:40 <fantasai> florian: OK, maybe let's go back to what Tab suggests
16:19:47 <fantasai> florian: Resolve, we would like to remove this, would like it to be in HTML
16:19:55 <fantasai> astearns: So adding an issue to draft, we'd like to remove pls don't implement?
16:20:17 <fantasai> 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
16:20:32 <fantasai> astearns: Note would say we'd like to remove, pls don't implement property, and HTML should define in a way that doesn't depend on CSS
16:20:38 <fantasai> florian: Tess is arguing for what we are saying to not do
16:20:49 <fantasai> astearns: Which is we should make it an issue and get Tess's input
16:21:12 <emilio> present+
16:21:17 <fantasai> 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
16:21:22 <smfr> present+
16:21:31 <dholbert> present+
16:21:43 <fantasai> 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
16:21:59 <fantasai> 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
16:22:02 <fantasai> astearns: Objections?
16:22:07 <TabAtkins> Topic: how does top-layer interact with ancestors
16:22:09 <fantasai> RESOLVED: Put an issue in the draft saying we'd like to remove
16:22:11 <TabAtkins> SHIT
16:22:17 <fantasai> GOOD JOB
16:22:50 <TabAtkins> Topic: how does top-layer interact with ancestors
16:22:56 <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/6939
16:23:17 <dgrogan> dgrogan has joined #css
16:23:27 <TabAtkins> smfr: top-laye ris used by <dialog>, ::backdrop,e tc
16:23:40 <TabAtkins> smfr: They generate new stackign contexts, escape ancestor opacity, other graphical effects
16:23:45 <TabAtkins> smfr: 'visibility' is a bit different
16:24:00 <TabAtkins> smfr: It's inherited; as specced, a visibility:hidden ancesotr will hide a dialog
16:24:11 <TabAtkins> [simon was dropped]
16:24:37 <TabAtkins> smfr: Tab responded with a confusing comment
16:25:08 <fantasai> TabAtkins: ...
16:25:13 <TabAtkins> smfr: he said top-layer things are reparented in the box tree
16:25:19 <TabAtkins> smfr: so that doesn't affect inheritance
16:25:30 <TabAtkins> smfr: I think people might be confused about that effect with visibility
16:25:41 <TabAtkins> smfr: Maybe UA stylesheet should put visibility:visible on the dialog?
16:26:27 <TabAtkins> ntim: Worth nothing - display:none on the ancestor propogates to the top-layer element
16:26:51 <faceless> present+
16:26:51 <TabAtkins> emilio: unsure to what extent display and visiblity work together
16:26:59 <TabAtkins> emilio: was going to suggest Simon's UA stylesheet tweak to make it work
16:27:18 <fantasai> TabAtkins: That seems fine to me. I don't see a particular issue to set 'visiblity' in the UA stylesheet
16:27:33 <fantasai> TabAtkins: I think it is surprising that a dialog would stay hidden if the ancestor is hidden
16:27:38 <TabAtkins> emilio: Seems like a special case, yeah. But other than that, no strong feeling.
16:27:48 <fantasai> TabAtkins: I guess 2 resolutions
16:28:09 <fantasai> 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
16:28:18 <fantasai> TabAtkins: b) We add rule to UA stylesheet that dialog is visibility: visible
16:28:23 <fantasai> emilio: I'm not super convinced we should add it
16:28:28 <fantasai> emilio: could argue the same for a ton of other properties
16:28:33 <fantasai> emilio: but not strong, so won't object
16:28:35 <dholbert__> dholbert__ has joined #css
16:28:37 <fantasai> astearns: what other properties?
16:28:40 <TabAtkins> emilio: everything that inherits, like pointer-events
16:28:50 <TabAtkins> emilio: anything that inherits thru could potentially be weird
16:29:06 <TabAtkins> astearns: And we're onlyt alking about setting visibility and not display
16:29:56 <fantasai> 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
16:30:03 <TabAtkins> astearns: So first proposal from tab is top-layer elements are reparented in teh box tree, and point out that inheritance isn't affected by that
16:30:22 <TabAtkins> smfr: The "etc" in the spec text needs clarification
16:30:23 <emilio> q+
16:30:38 <TabAtkins> TabAtkins: agree, can do that
16:30:41 <astearns> ack emilio
16:30:47 <TabAtkins> emilio: related to 'display' issue, something came up recently while triaging
16:31:02 <TabAtkins> emilio: Blink will create a box if the dialgo is a child of the replaced element
16:31:38 <fantasai> TabAtkins: I probably agree with you, decided on that in my comment too quickly. Because affects box generation, dialog shouldn't display at all
16:31:53 <TabAtkins> astearns: So any more discussion on the "reparenting in box tree" portion?
16:32:29 <fantasai> smfr: do we need to be that specific?
16:32:37 <fantasai> TabAtkins: You asked a bunch of questions, need to have consistent answers
16:32:46 <fantasai> TabAtkins: and having this conceptual model gives us consistent answers
16:33:00 <TabAtkins> ntim: I think stacking context/containing block dfns are enough to cover those cases
16:33:06 <fantasai> TabAtkins: Possibly
16:33:12 <fantasai> TabAtkins: I can review and see if that's enough
16:33:20 <fantasai> astearns: So why don't we not take that resolution for now, and you cna review
16:33:22 <TabAtkins> astearns: Okay so the etc
16:33:35 <fantasai> ntim: pointer-events
16:33:48 <fantasai> TabAtkins: It's an inherited property, so will just inherit. Unless we want to do a reset in the UA stylesheet
16:33:55 <fantasai> astearns: Do we need to resolve on resetting visibility?
16:34:01 <fantasai> TabAtkins: OK, let's do that
16:34:17 <fantasai> astearns: Proposed to have UA stylesheet reset visibility for dialog ... what about other top-level elements?
16:34:25 <fantasai> TabAtkins: Can't for other elements, can be arbitrary elements
16:34:28 <fantasai> TabAtkins: so can only do for dialog
16:34:39 <fantasai> astearns: OK, so proposed is that UA stylesheet sets 'visibility' on dialog
16:34:43 <fantasai> smfr: when they are in the modal state
16:35:04 <fantasai> fantasai: I believe there's a :modal pseudo-class in HTML
16:35:15 <fantasai> ntim: we have a pseudo-class, but internal, not exposed in CSS
16:35:24 <fantasai> iank_: I wrote that internal class
16:35:34 <fantasai> iank_: Wording is there, but not actually in the HTML spec
16:35:40 <fantasai> astearns: Anything else we can use to select?
16:35:52 <fantasai> TabAtkins: reasons we don't want to go into, are they blockers to putting in HTML spec or historical?
16:35:59 <fantasai> iank_: There was pushback to adding as an actual pseudo-class
16:36:04 <smfr> q+
16:36:08 <fantasai> iank_: HTML spec didn't want to define pseudo-classes itself
16:36:13 <fantasai> TabAtkins: put it in Selectors
16:36:23 <fantasai> ntim: UA stylesheet, should have a statement about it
16:36:29 <astearns> ack smfr
16:36:34 <fantasai> smfr: Comment about ::backdrop
16:36:40 <fantasai> smfr: current behavior, if have visiblity:hidden ancestor on dialog
16:36:46 <fantasai> smfr: is that dialog is hidden but backdrop shows up
16:36:55 <fantasai> smfr: because backdrop not affected by inherted visibility, that's not great
16:37:04 <fantasai> TabAtkins: right, because ::backdrop inherits from the root
16:37:15 <fantasai> emilio: I thought it didn't inherit, which causes problems with system properties
16:37:19 <fantasai> rune: ...
16:37:27 <iank_> https://html.spec.whatwg.org/#phrasing-content-3 and scroll up
16:37:36 <fantasai> emilio: Which is something we may want to consider fixing
16:37:49 <fantasai> TabAtkins: That can be done in today's CSS by setting 'all: initial' in the ::backdrop stylesheet
16:37:53 <fantasai> TabAtkins: so explainable in current CSS
16:37:59 <fantasai> emilio: is it though?
16:38:04 <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:"
16:38:10 <fantasai> emilio: all doesn't reset custom properties
16:38:31 <fantasai> emilio: We have an agenda item about selection, e.g. new ::selection model not inheriting from original element which causes other issues
16:38:48 <fantasai> iank_: Quoted the prose from HTML
16:39:27 <fantasai> TabAtkins: HTMl spec says "pretend there's a pseudo-class, and apply these properties"
16:39:32 <fantasai> TabAtkins: let's just define the pseudo-class
16:39:35 <tantek> tantek has joined #css
16:39:42 <fantasai> iank_: Pushback was exposing the internal pseudo-class to web developers
16:39:50 <fantasai> astearns: Is there a concern about exposing to web devs?
16:39:58 <fantasai> emilio: I think Gecko was the first to implement via internal pseudo-class
16:40:01 <fantasai> emilio: Everyone converged on that model
16:40:14 <fantasai> emilio: I think at first there was some resistance to expose a pseudo-class because not how some browsers work
16:40:25 <fantasai> emilio: but at this point, given we have interop in that sense, all browsers have internal pseudo-class
16:40:31 <fantasai> emilio: maybe makes sense to expose it
16:40:40 <fantasai> iank_: Agree it makes sense, but think we'll still get pushback from WHATWG
16:40:49 <fantasai> iank_: Another thing that could be internal class but isn't
16:40:56 <fantasai> TabAtkins: we don't have to invoke WHATWG, we just put it in Selectors
16:41:04 <fantasai> TabAtkins: as long as browsers want that, not a jurisdictional problem
16:41:17 <fantasai> emilio: ...
16:41:36 <fantasai> 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
16:41:41 <fantasai> ntim: I don't see much use case for it
16:41:54 <fantasai> ntim: Unlikely that someone will call showModal() and show() on the same dialog
16:42:12 <fantasai> astearns: I suggest we separate out whether propertly-defined pseudo into own issue
16:42:26 <fantasai> astearns: but whether or not we do that, we should define certain things for dialog using existing internal pseudo-class
16:42:34 <fantasai> astearns: so have some changes mentioning that you set visiblity and perhaps pointer-events
16:42:41 <fantasai> astearns: using same handwavy definition that HTML currently has
16:42:54 <fantasai> astearns: and separately figure out whether we need an exposed real pseudo-class to put into Selectors
16:42:58 <fantasai> astearns: does that sound reasonable?
16:43:02 <fantasai> TabAtkins: OK, opening issue
16:43:14 <fantasai> astearns: So can we resolve to set visiblity using internal pseudo-class?
16:43:31 <fantasai> astearns: Anyone want to continue discussing? Anyone have an objection?
16:43:34 <fantasai> [continued silence]
16:43:47 <fantasai> RESOLVED: Set visiblity:hidden on modal dialogs
16:43:55 <fantasai> astearns: Any other property to resolve now, or continue discussing in the issue?
16:44:01 <fantasai> ntim: Pointer-events maybe?
16:44:08 <fantasai> ntim: Idk if it should be auto or all ...
16:44:38 <fantasai> astearns: In interest of time, let's punt to issue
16:44:54 <fantasai> astearns: and find out what the value should be and figure out any other properties that should be set in this way
16:45:00 <fantasai> astearns: Done with this issue for today
16:45:20 <fantasai> astearns: bit about box-tree reparenting, should that be a separate issue so don't lose track of it?
16:45:22 <TabAtkins> (new issue for :modal-dialog https://github.com/w3c/csswg-drafts/issues/6965)
16:45:33 <fantasai> astearns: OK, we'll keep this issue just about properties to set in UA stylesheet
16:45:45 <fantasai> astearns: separate issue on modal pseudo-class
16:45:51 <fantasai> astearns: and separate issue on reparenting
16:46:12 <fantasai> Topic: [css-conditional-4][selectors-4] How should selector supports test react to partially-implemented selectors?
16:46:15 <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/3936
16:47:15 <TabAtkins> fantasai: So it's about how supports() should work for "partially-implemented" selectors (only implemented in some contexts)
16:47:24 <TabAtkins> fantasai: And if we need a separate supports*() function to differentiate them.
16:47:49 <fantasai> TabAtkins: :has() psueudo-class, was suggested could be implemented just in .querySelector and not in CSS
16:48:13 <fantasai> TabAtkins: Question about whether @supports/.supports() return true fo rsupport in that case
16:48:22 <fantasai> TabAtkins: Conclusion was that only true if supported in CSS
16:48:38 <fantasai> TabAtkins: and can tell if .querySelector supports by whether or not it throws
16:48:53 <fantasai> TabAtkins: So shouldn't need additional work
16:49:32 <TabAtkins> astearns: So anyone interested in keeping the issue open, or okay with closing?
16:49:39 <TabAtkins> astearns: Objections to closing?
16:49:55 <TabAtkins> astearns: I trust if Amelia disagrees we'll hear about it
16:50:00 <TabAtkins> RESOLVED: Close no-change
16:50:03 <fantasai> proposed: .supports/@supports checks for support in CSS, use .querySelector throwing to check for support there, close no change
16:50:16 <TabAtkins> Topic: can we ship hyphenate-character?
16:50:27 <TabAtkins> jfkthame: Question in the title
16:50:35 <TabAtkins> jfkthame: webkit and blink have this, but -webkit- prefixed
16:50:44 <TabAtkins> astearns: And Firefox has this unprefixed?
16:50:49 <TabAtkins> jfkthame: Yes, behind a nightly flag
16:50:57 <TabAtkins> jfkthame: So quesiton is whether we can ship it unflagged
16:51:12 <TabAtkins> fantasai: I think so. I don't remember there being any issues against this particular property for the many years it's been around
16:51:29 <Rossen_> Rossen_ has joined #css
16:51:32 <TabAtkins> 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
16:51:34 <plinss> present+
16:51:37 <TabAtkins> astearns: What's state of the spec?
16:51:41 <TabAtkins> florian: WD, this is level 4
16:51:43 <Rossen_> present+
16:51:57 <TabAtkins> astearns: So we resolve this is okay to publish, and add this to the snapshot list of things that are shippable ahead of process
16:52:09 <TabAtkins> astearns: objections?
16:52:28 <TabAtkins> RESOLVED: hyphenate-character is shippable; we'll add it to the Snapshot 2022 list of exceptions
16:52:40 <TabAtkins> fantasai: Do we want to resolve to publish a Draft Note 2022 with this change?
16:52:46 <TabAtkins> astearns: I think we should publish as needed, yes.
16:53:01 <TabAtkins> chris: Seems much better to publish as we ahve updates, yes
16:53:18 <TabAtkins> astearns: So proposed reoslution is we publish a Draft Note for 2022
16:53:31 <fantasai> (Now that we have a Draft Note)
16:53:49 <TabAtkins> 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?
16:54:01 <lea> lea has joined #css
16:54:05 <lea> present+
16:54:07 <TabAtkins> fantasai: I didn't like this; I think it's useful to have snapshots on a yearly basis
16:54:16 <TabAtkins> fantasai: Just walking back thru publish history isn't the same
16:54:36 <TabAtkins> 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
16:55:32 <TabAtkins> fantasai: I think your point is valid but it is true for all leveled/versioned things
16:55:38 <TabAtkins> fantasai: That's an issue for the templates
16:55:54 <TabAtkins> astearns: So no reoslution, we'll break
16:56:17 <dbaron> github-bot, end topic
16:57:31 <rachelandrew> present+
17:01:28 <emilio> https://github.com/w3c/csswg-drafts/issues/6939#issuecomment-1016671534
17:05:42 <emilio> ScribeNick: emilio
17:06:15 <TYLin> present+
17:06:50 <emilio> topic: top-layer stuff
17:06:52 <emilio> github: https://github.com/w3c/csswg-drafts/pull/6537
17:07:31 <emilio> RESOLVED: Set visibility: visible on modal dialogs
17:07:36 <emilio> topic: end
17:09:38 <emilio> topic: Kind of widget for an element
17:09:40 <emilio> github: https://github.com/w3c/csswg-drafts/pull/6537
17:09:53 <emilio> florian: haven't looked into this recently
17:10:22 <emilio> astearns: I think we should accept the edits and file issues if there are remaining problems
17:10:37 <emilio> fantasai: I'd like that to be conditional on florian's approval
17:10:44 <bradk> bradk has joined #css
17:10:50 <emilio> florian: Can we defer this to next week? Need to check changes were made
17:11:03 <emilio> Rossen_: yeah, that's fine, don't want to get that landed and then review it
17:11:10 <bradk> present+
17:11:17 <emilio> topic: conditionText setter interop
17:11:33 <emilio> github: https://github.com/w3c/csswg-drafts/issues/6819
17:12:08 <emilio> fantasai: there's a lot of failures when I was testing this. Firefox was the most correct on @media but fails on @supports. WebKit / Blink doesn't support either
17:12:21 <emilio> ... do we want to file impl bugs or call them readonly?
17:12:23 <emilio> q+
17:12:49 <emilio> TabAtkins: I know setting media attributes on link is useful
17:12:58 <emilio> ... and used by some tooling
17:13:13 <emilio> ... so I think it's useful to continue supporting it
17:13:28 <tantek> present+
17:13:34 <emilio> ... but I wouldn't shed too many tears if we call it readonly
17:14:09 <fantasai> emilio: I'd like to say that making conditionalText in the OM is different from what tooling does changing medi aof link
17:14:15 <fantasai> emilio: latter depends on ... stylesheets
17:14:22 <fantasai> TabAtkins: I was talking about toggling an @media rule
17:14:32 <fantasai> emilio: But not supported by WebKit and Blink
17:14:51 <fantasai> TabAtkins: Toggling *conditionText* isn't supported. But toggling mediaText *is*, though essentially a synonym
17:15:00 <fantasai> emilio: The media attribute on link or style element toggles the DOM attribute
17:15:04 <fantasai> TabAtkins: not talking about that
17:15:10 <fantasai> TabAtkins: talking about @media rule
17:15:15 <fantasai> emilio: ah, ok, that's weird
17:15:25 <fantasai> TabAtkins: Jonathan Neal has exploited that to toggle entire sets of rules before
17:15:37 <fantasai> Rossen_: So if we move to resolve on making this readonly
17:15:48 <fantasai> Rossen_: would there be any objections to it?
17:16:03 <fantasai> fantasai: I suspect in either case we need changes in implementations
17:16:10 <fantasai> fantasai: just a question of which way we want to go
17:16:27 <oriol> q+
17:16:33 <emilio> ack emilio
17:16:33 <Rossen_> q?
17:16:34 <fantasai> Rossen_: Forcing a normative change here would be encouraging something to change
17:16:42 <emilio> ScribeNick: emilio
17:16:44 <fantasai> fantasai: I have a PR adding tests, just haven't merged because opened this issue
17:17:11 <oriol> Reconnecting headset
17:17:11 <bradk> bradk has joined #css
17:17:19 <emilio> ack oriol
17:17:39 <emilio> oriol: conditionText seems analogous to selectorText for style rules and that's not read-only
17:17:48 <emilio> ... in the past it was not interoperable but it got fixed
17:18:27 <fantasai> emilio: Counter-example, we made layerName readonly
17:18:31 <bradk> bradk has joined #css
17:18:33 <fantasai> emilio: and generally leaning towards making OM readonly
17:18:43 <emilio> ... so counter-examples in both directions which is not a great state of affairs
17:19:06 <emilio> Rossen: So options are leave as-is and hoping tests cause browsers to change
17:19:15 <emilio> ... or resolve on making read-only
17:19:22 <emilio> ... should we do a straw-poll?
17:19:46 <emilio> TabAtkins: I'd prefer to make stuff consistently mutable
17:20:01 <bradk> +1 As is, but encourage browsers to change
17:20:06 <fantasai> s/mutable/mutable, given this is analogous to existing htings which are mutable/
17:20:17 <TabAtkins> emilio: Making @supports mutable would be a change
17:20:28 <TabAtkins> emilio: @media dynamically changes but @supports doesn't currently
17:20:38 <smfr> q+
17:20:53 <futhark> Existing issue for Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=1210073
17:21:16 <emilio> emilio: so that might be why Firefox doesn't support mutating it. In general readonly is going to be easier to get interop on
17:21:22 <emilio> ... but not super-strong feelings either way
17:21:27 <emilio> ack bradk
17:21:39 <emilio> bradk: I think it should be mutable
17:21:43 <emilio> ack smfr
17:22:01 <bradk> bradk has joined #css
17:22:08 <emilio> smfr: from an implementor perspective we'd like to CSSOM be more readonly, we don't have many incentives to fix these bugs
17:22:09 <TabAtkins> I suppose the fact that @media *does* have the .media mutable means it's okay for the .conditionText to be a readonly version that covers everyone
17:22:16 <bradk> A
17:22:19 <fantasai> 0
17:22:22 <emilio> strawpol: A - as-is, B - read-only
17:22:25 <oriol> A
17:22:25 <florian> 0
17:22:26 <emilio> B
17:22:26 <smfr> B
17:22:27 <TabAtkins> B
17:22:28 <futhark> B
17:22:28 <miriam> 0
17:22:29 <dholbert> 0
17:22:38 <jensimmons> B
17:22:39 <astearns> 0
17:22:46 <jfkthame> 0
17:22:47 <bradk> I don’t feel super strongly about it
17:22:55 <lea> Α
17:23:25 <delan> 0
17:23:30 <TYLin> A
17:23:34 <Morgan> 0
17:23:40 <rachelandrew> B
17:23:45 <tantek> B until there's a use-case described (didn't see it)
17:23:48 <Rossen_> B
17:23:51 <castastrophe> castastrophe has joined #css
17:23:54 <castastrophe> A
17:23:57 <chris> 0
17:24:39 <lea> Reasoning: Readonly puts undue burden on authors when they need to modify these rules to make things easier for implementors
17:25:16 <emilio> RESOLVED: Make conditionText readonly
17:25:49 <emilio> topic: feature detection for descriptors
17:26:22 <emilio> TabAtkins: seems reasonable to ask for this given we can do it for properties
17:26:35 <emilio> ... as @rules grow you might want to be able to test for given descriptors
17:26:46 <emilio> ... there's a suggestion that we add a new @supports query to test for descriptors
17:26:52 <lea> github: https://github.com/w3c/csswg-drafts/issues/2463
17:26:58 <castastrophe> castastrophe has joined #css
17:27:03 <emilio> ... I'd describe the two that I think we should add
17:27:15 <emilio> ... and lea has other ideas
17:27:36 <emilio> ... I think we should test for general @-rule support
17:28:03 <emilio> ... so "can you identify this rule at all"
17:28:24 <emilio> ... the other one should be a more complex one for testing for a whole @rule
17:28:27 <emilio> q+
17:28:33 <TabAtkins> @supports (@rule) {...}
17:28:46 <TabAtkins> and @supports (@rule { desc: value; }) {...}
17:28:57 <bradk> bradk has joined #css
17:29:09 <fantasai> TabAtkins was summarizing https://github.com/w3c/csswg-drafts/issues/2463#issuecomment-1015709662 right?
17:29:14 <TabAtkins> yes
17:29:38 <emilio> lea: I think the only additional thing I proposed is that we shouldn't have to add random descriptors to see if the browser supports particular descriptors or what not
17:30:02 <emilio> ... so test for support for e.g. @property or so
17:30:08 <chris> q+
17:30:22 <TabAtkins> emilio: Regarding testing the whole rule
17:30:23 <oriol> q+
17:30:32 <Rossen_> ack emilio
17:30:32 <TabAtkins> emilio: It's a bit weird, because we don't track parse errors, we just drop
17:30:41 <TabAtkins> emilio: We could od that potentially, but it goes against th eprinciple
17:30:48 <TabAtkins> q+
17:30:57 <dbaron> Present+
17:30:59 <TabAtkins> emilio: I think it would be nicer to do somethign else, but not sure what else could be
17:31:03 <TabAtkins> emilio: Don't have a generic idea for it
17:31:21 <TabAtkins> emilio: Like would great for `font-face-descriptor(desc: value)` but then you'd need it for each
17:31:27 <TabAtkins> emilio: Just scares me if it gets out of sync
17:31:51 <emilio> chris: wanted to check where we are in nested at rules
17:32:13 <Rossen_> ack chris
17:32:16 <fantasai> emilio: Another related concern, some rules are related
17:32:22 <fantasai> emilio: so if you parse an at-rule in an @supports block ...
17:32:28 <fantasai> emilio: should we consider position in the style sheet?
17:32:36 <Rossen_> ack oriol
17:32:36 <emilio> ack oriol
17:32:48 <emilio> oriol: it seems strange to me the including-the-whole-at-rule
17:32:59 <emilio> ... because parens would accept a weird set of syntax
17:33:08 <emilio> ... and this seems a bit inconsistent / confusing to authors to me
17:33:17 <TabAtkins> (I'm fine with an `at-rule()` function, fwiw.)
17:33:18 <emilio> ... because they might want to test for style rules
17:33:30 <emilio> ... but we're not supporting that, so I'd prefer another function
17:33:46 <emilio> ... or an option for testing general rules that could be an at-rule() or general rule
17:34:06 <emilio> ... but mixing some but not all rules, and also property-declarations in parens would be a strange mix
17:34:08 <Rossen_> ack TabAtkins
17:34:36 <emilio> TabAtkins: emilio's point about the whole rule testing is a very reasonable point and I don't want to do this if it requires special cases
17:34:48 <emilio> ... I'd like to instrument the existing parser if possible
17:35:13 <fantasai> emilio: Even with instrumentation, it can still get out of sync
17:35:16 <plh> plh has joined #css
17:35:20 <fantasai> emilio: e.g. someone forgets to propagate the error
17:35:38 <fantasai> emilio: so even if set just a boolean that indicates parser error
17:35:43 <fantasai> emilio: if don't set it at the right time, is a problem
17:35:50 <fantasai> emilio: It wouldn't be a whole new parser, just concerned about sync
17:36:16 <emilio> TabAtkins: connected to that, there's chris' question about nesting
17:36:49 <emilio> ... if you have per-at-rule descriptor function then you don't get nested at-rules for free
17:36:56 <emilio> ... the other question was about context
17:37:10 <emilio> ... I'd say we should specify what the parsing context is for this
17:37:37 <emilio> ... which would be the generic top-level stylesheet context, so @import would fail
17:37:45 <bradk> bradk has joined #css
17:37:53 <emilio> ... and re oriol's point I'm totally fine with `at-rule()` or something if you think it's less fair
17:38:14 <oriol> Yeah it think that's better
17:38:23 <Rossen_> ack dbaron
17:38:30 <emilio> dbaron: I think when I wrote the @supports proposal the way I had envisioned extending them is that we'd add new functions for other points where CSS drops things
17:39:01 <emilio> ... so at the point where the CSS parser says "oh, that is invalid so we drop it as a unit", that seems sensible to add a function for
17:39:42 <emilio> ... and I think it's a bit weird to put a whole rule inside @supports
17:39:53 <TabAtkins> q+
17:39:59 <emilio> ... that said I think TabAtkins' argument about nesting is interesting, because the approach I was thinking of at the time doesn't allow you to test for such things
17:40:09 <emilio> ... so I have mixed feelings about it
17:40:10 <Rossen_> ack fantasai
17:41:28 <emilio> fantasai: regarding the TabAtkins' generic top-level context I think that'd be confusing to authors, I think it'd be more understandable and useful to authors if we allowed both that or anything that's in the prelude, so that e.g. @import would count as supported
17:41:40 <emilio> ... I think it'd be less confusing to authors
17:42:05 <emilio> ... and I can see use cases for doing that if you want to do something conditional in whether some extended at-import syntax is supported
17:42:45 <emilio> ... I also wanted to say about dbaron's comment that it would be better to have the nested syntax rather than having many functions
17:43:05 <emilio> ... I'd prefer parenthesis rather than a function, I think it'd be a little bit cleaner and easier to type
17:43:06 <emilio> q+
17:43:11 <TabAtkins> @supports at-rule(@foo) {...} and @supports at-rule(@foo, desc: value) {...}
17:43:17 <bradk> bradk has joined #css
17:43:23 <emilio> ack TabAtkins
17:43:26 <Rossen_> ack TabAtkins
17:43:59 <emilio> TabAtkins: thanks dbaron for all that context. If we follow those premises we also avoid emilio's concerns. In that context perhaps we could do something like what I typed above in the chat
17:44:12 <emilio> ... it doesn't address nesting right now but we can extend it if needed
17:44:15 <fantasai> s/many functions/many custom functions per at-rule/
17:44:46 <emilio> ... we also don't and probably won't have many at-rules that are inconsistently nested
17:44:55 <faceless> Surely @supports (@import) should always fail, as @import must be the first rule? So if you precede it with @supports, it's not valid?
17:45:04 <miriam> q+
17:45:24 <fantasai> faceless, I don't think @supports queries should be sensitive to position
17:45:25 <Rossen_> ack emilio
17:45:33 <lea> faceless: is there a use case for @supports(@import)? Literally every browser supports @import, no?
17:45:38 <fantasai> emilio: @supports(@import) { } and then not put an @import inside
17:45:43 <TabAtkins> Not as a positive test, as a negative test.
17:46:05 <fantasai> TabAtkins: My proposal is not parsing, just is this at-rule in your list of recognize at-rules
17:46:24 <fantasai> emilio: fantasai it might be useful to test e.g. @supports(@import "" layer) or something
17:46:34 <fantasai> emilio: though for layer you could check to @layer
17:47:04 <fantasai> emilio: I think having a generic at-rule() function is better than having function per at-rule
17:47:13 <fantasai> TabAtkins: The downside is it wouldn't allow testing the prelude of an at-rule
17:47:28 <Rossen_> ack miriam
17:47:37 <emilio> miriam: prelude seem important for several things like layers and container
17:47:37 <fantasai> miriam: That was my question, because preludes seem important for many things, such as @layer and @container
17:47:46 <emilio> ... so it seems odd to leave it
17:48:05 <emilio> fantasai: I see that at-rule() as an improvement to having a function per at-rule
17:48:19 <emilio> ... but I don't see how that is better than just dropping the whole css syntax
17:48:31 <TabAtkins> If we wanted to add it, could have the form `at-rule(@foo prelude stuff)`; when there's >1 token there we test full prelude parsing
17:48:36 <emilio> ... it'd cover handling the prelude / descriptors / nested at-rules / etc
17:48:48 <emilio> ... so I don't understand why we'd go for the function rather than the proposal that was on the issue
17:48:51 <bradk> bradk has joined #css
17:48:59 <emilio> TabAtkins: emilio and dbaron explained why that wasn't great
17:49:20 <emilio> ... you'd need to detect whether there's a parse error somewhere in a rule needs intrumenting the parser
17:49:38 <emilio> ... whether testing whether something is dropped entirely or not is easy and can be done with no possibility of missing things
17:50:06 <Rossen_> q?
17:50:13 <Rossen_> ack fantasai
17:50:18 <emilio> ... because we definitely drop things that are invalid and is detectable, but detecting whether an inner descriptor failed to parse inside an at-rule requires special-casing
17:50:28 <emilio> Rossen: does that answer your question elika?
17:50:30 <emilio> fantasai: yes
17:50:37 <TabAtkins> @supports at-rule(@foo) {...} and @supports at-rule(@foo, desc: value) {...}
17:51:00 <emilio> TabAtkins: proposal is having the at-rule function with two syntax variants: `at-rule(@keyword)` and `at-rule(@keyword, descriptor)`
17:51:22 <emilio> fantasai: not against that but I have a question about how do we extend to the prelude
17:51:53 <emilio> TabAtkins: posted that up as well, we could have it drop the whole prelude in there or something
17:51:59 <emilio> fantasai: but prelude might include commas
17:52:10 <emilio> ... if you want something not in the prelude you're going to need a semi-colon
17:52:10 <lea> what about descriptor values? at-rule(@keyword, descriptor, value)?
17:52:39 <emilio> TabAtkins: alright let's use semi-colons
17:53:01 <fantasai> emilio: Meant to write descriptor:value
17:53:29 <emilio> lea: would there be a way to test for @rule <name> or so?
17:53:40 <emilio> TabAtkins: that's the prelude extension we were discussing above
17:53:40 <TabAtkins> at-rule(@keyword; desc:value)
17:54:00 <emilio> dbaron: so to clarify you wouldn't extend it to put the whole at-rule inside right?
17:54:26 <emilio> TabAtkins: right, or we just drop it and if we drop descriptors inside then it'd test true
17:54:46 <emilio> ... I think we should resolve on the keyword and descriptor variants and we can extend to support the whole prelude
17:55:18 <emilio> RESOLVED: Add an `at-rule` function with syntax `at-rule(@keyword)` or `at-rule(@keyword; descriptor: value)`
17:55:52 <emilio> topic: Make box-shadow a shorthand
17:55:55 <emilio> github: https://github.com/w3c/csswg-drafts/issues/4431
17:56:30 <emilio> TabAtkins: we've discussed about this in the past
17:56:46 <emilio> ... people want to animate one bit of a shadow, like increasing the spread etc
17:57:10 <lea> +q to express support
17:57:19 <emilio> ... you can always use custom props and so on and it seems so straight-forward that I think we could try
17:57:25 <TabAtkins> https://github.com/w3c/csswg-drafts/issues/4431#issuecomment-790113613
17:57:30 <emilio> ... sebastian proposed a grammar (link above)
17:57:41 <smfr> q+
17:57:50 <emilio> TabAtkins: (describes linked proposal)
17:58:18 <bradk> bradk has joined #css
17:58:28 <emilio> lea: I want to express support, this is a very common thing. It's one of the first examples I use for custom props
17:58:33 <emilio> ... is there an inset prop?
17:58:40 <emilio> TabAtkins: yeah
17:58:42 <fantasai> https://github.com/w3c/csswg-drafts/issues/4431#issuecomment-790113613
17:58:47 <emilio> lea: can we do it for text-shadow too?
17:58:49 <Rossen_> ack lea
17:58:49 <Zakim> lea, you wanted to express support
17:58:51 <emilio> TabAtkins: yeah, also in the proposal
17:58:58 <Rossen_> ack dbaron
17:59:15 <emilio> dbaron: I guess one of my reactions is that the stuff that background does is one of the most complicated parts of implementing value computations on CSS
17:59:41 <emilio> ... the code for dealing with that was a significant part of the old parser
17:59:58 <emilio> TabAtkins: for this there is one controlling property
18:00:06 <emilio> dbaron: true for backgrounds as well (for background-image)
18:00:34 <emilio> ... and you need to keep the whole list because you might inherit it somewhere where it matters
18:00:52 <Rossen_> q?
18:00:59 <emilio> TabAtkins: isn't this a common pattern like animation?
18:01:04 <emilio> dbaron: yeah, but it's special code every time
18:01:22 <emilio> smfr: should box-shadow-offset be further broken down into x/y offsets?
18:01:29 <bradk> bradk has joined #css
18:01:30 <emilio> TabAtkins: [meh reaction]
18:01:36 <emilio> q+
18:01:38 <emilio> ack smfr
18:01:40 <emilio> ack fantasai
18:01:40 <Zakim> fantasai, you wanted to mention that -position needs renaming 'cuz it's not a <position>
18:01:42 <Rossen_> ack fantasai
18:01:44 <Rossen_> ack emilio
18:01:59 <fantasai> emilio: Regarding what dbaron said, not just about parsing complexity but also efficiency
18:02:07 <fantasai> emilio: you need to store 5 different arrays rather than one
18:02:09 <delan> present-
18:02:13 <fantasai> emilio: so it's also a bit more inefficient
18:02:16 <lea> fantasai: box-shadow-offset perhaps?
18:02:21 <fantasai> emilio: maybe OK if we consider these to be relatively uncommon
18:02:45 <fantasai> emilio: The parsing complexity is real. Background is the worst by far, but need to check also transitions/animations. It's not super amazing
18:03:35 <fantasai> TabAtkins: Question is, is linked list-valued properties something we want to add generally, or not
18:03:36 <emilio> TabAtkins: the main q is whether adding more list-valued shorthands is ok, and if it's not we should not do it consistently
18:03:50 <emilio> dbaron: I wouldn't say never do them but it's more expensive than you might thing
18:04:21 <emilio> TabAtkins: curious, is the opinion different depending on "there's one length-controlling property vs. shortest wins"
18:04:30 <emilio> dbaron: I don't think it makes a huge difference
18:04:42 <emilio> ... only if you truncate computed values perhaps
18:04:46 <emilio> TabAtkins: that seems fine
18:05:00 <emilio> Rossen: let's follow-up in the issue
18:05:16 <emilio> topic: end
18:05:46 <Rossen_> Zakim, end meeting
18:05:46 <Zakim> As of this point the attendees have been vmpstr, alisonmaher, miriam, delan, jfkthame, TabAtkins, oriol, dbaron, Morgan, jensimmons, futhark, emilio, smfr, dholbert, faceless,
18:05:49 <Zakim> ... plinss, Rossen_, lea, rachelandrew, TYLin, bradk, tantek
18:05:49 <Zakim> RRSAgent, please draft minutes v2
18:05:49 <RRSAgent> I have made the request to generate https://www.w3.org/2022/01/19-css-minutes.html Zakim
18:05:51 <Zakim> I am happy to have been of service, Rossen_; please remember to excuse RRSAgent.  Goodbye
18:05:55 <Zakim> Zakim has left #css
18:06:16 <emilio> Yeah, thanks for all the scribing help over the second hour fantasai and TabAtkins :-)
18:06:23 <futhark> futhark has left #css
18:50:23 <hober> hober has joined #css
19:41:11 <CSSWG_LogBot> CSSWG_LogBot has joined #css
20:00:44 <zcorpan> zcorpan has joined #css
20:02:07 <zcorpan> The css editors drafts are down again
20:41:15 <astearns> plinss: ^
20:41:59 <astearns> (or maybe it’s already fixed, zcorpan?)
20:43:38 <zcorpan> astearns: seems like they are up again, yep. thanks!
22:26:30 <vit> vit has joined #css
22:47:13 <astearns> Are you running a 'how to read and contribute to specs' thing, zcorpan? We’re getting a bunch of (useful) one-word edit PRs today
22:47:59 <zcorpan> astearns: yes :)
22:58:06 <plh> plh has joined #css